[MOBY-l] Suzi + Alan = Solution

[Jason E. Stewart]

"Mark Wilkinson" <mwilkinson at gene.pbi.nrc.ca> writes:

> Suzanna Lewis wrote:
> 
> > 1. id and idtype (an additional attribute)
> > 2. id is structured (idtype:id) like (sp:P12345 or GO:1111)
> > 3. id stands alone and the application sends it scattershot
> >      to everything and sees what happens.

I believe that we need to advocate an ID naming convention. I would
advise using what I3C is proposing for the LSID: Life Science
Identifier, a sub-category of LOID: Location Independent Object
Identifier being promoted by the grid-computing folks.

The core of an LSID is:

urn:loid:lsid:<authority>:<namespace>:<objectID>:<security>

<authority>: the name of the organization that has defined the object
<namespace>: one or more statements that constrain the context of the
             object
<objectID>:  an alphanumeric sequence that *uniquely* defines the
             object within the context of the authority and namespace
<security>:  an optional cryptographic identity (RSA public key)

Now this already looks a lot like what we're talking about:

* authority - we were using this as where the data came from, but in
  the identifier case, it means who controls the namespace. Examples:
  i3c.org, ncbi.nih.nlm.gov, ebi.ac.uk.

* namespace - exactly what we have been discussing. Examples:
  GenBank/GI, GenBank/Accession, EMBL/ID, EMBL/AC, EBI/ArrayDesign

* objectID - this seems clear.

* security - seems that a lot of people care about this. It's optional
  so we wouldn't have to use it.

All we've done in MOBY is to break the pieces of the identifier into
separate XML attributes.

> I think what I'll do is the following:
> 
> a.  Service registration will have an optional 'namespace(s)' attribute
> (optinal because not all services will care what namespace they are being
> sent... e.g. a Blast service only cares about the sequence, not the ID of
> that sequence)
> b.  When searching for a service you may provide the namespace for the ID
> that you have in your hand if it is relevant.
> c.  If you don't have the namespace in your hand you get back all services
> that use that object-type, regardless of namespace
> d.  If a Service has not registered a namespace, then the Service is
> **obligated** to ensure that it checks/validates the namespace before it
> attempts to use the object it has received, if this is relevant to that
> service (to address Alan's 1/15 Million issue)

This looks fine by me.
jas.