[moby] [MOBY-dev] About serviceNotes block

Mark Wilkinson mwilkinson at mrl.ubc.ca
Mon Mar 14 21:27:29 UTC 2005


On Mon, 2005-03-14 at 13:03, José María Fernández González wrote:

> INB prefers serviceNotes block instead of 
> ProvisionInformation block because most of the warnings, and in general, 
> exception information, comprise the whole output, which is a Collection 
> for some services.

That's an interesting observation - I hadn't thought about that.  The
reason for the ProvisionInformation block being a part of an object was
so that different subcomponents of a complex object could potentially
have different provision annotations... however you rightly point out
that this would all have to be duplicated if these were part of a
collection, and that it would be more efficient to have it at that
level.

The serviceNotes block is the place where I had intended for this
"global" type of information to be placed - we just need to agree on a
format.


> 	The other drawback for ProvisionInformation is that it cannot appear in 
> a mobyData outside any object, or even Simple or Collection 
> declarations, so it becomes useless when you want (or need) to notify 
> some information related to a Collection,

I like the provision information block where it is for the reasons I
indicate above, but I tend to agree with you that there is possibly a
need for one additional level of provider feedback (I have to point out,
however, that as far as I know you and I are the only people who are
using these extra parts of the MOBY message ;-) )


>  or there is no answer at all 
> because there was a problem with that query.

It was intended that a blank mobyData node would indicate a "problem",
but it is not possible to differentiate between a problematic query, and
the lack of an answer to a valid query at this level.  Since the whole
MOBY thing is intended to be accessed by machines, we would have had to
build (or re-build) a large vocabulary of possible error messages in
order to create a machine-readable solution to errors at this level of
resolution... and since we cannot reasonably predict all of the possible
errors to the level of resolution required for a machine to fix the
problem on its own, this seemed a bit futile... so I didn't bother.  

A blank mobyData block means "I don't know what you are talking about" -
for whatever reason; it may be, but it is not necessarily an error.

This is something we could re-visit at the next MOBY meeting, however.

M


-- 
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada




More information about the MOBY-dev mailing list