[MOBY-dev] Moby API/LSID (Was: dashboard)

[Martin Senger]

> Can you give me an example of a sentence about the lsid resolver that
> you would find sufficiently non-vague?  The discussion on the website
> seems quite clear to me, but you have higher standards :-)
>
   Well, as usual, I am confused :-) What discussion? And what website?
   No, I am not making jokes now, I do not remember any discussion how to
use LSIDs in Biomoby. At least no recently. Anyway, here are the remarsks
I have promise to send:

   Biomoby consists of several parts, each of them may have several
protocols (or APIs). Some of them are well defined, some of them are just
assumed. Here they are as I understand it:

   1) An API how to communicate with a Biomoby registry and with Biomoby
services, using SOAP and XML messages. This is well defined on the Biomoby
website and everybody is cautious to change it only after good discussion
happens. It is in good shape, eventhough it may soon ask for some changes,
such as asynchonous invocation.
   The only "problem" with this API is my feeling (just feeling, no
evidence at all) that Mark would like to let this API go in the future,
and a closer collaboration with S-Moby may be a good excuse for it. But it
is just a feeling, we will cross that brige when we come to it.

   2) The contents of the RDF document returned when a provider registered
a service is part of the API mentioned above, but it is not documented (at
least I have not seen any documentation). In theory, providers do not
"need to know" the contents, they just get it from the registry and put it
somewhere as a token for the RDF agent. But in practice, it was
recommended to use it to enhance information about your services. In order
to do that a provider needs to know the predicate names (and what they
mean) that are there always and that may be there. Such discussion about
predicate names started (at least I and Eddie discussed it in Malaga, and
people briefly discussed it already in Vancouver) but it was never
"officially" approved and made part of the Biomoby well-defined behaviour.

   3) And finally, there is an LSID resolver. Which means that any entity
that has an LSID (in our case, an LSID assigned by a Biomoby registry when
the entity was registered) can be "resolved" by LSID's API. The LSID' API
is weel-defined, but it can be still used in several different ways. And I
believe that we should define what ways we prefer to have in Biomoby. Here
is a list of few things that came to my mind during writing this paragraph
but they may be other that I forgot. We surely have not discussed it in
such details yet:
   * LSID API has methods getData and getMetadata. Any of them can return
an empty result. What would be recommended for us: an empty getData() or
not? For some entities it would be quite good to get something from
getData()...
   * Resolving LSID metadata has more steps than just to make an HTTP
connection and to get an RDF file. But I guess that we want to
recommend to use just this step. So we are slightly "abusing" (in a
possitive way) the LSID spec, but we do not document it.
   * LSID metadata must have well defined predicates (at least some) -
this is the same problem as described in paragraph ad 2).

   Well, I stop now, too long email. But this is what I called "vague".
And I do not think that I have any "higher standard" than it should be
usual for a stable and robust software. And we want to have Biomoby a
stable and robust software, don't we?

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