Jonathan Rees wrote:
Thanks. I guess I thought it was obvious, but nothing seems to be in
this territory. I added
7. likelihood of adoption by uncommitted HCLS members [added 8/25]
8. ease of adoption [added 8/25]
Some specific questions to consider:
1. What effort is required for a data provider to support a scheme?
2. How much effort is required for a tool provider to support a scheme?
3. What requirements does a scheme impose (e.g. some appear to require that
identifiers be assigned to immutable resources, may not be practical).
About the http://purl.org/commons/ URIs, I think it would be wrong to
interpret their non-adoption as a sign of community resistance. I have
felt it would be a conflict of interest to promote them much in advance
of HCLS recommendations on the subject, so it's possible that if few
others are using them it's only because they haven't been recommended.
The purl.org/commons system was a unilateral Science Commons experiment
that was needed for the Banff demo, and the intent was always to review
the design before asking anyone else to adopt it. That is just what
we're doing now. If it looks like those URIs will work for HCLS, then
we'll say so in the recommendations note. If they need to be relocated
or redesigned, that's fine too. Better to do that now than after they're
widely deployed.
I suspect this entire discussion will be a lot more productive if we focus
on what is the most suitable scheme for a project such as the HCLS resolver
(or perhaps also other specific projects), than if we try to determine by
logical argument which of the schemes is the best of them all, in general.
Then later people can infer from the fact that scheme x was chosen for
project a for certain reasons, project b may also be better of with x.
Perhaps some general recommendations will crystallize, too, who knows...
Regarding the observation that no one outside of the project appears to
have picked up the HCLS identifiers: Here are my own reasons for not using
them in UniProt so far (despite the fact that I recognize that there is a
big need for someone to provide URIs for databases without usable URIs).
1. Given a PURL with "uniprot" and "P00750", it can't be rewritten to
http://beta.uniprot.org/uniprot/P00750.rdf, simply because the current
software can only append to but not interpolate into the URL templates!
Shouldn't be a big issue, technically, but this is a show-stopper for me.
2. The one-PURL-per-representation approach results in more URIs floating
around than I'd be willing to deal with (and I question the usefulness of
representation-specific URLs, for resources that already have such URLs).
3. If you enter a URL in the browser, people (including non-technical
people) have to get something useful (see e.g. DOI system), not something
that looks like an error page (which would also further encourage people to
ignore/bypass the PURLs and use the URLs directly for linking).