[DAS2] approval and maintenance of DAS/2 URI namespaces

[Garret Wilson]

Hi, Steve! Thanks for the reply.

The issue I raise is not resolvability---whether I can use an HTTP GET 
to retrieve some bytes at the location identified by the URI is a 
separate issue.

Likewise the issue is not opacity---a genome assembly URI of 
<http://biodas.or/cheesesandwich> would work just fine if we all agreed 
to use it.

The issue I raise is solely that of URI namespace ownership and 
management. Let me give an example. Why don't we simply use the NCBI 
identifier "B36.1" to identify the latest Homo sapiens genome assembly, 
instead of inventing URIs to do the same thing? The answer is that 
"B36.1" has no managed namespace, so that anyone could use the 
identifier "B36.1" to identify anything---the flavor of a milkshake, for 
instance. Using URIs prevents clashes by dividing up the identifier 
space into namespaces, each managed by whoever is responsible for that 
namespace (based upon DNS managed by IANA).

If someone who doesn't own a namespace (e.g. DAS2) starts reaching over 
into somebody else's namespace (e.g. NCBI) and starts using that 
namespace to create identifiers (e.g. 
<http://www.ncbi.nlm.hin.gov/genome/...>), then the namespace benefit of 
URIs has been negated. In fact, if the URIs are opaque and unresolvable, 
removing the benefit of namespace management means that URIs now have no 
benefit that I can think of over bare strings as IDs. That is my issue 
and concern.

If the NCBI would come on board and start publishing URIs in its 
namespace to identify its genome assemblies (or even to officially 
ratify the URIs DAS2 has come up with), that would be ideal. If this 
doesn't happen, I'd recommend switching to URIs in a namespace DAS2 
manages (producing e.g. <http://biodas.org/genome/H_sapiens/ncbi:B36.1/> 
or whatever.)

Garret

Steve Chervitz wrote:
> Hi Garret,
>
> As mentioned on the GlobalSeqIDs page:
>
> "The URLs do not need to be resolvable. At this point they are abstract
> identifiers."
>
> So they just happen to use ncbi, flybase, wormbase, etc. servers. In one
> sense, it doesn't matter what they are so long as all DAS servers that
> provide data for these assemblies consistently use them.
>
> To my knowledge, none of these organizations know that we are using their
> URI namespace in this way (except maybe for wormbase, which Lincoln -- who
> came up with these IDs -- works with). Is this a weakness? Perhaps. It's
> more a sign of the fact that most organizations are not yet clued into DAS.
>
> This issue harkens back to the URL-vs-URN-as-URI debate and whether URIs
> should be opaque, for example:
> http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity
>
> DAS has been designed with RESTful principles, so the abstractness
> requirement of the global seq IDs may seem unexpected.
>
> I can see some advantages of using the biodas.org namespace for these
> identifiers. The DAS maintainers would then be in control of managing any
> potential resolvability requirements.
>
> But given that we've already published these global seq IDs, I don't know
> the best route to change them should we decide to do so. If we published
> biodas.org-based URIs as synonyms to the current IDs, existing DAS/2 servers
> and clients (of which there aren't many yet) would need to be updated as
> well, to know that http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B33/ is
> equivalent to http://biodas.org/genome/H_sapiens/B33/, for example.
>
> Anyone else have thoughs/suggestions?
>
> Steve
>
>   
>> From: Garret Wilson <garret at globalmentor.com>
>> Organization: GlobalMentor, Inc.
>> Date: Fri, 29 Feb 2008 10:31:12 -0800
>> To: <das2 at lists.open-bio.org>
>> Subject: [DAS2] approval and maintenance of DAS/2 URI namespaces
>>
>> I read the "list of global identifiers based on community consensus" at:
>>
>> http://www.biodas.org/wiki/GlobalSeqIDs
>>
>> It's great the DAS/2 is using URIs for global identification. For
>> example, chromosome 1 for the B36.1 human genome assembly is identified
>> by the URI:
>>
>> http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B36.1/dna/chr1
>>
>> I'm unclear, however, regarding NCBI knowledge, participation, and
>> maintenance of these URIs. The system of uniform resource identifiers
>> prevents name clashes by delegating to the IANA-governed domain-name
>> system, so that whoever owns a particular domain-based namespace can
>> manage the URIs within that namespace.
>>
>> If DAS/2 were to use, for example, the http://www.biodas.org/genome/
>> namespace to manage all genome assembly URIs, I would have no cause for
>> concern. DAS/2 is instead using several namespaces managed by other
>> parties. I hope the response is that the NCBI is fully aware that its
>> URI namespace is being used as authoritative genome assembly URIs and
>> has either committed to maintaining that namespace or has delegated
>> maintenance of the http://www.ncbi.nlm.nih.gov/genome/ namespace to DAS.
>> (If the latter is true, it is unclear which organization would receive
>> such a delegation of maintenance responsibility---the Open
>> Bioinformatics Foundation? The BioTeam?)
>>
>> Thanks for any clarifications---this question is raised solely out of a
>> desire for long-term standards that can be use consistently by the
>> community.
>>
>> Garret
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>     
>
>
> ------------------------------------------------------------
>
> This transmission is intended for the sole use of the individual
> and entity to whom it is addressed, and may contain information
> that is privileged, confidential and exempt from disclosure under
> applicable law. You are hereby notified that any use,
> dissemination, distribution or duplication of this transmission by
> someone other than the intended addressee or its designated agent
> is strictly prohibited. If you have received this transmission in
> error, please notify the sender immediately by reply to this
> transmission and delete it from your computer. Thank You.
> Affymetrix, Inc.
>