Jessie Kennedy Rob Gales, Robert Kukla Converting an Existing Taxonomic Data Resource to Employ an Ontology and LSIDS Jessie Kennedy Rob Gales, Robert Kukla

Introduction Data sharing is fundamental to biodiversity and taxonomic data applications, Previous attempts to facilitate sharing have had limited success lack of take up of data exchange standards now slowly happening due to the TDWG standards initiative the absence of a common terminology or vocabulary for use in taxonomic data the lack of reference database systems for serving authoritative data Proposed new technologies a Core Ontology for taxonomic data to model the biodiversity domain. Adoption of Life Science Identifiers (LSIDs) by the TDWG GUID group for uniquely identifying taxonomic data objects, e.g specimens, names, concepts, etc. LSIDs can make use of an Ontology to define the data to be returned Need a mechanism for migrating existing data to the new technologies explore the issues in using LSIDs and RDF according to an Ontology.

Re-using LSIDs Using LSIDs per se will not address the issue of data sharing Repositories must reuse LSIDs to cross reference data within and outwith their own repository. It is important that we use the same LSID to refer to the same entity If multiple LSIDs exist for the same entity we would be required to decide whether or not two LSIDs were really the same thing. We would be in a similar situation as we are today, for example, trying to decide if two taxonomic names are really the same. Generating LSIDs for any self contained data set is a fairly trivial task Appointing LSIDs to existing data from an authoritative repository to re-use them is more challenging.

Project Overview Imagining the future Assume have authority providers for certain data Publications, names etc e.g. IPNI, ZOObank, IF, Pubbank… Want to Convert Existing Data repository Relational database the Hexacorallians of the World Represent existing data as RDF triples Use LSIDs to uniquely identify entities in data according to a domain ontology which extends TDGW core ontology Use LSIDs to cross reference between the data in the repository Some LSIDs re-used from external sources Some LSIDs generated locally Owned data Development of a tool to aid the process of converting internal database keys to LSIDs aid users in appointing the appropriate LSID from some external LSID authority.

Creating Domain Ontology Draft Core Ontology Core and BDI ontology Classes and optional relationships between classes Extend to Domain Ontology Domain classes inherit from the core classes Extended with additional classes Re-use existing ontologies where possible Specify additional literal properties Where necessary Straightforward for developer For Hexacorallia data Creating RDF triples Manual mapping of relational data to RDF triples according to OWL specification Used wasabi mapping extensions & custom code for generation

Simulate Authority Providers Hexacorallian Database Specimen Triple Store Publication Triple Store Concept Triple Name Map + AutoLSID Person Simulated Authority Data providers e . g IPNI / Zoobank , Pubbank Museum _ specimens Test Data set Generate LSID and RDF instances according to classes in the ontology appropriate to each “authority”

Convert Existing Provider Convert Existing Thematic Data Provider to use existing LSIDs and ontology Original data repository RDF Data to be updated with LSIDs from “authority” providers Linker Tool Hexacorallia Thematic Provider Map to ontology Hexacorallia Thematic LSID Observation subset Triple Store LSID Match with linking tool Match + ->LSID Match + ->LSID Match + ->LSID Match + ->LSID Match + ->LSID Store Authority ( simulated ) Name Person Specimen Concept Publication Observation LSID Resolution Triple Triple Triple Triple Triple Triple Store Store Store Store Store Services

WASABI Service Request Dispatcher Linking…. WASABI Service Request Dispatcher LSID SPARQL OAI Linker authoritative (“source”) provider & linker local (“target”) provider Linker Client Hexacorallia Thematic Triple Store Person Triple Store

Configure Provider for Update Name the local repository Select class to be linked

WASABI Service Request Dispatcher Linking…. WASABI Service Request Dispatcher LSID SPARQL OAI Linker authoritative (“source”) provider & linker local (“target”) provider Linker Client Hexacorallia Thematic Triple Store Person Triple Store

Name authority provider with linking service Configure the linker Select class to link on Name authority provider with linking service

WASABI Service Request Dispatcher Linking…. WASABI Service Request Dispatcher LSID SPARQL OAI Linker authoritative (“source”) provider & linker local (“target”) provider Linker Client Hexacorallia Thematic Triple Store Person Triple Store

Request Annotations

Linking Service… Communication between linking service and linking client RDF Handler takes RDF model’s in a POST request. If data is sufficient in size, it is cached and a thread spawned to link and maintain status, which is fetched through the polling mechanism. Contains URI’s of classes that may be linked by the service. Contains status information and any suggestions that have been made since last poll.

Linking Service Determines properties for matching Return suggestions to the client Weight possible matches Examines the ontology based on the classes the linking service or application has been configured with to determine any other classes that may be linked upon (super classes) and properties that have been defined on those classes. Determines properties that have been defined on submitted instances that have a range of one of the classes identified by the bootstrapping process by further examination of the ontology. Will download and cache additional ontologies if necessary. Each step of the linking pipeline is executed for each resource in the RDF model submitted

Confirm/Skip Annotations Suggested match Person to find LSID for

Confirm/Skip Annotations Person to find LSID for Choice of possible persons with LSIDs

Research Questions How effective is the draft ontology for representing existing data sources? Can suitable extensions be easily defined? Straight forward for developer Need independent verification… What are the issues for an existing data provider to convert their data to using the ontology and LSIDs? Replace or annotate existing data If, for example, I replace an author with a person LSID what I get when I resolve a person won’t likely be what I would have had when I had the data for an author. Dependencies between LSID’able objects If you link via a taxon name LSID – the resolved name should have embedded an LSID for a publication – so there shouldn’t be any need (in principal) to match publications for names What about authorities that issues LSIDs but don’t map to other authorities e.g. name providers not mapping to either publication or specimen providers and don’t want to!

Research Questions… What support would a linking tool need to provide end users? How would users want to process this data How much automation? E.g. above a certain confidence level Would his be trusted? Order of matching E.g. match all instances of persons at once Match of persons by publication? Other Issues… Performance of existing linking tool approach Lots of data passing going on Need better batch or one at a time Finding authorities that provide linking services How do you find out about authorities with linking services? How do you know which ones to use?

Acknowledgements TDWG/Gordon Betty Moore Foundation