Forums

One of the principles we established for the relationship between Level 3
core and Level 3 packages is that if you strip out the package
information, the remainder of the model must be syntactically valid, if
not semantically understandable.

If this principle was applied to packages, it would mean that if you had
multiple packages, and stripped just one of them, the remainder of the
model must again be syntactically valid.

As currently written, this is not true for 'comp', and I need your input
as to whether this is OK or not, and how I should structure validation
rules accordingly.

The issue is that I have Replacement and Deletion objects in comp that
need to point to other-package-defined constructs. As an example, if you
wanted to make a hierarchically composed spatial model, you would need to
be able to refer to the Geometry objects in the submodels, to say they
should be replaced or deleted.

So, assuming you referred to that Geometry object by its metaID, you might
have a ReplacedElement object that looked like:

<comp:replacedElement comp:metaIdRef="sphere1" comp:submodelRef="A" comp:identical="true"/>

The problem is that if you stripped out the spatial package information,
suddenly you are left with a dangling reference: 'sphere1' no longer
refers to anything you can parse.

In my opinion, it would make things entirely too complicated to do the
usual indirection we do to accomplish the 'fallback principle' for core.
Do you all agree? And if you do, how would you recommend I write the
validation rules for the 'metaIdRef' attribute?

-Lucian
____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the sbml-discuss list,
contact sbml-team@caltech.edu

Hi Guys

Just throwing another thought into the discussion.

I making the assumption that a 'flattening' algorithm needs to deal with
packages whether it knows about them or not. It should essential just
copy or delete based on references and not care whether it understands
what it is copying/deleting.

If that is true then if a comp model was flattened BEFORE any
unrecognised packages were stripped the result should be a syntactically
valid model.

Could the 'must leave syntactically correct model' requirement in comp
be imposed as a post flattening requirement ??

Sarah

Of course, if the flattening algorithm has to know about packages that
it does not know about then we are all up the creek sans paddle :-)


On 29/06/2011 19:45, Lucian Smith wrote:
> One of the principles we established for the relationship between Level 3
> core and Level 3 packages is that if you strip out the package
> information, the remainder of the model must be syntactically valid, if
> not semantically understandable.
>
> If this principle was applied to packages, it would mean that if you had
> multiple packages, and stripped just one of them, the remainder of the
> model must again be syntactically valid.
>
> As currently written, this is not true for 'comp', and I need your input
> as to whether this is OK or not, and how I should structure validation
> rules accordingly.
>
> The issue is that I have Replacement and Deletion objects in comp that
> need to point to other-package-defined constructs. As an example, if you
> wanted to make a hierarchically composed spatial model, you would need to
> be able to refer to the Geometry objects in the submodels, to say they
> should be replaced or deleted.
>
> So, assuming you referred to that Geometry object by its metaID, you might
> have a ReplacedElement object that looked like:
>
> <comp:replacedElement comp:metaIdRef="sphere1" comp:submodelRef="A" comp:identical="true"/>
>
> The problem is that if you stripped out the spatial package information,
> suddenly you are left with a dangling reference: 'sphere1' no longer
> refers to anything you can parse.
>
> In my opinion, it would make things entirely too complicated to do the
> usual indirection we do to accomplish the 'fallback principle' for core.
> Do you all agree? And if you do, how would you recommend I write the
> validation rules for the 'metaIdRef' attribute?
>
> -Lucian
> ____________________________________________________________
> To manage your sbml-discuss list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>
> For a web interface to the sbml-discuss mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the sbml-discuss list,
> contact sbml-team@caltech.edu
>

____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the sbml-discuss list,
contact sbml-team@caltech.edu

Hello All,

Though the discussion about flattening may help in understanding the
issue we face. Flattening in itself must not be our concern. This is
implementation specific and I can envision situations in which you do
not want to flatten at all for your simulation or analysis because you
are interested in a multi-scale model.

With respect to the comp package all we need to make sure is that when
we strip out all elements in the comp namespace we are left with a valid
core model. This the only requirements the core makes.

Another question is what a comp aware tool should do if the model
contains references to other packages. Here we are entirely free to
define our own requirements which go beyond the stipulations of the core.

I think the comp package should require that for the data model to stay
intact all foreign (not core and comp) objects which contain an
attribute derived from XML.Id, core.SId, or core.UnitId must be
preserved even if their meaning is unknown.

Thanks,
Stefan


On 7/1/11 10:27 AM, Chris J. Myers wrote:
> I replaced the reply to sbml-comp, so we stop spamming discuss :-).
>
> This was actually kind of what I was trying to say in my message. I
> think flattening should not need package awareness.
>
> Lucian: if this assumption is not correct, can you provide a concrete
> example?
>
> Thanks,
>
> Chris
>
>
> On Jul 1, 2011, at 4:00 AM, Sarah Keating wrote:
>
>> Hi Guys
>>
>> Just throwing another thought into the discussion.
>>
>> I making the assumption that a 'flattening' algorithm needs to deal
>> with
>> packages whether it knows about them or not. It should essential just
>> copy or delete based on references and not care whether it understands
>> what it is copying/deleting.
>>
>> If that is true then if a comp model was flattened BEFORE any
>> unrecognised packages were stripped the result should be a
>> syntactically
>> valid model.
>>
>> Could the 'must leave syntactically correct model' requirement in comp
>> be imposed as a post flattening requirement ??
>>
>> Sarah
>>
>> Of course, if the flattening algorithm has to know about packages that
>> it does not know about then we are all up the creek sans paddle :-)
>>
>>
>> On 29/06/2011 19:45, Lucian Smith wrote:
>>> One of the principles we established for the relationship between
>>> Level 3
>>> core and Level 3 packages is that if you strip out the package
>>> information, the remainder of the model must be syntactically
>>> valid, if
>>> not semantically understandable.
>>>
>>> If this principle was applied to packages, it would mean that if
>>> you had
>>> multiple packages, and stripped just one of them, the remainder of
>>> the
>>> model must again be syntactically valid.
>>>
>>> As currently written, this is not true for 'comp', and I need your
>>> input
>>> as to whether this is OK or not, and how I should structure
>>> validation
>>> rules accordingly.
>>>
>>> The issue is that I have Replacement and Deletion objects in comp
>>> that
>>> need to point to other-package-defined constructs. As an example,
>>> if you
>>> wanted to make a hierarchically composed spatial model, you would
>>> need to
>>> be able to refer to the Geometry objects in the submodels, to say
>>> they
>>> should be replaced or deleted.
>>>
>>> So, assuming you referred to that Geometry object by its metaID,
>>> you might
>>> have a ReplacedElement object that looked like:
>>>
>>> <comp:replacedElement comp:metaIdRef="sphere1"
>>> comp:submodelRef="A" comp:identical="true"/>
>>>
>>> The problem is that if you stripped out the spatial package
>>> information,
>>> suddenly you are left with a dangling reference: 'sphere1' no longer
>>> refers to anything you can parse.
>>>
>>> In my opinion, it would make things entirely too complicated to do
>>> the
>>> usual indirection we do to accomplish the 'fallback principle' for
>>> core.
>>> Do you all agree? And if you do, how would you recommend I write the
>>> validation rules for the 'metaIdRef' attribute?
>>>
>>> -Lucian
>>> ____________________________________________________________
>>> To manage your sbml-discuss list subscription, visit
>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>>
>>> For a web interface to the sbml-discuss mailing list, visit
>>> http://sbml.org/Forums/
>>>
>>> For questions or feedback about the sbml-discuss list,
>>> contact sbml-team@caltech.edu
>>>
>>
>> ____________________________________________________________
>> To manage your sbml-discuss list subscription, visit
>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>
>> For a web interface to the sbml-discuss mailing list, visit
>> http://sbml.org/Forums/
>>
>> For questions or feedback about the sbml-discuss list,
>> contact sbml-team@caltech.edu
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> sbml-comp mailing list
> sbml-comp@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sbml-comp


--
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility II
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax: (540) 231-2606
Email: shoops@vbi.vt.edu

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
sbml-comp mailing list
sbml-comp@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbml-comp

Indeed, it turns out this is not correct. You can go partway without
knowing the specifics of a package, but not the whole way, and in my
opinion, the mess you would make by trying to do it partially would not be
helpful.

Even at the most basic aggregation level, if you want to output a
non-hierarchical model, you're going to have to worry about namespace
issues. Let's go ahead and look at spatial, since I've already used it
once. Spatial is set up:

model
spatial:geometry
spatial:listOfCoordinateComponents
spatial:coordinateComponent
spatial:listOfDomainTypes
spatial:domainType
[a few more spatial:listOfs]
listofCompartments
compartment
spatial:listOfCompartmentMappings
spatial:compartmentMapping


If you are aggregating two models with these structures, you're going to
have to figure out that the final model should have exactly one 'geometry'
object, and exactly one 'listofCoordinateComponents' object, but that the
various coordinateComponent objects from both models should be combined as
children of the same parent listOfCoordinateComponents model.

Now, maybe you could invent an algorithm to figure this out for you, or
maybe we could have rules for packages that made this explicit. But it's
a bit chancy, and I'm nervous about saying that even this simple step
could be automated without knowing about spatial.

Beyond this, however, there's the issue of having to end up with unique
names. As it happens, as written, the spatial package has defined a whole
new namespace 'Spid' that needs to be unique. A coordinate component has
the attributes 'spatialId', 'coordinateIndex', 'componentType', and
'sbmlUnit'. The first thing is that none of them are 'id' which might
give us a clue about namespaces. But if we aggregated two models that
each had a coordinateComponent with the same value for their 'spatialId'
attribute, it would turn out that without renaming, we would have just
created an invalid model.

Also suspicious is the 'sbmlUnit' attribute. I can't quite tell from the
spatial specification, but it's a good bet that this is the type
'UnitSIdRef'. If we rename a unit from the core spec, who is to know that
this 'spatial:sbmlUnit' attribute also needs to be changed? Without
knowing spatial, you won't be able to tell.

Finally, there's the compartmentMapping element. This element has the
attributes 'spatialId (Spid)', 'compartment (SIdRef)', 'domainType
(SpidRef)', and 'initSize (double)'. The first has the same issue we've
arleady talked about. The second has the same problem as the sbmlUnit
attribute: if you change the compartment's SId, you'll need to change
this attribute as well. And 'domainType' is yet another problem: here,
if the Spid of the element to which it refers has changed, we need to know
that this is to be changed as well.

And this is before you even get to replacements and deletions. Deletions
are probably actually safe to follow the rules for: all you have to do is
remove them from the model. And replacements *mostly* have exactly the
same issues as aggregation, above.

But once your new elements have a mathematical meaning, suddenly you have
to worry about conversion factors, too, which are if anything a larger
mess than anything we've discussed yet. There's a whole table at the end
of the comp spec that talks about how to convert all sorts of different
SBML core constructs according to the default model units. If any of
these new spatial elements have a mathematical meaning, will they be in
units of length? area? volume? time? time/volume? extent*length? It
would be hopeless to even begin to try to flatten such a mathematical
model without understanding its semantics.

Even *with* understanding the semantics, it's going to be hard! When I
write the flattening algorithm for core, I'm going to be paying attention
to how best let packages hook into those algorithms. The trick will be to
give them functions that let them know what needs to be done, while
letting them use their understanding of their semantics to accomplish
this.

-Lucian

* Chris J. Myers <myers@ece.utah.edu> [2011-07-01 15:27] writes:
> I replaced the reply to sbml-comp, so we stop spamming discuss :-).
>
> This was actually kind of what I was trying to say in my message. I
> think flattening should not need package awareness.
>
> Lucian: if this assumption is not correct, can you provide a concrete
> example?
>
> Thanks,
>
> Chris
>
>
> On Jul 1, 2011, at 4:00 AM, Sarah Keating wrote:
>
> > Hi Guys
> >
> > Just throwing another thought into the discussion.
> >
> > I making the assumption that a 'flattening' algorithm needs to deal
> > with
> > packages whether it knows about them or not. It should essential just
> > copy or delete based on references and not care whether it understands
> > what it is copying/deleting.
> >
> > If that is true then if a comp model was flattened BEFORE any
> > unrecognised packages were stripped the result should be a
> > syntactically
> > valid model.
> >
> > Could the 'must leave syntactically correct model' requirement in comp
> > be imposed as a post flattening requirement ??
> >
> > Sarah
> >
> > Of course, if the flattening algorithm has to know about packages that
> > it does not know about then we are all up the creek sans paddle :-)
> >
> >
> > On 29/06/2011 19:45, Lucian Smith wrote:
> >> One of the principles we established for the relationship between
> >> Level 3
> >> core and Level 3 packages is that if you strip out the package
> >> information, the remainder of the model must be syntactically
> >> valid, if
> >> not semantically understandable.
> >>
> >> If this principle was applied to packages, it would mean that if
> >> you had
> >> multiple packages, and stripped just one of them, the remainder of
> >> the
> >> model must again be syntactically valid.
> >>
> >> As currently written, this is not true for 'comp', and I need your
> >> input
> >> as to whether this is OK or not, and how I should structure
> >> validation
> >> rules accordingly.
> >>
> >> The issue is that I have Replacement and Deletion objects in comp
> >> that
> >> need to point to other-package-defined constructs. As an example,
> >> if you
> >> wanted to make a hierarchically composed spatial model, you would
> >> need to
> >> be able to refer to the Geometry objects in the submodels, to say
> >> they
> >> should be replaced or deleted.
> >>
> >> So, assuming you referred to that Geometry object by its metaID,
> >> you might
> >> have a ReplacedElement object that looked like:
> >>
> >> <comp:replacedElement comp:metaIdRef="sphere1"
> >> comp:submodelRef="A" comp:identical="true"/>
> >>
> >> The problem is that if you stripped out the spatial package
> >> information,
> >> suddenly you are left with a dangling reference: 'sphere1' no longer
> >> refers to anything you can parse.
> >>
> >> In my opinion, it would make things entirely too complicated to do
> >> the
> >> usual indirection we do to accomplish the 'fallback principle' for
> >> core.
> >> Do you all agree? And if you do, how would you recommend I write the
> >> validation rules for the 'metaIdRef' attribute?
> >>
> >> -Lucian
> >> ____________________________________________________________
> >> To manage your sbml-discuss list subscription, visit
> >> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
> >>
> >> For a web interface to the sbml-discuss mailing list, visit
> >> http://sbml.org/Forums/
> >>
> >> For questions or feedback about the sbml-discuss list,
> >> contact sbml-team@caltech.edu
> >>
> >
> > ____________________________________________________________
> > To manage your sbml-discuss list subscription, visit
> > https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
> >
> > For a web interface to the sbml-discuss mailing list, visit
> > http://sbml.org/Forums/
> >
> > For questions or feedback about the sbml-discuss list,
> > contact sbml-team@caltech.edu
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> sbml-comp mailing list
> sbml-comp@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
sbml-comp mailing list
sbml-comp@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbml-comp

I was reading this, thinking "didn't I already write about my proposal for
how to change libsbml?" and then realized that yes, indeed, I had--and
saved it on my computer and never showed anyone. So! I've copied it to
the wiki:

http://sbml.org/SBML_Level_3_Proposals/comp/Flattening_and_other_packages

Basically I totally agree that as a first pass, we need only flatten core,
but the functions I'll need for that should be available (imo) in libsbml
so that I can use them as can other package writers. Happily, I'm now on
the libsbml team, so I think I can convince them ;-)

Take a look and see what you think.

-Lucian

* Chris J. Myers <myers@ece.utah.edu> [2011-07-01 20:54] writes:
> Okay, I'm convinced :-).
>
> So, we can make progress, I suggest that flattening should currently
> only be defined on core. Namely, the flattening process would first
> strip out all parts which it doesn't recognize as core components.
> This should be allowed since the packages are supposed to permit
> this. The flattening process would then produce a model of just the
> core components.
>
> Note that this is just a stop gap as it is a mistake to get stuck
> worrying about packages right now given the importance of the comp
> package. Indeed, I would advocate once comp is done, that we promote
> it to core so it does not need to abide by the ignore package elements
> rule.
>
> Then, once this works, each package developer would be required to
> work out the details/rules of how their elements are to be flattened.
> They will also need to implement in libsbml the flattening of their
> elements. I'm a little worried that this may require them to modify
> not only their package code but also the core (including comp in that)
> part of libsbml, but this just may be unavoidable.
> Note that they should also define the semantics of their packages as
> relates to a hierarchical model.
>
> I think this approach makes the most sense. I really think we should
> promote comp as soon as possible which will make this more consistent.
>
> Chris
>
> On Jul 1, 2011, at 11:24 AM, Lucian Smith wrote:
>
> > Indeed, it turns out this is not correct. You can go partway without
> > knowing the specifics of a package, but not the whole way, and in my
> > opinion, the mess you would make by trying to do it partially would
> > not be
> > helpful.
> >
> > Even at the most basic aggregation level, if you want to output a
> > non-hierarchical model, you're going to have to worry about namespace
> > issues. Let's go ahead and look at spatial, since I've already used
> > it
> > once. Spatial is set up:
> >
> > model
> > spatial:geometry
> > spatial:listOfCoordinateComponents
> > spatial:coordinateComponent
> > spatial:listOfDomainTypes
> > spatial:domainType
> > [a few more spatial:listOfs]
> > listofCompartments
> > compartment
> > spatial:listOfCompartmentMappings
> > spatial:compartmentMapping
> >
> >
> > If you are aggregating two models with these structures, you're
> > going to
> > have to figure out that the final model should have exactly one
> > 'geometry'
> > object, and exactly one 'listofCoordinateComponents' object, but
> > that the
> > various coordinateComponent objects from both models should be
> > combined as
> > children of the same parent listOfCoordinateComponents model.
> >
> > Now, maybe you could invent an algorithm to figure this out for you,
> > or
> > maybe we could have rules for packages that made this explicit. But
> > it's
> > a bit chancy, and I'm nervous about saying that even this simple step
> > could be automated without knowing about spatial.
> >
> > Beyond this, however, there's the issue of having to end up with
> > unique
> > names. As it happens, as written, the spatial package has defined a
> > whole
> > new namespace 'Spid' that needs to be unique. A coordinate
> > component has
> > the attributes 'spatialId', 'coordinateIndex', 'componentType', and
> > 'sbmlUnit'. The first thing is that none of them are 'id' which might
> > give us a clue about namespaces. But if we aggregated two models that
> > each had a coordinateComponent with the same value for their
> > 'spatialId'
> > attribute, it would turn out that without renaming, we would have just
> > created an invalid model.
> >
> > Also suspicious is the 'sbmlUnit' attribute. I can't quite tell
> > from the
> > spatial specification, but it's a good bet that this is the type
> > 'UnitSIdRef'. If we rename a unit from the core spec, who is to
> > know that
> > this 'spatial:sbmlUnit' attribute also needs to be changed? Without
> > knowing spatial, you won't be able to tell.
> >
> > Finally, there's the compartmentMapping element. This element has the
> > attributes 'spatialId (Spid)', 'compartment (SIdRef)', 'domainType
> > (SpidRef)', and 'initSize (double)'. The first has the same issue
> > we've
> > arleady talked about. The second has the same problem as the sbmlUnit
> > attribute: if you change the compartment's SId, you'll need to change
> > this attribute as well. And 'domainType' is yet another problem:
> > here,
> > if the Spid of the element to which it refers has changed, we need
> > to know
> > that this is to be changed as well.
> >
> > And this is before you even get to replacements and deletions.
> > Deletions
> > are probably actually safe to follow the rules for: all you have to
> > do is
> > remove them from the model. And replacements *mostly* have exactly
> > the
> > same issues as aggregation, above.
> >
> > But once your new elements have a mathematical meaning, suddenly you
> > have
> > to worry about conversion factors, too, which are if anything a larger
> > mess than anything we've discussed yet. There's a whole table at
> > the end
> > of the comp spec that talks about how to convert all sorts of
> > different
> > SBML core constructs according to the default model units. If any of
> > these new spatial elements have a mathematical meaning, will they be
> > in
> > units of length? area? volume? time? time/volume?
> > extent*length? It
> > would be hopeless to even begin to try to flatten such a mathematical
> > model without understanding its semantics.
> >
> > Even *with* understanding the semantics, it's going to be hard!
> > When I
> > write the flattening algorithm for core, I'm going to be paying
> > attention
> > to how best let packages hook into those algorithms. The trick will
> > be to
> > give them functions that let them know what needs to be done, while
> > letting them use their understanding of their semantics to accomplish
> > this.
> >
> > -Lucian
> >
> > * Chris J. Myers <myers@ece.utah.edu> [2011-07-01 15:27] writes:
> >> I replaced the reply to sbml-comp, so we stop spamming discuss :-).
> >>
> >> This was actually kind of what I was trying to say in my message. I
> >> think flattening should not need package awareness.
> >>
> >> Lucian: if this assumption is not correct, can you provide a concrete
> >> example?
> >>
> >> Thanks,
> >>
> >> Chris
> >>
> >>
> >> On Jul 1, 2011, at 4:00 AM, Sarah Keating wrote:
> >>
> >>> Hi Guys
> >>>
> >>> Just throwing another thought into the discussion.
> >>>
> >>> I making the assumption that a 'flattening' algorithm needs to deal
> >>> with
> >>> packages whether it knows about them or not. It should essential
> >>> just
> >>> copy or delete based on references and not care whether it
> >>> understands
> >>> what it is copying/deleting.
> >>>
> >>> If that is true then if a comp model was flattened BEFORE any
> >>> unrecognised packages were stripped the result should be a
> >>> syntactically
> >>> valid model.
> >>>
> >>> Could the 'must leave syntactically correct model' requirement in
> >>> comp
> >>> be imposed as a post flattening requirement ??
> >>>
> >>> Sarah
> >>>
> >>> Of course, if the flattening algorithm has to know about packages
> >>> that
> >>> it does not know about then we are all up the creek sans paddle :-)
> >>>
> >>>
> >>> On 29/06/2011 19:45, Lucian Smith wrote:
> >>>> One of the principles we established for the relationship between
> >>>> Level 3
> >>>> core and Level 3 packages is that if you strip out the package
> >>>> information, the remainder of the model must be syntactically
> >>>> valid, if
> >>>> not semantically understandable.
> >>>>
> >>>> If this principle was applied to packages, it would mean that if
> >>>> you had
> >>>> multiple packages, and stripped just one of them, the remainder of
> >>>> the
> >>>> model must again be syntactically valid.
> >>>>
> >>>> As currently written, this is not true for 'comp', and I need your
> >>>> input
> >>>> as to whether this is OK or not, and how I should structure
> >>>> validation
> >>>> rules accordingly.
> >>>>
> >>>> The issue is that I have Replacement and Deletion objects in comp
> >>>> that
> >>>> need to point to other-package-defined constructs. As an example,
> >>>> if you
> >>>> wanted to make a hierarchically composed spatial model, you would
> >>>> need to
> >>>> be able to refer to the Geometry objects in the submodels, to say
> >>>> they
> >>>> should be replaced or deleted.
> >>>>
> >>>> So, assuming you referred to that Geometry object by its metaID,
> >>>> you might
> >>>> have a ReplacedElement object that looked like:
> >>>>
> >>>> <comp:replacedElement comp:metaIdRef="sphere1"
> >>>> comp:submodelRef="A" comp:identical="true"/>
> >>>>
> >>>> The problem is that if you stripped out the spatial package
> >>>> information,
> >>>> suddenly you are left with a dangling reference: 'sphere1' no
> >>>> longer
> >>>> refers to anything you can parse.
> >>>>
> >>>> In my opinion, it would make things entirely too complicated to do
> >>>> the
> >>>> usual indirection we do to accomplish the 'fallback principle' for
> >>>> core.
> >>>> Do you all agree? And if you do, how would you recommend I write
> >>>> the
> >>>> validation rules for the 'metaIdRef' attribute?
> >>>>
> >>>> -Lucian
> >>>> ____________________________________________________________
> >>>> To manage your sbml-discuss list subscription, visit
> >>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
> >>>>
> >>>> For a web interface to the sbml-discuss mailing list, visit
> >>>> http://sbml.org/Forums/
> >>>>
> >>>> For questions or feedback about the sbml-discuss list,
> >>>> contact sbml-team@caltech.edu
> >>>>
> >>>
> >>> ____________________________________________________________
> >>> To manage your sbml-discuss list subscription, visit
> >>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
> >>>
> >>> For a web interface to the sbml-discuss mailing list, visit
> >>> http://sbml.org/Forums/
> >>>
> >>> For questions or feedback about the sbml-discuss list,
> >>> contact sbml-team@caltech.edu
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> All of the data generated in your IT infrastructure is seriously
> >> valuable.
> >> Why? It contains a definitive record of application performance,
> >> security
> >> threats, fraudulent activity, and more. Splunk takes this data and
> >> makes
> >> sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> _______________________________________________
> >> sbml-comp mailing list
> >> sbml-comp@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/sbml-comp
> >
> > ------------------------------------------------------------------------------
> > All of the data generated in your IT infrastructure is seriously
> > valuable.
> > Why? It contains a definitive record of application performance,
> > security
> > threats, fraudulent activity, and more. Splunk takes this data and
> > makes
> > sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > sbml-comp mailing list
> > sbml-comp@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/sbml-comp
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> sbml-comp mailing list
> sbml-comp@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
sbml-comp mailing list
sbml-comp@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbml-comp

Yup--my first goal is to get hierarchical translation to and from
Antimony, then to work on the flattening stuff.

-Lucian

* Chris J. Myers <myers@ece.utah.edu> [2011-07-02 16:01] writes:
> This looks very well thought out.
>
> Are you getting close to where others can experiment with it?
>
> Chris
>
> Sent from my iPhone
>
> On Jul 1, 2011, at 3:16 PM, Lucian Smith <lpsmith@spod-central.org> wrote:
>
> > I was reading this, thinking "didn't I already write about my proposal for
> > how to change libsbml?" and then realized that yes, indeed, I had--and
> > saved it on my computer and never showed anyone. So! I've copied it to
> > the wiki:
> >
> > http://sbml.org/SBML_Level_3_Proposals/comp/Flattening_and_other_packages
> >
> > Basically I totally agree that as a first pass, we need only flatten core,
> > but the functions I'll need for that should be available (imo) in libsbml
> > so that I can use them as can other package writers. Happily, I'm now on
> > the libsbml team, so I think I can convince them ;-)
> >
> > Take a look and see what you think.
> >
> > -Lucian
> >
> > * Chris J. Myers <myers@ece.utah.edu> [2011-07-01 20:54] writes:
> >> Okay, I'm convinced :-).
> >>
> >> So, we can make progress, I suggest that flattening should currently
> >> only be defined on core. Namely, the flattening process would first
> >> strip out all parts which it doesn't recognize as core components.
> >> This should be allowed since the packages are supposed to permit
> >> this. The flattening process would then produce a model of just the
> >> core components.
> >>
> >> Note that this is just a stop gap as it is a mistake to get stuck
> >> worrying about packages right now given the importance of the comp
> >> package. Indeed, I would advocate once comp is done, that we promote
> >> it to core so it does not need to abide by the ignore package elements
> >> rule.
> >>
> >> Then, once this works, each package developer would be required to
> >> work out the details/rules of how their elements are to be flattened.
> >> They will also need to implement in libsbml the flattening of their
> >> elements. I'm a little worried that this may require them to modify
> >> not only their package code but also the core (including comp in that)
> >> part of libsbml, but this just may be unavoidable.
> >> Note that they should also define the semantics of their packages as
> >> relates to a hierarchical model.
> >>
> >> I think this approach makes the most sense. I really think we should
> >> promote comp as soon as possible which will make this more consistent.
> >>
> >> Chris
> >>
> >> On Jul 1, 2011, at 11:24 AM, Lucian Smith wrote:
> >>
> >>> Indeed, it turns out this is not correct. You can go partway without
> >>> knowing the specifics of a package, but not the whole way, and in my
> >>> opinion, the mess you would make by trying to do it partially would
> >>> not be
> >>> helpful.
> >>>
> >>> Even at the most basic aggregation level, if you want to output a
> >>> non-hierarchical model, you're going to have to worry about namespace
> >>> issues. Let's go ahead and look at spatial, since I've already used
> >>> it
> >>> once. Spatial is set up:
> >>>
> >>> model
> >>> spatial:geometry
> >>> spatial:listOfCoordinateComponents
> >>> spatial:coordinateComponent
> >>> spatial:listOfDomainTypes
> >>> spatial:domainType
> >>> [a few more spatial:listOfs]
> >>> listofCompartments
> >>> compartment
> >>> spatial:listOfCompartmentMappings
> >>> spatial:compartmentMapping
> >>>
> >>>
> >>> If you are aggregating two models with these structures, you're
> >>> going to
> >>> have to figure out that the final model should have exactly one
> >>> 'geometry'
> >>> object, and exactly one 'listofCoordinateComponents' object, but
> >>> that the
> >>> various coordinateComponent objects from both models should be
> >>> combined as
> >>> children of the same parent listOfCoordinateComponents model.
> >>>
> >>> Now, maybe you could invent an algorithm to figure this out for you,
> >>> or
> >>> maybe we could have rules for packages that made this explicit. But
> >>> it's
> >>> a bit chancy, and I'm nervous about saying that even this simple step
> >>> could be automated without knowing about spatial.
> >>>
> >>> Beyond this, however, there's the issue of having to end up with
> >>> unique
> >>> names. As it happens, as written, the spatial package has defined a
> >>> whole
> >>> new namespace 'Spid' that needs to be unique. A coordinate
> >>> component has
> >>> the attributes 'spatialId', 'coordinateIndex', 'componentType', and
> >>> 'sbmlUnit'. The first thing is that none of them are 'id' which might
> >>> give us a clue about namespaces. But if we aggregated two models that
> >>> each had a coordinateComponent with the same value for their
> >>> 'spatialId'
> >>> attribute, it would turn out that without renaming, we would have just
> >>> created an invalid model.
> >>>
> >>> Also suspicious is the 'sbmlUnit' attribute. I can't quite tell
> >>> from the
> >>> spatial specification, but it's a good bet that this is the type
> >>> 'UnitSIdRef'. If we rename a unit from the core spec, who is to
> >>> know that
> >>> this 'spatial:sbmlUnit' attribute also needs to be changed? Without
> >>> knowing spatial, you won't be able to tell.
> >>>
> >>> Finally, there's the compartmentMapping element. This element has the
> >>> attributes 'spatialId (Spid)', 'compartment (SIdRef)', 'domainType
> >>> (SpidRef)', and 'initSize (double)'. The first has the same issue
> >>> we've
> >>> arleady talked about. The second has the same problem as the sbmlUnit
> >>> attribute: if you change the compartment's SId, you'll need to change
> >>> this attribute as well. And 'domainType' is yet another problem:
> >>> here,
> >>> if the Spid of the element to which it refers has changed, we need
> >>> to know
> >>> that this is to be changed as well.
> >>>
> >>> And this is before you even get to replacements and deletions.
> >>> Deletions
> >>> are probably actually safe to follow the rules for: all you have to
> >>> do is
> >>> remove them from the model. And replacements *mostly* have exactly
> >>> the
> >>> same issues as aggregation, above.
> >>>
> >>> But once your new elements have a mathematical meaning, suddenly you
> >>> have
> >>> to worry about conversion factors, too, which are if anything a larger
> >>> mess than anything we've discussed yet. There's a whole table at
> >>> the end
> >>> of the comp spec that talks about how to convert all sorts of
> >>> different
> >>> SBML core constructs according to the default model units. If any of
> >>> these new spatial elements have a mathematical meaning, will they be
> >>> in
> >>> units of length? area? volume? time? time/volume?
> >>> extent*length? It
> >>> would be hopeless to even begin to try to flatten such a mathematical
> >>> model without understanding its semantics.
> >>>
> >>> Even *with* understanding the semantics, it's going to be hard!
> >>> When I
> >>> write the flattening algorithm for core, I'm going to be paying
> >>> attention
> >>> to how best let packages hook into those algorithms. The trick will
> >>> be to
> >>> give them functions that let them know what needs to be done, while
> >>> letting them use their understanding of their semantics to accomplish
> >>> this.
> >>>
> >>> -Lucian
> >>>
> >>> * Chris J. Myers <myers@ece.utah.edu> [2011-07-01 15:27] writes:
> >>>> I replaced the reply to sbml-comp, so we stop spamming discuss :-).
> >>>>
> >>>> This was actually kind of what I was trying to say in my message. I
> >>>> think flattening should not need package awareness.
> >>>>
> >>>> Lucian: if this assumption is not correct, can you provide a concrete
> >>>> example?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>> On Jul 1, 2011, at 4:00 AM, Sarah Keating wrote:
> >>>>
> >>>>> Hi Guys
> >>>>>
> >>>>> Just throwing another thought into the discussion.
> >>>>>
> >>>>> I making the assumption that a 'flattening' algorithm needs to deal
> >>>>> with
> >>>>> packages whether it knows about them or not. It should essential
> >>>>> just
> >>>>> copy or delete based on references and not care whether it
> >>>>> understands
> >>>>> what it is copying/deleting.
> >>>>>
> >>>>> If that is true then if a comp model was flattened BEFORE any
> >>>>> unrecognised packages were stripped the result should be a
> >>>>> syntactically
> >>>>> valid model.
> >>>>>
> >>>>> Could the 'must leave syntactically correct model' requirement in
> >>>>> comp
> >>>>> be imposed as a post flattening requirement ??
> >>>>>
> >>>>> Sarah
> >>>>>
> >>>>> Of course, if the flattening algorithm has to know about packages
> >>>>> that
> >>>>> it does not know about then we are all up the creek sans paddle :-)
> >>>>>
> >>>>>
> >>>>> On 29/06/2011 19:45, Lucian Smith wrote:
> >>>>>> One of the principles we established for the relationship between
> >>>>>> Level 3
> >>>>>> core and Level 3 packages is that if you strip out the package
> >>>>>> information, the remainder of the model must be syntactically
> >>>>>> valid, if
> >>>>>> not semantically understandable.
> >>>>>>
> >>>>>> If this principle was applied to packages, it would mean that if
> >>>>>> you had
> >>>>>> multiple packages, and stripped just one of them, the remainder of
> >>>>>> the
> >>>>>> model must again be syntactically valid.
> >>>>>>
> >>>>>> As currently written, this is not true for 'comp', and I need your
> >>>>>> input
> >>>>>> as to whether this is OK or not, and how I should structure
> >>>>>> validation
> >>>>>> rules accordingly.
> >>>>>>
> >>>>>> The issue is that I have Replacement and Deletion objects in comp
> >>>>>> that
> >>>>>> need to point to other-package-defined constructs. As an example,
> >>>>>> if you
> >>>>>> wanted to make a hierarchically composed spatial model, you would
> >>>>>> need to
> >>>>>> be able to refer to the Geometry objects in the submodels, to say
> >>>>>> they
> >>>>>> should be replaced or deleted.
> >>>>>>
> >>>>>> So, assuming you referred to that Geometry object by its metaID,
> >>>>>> you might
> >>>>>> have a ReplacedElement object that looked like:
> >>>>>>
> >>>>>> <comp:replacedElement comp:metaIdRef="sphere1"
> >>>>>> comp:submodelRef="A" comp:identical="true"/>
> >>>>>>
> >>>>>> The problem is that if you stripped out the spatial package
> >>>>>> information,
> >>>>>> suddenly you are left with a dangling reference: 'sphere1' no
> >>>>>> longer
> >>>>>> refers to anything you can parse.
> >>>>>>
> >>>>>> In my opinion, it would make things entirely too complicated to do
> >>>>>> the
> >>>>>> usual indirection we do to accomplish the 'fallback principle' for
> >>>>>> core.
> >>>>>> Do you all agree? And if you do, how would you recommend I write
> >>>>>> the
> >>>>>> validation rules for the 'metaIdRef' attribute?
> >>>>>>
> >>>>>> -Lucian
> >>>>>> ____________________________________________________________
> >>>>>> To manage your sbml-discuss list subscription, visit
> >>>>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
> >>>>>>
> >>>>>> For a web interface to the sbml-discuss mailing list, visit
> >>>>>> http://sbml.org/Forums/
> >>>>>>
> >>>>>> For questions or feedback about the sbml-discuss list,
> >>>>>> contact sbml-team@caltech.edu
> >>>>>>
> >>>>>
> >>>>> ____________________________________________________________
> >>>>> To manage your sbml-discuss list subscription, visit
> >>>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
> >>>>>
> >>>>> For a web interface to the sbml-discuss mailing list, visit
> >>>>> http://sbml.org/Forums/
> >>>>>
> >>>>> For questions or feedback about the sbml-discuss list,
> >>>>> contact sbml-team@caltech.edu
> >>>>
> >>>>
> >>>> ------------------------------------------------------------------------------
> >>>> All of the data generated in your IT infrastructure is seriously
> >>>> valuable.
> >>>> Why? It contains a definitive record of application performance,
> >>>> security
> >>>> threats, fraudulent activity, and more. Splunk takes this data and
> >>>> makes
> >>>> sense of it. IT sense. And common sense.
> >>>> http://p.sf.net/sfu/splunk-d2d-c2
> >>>> _______________________________________________
> >>>> sbml-comp mailing list
> >>>> sbml-comp@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/sbml-comp
> >>>
> >>> ------------------------------------------------------------------------------
> >>> All of the data generated in your IT infrastructure is seriously
> >>> valuable.
> >>> Why? It contains a definitive record of application performance,
> >>> security
> >>> threats, fraudulent activity, and more. Splunk takes this data and
> >>> makes
> >>> sense of it. IT sense. And common sense.
> >>> http://p.sf.net/sfu/splunk-d2d-c2
> >>> _______________________________________________
> >>> sbml-comp mailing list
> >>> sbml-comp@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/sbml-comp
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> All of the data generated in your IT infrastructure is seriously valuable.
> >> Why? It contains a definitive record of application performance, security
> >> threats, fraudulent activity, and more. Splunk takes this data and makes
> >> sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> _______________________________________________
> >> sbml-comp mailing list
> >> sbml-comp@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/sbml-comp
> >
> > ------------------------------------------------------------------------------
> > All of the data generated in your IT infrastructure is seriously valuable.
> > Why? It contains a definitive record of application performance, security
> > threats, fraudulent activity, and more. Splunk takes this data and makes
> > sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > sbml-comp mailing list
> > sbml-comp@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/sbml-comp
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> sbml-comp mailing list
> sbml-comp@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
sbml-comp mailing list
sbml-comp@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbml-comp