[MOBY-l] thinking about provision info and authoritative service providers

[Phillip Lord]

>>>>> "Mark" == Mark Wilkinson <mwilkinson at gene.pbi.nrc.ca> writes:

  Mark> Martin Senger wrote:

  >> The question is what the service providers will do with different
  >> versions of their services.

  Mark> currently, they simply change the database without telling
  Mark> you... for the most part.  I rarely see any indication of the
  Mark> "version" of a database in the CGI interfaces.  In fact, I
  Mark> suspect that many of the databases are simply "live" - that
  Mark> they are constantly being updated and modified, and that there
  Mark> is no such thing as a database "version" (Lukas, is this the
  Mark> case for TAIR?  Chris, is this the case for Flybase? or do you
  Mark> actually have database releases with corresponding version
  Mark> numbers?)


The question here is whether it is possible, or desirable, to offer
specific defined metadata methods with each service. If the service
does not wish to provide this metadata, then, of course, this is their
choice, and there is remarkably little that moby, or anyone else can
do about it. 

But make the assumption that people want to provide versioning
metadata, then can we support them doing this in a standardised
way? This should be possible. I suspect that webdav, for instance, has
a standardised way of doing this. Anyone know for sure?

I believe, for instance, that the GO database people are considering
putting versioning metadata into their database. At the moment, you
can only find out what version of the GO database you have by looking
at the dump files you installed. If you have lost them, you are in
trouble. It would be nice if there were a uniform mechanism for
accessing this information with moby. 


  >> If they provide simply several different services (for example on
  >> top of several versions of GenBank) then all of them should be
  >> registered as separated services by Moby central - with
  >> preference to have the version number in their descriptions.

  Mark> I doubt that this will ever be the case for most services.  It
  Mark> is unlikely that e.g. Genbank will keep archives of the entire
  Mark> database for every release in order to allow services to be
  Mark> run on archived data...

Well I am not convinced that this is true. It's certainly the case
that I've often wanted to look over archival versions, and from a
repeatability point of view, this would be a sensible thing to
want. If this desire of mine is shared with enough other people, then
genbank might eventually wish to provide it.

The obvious problem is the amount of space it would take up. But again
I am not convinced of this. I've certainly seen one claim which
suggested that version information for swissprot for example, could be
provided for all old versions in something like 1/10 of the size used
to store the latest version of swissprot. This works if you diff
swissprot, and, of course, because of the rate of growth of
swissprot. I'm afraid that I can remember who said this, although I
can find out if anyone is interested. 




  >> Or have you in mind some concrete use cases where putting the
  >> version info into the Moby envelope can work?

  Mark> [...]Something has to be sent back to the end-user telling
  Mark> them what version of the data was used to generate their
  Mark> result object. Putting the database version number somewhere
  Mark> in the result object seems to be not only desirable, but
  Mark> necessary!

Perhaps this is a good way in which moby could define additional
methods for each service. Putting the version number into the envelope
would not take up much room. But then you might also want to extend
this with, for instance, information about authority, or perhaps all
the dublin core metadata, and perhaps versions of the tools which have
produced the data (say you are blasting over swissprot...there are two
version numbers to consider). And so on. 

Of course, its a moot question whether you want to get involved in all
of this. If you look at the Moby as a transport layer, then organised
metadata is something that moby can provide the transport for, without
providing the exact mechanism for. 

Cheers

Phil