%META:TOPICINFO{author="RicardoPereira" date="1182540295" format="1.1" reprev="1.14" version="1.14"}% ---++ LSID Resolver for Taxon Names (IPNI) *Coordinator(s):* Roger Hyam, Sally Hinchcliffe *Participants:* Nicky Nicolson See the other taxon name LSID resolver prototype: LSIDResolverForTaxonNamesIF ---- ---+++ Description This group will develop a prototype LSID resolver for taxon names. The prototype will be developed by nomenclators using IPNI database and an RDF version of TCS-Names. ---- ---+++ Technical Information * *URL for prototype user interface:* * *LSID authority(ies):* ipni.org * *LSID namespace(s):* names (note all lowercase, authors may be added later) * *Hardware platform:* Dell PowerEdge 2650 Server - Dual Intel Xeon Processor 2.8 GHz, 6GB ECC DDR memory, additional Xeon 2.8 GHz processor, 73 GB SCSI ULTRA320 (10,000 rpm) hard drive, PERC 3/DC dual channel RAID card, CD-ROM, AC redundant power option, 2 X 2GB HBA QLA2340F/C * *Server platform:* Linux Fedora Core 3 (Heidelberg), Tomcat 4.1.27, Java 1.4.2_07 * *LSID Software stack used:* custom java * *RDF/OWL ontology used for metadata:* Roger's RDFSchema (Roger is there a link for this?) * *Approximate number of LSIDs stored:* 1.5 million * *Other resources:* * *Sample LSIDs:* The examples here correspond to the sample RDF file circulated to the mailing list. Between them they cover all levels of names (from infraspecifics to families) and the full complexity of the sort of data that IPNI should be able to serve With versions: * urn:lsid:ipni.org:names:30000959-2:1.1.2.1 * urn:lsid:ipni.org:names:312219-2:1.2 * urn:lsid:ipni.org:names:1786-1:1.1.2.1.1.1 * urn:lsid:ipni.org:names:60435733-2:1.1.2.1 * urn:lsid:ipni.org:names:70029497-1:1.1 * urn:lsid:ipni.org:names:907328-1:1.1.4.2.2.1 * urn:lsid:ipni.org:names:1002492-1:1.1.2.2 * urn:lsid:ipni.org:names:199571-2:1.2 * urn:lsid:ipni.org:names:265591-2:1.3.2.1 * urn:lsid:ipni.org:names:60433970-2:1.2 (If you've got Firefox and the launchpad plugin for it these will work) Without versions: * urn:lsid:ipni.org:names:30000959-2 * urn:lsid:ipni.org:names:312219-2 * urn:lsid:ipni.org:names:1786-1 * urn:lsid:ipni.org:names:60435733-2 * urn:lsid:ipni.org:names:70029497-1 * urn:lsid:ipni.org:names:907328-1 * urn:lsid:ipni.org:names:1002492-1 * urn:lsid:ipni.org:names:199571-2 * urn:lsid:ipni.org:names:265591-2 * urn:lsid:ipni.org:names:60433970-2 (For IE users. This will automatically retrieve the most recent version of the metadata) ---- ---+++ Roadmap, Milestones, Timeline (Enter one task per line with estimated time for completion. Check tasks when completed, but leave all entries for logging purposes) Example: * Apr/06 - Map IPNI onto latest version of TCS (done) * Apr/06 - internal IPNI work to enable development (done) * May/06 - translate IPNI data into RDF format (done) * May/06 - set up beta LSID resolution service serving RDF metadata * May/06 - if time, set up LSID resolution service for authors as well * June/06 - report initial findings to GUID workshop ---- ---+++ Discussion, Implementation Issues Current _tentative_ format for the lsid: urn:lsid:ipni.org:names:ipni-id[:version-number] NB The Index Fungorum LSID had an uppercase N for names and we were going to go for that but it looked odd so we stuck with lowercase throughout. From what I understand, they should not really be case sensitive. Any reason to go with 'Names' rather than 'names' (or v.v.) that anyone can see? Open Questions: Versioning - we do version everything we do in IPNI so adding the version number is not a problem. Index Fungorum have put names into the data and everything else into the metadata. For ipni, we can only do this if we version because our names themselves may change due to scanning errors. The versioning relates to changes in the whole record (including edits which may not make any changes to the data or even to the metadata) - it could be that the expectation is that the version number will only increment if the data itself changes ... (Another problem with versions seems to be that Launchpad chokes on them...) Another issue on versioning: using Roger's TCS-RDF format, there are times when we refer to other IPNI records. In those situations I have left the version out of the linking LSID - my reasoning being that what these links are stating is that 'X has basionym Y' where Y is still the basionym irrespective of what version the record is. Alternatively we can leave everything in the meta data and leave versioning out Authors - IPNI also contains the TDWG standard for abbreviations of botanical authors. These can be served and accessed in isolation so it makes sense to have an LSID resolution service for those. The lsid format for those would be urn:lsid:ipni.org:authors:ipni-id[:version-number] Again, nothing is immutable although the abbreviation itself is only changed very occasionally. So either the data will consist of the abbreviation and we'll version, or it will all be in the metadata. Presumably we could use a lot of FOAF vocabulary for describing authors? At the moment the RDF format that Roger worked out (link?) does not have any way of dividing up multiple authors in a team so that they can be explicitly linked to IPNI authors (when known) via one of these LSIDs. I don't know enough about RDF to know how to do this ... Rod Page's conformance tester doesn't currently support http redirects, however a modified version of the tester installed locally is fine - NB This is now fixed dc:modified and dc:created are both null at the moment - we are working on this At the moment, around 100,000 basionyms will not be resolved due to problems with the data which we are working around. In general ALL ipni data should come with a health warning - just because we don't include links to a basionym, corrected name, type specimen or typification doesn't mean there isn't one - any idea how to add these health warnings to some metadata somewhere? ---- ---+++ Lessons Learned, Conclusions, Recommendations be careful what you promise to do in meetings ... ---- ---+++++ Categories CategoryWorkingGroup CategoryPrototypingWG