[MISC] Re: [MOBY] Re: [MOBY-l] Name Space

Wed Feb 11 23:49:13 UTC 2004

Yes... and no... the problem is that an LSID kinda sorta inferrs that
there is a resolver out there who can resolve it to data or metadata. 
Since I cannot force e.g. NCBI to set up a resolver, and neither can I
force LSID's with the ncbi.nlm.nih.gov authority to come to biomoby.org
for their resolution (since the resolver address is embedded in the
LSID), I cannot make valid LSID's in any namespace that I do not
control.  

This is irrelevant, of course, if we don't plan to resolve them... but
we already have various tools that DO resolve them, so we need to have
them resolvable... so we have to put them in our own namespace.

By using an LSID, I only promise that I will never change its meaning -
I neither promise that it will always be valid, nor that there will
never be another LSID with an identical meaning... so what we are doing
does not break the rules (though I agree it is unfortunate in the way it
is playing out)

M

On Wed, 2004-02-11 at 19:24, Boris Steipe wrote:

> Again: what would prevent you from constructing and using them "as if"? 
> I don't think the potential amount of migration would be larger 
> (probably smaller) than migrating say, all the moby LSIDs to whatever 
> their proper authority is once that authority starts using proper 
> LSIDS. Remember, you are supposed to commit to keeping LSIDs 
> permanently, for hundreds of years. Do you really want to do that ? On 
> the other hand I could not imagine that you would even *allow* e.g. a 
> biomoby.org:pubmed to diverge in its semantics from the NCBI one.
> 
> I would suggest not assigning biomoby.org LSIDs but simply and 
> pragmatically requiring an object to disambiguate its namespace by 
> providing an authority. Then everyone could create/maintain their own 
> namespaces - either semantically linking them to another provider's 
> definition through the domain name, or rolling their own. The nice 
> thing is that this would be forward compatible. Whether this tuple is 
> prefixed by nothing or by urn:lsid doesn't really make a difference, 
> does it ? And even if it did, it would make more sense to use 
> urn:biomoby_id:authority:ns    ...
> 
> To my mind, the neatest thing about the LSIDs is not their resolve to 
> maintain universal and permanent identifiers, but the elegant way of 
> piggybacking on the ICANN solution to creating unique namespaces.
> 
> Sense ?
> 
> 
> B.
> 
> (Or maybe I should start registering a batch of biomoby.org namespaces 
> as a potential source of future income... Hm.   ;-)
> 
> 
> > yes, that was the plan... and in effect it still *is* the plan.
> > However, I cannot assign LSID's arbitrarily to another authority (this
> > is something they must do on their own), so for the moment all 
> > namespace
> > identifiers are in the "biomoby.org" LSID authority, and thus we have 
> > to
> > be careful of collisions.
> >
> > Once LSID's become more widespread we will certainly stop using our own
> > LSID authority prefix and use the "genuine" one, as assigned by the 
> > true
> > naming authority, but until then... we're stuck.
> >
> > M
> >
> >
> > On Wed, 2004-02-11 at 17:37, Boris Steipe wrote:
> >> On Wednesday, Feb 11, 2004, at 16:18 Canada/Eastern, Vijay 
> >> Narayanasamy
> >> wrote:
> >>
> >>> Hi Mark,
> >>>
> >>> I want a NameSpace for Agricola.
> >>>
> >>> In the GO http://www.geneontology.org/doc/GO.xrf_abbs there are three
> >>> entries for Agricola.
> >>>
> >>> 'NAL', 'bib' and 'IND'
> >>>
> >>
> >> What happened to the idea of namespacing like in LSIDs i.e. making a
> >> namespace valid only in the context of its issuing authority and thus
> >> effectively using the (working, sort of) ICANN resolution mechanism to
> >> ensure that namespaces remain unique ?
> >>
> >> The LSID of the object that Vijay describes apparently would be:
> >> urn:lsid:agricola.cos.com:IND:84014403
> >>
> >> The huge advantage is that this distributes the task of maintaining
> >> namespaces to the data providers - no need to register with a central
> >> authority.
> >>
> >> Sure, LSIDs are meant to be permanent and not every provider supports
> >> them yet, but that does not prevent anyone from using the principle on
> >> accession numbers from elsewhere, even if the other authority has no
> >> mechanism to ensure uniqueness and permanence in place - it just
> >> wouldn't be a proper LSID yet, even if it would be structured like 
> >> one.
> >> But it would still serve the purpose at least as well as what's
> >> available already.
> >>
> >> I can't remember what the plan was, regarding that concept.
> >>
> >> Best regards,
> >>
> >>
> >> Boris
> >>
> >> ---
> >> Boris Steipe
> >> University of Toronto
> >> Program in Proteomics & Bioinformatics
> >> Departments of Biochemistry & Molecular and Medical Genetics
> >> http://biochemistry.utoronto.ca/steipe/
> >>
> >> _______________________________________________
> >> moby-l mailing list
> >> moby-l at biomoby.org
> >> http://biomoby.org/mailman/listinfo/moby-l
> > -- 
> > Mark Wilkinson <markw at illuminae.com>
> > Illuminae
> > _______________________________________________
> > moby-l mailing list
> > moby-l at biomoby.org
> > http://biomoby.org/mailman/listinfo/moby-l
> >
> 
> Best regards,
> 
> 
> Boris
> 
> ---
> Boris Steipe
> University of Toronto
> Program in Proteomics & Bioinformatics
> Departments of Biochemistry & Molecular and Medical Genetics
> http://biochemistry.utoronto.ca/steipe/
-- 
Mark Wilkinson <markw at illuminae.com>
Illuminae