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

[Martin Senger]

Mark,
   Many thanks for the explanation.

> v.v. your suggested changes, I think I addressed most of them in the 
> version of the RFC that I announced; if you recall, I gave you a preview 
> of the proposals, and you commented on that preview, so I made those 
> modifications before making the public RFC announcement.
>
   No doubts about it, yes you did. But getData() were of the few not
addressed and they are very impotant for me and perhaps for others (see
more below).

> v.v. what is returned by a getData call on an LSID?  This is currently 
> still an open issue.  The RFC describes (and is titled) how to retrieve 
> metadata about MOBY entities.
>
   Well, there are two RFCs (1913 and 1914) and they both are related to
LSIDs, so it is perhaps wise to discuss them both, or to merge them
together, before we start voting on any of them.

> What is returned by a getData call can be addressed in another RFC(s)
> if anyone can think of a useful behaviour in the case of object,
> namespace, servicetype, and serviceinstance LSID's (collectively or
> respectively).
>
   I definitely think about a useful behaviour (we discussed in with Ediie
already in summer in Malaga). And the behaviour is very important - can
make the real and immediate impact on the moby use, so I would like to see
it on the table soon, whatever RFC issue to use it for.
   Here is what we spoke about with Eddit (slightly updated by the
development of Dashboard):
   Practically all general moby clients need to have access to all data
types (and perhaps also to all service instances). This is a consequence
of the moby design, and I do not argue that. Examples are: Taverna, Ahab
(I guess), Moses, Moby Graphs. (Anti-example is , I think, gbrowse that
works differently.) Because of that, these clients rapidly move to RDF
resources because that way they get all information faster. But still not
fast enough.
   That's why I started to use local cache in Moses/Dasboard and in few
other clients. The local cache needs, however, ability to be updated and
synchronize with its moby registry. At the moment, it is possible to
recognize completely new entries (and download them), or deleted entries
(and remove them). But without re-loading the whole ontology it is not
possible to recognize that a moby entity is of a newer version (such that
somebody deregistered a service and registered it again slighly
changed).
   But we have LSIDs for all moby entities already! So I would like to use
it. Actually, I do not need to use getData(), but I need to have version
in the LSIDs. But once you start to add a version there, you almost
automatically imply what should be returned by getData() - because you
need to know what represents a version. So I think that version should be
assigned whenever a moby entity of the same name (and authority, etc.) is
registered. I do not ask to keep all versions (simply the old LSIDs will
not be resolvable if somebody asked for it - and its metadata may point to
its latest version).
   Having versions in LSIDs can make a real impact on all clients using
cache - and they can significantly help users. I can imagine Taverna
starting like a breezy for biomoby. In jMoby, we have already software
doing cacheing, and we can easily improve it to take versions into
account.
   I also plan (in February) to reease for windows users a "package"
(using commercial softawre InstallAnywhere) with some of jMoby software
(especially Dashboard with a simple client for service invocation) and a
snapshot of a moby registry. So normal users (not developers, and not
Taverna users) will have finally one-stop to take everything - and having
advanced caching there (advanced = using versions) would be a perfect.

   Martin

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