Sounds like a good idea, but I’m not sure I agree with this.

Putting in a hard coded GUID type (LSID) into the name of an element does not sound wise. It restricts the use of that element too much.

The issue here is that linked data technologies cannot automatically resolve a URN (basic http get). So it may be better to include all URNs in this idea, eg

hasScientificName = string form

hasScientificNameID = http resolvable URI

hasScientificNameURN = LSID or other URN

This also then relies on any consuming technology to “know” what a specific URN type is and how to resolve it, but I suppose it is really systems that are LSID aware that tend to have this issue in the first place, so this would cover this specific area of concern …

So, I suppose I am agreeing with this approach, and like Gregor stated this sounds like a better way than “hacking” with URNs to make them http URLs.

Kevin

From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content-bounces@lists.tdwg.org] On Behalf Of Peter DeVries
Sent: Monday, 4 October 2010 6:55 a.m.
To: tdwg-content@lists.tdwg.org
Subject: [tdwg-content] Idea for Discussion, Differentiating between "type's" of identifiers

I have been thinking about the following pattern. In part after looking at the GBIF vocabulary.

I am not sure if it is even a good idea but might be worth some discussion.

For those fields that have both a string and "ID" form maybe the following pattern might be useful

hasScientificName = string form

hasScientificNameURI = Resolvable LOD compliant identifier

hasScientificNameLSID = LSID identifier which could be resolvable once you add the "http:proxy" etc.

This allows all three forms to be included if desired, it also provides a hint as to how the field should be interpreted or resolved.

One group could also provide a mapping service so that each record does not need to include all three forms, but would allow systems

to find the matching LSID for a given URI or vs. versa.

My concern was that it would be difficult to infer how a scientificNameID should be interpreted by other systems.

Is this an LSD, is it a URI, is it a UUID etc. ?

This impacts the structure of the RDF.

* Note that the actual identifiers might not be correct, the example below is more about the form of the RDF

* For instance, I don't think it is probably correct to see the COL LSID as just a namestring

* Also in this example the GNI name does not exactly match the string name

<dwc:hasScientificName>Puma concolor (Linnaeus 1771)</dwc:hasScientificName>

<dwc:hasScientificNameURI rdf:resource="http://gni.globalnames.org/name_strings/6c3dc35f-d901-5cc5-b9c8-ad241069b9f8"/>

<dwc:hasScientificNameLSID rdf:resource="urn:lsid:catalogueoflife.org:taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010"/>

Some system may choke on the LSID form assuming that it uses a standard resolution mechanism

So it might be best to use this form

<dwc:hasScientificNameLSID>urn:lsid:catalogueoflife.org:taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010</dwc:hasScientificNameLSID>

- Pete

----------------------------------------------------------------
Pete DeVries
Department of Entomology
University of Wisconsin - Madison
445 Russell Laboratories
1630 Linden Drive
Madison, WI 53706
TaxonConcept Knowledge Base / GeoSpecies Knowledge Base
About the GeoSpecies Knowledge Base
------------------------------------------------------------