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:hasScientificNamePuma 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:hasScientificNameLSIDurn: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 Basehttp://www.taxonconcept.org/ / GeoSpecies Knowledge Basehttp://lod.geospecies.org/ About the GeoSpecies Knowledge Basehttp://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
_______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content