[tdwg-content] Idea for Discussion, Differentiating between "type's" of identifiers

[Kevin Richards]

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 at lists.tdwg.org [mailto:tdwg-content-bounces at lists.tdwg.org] On Behalf Of Peter DeVries
Sent: Monday, 4 October 2010 6:55 a.m.
To: tdwg-content at 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<http://www.taxonconcept.org/> / GeoSpecies Knowledge Base<http://lod.geospecies.org/>
About the GeoSpecies Knowledge Base<http://about.geospecies.org/>
------------------------------------------------------------

________________________________
Please consider the environment before printing this email
Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails.
The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-content/attachments/20101006/501b5ca7/attachment.html 
-------------- next part --------------
_______________________________________________
tdwg-content mailing list
tdwg-content at lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-content