Re: feasibility; purl.org/commons

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).

Received on Monday, 27 August 2007 14:12:01 UTC