master attribute unique or not
11 views
Skip to first unread message
Nicolas Rodriguez
Jun 6, 2014, 8:32:56 AM6/6/14
to combine...@googlegroups.com
Hello,
In the current draft specifications for the combine archive it is said that
at most one file per archive may have its master attribute set to true.
Do we want to let it like that ? I was thinking that may be biomodels or
pmr2 could
provides combine-archives that include many models or even all models.
Without going that far, you could have a archive (without a sed-ml
provided) that contain
several version of one models that are used to produce different figures
in a paper. Or
an archive with the same model encoded in sbml and cellml (and matlab
and ...)
In those cases, it might make sense to have several master attribute set
to true.
What do you think ? The above examples should be valid archives as we
can put what we want
in the archive but if the master is limited to one, we might have to not
set it at all or set it randomly
for those archives
To make it simple, I would like you to choose between these 3 options :
1) don't change anything. We can have only one master attribute set to
true per archive.
2) don't enforce in the specs to have only one master attribute set to
true but put it as a best practice to have only one.
3) don't enforce in the specs to have only one master attribute set to
true and give examples when it could be possible.
Thanks,
Nico
In the current draft specifications for the combine archive it is said that
at most one file per archive may have its master attribute set to true.
Do we want to let it like that ? I was thinking that may be biomodels or
pmr2 could
provides combine-archives that include many models or even all models.
Without going that far, you could have a archive (without a sed-ml
provided) that contain
several version of one models that are used to produce different figures
in a paper. Or
an archive with the same model encoded in sbml and cellml (and matlab
and ...)
In those cases, it might make sense to have several master attribute set
to true.
What do you think ? The above examples should be valid archives as we
can put what we want
in the archive but if the master is limited to one, we might have to not
set it at all or set it randomly
for those archives
To make it simple, I would like you to choose between these 3 options :
1) don't change anything. We can have only one master attribute set to
true per archive.
2) don't enforce in the specs to have only one master attribute set to
true but put it as a best practice to have only one.
3) don't enforce in the specs to have only one master attribute set to
true and give examples when it could be possible.
Thanks,
Nico
Frank T. Bergmann
Jun 6, 2014, 9:28:01 AM6/6/14
to Nicolas Rodriguez, combine...@googlegroups.com
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 you
save a file with one program, and you use it in the next, you would expect
to see the same document opened.
For me multiple master=true elements would not be useful (or just as useful
as having no element with master=true).
All the best
Frank
> --
> You received this message because you are subscribed to the Google Groups
> "COMBINE archive" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to combine-archi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/combine-archive.
> For more options, visit https://groups.google.com/d/optout.
(the same) element when exchanged between software tools. Because when you
save a file with one program, and you use it in the next, you would expect
to see the same document opened.
For me multiple master=true elements would not be useful (or just as useful
as having no element with master=true).
All the best
Frank
> You received this message because you are subscribed to the Google Groups
> "COMBINE archive" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to combine-archi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/combine-archive.
> For more options, visit https://groups.google.com/d/optout.
Nicolas Le Novere
Jun 6, 2014, 10:27:13 AM6/6/14
to combine...@googlegroups.com
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 you
> save a file with one program, and you use it in the next, you would expect
> 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.
> 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 you
> save a file with one program, and you use it in the next, you would expect
> to see the same document opened.
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.
> For me multiple master=true elements would not be useful (or just as useful
> as having no element with master=true).
Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere
Skype:n.lenovere, n.len...@gmail.com, ORCID: 0000-0002-6309-7327
http://lenoverelab.org/, http://lenoverelab.org/perso/lenov/
Frank T. Bergmann
Jun 6, 2014, 10:48:34 AM6/6/14
to n.len...@gmail.com, combine...@googlegroups.com
> 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.
>
> 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.
>
Indeed, I would go that route. Have one composed model as master model, and
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.
>
> 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.
>
it together with its dependents in the archive if that is what the archive
is about.
> > For me multiple master=true elements would not be useful (or just as
> > useful as having no element with master=true).
>
> Could it be a best practise instead?
>
Frank
Stian Soiland-Reyes
Jun 6, 2014, 10:59:19 AM6/6/14
to Frank T. Bergmann, combine...@googlegroups.com, Nicolas Rodriguez
In the Adobe UCF specification
Which we use for RO Bundles,
http://wf4ever.github.io/ro/bundle/#rootfile
> A UCF Container MAY include a file named container.xml in the META-INF directory at the root level of the container file system. If present, the container.xml file MAY identify the MIME type of, and path to, the root file for the container and any OPTIONAL alternative renditions included in the container.
> Each <rootfile> element specifies the root file of a single rendition of the contained publication. A root file often includes an enumeration of the other files needed by the rendition.
So this is useful when you can't decide between say PDF and HTML. I would not recommend multiple master files unless they are of different content types.
If you simply have many models in the same format, then rather have no master (which is not ideal if those models again have nestings), or introduce an aggregation type.
Camille Laibe
Jun 10, 2014, 5:01:33 PM6/10/14
to combine...@googlegroups.com
Hi,
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
>> you
>> save a file with one program, and you use it in the next, you would
>> expect
>> 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
software.
> 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).
Cheers.
Camille Laibe
BioModels.net Coordinator
European Bioinformatics Institute (EMBL-EBI), Cambridge, UK
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
>> you
>> save a file with one program, and you use it in the next, you would
>> expect
>> 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.
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
software.
> 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.
allowing references to files/archives stored outside the archive
(ideally via a perennial URI).
Cheers.
BioModels.net Coordinator
European Bioinformatics Institute (EMBL-EBI), Cambridge, UK
Frank T. Bergmann
Jun 11, 2014, 2:48:12 AM6/11/14
to la...@ebi.ac.uk, combine...@googlegroups.com
> 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.
>
I'm not saying that they are not relevant. What I was suggesting, is that
> 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.
>
for a first version, we would mark only one of them (i.e. in nicos case: the
newest model, or the model last looked at before saving the archive, or in
Nicolas' case: the outer hierarchical model) as master file. We have to make
the first version easy to use, and ensure that the files can readily be
exchanged providing the same result between tools. (i.e the same information
displayed).
> 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
> software.
>
will want to look at down the road. But I would suggest sticking to the
current version for now without adding more things, and let software tools
use it as a version and produce files that way. And while a first version is
used, and experiences are gathered that way, we can improve on the overall
scheme.
> > 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).
>
for composed models all the individual bits and pieces of it. And for
simulation experiments all the models and references it needs. Anything else
would defeat the purpose of storing files that way, and will result in a bad
experience between tools, when files cannot be resolved.
Cheers
Frank
Stian Soiland-Reyes
Jun 11, 2014, 3:55:03 AM6/11/14
to la...@ebi.ac.uk, combine...@googlegroups.com
On 10 June 2014 22:01, Camille Laibe <la...@ebi.ac.uk> wrote:
> 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.
Agreed!
> 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.
Here are some useful provenance vocabularies that could be relavant
for expressing such relations:
http://www.w3.org/TR/prov-o
http://purl.org/pav/html
http://purl.org/spar/cito
--
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
Reply all
Reply to author
Forward
0 new messages