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

[Martin Senger]

> The reason it is not allowed is that service instances use the LSID of
> their input/output objects as the primary key in the database
>
   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).

   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. This seems (to me, as a non-db-expert)
like a usual database maintainance task.

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

> 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.

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger at gmail.com
   skype: martinsenger