Provide collectionID as http: or uri:

[GoogleCodeExporter]

Should the CollectionID from the biodiversity collections index use the 
resolvable http://biocol.or/urn:lsid:biocol.org or the raw 
urn:lsid:biocol.org:col form of the identifier? 

The rdf document that biocol delivers for a collection includes an owl:sameAs 
linking the two.  For example in: 
http://biocol.org/collection/rdf/id/15406

<tc:Collection rdf:about="urn:lsid:biocol.org:col:15406">
<owl:sameAs rdf:resource="http://biocol.org/urn:lsid:biocol.org:col:15406"/>

Original issue reported on code.google.com by mole@morris.net on 9 Jun 2011 at 5:19

• Blocking: institutionID #24, datasetName & datasetID #37

[GoogleCodeExporter]

I don't have a strong opinion about this one. Personally I would choose the 
most useful one.

Original comment by peter.de...@gmail.com on 9 Jun 2011 at 8:40

[GoogleCodeExporter]

To quote page 9 of the TDWG GUID applicability statement: 

"By themselves, LSIDs do not meet the requirements of Linked Data because they 
are not HTTP URIs. Standard Linked Data clients will not be able to handle 
them. One solution to this problem is to represent LSIDs as HTTP URIs."

"For example, the bioguid.info Web site provides LSID resolution proxy 
services. Appending the LSID “urn:lsid:ipni.org:names:20012728-1:1.1” to 
“http://bioguid.info/” yields the HTTP URI 
http://bioguid.info/urn:lsid:ipni.org:names:20012728-1:1.1. That URI, when 
presented to a Web browser, produces an HTML document containing the metadata 
of the referenced name object."

This goes to recomendation 7 of the applicability statement, that GUIDs should 
be resolvable.  

Original comment by mole@morris.net on 9 Jun 2011 at 9:17

[GoogleCodeExporter]

John, you advised me to use unresolved identifiers for e.g. collectionID: 
urn:lsid:biocol.org:col:15406, not 
http://biocol.org/urn:lsid:biocol.org:col:15406. What is your reaction to 
Paul's comment, citing TDWG GUID applicability statement: 
http://code.google.com/p/applecore/issues/detail?id=28#c2 ?

Original comment by peter.de...@gmail.com on 12 Nov 2011 at 8:05

[GoogleCodeExporter]

Original comment by peter.de...@gmail.com on 12 Nov 2011 at 8:18

[GoogleCodeExporter]

Original comment by peter.de...@gmail.com on 12 Nov 2011 at 8:19

[GoogleCodeExporter]

The only problem I see with the http solution is that it is a huge management 
issue. What if http://bioguid.info/ goes away as an LSID resolution service? 
Or, what if another better one comes along? To me it seems easier to build out 
a resolvable guid from a guid than to create the guid as a resolvable one and 
have to continually manage it. But, usefulness was one of your criteria. So, as 
long as the recolution mechanism persists, the http guid is more useful.

Original comment by gtuco.bt...@gmail.com on 18 Nov 2011 at 7:10

[GoogleCodeExporter]

After evaluating the arguments pro and con, I've decided we should advise the 
use of non-resolved GUIDs.

1. It is easier to maintain: imagine having to go back to all data publishers 
asking them to update the resolution service of their GUIDs because it went 
away.
2. It is cleaner: if you as a aggregator (or a user for that matter) want to 
use another resolver, you don't have to parse out the resolution service first.
3. It's rather easy to add a resolution service, as the GUIDs are provided in 
single, specific terms: collectionID, institutionID, otherID

Original comment by peter.de...@gmail.com on 21 Nov 2011 at 2:21

• Changed state: Fixed