Category: General

The vote was for Mark to start working on jMoby… bad idea!

What is missing?
– asynchronous services
– Martin will put it into jMoby core. Eddie was very forlorn. Martin assured him that he is only going to repackage Eddie’s code but that Eddie’s code really was good! Using existing libraries is not a good idea right now because they are not up-to-date v.v. the specification.
– how do we handle BIIIG data?

1: Should we pass references to data?
2: Taverna’s upload server, ten pass references – a ticket is given to a service provider to grab the data from a URL.
3: iterator pattern in the Moby API
4: or we should use Web Services protocol to stream data.

v.v. possibility #1
Martin was right, Mark was wrong. The reference to data should be an attribute at the moby:Simple/moby:Collection level, not at the moby:mobyContent level. Should we do this using WSRF so that we can tell the service provider to destroy it when we’ve retrieved the data reference? We think INB should do this, since they’re the experts on WSRF.

Other possibilities will be discussed tomorrow

branch normal and testing code at the root level.

Paul and Mark say YES!
Martin and Ivan say NO!
Eddie plays devils advocate – agreeing with Martin but arguing against him. Martin misunderstood and assumed that Eddie was saying something that made sense… he wasn’t 😉

Martin’s solution was even WORSE than bad – that we could pass a novel object type called “NULL” – and we all laughed at him… and he laughed at himself.

The conclusion: Contained objects DO NOT need to be there. The semantics are that if the object is there, and is blank, then the data is known to be blank. If the object is NOT there, this indicates that the service provider does not know what the content should be. So “blank” has meaning, absence also has meaning.

This raises another issue – should we have some way of specifying that an object MUST be there – i.e. is a required field? This would be a change in the registry. The question is, does this “mandatory” flag belong in the object registration or in the service registration, where a service provider says “don’t give me this object unless you are going to give me this property”. We decided that it belongs in the service description, and it should be in the LSID metadata, but NOT in the registry.

Q1 is it possible to register a different object type for an existing article inherited by ISA assuming that it is a subclass of the existing type? MAYBE

Q2 is it possible to register a different object type for an existing article inherited by ISA assuming that it is NOT a subclass of the existing type? DEFINITIVE NO!!!

Q3 is it possible to simply send a different object type for an existing article inherited by ISA assuming that it is a child type? YES

A3: Quorum of the RDF committee is present so it is decided by the deciders that we will allow inheritence of objects contained by HAS and HASA without the need to register a new object.

i.e.

A hasa B in the registry

is valid, but also

is valid.

A1: now, to the more difficult question: can we create object templates? The use-case is validation – we want to be able to restrict what is contained in an object so that we can validate what is given to us.

We cannot see a way around needing to register a new object for every restriction anyway, so we’re not convinced of the utility of these templates. There is a combinatorial problem, but we need a stronger use-case to prove that it is worth the pain that this change will cause.

Final decision – NO… unless we can find a more convincing use case.

It was decided that the file .classpath.template will be committed to the CVS, and individual developers will have to rename it to .classpath themselves. Then changes to the classpath will not be committed back to the CVS

Martin’s presentation of the advantages, followed by discouragement from using it.

Ant and Maven are similar. What Maven does in addition is that it makes project dependencies and repositories. Therefore you can define the library that you code is using without having the library downloaded, you simply refer to it. it is then found and used in the build. Ant has a library called “ant maven library” that can accomplish the same thing. Martin will update the ant document he has made for GCP and will make it appropriate for the BioMoby homepage/documentation. You just install Ant and then build the project using “ant ”

Need to write to Chris Dag. to get added to the “maven” group so that we can use the maven repository on open-bio.

What belongs in the repository? Dashboard? It isn’t used for development… so should it be there?

People will be less intimidated by ant than by maven. So we agreed to use ant wtih the maven library.

Used to be only selected classes were documented, but now all classes are documented and it is confusing. Martin suggests re-documenting only those classes that are USED by developers.

Wendy’s experience was telling: she discovered CentralImpl after TWO MONTHS of studying the documentation! We need to document only the core classes and somehow provide a navigation/roadmap for newcomers.

Martin will look at the classes and make suggestions to the group about what the “core classes” are. Perhaps have two javadocs – one for all classes and one with only core classes.

Another example: there are three versions of CentralImpl in various places for various purposes. Need to be better documented.

ant – separate jar files into appropriate groups.

Mark needs to write an introduction to BioMoby that explains the basis of namespaces and objects. Need to document WHY Moby is better, and WHY certain decisions were made.

Start with a more detailed intro to Moby namespaces and datatypes
More detailed introduction to Dashboard
then split into Perl and Java streams

Errors: if the path to the project is too long then javadoc fails in ant.

A code release should include a snapshot of the cache of the registry for Dashboard.

Martin will make a CPAN release of Perl MoSeS including a snapshot of the registry. It’s currently hidden in the Java tree. Martin will bring it into a more obvious place.

Some of the problems setting up Java MoSeS in Eclipse were machine-specific.

Some problems were due to having three copies of the documentation for setting up (biomoby, tigr, and rws). Need to unify the documentation and keep one copy on biomoby.org updated. We’ll talk to Wendy about being the goddess of documentation. We’d like to have the API all in one document again, and to have the registry calls in e.g. BNF format. And get the links right!

Mark should see how difficult it is to do this… sometimes they can be empty…

Versioning

– Add to the registry API a way to determine the version of code it is running.

How to test services

– sample input and output will be part of service-provider’s RDF
– methods for testing services will become part of jMoby API
– will also have a panel in Dashboard (?)
– INB has extended metadata in Moby Central – this was for internal use and works best when the entire infrastructure is under some centralized control. Having service invocation examples in the hands of the service provider is more scalable and decentralized.
– do we need extra metadata? e.g. for testing asynchronous services? Perhaps using some sort of “type” of checking. is it alive? Does it take my input? does it give me a result? does the result match a particular pattern/filter? does the result match a predictable output?
– Martin will implement this in September sometime and will pass around the API to the group before implementation for comments