Chronological Thread 

< Chronological >      < Thread >

---

On 8/15/07, David Nickerson <david.nickerson at nus.edu.sg> wrote:
> Hi Matt,
>
> This makes quite a bit of sense to me.
>
> > So, more concretely, I am proposing that:
> > - we start the notion of a versioned workspace or package.
>
> yep. It would also be good to decide on either workspace or package :-)

I like 'package' over 'workspace' since I can imagine someone's
workspace having more than one package present.

I am thinking of a package as being a collection of one or more models
that are considered a unit. I don't know whethere this would require
all models to be related in some way via imports, or whether there
could be arbitrary collections that form a package where entry
points(models) are defined in a manifest/metadata file.

>
> > - the package is named and has an abstract version
>
> and the name is part of the package URI or the URI is the name?

I don't know if a package name would need to be a URI, but it might be
convenient. It's not clear to me yet what the scenarios for a package
would look like. But if there is some consensus of at least a package
root that contains the package manifest/details, then a URI for this
could be possible. But if not a URI, I would at least recommend some
use of namespaces, e.g. the package a.b.c.tar.gz would unbundle into
a/b/c/*, where c would be the root of the package and * is the tree
from there onwards. But that's just a possible pattern amongst many.

> Do you see things like the simulation and graphing metadata to start
> interacting with packages/workspaces in addition to straight CellML
> models or that the concept of a package supersedes the use of models in
> this context? (I'm thinking the latter would make more sense than
> starting to tie variable references to particular document versions)

I would think metadata that needs to refer to a particular version of
a package would refer to the package itself via a URI and also a
version label. Note, version labels, if used in a similar way to
software, can include wildcards or wildcard like behaviour to refer to
groups of versions, or all versions, or a very specific version.

>
> > - for the minimal case of a CellML 1.0 model and metadata in a single
> > document, the package name can be the model name, but the abstract
> > version is still separate from the document version
>
> Why the restriction on only CellML 1.0 models? Currently a model name is
> not used for anything so I'm not sure why a 1.1 model name can't also be
> used as a package name?

Sorry, I wasn't very clear. I was trying to think of the simplest case
of a model, which is actually a 1.0 or 1.0 model that consists of only
a single model document that has both model and metadata contained in
it. And I was thinking what a package would mean for that. But I
suppose that even a single model document scenario should be thought
of as residing in a single container that would form the package root
and hence offer a way of naming it through a URI or dotted
namespace.packageroot combination.

>
> > - that we add a package name and version number metadata construct to
> > all the models.
>
> while this makes sense in a 1.0 world, in a more general case any given
> model could be in more than one package/workspace. I'm guessing that the
> metadata construct you are thinking about could then easily be outside a
> particular model document (or within one) and refer to all it's
> constituent models via their URI? Where the URI or some other identifier
> would consist of the document version information.

Yep. You are right. This information would need to be a package metadata file.


so an example minimal layout:

bread/sourdough/matts/.metadata
bread/sourdough/matts/recipe.xml
.metadata would point to the local recipe.xml and also contains a
version, e.g. 0.1-dev

The package might be called bread.sourdough.matts or
http://backing.org/bread/sourdough/matts/

more complicated would be:

bread/sourdough/matts/.metadata
bread/sourdough/matts/recipe.xml
bread/sourdough/matts/ingredients.xml

where .metadata points to the local recipe.xml and ingredients.cml and
also to the following external resources (which are likely to be used
in imports by the models)
bread/measurement/metric/units.xml
bread/techniques/kneeding/method1.xml
and .metadata also contains a version, e.g. 0.1-dev

The package name would still be the same as in the minimal example.

If we round trip to subversion and document versions again, then I
would expect that useful releases of a package would be tagged.

>
> > - that for most purposes in our discussions we will be talking about
> > this abstract version and what it would mean to increase its major or
> > minor numbers, alpha, beta, or release status etc.
>
> agreed.
>
>
> Andre.
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>

---

• [cellml-discussion] Model versions, Matt , 08/15/2007
  • [cellml-discussion] Model versions, David Nickerson, 08/15/2007
    • [cellml-discussion] Model versions, Matt , 08/15/2007

---

Archive powered by MHonArc 2.6.18.