[MOBY-dev] Changes in the 0.86API

[markw at illuminae.com]

Quoting Martin Senger <senger at ebi.ac.uk>:


>    Generally it is a good idea (to have things named). I also remember
> that we had asked for in in Vancouver. But the change, even though may not
> be big in the code, is big in the documentation, in the API description. I
> would rather see first an updated API documentation, read it and only then
> have here a discussion about it. This is mainly we used the name 'article'
> not only as an XML attribute, but we had/have also an XML tag called
> 'secondaryArticle', we often speak about 'parameters' (as you just done
> above) but we mean by that actually all input data... and so on.
>    Other issue is that the biomoby.org now has API086 from the August
> 3. But it does not have the changes described in your last email - and the
> email is labeled 'changes in the 0.86'

The changes I describe in my email are, in fact (I think??) documented in the
0.86 API that
is on the website (see the change history at the bottom of the page), but you
are correct that the current production server is not running the 0.86 API - it
is running the 0.85 API.  I have sent the main developers the endpoint of the
instance of MOBY Central that is running the 0.86 codebase so that you can test
it and begin the process of coding to it. 

I share your reservations about changing the articleName (in its "parameter"
meaning) to componentName, given that we have many other tags in our XML
messaging that use the word "Article" with the same intention.  Perhaps it is
better to change the MOBY Object articleName attribute to something else
instead?  That would likely require less changes in our code...  One or the
other of them really must go because they have two different meanings!


> - so you are actually describing
> changes that will be in 0.87API? I am confused... The normal practice -
> which I strongly suggest - is to keep on biomoby.org an API which works
> currently - and to have a separate page, where we can see 'proposed API' -
> which is not yet implemented, even it is not yet approved by us/developers
> and it serves for these discussions.

This is a good idea...  I will try to do that right now.  I can get a diff of
the current API versus the 0.85 API and then set up a second Twiki page from
that diff.


> I know that it is boring to keep docs
> updated but that is one of the issues we discussed in V. when we said that
> the current biomoby does not have enough of the 'project management' :-)

It's not so much that it is boring (I actually enjoy documentation!  What a
pedantic nutter I am!), however it is really a matter of limited resourcing and
time - it is rare for me to have so much time for coding, and as you have
pointed out frequently, MOBY Central is currently a one-man-show for the most
part, so when these moments arise I feel obligated to use it to push forward the
codebase as far as possible rather than slowly and carefully as I would prefer
:-/  I'm trying to keep you and the other core developers updated as to my
activities, and I am similarly trying to limit my changes to those that were
made in agreement with the attendees at the last meeting (i.e. that we have
already discussed as a group), and to respond to those decisions as quickly as
possible.  Given the ten fingers I have, and the time constraints, that's the
best I can manage...


>    Back to article names: I remember that in Malaga the ICN people had
> talked about their incoming proposal for more decent error handling in
> biomoby messages. For that, the article names were mandatory (so it is
> good that we are thinking about it in the same way) - but I think that
> they wanted to name also individual Simples in Collection. So it may be
> worth to make sure that they are listening now...

Eeek!  I don't remember that...  Can you recall why this was necessary?



> > 2)  Inheritence from primitive classes is now forbidden and this is
> enforced by
> > the MOBY Central code.
> >
>    Again, this need to be documented first...

It is, in the 0.86API.

 
> > 4)  a new method "retrieveResourceURLs" has been added to the API that
> provides
> > you with a list of the URLs from which you can retrieve the RDF versions of
> all
> > of the ontologies.
> >
>    Here comes my previous email (send only to Mark) about how to make
> these (BIG) RDF documents compressed. One solution is to allow registry
> providers to specify two URLs for each resource type, one for normal and
> one for zipped document.

I guess the "safe" way to handle that would be to add a "type" attribute to the
<Resource...> tag indicaing the MIME type of the document that is behind the URL
(yeah... we could get that by calling HEAD, I guess...).  It will be important
to know this for software that needs to receive an ontology by calling the URL...


> > I will be moving the production server to the new codebase next week
> sometime.
> >
>    No, don't do it so soon... Please... Describe it first in the API in
> details...

OK.  The code is, however, up and running on the test server that I told you
about yesterday.

Cheers!

M