Closed GoogleCodeExporter closed 9 years ago
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
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
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
Original comment by peter.de...@gmail.com
on 12 Nov 2011 at 8:18
Original comment by peter.de...@gmail.com
on 12 Nov 2011 at 8:19
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
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
Original issue reported on code.google.com by
mole@morris.net
on 9 Jun 2011 at 5:19