[MOBY-dev] an ontology of LSID's for datatypes

[Mark Wilkinson]

Hi all, 

First, thank you for inviting me and other MOBYers to your hackathon -
it was one of the most successful events I have ever attended!  Good job
Brian, Michael, and all other event organizers, and well done to all
those bleary-eyed coders who went to the mattresses to get things done!

I've been mulling over the semantic difference between the MOBY
"namespace", and the LSID "namespace".  I think we agreed that, to
achieve the *meaning* of the MOBY triple will require three LSID's - one
defining the structure of the contained data (Class), one defining the
datatype (moby namespace), and the last defining the unique identifier
for the data (effectively, its LSID).

I would be willing (and moreover, I think it is critical for MOBY/LSID
integration) to be the authority for LSID's representing datatypes,
since we need to do this in MOBY anyway.  As I understand it, this
requires me to set up a metadata server, ja?

It wont get done right away, but if nobody objects to me taking on this
authority (please say so if you do!) then I will get to it as soon as I
learn how :-)

One of the aspects of our datatyping system is that it will be a 
hierarchical controlled vocabulary, though I suspect that it will be a
fairly shallow and broad hierarchy... in fact, the only parent/child
relationship that I have become aware of so far is with Genbank gi
numbers, which may represent either a nucleotide or an amino acid
sequence and will thus get two different LSID's for datatypes...  Is
there any "canned" way of representing parent/child relationships in
LSID metadata?

Anyway, let me know if this rubs any of you the wrong way.  If not, then
I think we have finally succeeded in integrating LSID's into MOBY!  And
not a moment too soon either!!

For MOBY-dev recipients:  MOBY Central is being coded to understand both
LSIDs and our more traditional human-readable CV names for Classes and
Namespaces.  It will determine on-the-fly what to do with an identifier
it is given.  This allows people to register services that operate on
objects entirely outside of the MOBY datatyping system, since they
simply register the LSID of the datatype that they accept as input - be
it MOBY or caBIO or whatever.  There is a consequence to this, however. 
MOBY Central needs to be re-coded to use something other than XML::DOM,
since XML::DOM does not properly deal with namespaces.  I think Jason
would encourage us to use XML::Xerces (in fact, I think that ended up
being our only option, right Jas?), so I will get on to that ASAP.  In
the meantime we should be okay since there aren't many other datatyping
systems...

Anyway, I think we finally got it right!!  hurrah!!

Cheers all!

Mark



-- 
=======================================================================
                                    |--==\
Mark Wilkinson, Ph.D.                \==-|       
Bioinformatics Consultant             \=/        0010010010100101110010
Illuminae Media                       /-\        
727 6th Ave. N.                      /-==|       0010100100111101010010
Saskatoon, SK, Canada               |==-/        
S7K 2S8                              \=/         0100100100010010010101
+1 (306) 373 3841                     /\         
markw at illuminae.com                  /=-\        1101001010100101010101
                                    |--==\
=======================================================================