Re: [Tdwg-tag] Why we should not use LSID
Roger
I agree that PURLs are a perfectly good option for our GUID needs, and that they would probably be one of the easier technologies to get "working".
Like you I really had to think again to work out the benefits of LSIDs over PURLs, expecially considering the disadvantage you have mentioned.
Some of the benefits of LSIDs include: - clearly separate data and metadata services (as you have mentioned) - separation from domain names - as far as I understand, the PURL still requires domain name resolution of the actual ID url to obtain the resolution server address - this ties you to a particular url format - LSID assigning service can be managed by provider organisation ("ownership" of data and IDs is often high on a data provider's requirements list) - LSIDs provide a "standard" technology for resolving and serving up data objects - ie every provider will have the LSID authority services running on their server that will serve up data and metadata (+ other services if required) in the same way, for every provider - related to the previous point, a standard mechanism for third party annotations of LSIDs is provided with every LSID server implementation - same URN LSID can be used for resolution of http, ftp, soap and tcp protocols (unsure how PURLs handle this?) ...other cool stuff, I'm sure, that I cant think of right now - too late at night
Probably best to avoid LSIDs for RDF class identfiers etc, but do the semantic web tools you are talking about have no way of recognising different url resolution types - I'm wondering if you can "plug in" lsid resolution into these tools?
Kevin
Roger Hyam roger@tdwg.org 05/03/06 10:29 PM >>>
Hi Rod,
From the meeting report - which I am struggling to get back to - these two bullet points sum it up I think
· There are certain things for which LSIDs are not appropriate. It would be legal to use them for RDF resource identifiers for controlled vocabularies and XML Schema locations BUT we would have to extend existing software libraries to do this which is not desirable.
· *Recommendation:* LSIDs are not used for controlled vocabularies, ontologies or XML Schema locations. LSIDs should be used to refer to instances.
Basically it was felt that if we used LSIDs for things like rdfs:Class definitions then any library that went off to fetch the definitions automatically would have to be extended so that it understood LSID resolution. On the other hand it was felt that use of LSIDs for real resources (things we are actually describing like specimens and people) was fine. Once an ontology is loaded then it is all fine though so to an extent this may be a false problem.
We spent a long time talking about what is part of the ontology and what isn't and went round in circles (please lets not do it again). Basically class and property descriptions should be URL type URIs but instance URIs can be LSIDs. If you want to define the genus /Rhododendron/ as being an OWL DL class retrieved remotely then you should probably give it a URL. If you want to define it as a data item then use a LSID.
I think Gregor's worries (correct me if I am wrong Gregor) are that in SDD (possibly our whole domain) many things could be considered classes and properties. i.e. Things you want your reasoner to use in the reasoning rather than simply reason about. In this case it may be better to have URLs for everything.
There is a niggling doubt (in my mind) that we may come across 'cool' tools and libraries that assume that *all *resource URIs are URLs and that we would not be able to use them or would need to extend them if we use LSIDs. Imagine a semantic web browser where you click on a node and it fetches the associated resource to expand itself.
I do occasionally struggle to see the advantages of LSIDs as GUIDs over just conventions for use of URLs but these may be matters of personal faith. Another bullet point in the report says:
· *Recommendation: *GUIDs Group should issue a document clearly justifying adoption of GUID technology. The advantages need to be clearly explained.
I'll try and get this report out ASAP but it looks very similar to the wiki page here:
http://wiki.tdwg.org/twiki/bin/view/TAG/TagMeeting1ReportDraft
Obviously would be grateful for your thoughts.
Roger
Roderic Page wrote:
Dear Gregor,
For the benefit of those not at TAG 1, can you please explain why "LSIDs are not interoperable with semantic web technologies"?
Regards
Rod
On 2 May 2006, at 16:44, Gregor Hagedorn wrote:
Note that part of my concern about the use of concept when talking about classes/properties/data elements is that I more and more believe we will want to use ontology reasoners for uses other than software design, i.e. as part of what we currently consider data (taxon names, concepts, rank hierarchy, parts of organisms, properties of organisms, etc.). All these are ontological concepts, and efforts www.plantontology.org do use OWL to reason on them.
The SDD presentation (the one not held in EDI, attached) contained some examples how we might want to query our data - in ways that OWL-for-software- design seems not to cover - and which using LSIDs would even prevent.
Please discuss:
http://wiki.tdwg.org/twiki/bin/view/TAG/WhyWeShouldNotUseLSIDs
http://wiki.tdwg.org/twiki/bin/view/TAG/UsePURLsAsGUIDs
Gregor
Gregor Hagedorn (G.Hagedorn@bba.de) Institute for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Königin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: SDD-TAG1.ppt Date: 23 Apr 2006, 18:10 Size: 1056768 bytes. Type: Unknown <SDD-TAG1.ppt>_______________________________________________ Tdwg-tag mailing list Tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org
Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom
Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html
Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com
Send instant messages to your online friends http://uk.messenger.yahoo.com
Tdwg-tag mailing list Tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org
Two thoughts.
If we adopt PURLs (or, indeed, Handles, or DOIs, both of which have a proper management structure), we still need to sort out metadata, data, etc., which means essentially reinventing much of what we have for LSIDs. Personally, I've no particular stake in this (having taken a devil's advocate position at TDWG-GUID and argued for Handles, just for fun), but given we have stuff for LSIDs, I struggle to see why we should spend time reinventing this stuff.
I fail to see a logical reason for banning the use of LSIDs in ontologies. Let people chose what technology they think works best. If they want something that works right now, PURLs (or, indeed, URLs) work fine. If people want to use LSIDs, then let them. If existing software doesn't handle them, either (a) add support for it, (b) use a proxy server, (c) don't use LSIDs. I don't think we should decide what to so simply because other people's software doesn't support something that (some of us) think makes a lot of sense.
If you want to define the genus Rhododendron as being an OWL DL class retrieved remotely then you should probably give it a URL. If you want to define it as a data item then use a LSID.
Please God no. Why would the type of information I'm requesting influence the GUID protocol? This just strikes me as crazy.
I really think one should avoid making decisions based on technological expediency alone.
Regards
Rod
------------------------------------------------------------------------ ---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom
Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html
Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com
Ro Page wrote:
If we adopt PURLs (or, indeed, Handles, or DOIs, both of which have a proper management structure), we still need to sort out metadata, data, etc., which means essentially reinventing much of what we have for LSIDs. Personally, I've no particular stake in this (having taken a devil's advocate position at TDWG-GUID and argued for Handles, just for fun), but given we have stuff for LSIDs, I struggle to see why we should spend time reinventing this stuff.
I fail to see a logical reason for banning the use of LSIDs in ontologies. Let people chose what technology they think works best. If
No problem with this.
From an SDD standpoint I would argue to currently avoid using LSIDs for taxon
names or descriptive terms if you plan to use RDF/OWL based reasoning in the future, otherwise you may end up having to reissue (P)URL-based identifiers for all your objects, and provide translation services for data that use your LSID- based identifiers. I see no reason why people should not use LSIDs for specimens if they like.
However, on the contrary at the TAG-1 meeting I perceived exactly the opposite, that TDWG does intend to make recommendations. I proposed that we should expect people to even provide the same object under different GUID schemes or services (purl, lsids) but the (clearly justified) concern was that this would make the system much more complicated.
If you want to define the genus Rhododendron as being an OWL DL class retrieved remotely then you should probably give it a URL. If you want to define it as a data item then use a LSID.
Please God no. Why would the type of information I'm requesting influence the GUID protocol? This just strikes me as crazy.
I agree (although with the conclusion that a good recommendation is to avoid LSIDs for taxon names and concepts).
Gregor---------------------------------------------------------- Gregor Hagedorn (G.Hagedorn@bba.de) Institute for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Königin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203
participants (3)
-
Gregor Hagedorn -
Kevin Richards -
Roderic Page