February 2006 - tdwg-tag - lists.tdwg.org

Re: Task 9: LSID Resolver Namespaces (or should it be Authority Identifications)
by Kevin Richards 27 Feb '06

27 Feb '06

I believe this topic should cover both LSID namespaces and authority names. These are very related topics and the best practices for one greatly influences the best practices for the other, ie if you decide that it is best that authority names use sub-domains to a specific level, eg names.indexfungorum.org (not the best example I know but it illustrates the point), then less namespacing is required for the "namespace" part of the LSID. (All this assumes opacity - I see it as just "reccommendations" on how to divide your namespacing over the authority name and namespace parts of the LSID). Kevin >>> ricardo(a)TDWG.ORG 25/02/2006 6:11 a.m. >>> Donald Hobern wrote: > *_9. LSID Resolver Namespaces_** > (http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolverNamespaces) * > > > > This is a starting-point for discussion of best practices in using DNS > entries for LSID resolution services. > Donald, I believe that the definition of this task and its name do not match. I think it is a terminology problem. The part of the LSID that is related to DNS is the *authority identification*. The *namespace* isn't related to DNS. here's the LSID syntax to illustrate: urn:lsid:authority_identification:namespace:identifier:revision. So, this group will discuss authority ids or namespaces (or both)? Which should we fix, the page name or the description? I think I have already mixed this up in a previous post to Kevin Richards. Sorry about that. Regards, Ricardo ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Task 9: LSID Resolver Namespaces (or should it be Authority Identifications)
by Donald Hobern 26 Feb '06

26 Feb '06

Thanks, Kevin. I agree that this is very sensible, and I'll update the description on the wiki accordingly Donald --------------------------------------------------------------- Donald Hobern (dhobern(a)gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 --------------------------------------------------------------- _____ From: Taxonomic Databases Working Group GUID Project [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU] On Behalf Of Kevin Richards Sent: 26 February 2006 20:56 To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: Task 9: LSID Resolver Namespaces (or should it be Authority Identifications) I believe this topic should cover both LSID namespaces and authority names. These are very related topics and the best practices for one greatly influences the best practices for the other, ie if you decide that it is best that authority names use sub-domains to a specific level, eg names.indexfungorum.org (not the best example I know but it illustrates the point), then less namespacing is required for the "namespace" part of the LSID. (All this assumes opacity - I see it as just "reccommendations" on how to divide your namespacing over the authority name and namespace parts of the LSID). Kevin >>> ricardo(a)TDWG.ORG 25/02/2006 6:11 a.m. >>> Donald Hobern wrote: > *_9. LSID Resolver Namespaces_** > (http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolverNamespaces) * > > > > This is a starting-point for discussion of best practices in using DNS > entries for LSID resolution services. > Donald, I believe that the definition of this task and its name do not match. I think it is a terminology problem. The part of the LSID that is related to DNS is the *authority identification*. The *namespace* isn't related to DNS. here's the LSID syntax to illustrate: urn:lsid:authority_identification:namespace:identifier:revision. So, this group will discuss authority ids or namespaces (or both)? Which should we fix, the page name or the description? I think I have already mixed this up in a previous post to Kevin Richards. Sorry about that. Regards, Ricardo ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Test LSID resolver for TaxonConcepts
by Donald Hobern 24 Feb '06

24 Feb '06

The GBIF Secretariat now has a test LSID resolver running to access TaxonConcepts based on the data from the Catalogue of Life 2005 Annual Checklist. See http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolveForTaxonConceptsCoL for more information. This is based on a simple mapping of the data into TCS and then representing the information as rather simple RDF metadata. Thanks, Donald --------------------------------------------------------------- Donald Hobern (dhobern(a)gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 ---------------------------------------------------------------

1 0

Follow-on from GUID-1: Infrastructure Working Group
by Donald Hobern 24 Feb '06

24 Feb '06

During the GUID workshop in Durham, we held several break-out sessions to identify and start discussing key issues around the proposed use of LSIDs. Subsequently these have been grouped under two broad headings. One relates to prototyping activities (Prototyping Working Group). The other relates to consideration of best practices and long-term infrastructure requirements for our community as we adopt LSIDs as our GUID technology (Infrastructure Working Group). A wiki page has been established at: http://wiki.gbif.org/guidwiki/wikka.php?wakka=InfrastructureWorkingGroup This message is to invite contribution to and discussion of the various themes identified for the Infrastructure Working Group. I have started by adding some initial comments under two of the themes and would particularly ask for input on these. 1. LSID Minimal Standards (http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDMinimalStandards) This is an attempt to start defining a set of minimal standards which all LSID issuers should meet. The purpose is to establish baseline expectations of what an LSID implies, and to assist potential issuers with deciding whether they are in a position to issue, resolve and maintain LSIDs. 9. LSID Resolver Namespaces (http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolverNamespaces) This is a starting-point for discussion of best practices in using DNS entries for LSID resolution services. Please contribute to either of these discussions, and contact me if you are interested in helping to organise discussion around any of the other themes listed on the Infrastructure Working Group - I really hope not to have to start all of them myself. Thanks, Donald --------------------------------------------------------------- Donald Hobern (dhobern(a)gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 ---------------------------------------------------------------

1 0

Task 9: LSID Resolver Namespaces (or should it be Authority Identifications)
by Ricardo Scachetti Pereira 24 Feb '06

24 Feb '06

Donald Hobern wrote: > *_9. LSID Resolver Namespaces_** > (http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolverNamespaces) * > > > > This is a starting-point for discussion of best practices in using DNS > entries for LSID resolution services. > Donald, I believe that the definition of this task and its name do not match. I think it is a terminology problem. The part of the LSID that is related to DNS is the *authority identification*. The *namespace* isn't related to DNS. here's the LSID syntax to illustrate: urn:lsid:authority_identification:namespace:identifier:revision. So, this group will discuss authority ids or namespaces (or both)? Which should we fix, the page name or the description? I think I have already mixed this up in a previous post to Kevin Richards. Sorry about that. Regards, Ricardo

1 0

House Keeping
by Roger Hyam 23 Feb '06

23 Feb '06

I am maintaining a wiki page that charts what I believe we have agreed on and what I think we might discuss next. I link from this page to the list archive. http://www.tdwg.hyam.net/twiki/bin/view/TAG/TagDiscussionRoadMap Please send comments and additions to me or the list especially if you think: 1. I am saying we have agreed when we have not. 2. You want something to be discussed in the future but not just yet (so we can schedule it). You can of course edit the wiki yourself if you like. I hope that this page will act like a ratchet to keep us heading forward and prevent slipping back over old issues again and again as is common in many mailing list discussions! Thanks for your cooperation on this. Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

IndexFungorum LSID Wiki
by Kevin Richards 23 Feb '06

23 Feb '06

I have briefly updated the Wiki for the IndexFungorum LSID prototype at http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolverForTaxonNamesIF As I was filling in the specs, it made me think it would be good to have a "suggested" list of LSID namespaces that different LSID authorities could use if suitable. At present the IndexFungorum namespace is "Names" - which may not be ideal. This will differ however for central LSID authorities and distributed authorities. Eg if a central authority "guid.org" is setup the namespace "indexfungorum/names" may be suitable for taxon name objects [a link to a glossary would be helpful here to explain what I mean by a name object], but for the distributed authority "indexfungorum.org" then just "names" may do the job. Another alternative is to put the "distributed" authority in the authority name, eg "indexfungorum.guid.org" leaving it up to DNS to locate the authority, then leave the namespace simple, in this example "names", eg "urn:lsid:indexfungorum.guid.org:names:123456". Any thoughts? Kevin ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Primary Objects as XML Structures or OWL Classes
by Roger Hyam 22 Feb '06

22 Feb '06

Hi All, In a previous post I suggested definitions for Resolving, Searching and Querying from the point of view of the TAG. There has been a muted response which I take as meaning there aren't any strong objections to these definitions. We can come back to them later if need be. You can read the post here if you missed it: http://lists.tdwg.org/pipermail/tdwg-tag_lists.tdwg.org/2006-February/00000… I'd like to look at the implications of the first two definitions: 1. *Resolving.* This means to convert a pointer into a data object. Examples would be to resolve an LSID and get back either data or metadata or resolve a url and get back a web page in html. 2. *Searching.* This means to select a set of objects (or their proxies) on the basis of the values of their properties. The objects are predefined (implicitly part of the call) and we are simply looking for them. An example would be finding pages on Google. Both these definitions imply the existence of data 'Objects' or 'Structures' that are understood by the clients when they are received. The kinds of objects that jump to mind are Specimens, TaxonNames, TaxonConcepts, NaturalCollections, Collectors, Publications, People, Expeditions etc etc. A piece of client software should be able to know what to do with an object when it gets - how to display it to the user or map it to a db etc. My two leading questions are: 1. *Should there be commonality to all the objects?* If yes - what should it be? XML Schema location or OWL Class or something else? If no - then how should clients handle new objects dynamically - or shouldn't they be doing that kind of thing. 2. *Should we have multiple ways of representing the SAME objects?* e.g. Should there be only one way to encode a Specimen or should it be possible to have several encodings running in parallel. If there is only one way how do we handle upgrades (where we have to run two types of encoding together during the roll out of the new one) AND how do we reach consensus on the 'perfect' way of encoding each and every object in our domain? The answers I have for my leading questions are: 1. Yes - We should have some commonality between objects or it will be really difficult to write client code - but what that commonality is has to be decided. 2. Yes - The architecture has to handle multiple versions/ways of encoding any particular object type because any one version is not likely to be ideal for everyone forever. Are the two conclusions I come to here reasonable? Is this too high level and not making any sense? I'd be grateful for your thoughts on this, Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

4 6

Re: IndexFungorum LSID Wiki
by Ricardo Scachetti Pereira 22 Feb '06

22 Feb '06

Kevin, Thanks a lot for filling in the details for the Index Fungorum LSID resolver prototype. Interestingly enough, there is another GUID group (http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolverNamespaces - coordinated by Donald) which task is to come up with guidelines for selection of LSID namespaces. That group will untimately come up with the answers to your question. However, since they just got started, they don't have any guidelines for us yet. Actually, this thread is likely to provide that group with use cases and scenarios for them to work on. Anyway, in the absense of any namespace assignment guidelines, the LSID spec states that ids are supposed to be opaque and the namespace part is there just as a convenience feature for authorities to partition their internal databases. So, strictly speaking, we are not allowed to add any global semantics to the namespace. That means that is up to you (or IndexFungorum) to define what's in the namespace of the LSIDs you assign. That doesn't mean that we cannot come up with guidelines on how to best partition your internal database, though. But that's another story. Assuming that Index Fungorum has complete autonomy over Fungi names (I assume it has as a nomenclator), and that it has the required software development and system administration skills, I think that IF would most benefit from a completely distributed LSID assignment and resolution schema. This implies that: 1) The authority identifier (and thus the DNS record) should be owned and set up by IF (i.e. indexfungorum.org, lsidauthority.indexfungorum.org, and lsid.indexfungorum.org are good choices while guid.org and indexfungorum.guid.org are bad options). 2) It's up to IF to define its namespaces and no external client (or no one at all) should rely on their choices of namespaces. Any centralization in this case would yield in unnecessary delegation of tasks from IF to some external entities (whoever owns guid.org domain for example). However, the community MUST agree on the format of the metadata returned by any Taxon Names resolver. That's exactly what the TAG (TDWG Architecture Group) is doing now. Cheers, Ricardo Kevin Richards wrote: > I have briefly updated the Wiki for the IndexFungorum LSID prototype at > http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolverForTaxonNamesIF > > As I was filling in the specs, it made me think it would be good to > have a "suggested" list of LSID namespaces that different LSID > authorities could use if suitable. At present the IndexFungorum > namespace is "Names" - which may not be ideal. This will differ > however for central LSID authorities and distributed authorities. Eg > if a central authority "guid.org" is setup the namespace > "indexfungorum/names" may be suitable for taxon name objects [a link > to a glossary would be helpful here to explain what I mean by a name > object], but for the distributed authority "indexfungorum.org" then > just "names" may do the job. > > Another alternative is to put the "distributed" authority in the > authority name, eg "indexfungorum.guid.org" leaving it up to DNS to > locate the authority, then leave the namespace simple, in this > example "names", eg "urn:lsid:indexfungorum.guid.org:names:123456". > > Any thoughts? > > Kevin

1 0

An LSID Authority in < 20 lines of PHP?
by Roger Hyam 20 Feb '06

20 Feb '06

Hi All, Apologies for cross posting on this. The motivation for this message comes out of the TDWG-GUID Project but detailed discussion is probably more appropriate to the lsid-developer list so I am posting to both and ask you to keep techie responses to the developer list and TDWG specific responses to the TDWG-GUID list. I was looking at the LSID specification and thinking about how simply I could implement an LSID Authority that just supported the HTTP GET bindings. The results of this were about 20 or so lines of PHP code - so the answer is very simply indeed. This falls into the programming-for-fun category of development! The implications for the TDWG side of this is that there should really be no technical barrier to setting up an LSID Authority at all. It is only necessary to write some very simple web applications indeed. No more complex than simple web form processing code. This is something many data providers already have the ability to do. The caveat to this is that the developer community may find this is not a feasible approach....hence this post going to the developer list. Point your copy of Launchpad at: lsidres:urn:lsid:hyam.tdwg.gbif.org:apples:4399 (If this doesn't work then we are still having the DNS problems near you (they should be sorted soon). You could try lsidres:urn:lsid:biodiv.hyam.net:apples:4399 which will work slowly as Launchpad needs to time out on each call before calling the biodiv.hyam.net server directly. If you add the authority biodiv.hyam.net => http://biodiv.hyam.net/authority/ then it should rocket along.) You can read more about the Authority here: http://biodiv.hyam.net/authority/readme.html You can download all the code and docs here: http://biodiv.hyam.net/authority/authority.zip This is fun code to get people started so have fun playing ... All the best, Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0