[MOBY-l] MOBY namespaces and the GO xrefs

[Mark Wilkinson]

Hi all, 

This is a fairly broad cross-posting as the questions are directed at
various individuals in these three organizations:

Now that we have a ~stable MOBY API (touch wood) I'd like to "seed" the
MOBY Central registry with a set of standard "namespaces" (e.g. a
genbank GI number is a namespace, and a genbank Accession is another
namespace) before things get chaotic.  The GO has database xref
abbreviations that are already nicely defined, so clearly it would be a
good idea to take advantage of this resource:
http://www.geneontology.org/doc/GO.xrf_abbs

Q1)  GO friends - Is there a way to request inclusion of new xref
abbreviations into this list?  In MOBY, *every* piece of data will have
a namespace, so the list may blossom quickly...  

Q2)  Alternately, someone from MOBY could take on the responsibility of
curating this list with you/for you.  We are taking this issue quite
seriously as we plan to soon set up an LSID resolver for LSID's
representing namespaces/data-types.  Hopefully the resolver would
eventually become a resource useful to GO also, if we can find a way to
stay synchronized.  Under any circumstance, we want to work as closely
with you as possible, and if we can share some of the burden, that's
great :-)

Q3)  To the I3C people, do you see anything "structural" in these
abbreviations that would prevent them from being converted to LSID's in
the way we have been so far?  <background> In the three MOBY ontologies
we have both common names, and their respective LSID's; web services can
be discovered/called using either representation.  At present, an LSID
within the MOBY namespace is derived by simply taking the common name,
making it lower-case, and then prepending the string: 
urn:lsid:www.biomoby.org:moby[thingy]: </background>   I just want to be
sure that there are no invalid characters in these abbreviations that
will trip us up.  Nothing struck me as being unusual, but I'm not an
LSID expert...

Q4)  Before we start building services using these abbreviations, are
there any "issues" with this list that you are aware of that should be
addressed prior to us using them "In Anger"? ((c) M.A.  ;-) )  e.g. Have
they been of sufficient granularity, or do you know of some that need to
be subdivided?

Any advice/comment from any of the three groups is welcome!

Cheers all,

Mark


-- 
Mark Wilkinson <markw at illuminae.com>
Illuminae