May 2006 - tdwg-tag - lists.tdwg.org

Re: [Tdwg-tag] Why we should not use LSID
by "Döring, Markus" 05 May '06

05 May '06

Hello, please see my comments inline below. I will try to use PURLs not only in the purl.org sense, but also as a simple way of creating stable URLs through a centralized URL redirection. If you consider this I cant see relevant benefits of LSIDs that are not shared by PURLs. Considering the potential problems we might run into with any software framework (not only RDF) that includes resolving I am in strong favor of simple URLs. -- Markus -----Ursprüngliche Nachricht----- > Von: tdwg-tag-bounces(a)lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] Im Auftrag von Kevin Richards > Gesendet: Mittwoch, 3. Mai 2006 13:45 > An: tdwg-tag(a)lists.tdwg.org > Betreff: 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) MD: From what I've understood from the GUID group nearly only metadata is used though. So if we deal with metadata only then its not a big practical difference at least. > - 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 MD: We could easily setup a redirection service http://purl.gbif.net/AUTHORITY/whatever that redirects to whereever you want to keep your resolver. Just the authority URL part needs to be centrally managed. MD: This leads me to a questions about LSIDs which I never understood. LSID are bound to domain name resolution and their guarantee to be globally unique is heavily based on DNS. So to me a central body keeping track of LSID authorities is required to guarantee life long uniqueness of LSID URNs. If "bgbm.org" is owned by someone different that also wants to set up a LSID authority, how does he know there was one already under that domain? He could be reissuing the same URN (LSID) again. Thats exactly what people use as an argument against URLs, but its also true for LSIDs as far as I understand the technology. > - LSID assigning service can be managed by provider organisation ("ownership" of data and IDs is often high on a data provider's requirements list) MD: so can PURLs > - 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 MD: URLs are even more standard I would think. Take Apache and there you go. > - related to the previous point, a standard mechanism for third party annotations of LSIDs is provided with every LSID server implementation MD: Annotea (for RDF) uses simple HTTP. As Rod said pingbacks are a way to go as well (over http). And I am sure there are many other standards existing for URLs. > - 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 MD: true. but is that needed? > > 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? MD: that would surely be good. I have no experience with RDF frameworks, but everywhere I look I see URIs that are in fact URLs. > > Kevin > > > > >>> Roger Hyam <roger(a)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(a)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(a)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(a)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(a)lists.tdwg.org > > http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org > > > > > > > -- > > ------------------------------------- > Roger Hyam > Technical Architect > Taxonomic Databases Working Group > ------------------------------------- > http://www.tdwg.org > roger(a)tdwg.org > +44 1578 722782 > ------------------------------------- > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. > > The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. > > Landcare Research > http://www.landcareresearch.co.nz > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > _______________________________________________ > Tdwg-tag mailing list > Tdwg-tag(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org >

6 5

[Tdwg-guid] WG: CHRONOS, GNS LSID
by Robert Huber 05 May '06

05 May '06

Dear all, Below is Doug Fils answer to my questions on the CHRONOS LSID efforts.. I tried to send this to the old listserver.. thanks Ricardo for reminding us to use the new address! It seems as if LSIDs are (independently our efforts) on their way to become a de facto standard for such purposes? Well,another reason _not_ to think about switching to PURLs ;) All in all this sounds very interesting and it is another, promising way to bring the paleo/geo and bio data communities together.. Robert > > -----Ursprüngliche Nachricht----- > > Von: Douglas Fils [mailto:fils@iastate.edu] > > Gesendet: Donnerstag, 27. April 2006 16:43 > > An: Robert Huber > > Cc: TDGW Listserver; Cinzia Cervato > > Betreff: Re: CHRONOS, GNS LSID > > > > > > Robert et al. > > Wow.. people actually read those news items. :) If this is a way > > to get me to reply to your email of 4/13 Robert, it worked. ;) I do > > appreciate you sending me that info by the way and I am looking forward > > to increasing connections between CHRONOS and both Pangaea and S.net. > > Let me prefix the rest of this email by saying what I am going to talk > > about here is a joint effort with GNS Science New Zealand. > > > > Ok, let me just bullet out a few points here in case people are > > interested. I have been to a TDWG meeting or two (was at the > > Christchurch meeting). I very much enjoyed them. > > > > a) First, thanks for referencing me the URL: > > http://wiki.gbif.org/guidwiki/wikka.php?wakka=HomePage I have > looked it > > over and liked what I saw. I think I actually saw some of these > > presentations in Christchurch. > > > > b) CHRONOS is working with GNS and using UID's as an element of a > > different project. This project is the TSDF or Taxonomic Synonymy > > Definition Framework. This is an RDF (based on SKOS) file > that will be > > used to encode synonymy information for exchange between GNS > and CHRONOS > > (initially) and then also used internally as a means to pass synonymy > > information around to other searches and services (web services and > > ReST) inside CHRONOS. Beyond that we intend to use use some of the RDF > > tools from the MIT Simile effort for working with these files. > > > > We need the GUIDs in this effort to ensure that we are not > mixing up > > different taxa from different sites and also that we can consistently > > resolve individual taxa across multiple locations and create sets of > > synonymous (or explicitly not synonymous) taxa that remain valid. We > > also need to associate these with the author as different people may > > (will) have different ideas of what taxa are and are not synonymous. > > > > Obviously then we would begin to expand out use of these UID's into > > many other aspects of CHRONOS. In discussion with our developers we > > already see the windfall this would give us in our SOA environment and > > out to the various tools groups we are working with. > > > > c) This RDF format will be made public soon and I am talking about it > > at the Geoinformatics 2006 meeting May 10-12 in Reston Virginia. So > > obviously I have to get some stuff pulled together on that and out to > > the public here soon. We will place what we have on-line at CHRONOS at > > that time. If anyone here will be at that meeting I would be happy to > > meet with them. > > > > d) ok, back to UID's. Yes, we want to use UID's.... yes we > also like > > the LSID model and are basing our efforts off that. I would _love_ to > > leverage what we are both doing. I will look forward to hearing what > > occurred at the GUID-2 workshop. > > > > If anyone has any questions, please feel free to get in touch with me. > > > > take care > > doug > > > > > > > > > > Robert Huber wrote: > > > > >Dear all, > > > > > >I found this message on the CHRONOS news pages: > > > > > >'Taxonomic Synonymy efforts with GNS New Zealand': > > >CHRONOS is implementing URNs (Uniform Resource Names) of taxon names > > >as a means to connect multiple sources of taxonomic data. > > >Initial tests include Neptune, the Mesozoic Planktonic Foraminifera > > >Taxonomic Database, and FRED, the paleontological database of the > > >Geoscience and Nuclear Sciences in New Zealand. Modeled after the > > >Life Science Identifiers (LSID), taxonURNs are unique IDs. > > > > > >http://chronos.org:8080/chronosRSS/jsp/chronosRSS.jsp?mode=rss_2. > 0&url=55&id > >=chronos.rss > > > >I cc this message to Cinzia and Doug from CHRONOS.. hey, I hope you > >both are OK? It would be great if you could join the TDWG mailinglist > >and give us some more details on that effort.. > > > >best regards, > >Robert > > > > > >Dr. Robert Huber > >WDC-MARE / PANGAEA - www.pangaea.de, www.wdc-mare.org > >Stratigraphy.net - www.stratigraphy.net > >_____________________________________________ > >MARUM - Institute for Marine Environmental Sciences (location) > >University Bremen > >Leobener Strasse > >POP 330 440 > >28359 Bremen > >Phone ++49 421 218-65593, Fax ++49 421 218-65505 > >e-mail rhuber@@wdc-mare.org, robert.huber(a)stratigraphy.net > > > > >

1 0

[Tdwg-guid] Why we should not use LSID (from TDWG-TAG mailing list)
by Ricardo Scachetti Pereira 05 May '06

05 May '06

Folks, I wanted to let you know about a discussion regarding the use of PURLs as GUIDs that is happening at the TDWG Technical Architecture Group (TAG) mailing list. I am sending you this message because I believe that the GUID wiki and mailing list is the most appropriate forum to discuss the issue. The thread starts here: http://lists.tdwg.org/pipermail/tdwg-tag_lists.tdwg.org/2006-May/000135.html I have also moved the the original pages posted by Gregor Hagedorn on the TAG wiki to the GUID wiki. Links are below: http://wiki.gbif.org/guidwiki/wikka.php?wakka=WhyWeShouldNotUseLSIDs http://wiki.gbif.org/guidwiki/wikka.php?wakka=UsePURLsAsGUIDs Feel free to contribute to the discussion. Best regards, Ricardo

2 1

[Tdwg-guid] TDWG-GUID mailing list has moved
by Ricardo Scachetti Pereira 04 May '06

04 May '06

Dear Subscriber, I would like to inform (or remind) you that the TDWG-GUID mailing list has been moved from LSoft's Listserv to GNU Mailman Mailing List Manager. The new web addresses for our list are now: tdwg-guid(a)mailman.nhm.ku.edu (email address to post messages to the list) http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid (list information page) You don't need to take any action. Your subscription information has been moved to the new list. Regards, Ricardo

1 0

[tdwg-tapir] Schema modification: r524 - trunk/protocol
by tdwg-tapir＠lists.tdwg.org 04 May '06

04 May '06

Author: markus Date: 2006-05-04 18:17:16 +0200 (Thu, 04 May 2006) New Revision: 524 Modified: trunk/protocol/tapir.xsd Log: reintroduced the custom extension slot in metadata responses Modified: trunk/protocol/tapir.xsd =================================================================== --- trunk/protocol/tapir.xsd 2006-05-04 14:42:12 UTC (rev 523) +++ trunk/protocol/tapir.xsd 2006-05-04 16:17:16 UTC (rev 524) @@ -1473,6 +1473,7 @@ </xsd:sequence> </xsd:complexType> </xsd:element> + <xsd:element ref="custom"/> </xsd:sequence> <xsd:attribute ref="lang"/> </xsd:complexType> @@ -1553,6 +1554,7 @@ </xsd:element> <xsd:element name="contact" type="contactInformationType" maxOccurs="unbounded"/> <xsd:element name="geoLocation" type="geoLocationType" minOccurs="0"/> + <xsd:element ref="custom"/> </xsd:sequence> <xsd:attribute ref="lang"/> </xsd:complexType>

1 0

[tdwg-tapir] Schema modification: r523 - trunk/protocol
by tdwg-tapir＠lists.tdwg.org 04 May '06

04 May '06

Author: markus Date: 2006-05-04 16:42:12 +0200 (Thu, 04 May 2006) New Revision: 523 Modified: trunk/protocol/tapir.xsd Log: created 2x2 new simpleTypes for entityRoles and contactRoles. For each of them a simple type with an enumeration is created and another simple type that extends this list with a union of xsd:string, thus allowing any other string too. Modified: trunk/protocol/tapir.xsd =================================================================== --- trunk/protocol/tapir.xsd 2006-05-04 14:10:04 UTC (rev 522) +++ trunk/protocol/tapir.xsd 2006-05-04 14:42:12 UTC (rev 523) @@ -1485,7 +1485,7 @@ <xsd:element name="title" type="languageAwareElementType" minOccurs="0"/> <xsd:element name="email" type="xsd:string"/> <xsd:element name="phone" type="xsd:string" minOccurs="0"/> - <xsd:element name="role" type="xsd:string" maxOccurs="unbounded"> + <xsd:element name="role" type="contactRoleExtensionType" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation>Used to specify the roles of a contact, such as "data administrator", "system administrator", etc.</xsd:documentation> @@ -1494,6 +1494,24 @@ </xsd:sequence> <xsd:attribute ref="lang"/> </xsd:complexType> + <xsd:simpleType name="contactRoleType"> + <xsd:restriction base="xsd:string"> + <xsd:enumeration value="data administrator"/> + <xsd:enumeration value="system administrator"/> + </xsd:restriction> + </xsd:simpleType> + <xsd:simpleType name="contactRoleExtensionType"> + <xsd:union memberTypes="contactRoleType xsd:string"/> + </xsd:simpleType> + <xsd:simpleType name="entityRoleType"> + <xsd:restriction base="xsd:string"> + <xsd:enumeration value="data supplier"/> + <xsd:enumeration value="technical host"/> + </xsd:restriction> + </xsd:simpleType> + <xsd:simpleType name="entityRoleExtensionType"> + <xsd:union memberTypes="entityRoleType xsd:string"/> + </xsd:simpleType> <xsd:complexType name="entityInformationType"> <xsd:annotation> <xsd:documentation>Entity information.</xsd:documentation> @@ -1546,7 +1564,7 @@ <xsd:complexContent> <xsd:extension base="entityInformationType"> <xsd:sequence> - <xsd:element name="role" type="xsd:string" maxOccurs="unbounded"> + <xsd:element name="role" type="entityRoleExtensionType" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation>Used to specify the roles of a related entity, such as "data supplier", "technical host", etc.</xsd:documentation>

1 0

[tdwg-tapir] Schema modification: r522 - trunk/protocol
by tdwg-tapir＠lists.tdwg.org 04 May '06

04 May '06

Author: markus Date: 2006-05-04 16:10:04 +0200 (Thu, 04 May 2006) New Revision: 522 Modified: trunk/protocol/tapir.xsd Log: use xsd:time for indexingPreference startTime. Modified: trunk/protocol/tapir.xsd =================================================================== --- trunk/protocol/tapir.xsd 2006-05-02 11:36:41 UTC (rev 521) +++ trunk/protocol/tapir.xsd 2006-05-04 14:10:04 UTC (rev 522) @@ -1456,11 +1456,9 @@ <xsd:element name="lastUpdated" type="xsd:dateTime" minOccurs="0"/> <xsd:element name="indexingPreferences" minOccurs="0"> <xsd:complexType> - <xsd:sequence> - <xsd:element name="startTime" type="xsd:duration"/> - <xsd:element name="maxDuration" type="xsd:duration"/> - <xsd:element name="frequency" type="xsd:duration" minOccurs="0"/> - </xsd:sequence> + <xsd:attribute name="startTime" type="xsd:time"/> + <xsd:attribute name="maxDuration" type="xsd:duration"/> + <xsd:attribute name="frequency" type="xsd:duration" /> </xsd:complexType> </xsd:element> <xsd:element name="relatedEntities">

1 0

Why we should not use LSID
by Gregor Hagedorn 03 May '06

03 May '06

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(a)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

5 5

Re: [Tdwg-tag] Why we should not use LSID
by Kevin Richards 03 May '06

03 May '06

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(a)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(a)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(a)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(a)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(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org > > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 ------------------------------------- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Meaning of 'concept'
by Roger Hyam 03 May '06

03 May '06

Hi All, Gregor and I are having a discussion over what 'concept' means. Gregor said: Roger, I suggest, you replace unqualified "concept" with something that qualifies what kind of concept you mean. If I read concept I think of a taxon concept or descriptive concept (flower, color, blue, frequently) but not of the kind of concepts you mean (I would say "data elements" for these, but I leave it to you. This was the source of the major misunderstanding about Management system and data. Note that both taxon and descriptive concepts have and need ontology information, even if not expressed in RDF - so just saying "ontology concepts" would not be very clear I believe. I know TAPIR and BioCASE use concepts to mean element or attribute and believe DwC do as well. I thought I was on clear ground here in using it in the context of ontologies. What word other than 'concept' can I use to describe a thing in an ontology i.e. a class, property, attribute whatever. Any suggestions, Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

4 4