[MOBY-dev] [moby] Re: RFC #1914 - change & call for vote

Tue Jan 17 19:38:04 UTC 2006

Hi Martin,

So far I really like your idea for versioning of the LSIDs and a  
timestamp is fine. Basically I wouldn't care what exact version  
number I am working with. The only thing most of us will care about  
is whether the LSID is up to date. Major and minor version number  
increments are more something for a marketing department to make a  
difference in free updates and payed upgrades :). I do think you  
should write a small update for the RFC though. It's important we all  
know what exactly those new versioned LSIDs will look like. Will it  
be ...MyObject_timestamp, ...MyObject:timestamp, or .... and what is  
the format of your timestamp. It doesn't really matter which format  
it will be as long as we all know what it looks like. Therefore it  
should be written down somewhere and preferably documented on the  
BioMOBY website.

One thing I was wondering about is the following: If a service is  
registered, we specify the input and output. Lets say for example I  
register service A with as input a simple Object SomeObject_version1.  
Some time later somebody else decides to update SomeObject, maybe for  
something as simple as a typo in the description. The up-to-date  
version of SomeObject now becomes SomeObject_version2. What happens  
to my service? Do I have to reregister it with SomeObject_version2 as  
input? SomeObject_version1 is no longer "available", so my service is  
registered with an outdated => not LSID resolvable => invalid input ....

Another thing I was wondering about is relationships. What happens if  
I have SomeObject_v1 hasa AnotherObject_v1 and AnotherObject is  
updated? If this happens SomeObject has a child that is no longer  
LSID resolvable => no longer valid. I guess the parent will need to  
be updated too, or am I missing something? Currently the object  
ontology in BioMOBY Central is still rather flat, but when a lot of  
objects with a complex structures are registered, updating one object  
might result in updating half the registry, because of all the  
relationships....

Cheers,

Pi

On 14-Jan-2006, at 1:04 AM, Martin Senger wrote:

>> I was also thinking along these lines.  So long as our tooling never
>> *shows* the version number to the user (or at least, not unless  
>> they ask
>> for it), then it really doesn't matter how comlpex the version number
>> format is.  I don't know if adding a timestamp is any more complex  
>> than
>> incrementing a version number... but it might be more informative??
>>
>    Timestamp can be a number of elapsed second/millisecond from the
> beginning of an epoche. So it is a long integer - not that  
> different from
> a usual version number. Important is that it is always the same
> unless/until the entity is re-registered.
>    Incrementing a version number is more complex than timestamp  
> because in
> order to increment you need to know an old value (that will be
> incremented). With a timestamp you do not need to keep unregistered
> objects at all. You need just to add a new column "timestamp" and  
> fill it
> with the current time when an object is registered. And to add this
> "timestamp" field as version to the created LSID. That seems all  
> you need
> to do (but perhaps I am still missing some catch).
>
>> I see - so jMoby would not automatically know about any newly  
>> registered
>> objects unless you explicitly asked for a refresh of the entire RDF;
>>
>    (Almost) correct. jMoby (its caching mechanism) does not know  
> about any
> newly registered objects automatically, the user has to ask for update
> (the "user" can be, however, a cron job, or whatever). But for  
> refreshing,
> jMoby does not use RDF - but it asks for a list of entities using  
> normal
> API call (such as getServiceNames - or whatever the method is  
> called, I
> can't remember now). There is no such RDF document to give me "only" a
> list of object names (and I am not asking for that, the API is fine).
>
>> however you WOULD be guaranteed of always having the latest  
>> version of
>> whatever object you were working with, because as soon as you  
>> "selected"
>> it, that PARTICULAR object would be validated against the  
>> registry.  Is
>> that correct?
>>
>    Yes, it could be done this way. The "selection" can trigger the  
> update
> mechanism. But it does not - the users (of dashboard, for example)  
> have to
> click on a button 'update' if they feel that their cache is not
> up-to-date. This does not seem to be a problem in the real life.
>
>> Do you want to write up an addition to the RFC?
>>
>    Well, adding a version number to the LSIDs is not really a  
> change that
> needs an RFC I guess. It is just making current existing features  
> better -
> and without breaking existing software. I would suggest that you  
> just ask
> Eddie to add versioning and then you both can announce it as a  
> improved
> feature. I would really love it to have - and I can at once make  
> use of it
> in Dashboard (and slightly later, and with coordination with Eddie, in
> Taverna).
>
>> (we still don't know what you want to be returned by a getData call -
>> you are keeping us in suspense! ;-) )
>>
>    I said: I am stepping back a bit. Talk about getData() brought  
> me to
> versioning - and that's what I wish to have. Forget getData() for  
> now :-)
>    (Mainly because what I would return by getData() is identical to  
> what
> normal old-fashioned moby API calls do quite well now (such as
> retrieveObjectDefinition()) ).
>
>    Martin
>
> PS. TW, Mylah from IRRI is just finishing her mirroring scripts (to
> regularly update our local/testing GCP registry from the central  
> one) -
> and she would definitely welcome the versions as well - mirroring  
> is just
> another example (additional to my local caching usage) where LSIDs  
> with
> versions would be tremendously and immediately useful. M.
>
> -- 
> Martin Senger
>    email: martin.senger at gmail.com
>    skype: martinsenger
> consulting for:
>    International Rice Research Institute
>    Biometrics and Bioinformatics Unit
>    DAPO BOX 7777, Metro Manila
>    Philippines, phone: +63-2-580-5600 (ext.2324)
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-dev

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl