[MOBY-dev] [moby] Re: v.v. the Object Ontology curation

[Mark Wilkinson]

On Thu, 2006-07-06 at 17:56 +0100, Martin Senger wrote:

>    But why it is like that? 
> The simple name of a data type could be as
> good as its LSID - of course unless you consider the version in LSID. I
> think that the primary key could be either an LSID - but in such case the
> update of all connected entities must happen, or it should be a simple
> name (like DNASequence). Having it as it is now asks for troubles (as you
> have just described and witnessed).

The object Name could equally well be used as the primary key, you're
right.  The API does not allow editing of an object definition if that
object is being used by a service, or as a parent or hasa component of
another object, so effectively the LSID for an object should never
change in any case that affects service providers.  It would only change
(i.e. the object definition could only change) if no services were using
it.  As such, the object Name and the object LSID are equally "robust"
as identifiers in the database.


>    I am not that worried about this particular case of cleaning (okay:
> Dashboard's users, plese forget my reminder and use the button 'reload'
> and not 'update' :-)) but about that such situation can happen again. I am
> not a particular database person but I can imagine a script that will get
> as an input changed primary key and will go to other tables automatically
> and changed the references there.

That script could be written; however this kind of editing isn't allowed
in the API, so I've never taken the time to write it.


>  This seems (to me, as a non-db-expert)
> like a usual database maintainance task.

It is.  It's just that we don't touch the database itself often enough
to have written the kinds of support scripts we need for this detail of
editing.


>    Actually, it would be good if my service gets a new LSID just because
> some underlying data type - this service is using - changed.


I thought this would horrify you! :-)  The API does not allow this to
happen because if I re-define an object that you are using I may
(probably will) break your service.  Even if I notify you that the
definition has changed, and update the LSID of your service, it is still
a destructive thing to do because I can't automatically update your code
to compensate for this change (in fact, it may not be possible to
compensate for the change if the object has been dramatically modified).


> > I guess *technically*, since our LSIDs do not resolve by getData, only
> > by getMetadata, we haven't really broken the LSID specification by not
> > updating the version number in this case - we've broken it "in spirit",
> > but not "in practice".
> >
>    I am not sure about this conclusion. We do not resolve our LSID's using
> getData, that's true. But we do not do it because we already have an API
> for the same functionality (the API returning definitions from the
> registry). But still our LSID represents a "chunk of bytes" - and if this
> chunk (even though not resolvable by getData) changes, its LSID should be
> changed, as well.


I agree 100%... which is why I say we have broken the LSID spec "in
spirit" :-)  I'm certainly not saying that it is something to be proud
of... but in the absence of DB maintenance scripts, it is just not
practical (or should I say, it is more dangerous given how much I hate
touching the database by hand) to do "the right thing" this time.

M



-- 

--
Mark Wilkinson
Asst. Professor, Dept. of Medical Genetics
University of British Columbia
PI in Bioinformatics, iCAPTURE Centre
St. Paul's Hospital, Rm. 166, 1081 Burrard St.
Vancouver, BC, V6Z 1Y6
tel: 604 682 2344 x62129
fax: 604 806 9274

"For most of this century we have viewed communications as a conduit, 
       a pipe between physical locations on the planet. 
What's happened now is that the conduit has become so big and interesting 
      that communication has become more than a conduit, 
       it has become a destination in its own right..."

                Paul Saffo - Director, Institute for the Future