On 06/06/14 15:27, Nicolas Le Novere wrote:
> On 06/06/14 14:27, Frank T. Bergmann wrote:
>> The intent for the master attribute was to make it easy for tools to
>> open a
>> (the same) element when exchanged between software tools. Because when
>> save a file with one program, and you use it in the next, you would
>> to see the same document opened.
> True. But if you have several models in one archive? For instance if you
> have two composed models, each made up of three SBML files. In total you
> have 6 SBML files. Having two master SBML files could help. At the
> moment, most software only open one model at a time. I always found that
> odd. Most other software allow to open any number of different files.
> One of my feature requests for COPASI for instance, is to be able to
> drag and drop a bunch of models on it, and they are all opened. In that
> case, knowing the masters would be useful.
I'm not too sure that having a model repository providing all the hosted
models in one archive is a good example. But Nico's example of several
versions of one model, or Nicolas' example of reuse of other models in
the case of models composed of others are, I think, very relevant use
cases for the archive.
If you consider that those use cases should be covered in the first
version of the specification, then I think the currently proposed
"master" attribute is not sufficient.
One possibility would be to extend the content of the current manifest
file to add some additional information about each file, or have some
mandatory elements in the metadata file, so that a tool could at least
display a choice to its user in case several files can actually be
opened by the tool.
That could include a computer readable description. For example relying
on a simple set of terms (isCuratedVersion, isAlternativeVersion,
isEmbeddedModel, ...), hopefully taken from some existing vocabularies.
Additionally, a human readable description could be provided.
With this additional information, tools would be able to easily decide
which file they can and should open, and allow users to make an informed
decision (if necessary).
Of course such solution would be more painful to implement in supporting
> But maybe, what we should do is to discourage people to store several
> models in one archive, but use several archives instead? Of course that
> limit the reuse of the same file for different model.
In the case of models composed of others, this could be covered by
allowing references to files/archives stored outside the archive
(ideally via a perennial URI).
European Bioinformatics Institute (EMBL-EBI), Cambridge, UK