sed-ml-discuss — Migrating to google groups: https://groups.google.com/d/forum/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[David B. <d.b...@au...>]

Hi,

Could this discussion be resolved by extending SED-ML to include a 
`name` attribute that is unique amongst a given class of XML elements 
(and keep `id` as unique within a document)??

Then what about combining an element's tag name with the value of its 
name attribute (if it has one) with '.' and then combining these named 
tags with `/` to produce relative URIs? As an example, in the XML document:

<A>
   <B name="name_b1">
     <C>
       <D name="name_d"/>
     </C>
   </B>
   <B name="name_b2">
     <C>
       <D name="name_d" id="123"/>
     </C>
   </B>
</A>

the element with an id of "123" could be referred to both as `#123` or 
`/A/B.name_b2/C/D.name_d`.




Best regards,

Dave





On 11/07/16 7:45 PM, Matthias König wrote:
> Hi Chris,
> I am using the python bindings to libsedml.
> Sorry for the confusion with the model.
>
> Here the correct example using the SedDocument (code just for 
> demonstration, not working example).
> Via the function one can get the element based on the id independent 
> of the class. This is quit useful if one does not want to question all 
> the listOfs.
> I use this a lot in libsbml which has an analogue function, but also 
> in libsedml to quickly O(1) lookup an object without the need to look 
> in all listOfs.
>
> import libsedml
>
> sid ="abd" doc = libsedml.SedDocument()
> element = doc.getElementBySId(sid)
> Matthias
>
> On Mon, Jul 11, 2016 at 3:56 PM, Chris Myers <my...@ec... 
> <mailto:my...@ec...>> wrote:
>
>     Agreed.  I would just like to gauge the pros and cons.
>
>     I’m not sure what you mean by model = Model().  Is this just the
>     Model elements of SED-ML or are you getting all SED-ML objects?  I
>     use jlibSEDML, and there Model is only the Model elements of
>     SED-ML.  Within any single class, there would still be unique ids.
>
>     Chris
>
>
>>     On Jul 11, 2016, at 1:23 AM, Matthias König
>>     <kon...@go... <mailto:kon...@go...>> wrote:
>>
>>     Hi Chris,
>>     the method is
>>     model  = Model()
>>     model.getElementBySId(sid)
>>     I use this method to get my unique objects based on unique ids
>>     and to store things in HashMaps with ids as keys.
>>     As soon as keys, i.e. ids are not unique anymore, the objects in
>>     the hashmaps are overwritten (this is a silent difficult bug,
>>     because all code will work, but will not give the correct results).
>>     Anybody storing anything for lookup via id will have similar issues.
>>
>>     @Chris I don't have a problem to rewrite code, but I fear similar
>>     lookups via id will be part of many code bases. So the unique id
>>     constraint should only be changed if the advantages are much
>>     larger than the costs.
>>
>>     Matthias
>>
>>
>>     On Sun, Jul 10, 2016 at 12:11 AM, Chris Myers <my...@ec...
>>     <mailto:my...@ec...>> wrote:
>>
>>         Lucian, if you had read the whole message, I do mention what
>>         Matthias said.  My concern with his statement is I’m not sure
>>         why he is using Id’s for annotations. In SBML, they are
>>         linked to meta-ids, which would still be globally unique.  If
>>         this is the only use by anyone in the community of the global
>>         unique property, then I still think this is worthy of
>>         discussion.  Namely, is using id’s in this way correct?  If
>>         not, is there another use case for global ids that is
>>         important to people?  If so, how much effort is it to loosen
>>         this requirement.
>>
>>         Maintaining global id uniqueness in a large document places a
>>         huge burden on software. There is a reason why programming
>>         languages use scoping rules, so you don’t need global
>>         variable uniqueness.  With this rule, every time you mint an
>>         id, you must check if it is in use somewhere else, and if so
>>         have a scheme to try again.  Currently, there is no easy way
>>         to do this in jlibSEDML.
>>
>>         I think the jury is still out on whether this rule adds more
>>         burden on software developers than not having this rule. 
>>         Having this rule means my code is broken, and there is no
>>         clean and easy way to fix it currently.  There are not a lot
>>         of SED-ML implementations yet, so if we are to ever consider
>>         changing this rule, it should be sooner than later before
>>         more implementations come to rely on it.
>>
>>         If having this rule helps more people than it hurts, we will
>>         clearly keep it, but if it is the other way around, we need
>>         to consider removing it.  So far, Matthias has explained how
>>         his code relies on the rule, and I’ve explained that my code
>>         is flawed due to this rule.  How do others feel about the
>>         rule and its impact on their code?
>>
>>         Chris
>>
>>>         On Jul 9, 2016, at 3:57 PM, Lucian Smith
>>>         <luc...@gm...
>>>         <mailto:luc...@gm...>> wrote:
>>>
>>>         On Jul 9, 2016 1:10 PM, "Chris Myers" <my...@ec...
>>>         <mailto:my...@ec...>> wrote:
>>>         >
>>>         > But will it really break things?
>>>
>>>         Yes, Matthias said it would break his code.
>>>
>>>         -Lucian
>>>
>>>         ------------------------------------------------------------------------------
>>>         Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T
>>>         Park in San
>>>         Francisco, CA to explore cutting-edge tech and listen to
>>>         tech luminaries
>>>         present their vision of the future. This family event has
>>>         something for
>>>         everyone, including kids. Get more information and register
>>>         today.
>>>         http://sdm.link/attshape_______________________________________________
>>>         SED-ML-discuss mailing list
>>>         SED...@li...
>>>         <mailto:SED...@li...>
>>>         https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>>
>>         ------------------------------------------------------------------------------
>>         Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T
>>         Park in San
>>         Francisco, CA to explore cutting-edge tech and listen to tech
>>         luminaries
>>         present their vision of the future. This family event has
>>         something for
>>         everyone, including kids. Get more information and register
>>         today.
>>         http://sdm.link/attshape
>>         _______________________________________________
>>         SED-ML-discuss mailing list
>>         SED...@li...
>>         <mailto:SED...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>>
>>
>>
>>     -- 
>>     Matthias König
>>     Junior Group Leader LiSym - Systems Medicine of the Liver
>>     Humboldt-University Berlin, Institute for Theoretical Biology
>>     https://www.livermetabolism.com <https://www.livermetabolism.com/>
>>     kon...@go... <mailto:kon...@go...>
>>     Tel: +49 30 20938450
>>     Tel: +49 176 81168480 <tel:%2B49%20176%2081168480>
>>     ------------------------------------------------------------------------------
>>     Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park
>>     in San
>>     Francisco, CA to explore cutting-edge tech and listen to tech
>>     luminaries
>>     present their vision of the future. This family event has
>>     something for
>>     everyone, including kids. Get more information and register today.
>>     http://sdm.link/attshape_______________________________________________
>>     SED-ML-discuss mailing list
>>     SED...@li...
>>     <mailto:SED...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>     ------------------------------------------------------------------------------
>     Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park
>     in San
>     Francisco, CA to explore cutting-edge tech and listen to tech
>     luminaries
>     present their vision of the future. This family event has
>     something for
>     everyone, including kids. Get more information and register today.
>     http://sdm.link/attshape
>     _______________________________________________
>     SED-ML-discuss mailing list
>     SED...@li...
>     <mailto:SED...@li...>
>     https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>
>
> -- 
> Matthias König
> Junior Group Leader LiSym - Systems Medicine of the Liver
> Humboldt-University Berlin, Institute for Theoretical Biology
> https://www.livermetabolism.com
> kon...@go... <mailto:kon...@go...>
> Tel: +49 30 20938450
> Tel: +49 176 81168480
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
>
>
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

[SED-ML-discuss] Extended deadline for abstract submission, COMBINE 2016

[Dagmar W. <dag...@un...>]

== Call for Abstracts ==



== Submission deadline extended ==





COMBINE 2016: 7th Computational Modeling in Biology Network Workshop



19-23 September 2016, Newcastle upon Tyne, UK



http://co.mbine.org/events/COMBINE_2016





The "Computational Modeling in Biology" Network (COMBINE) is an
initiative to coordinate
the development of the various community standards and formats in
systems biology and related fields. COMBINE 2016 will be a
workshop-style event with oral presentations,
posters, and breakout sessions. The five meeting days will include talks
about the COMBINE standards and associated or related standardization
efforts, as well as presentations of tools using these standards. Oral
presentations will be selected from the submitted
abstracts. In addition, poster sessions will allow people to inform each
other about their
software and other projects in a setting that fosters interaction and
in-depth discussion.





== IMPORTANT DATES ==

Abstract submission:        15 July 2016 (Extended)

Scholarship application:    15 July 2016 (Extended)

Notification:               22 July 2016 (Extended)

COMBINE Workshop:  19-23 September 2016





== KEYNOTE SPEAKERS ==

- Alfonso Bueno-Orovio (Oxford)

- Carole Goble (Manchester)

- Michael Hucka (Caltech)

- Dagmar Iber (ETH Zurich)

- Andrew Millar (Edinburgh)

- Chris J. Myers (Utah)

- David Nickerson (Auckland)

- Daryl Shanley (Newcastle)

- Yujiang Wang (Newcastle)





== TOPICS OF INTEREST ==

Topics include, but are not limited to:

- Data exchange and model standards for systems biology

- Graphical notation standards for systems biology

- Standards for sharing and analysing biological pathway data

- Standards for computational biological models

More on the COMBINE standards at http://co.mbine.org/standards





== CALL FOR ABSTRACTS ==

We solicit high-quality abstracts, to be refereed by the COMBINE
Coordinators below, for either
 oral or poster presentation at the Workshop. Abstracts will appear on
the COMBINE website only,
 there will be no formal publication.



Please see the COMBINE website for submission instructions.





== TRAVEL SCHOLARSHIPS ==

PhD students and postdocs may apply for travel funds to attend COMBINE.
More information
on the COMBINE website.





== ACKNOWLEDGEMENTS ==

COMBINE 2016 is generously supported by:

- Engineering and Physical Sciences Research Council (UK) [AUDACIOUS
project EP/J004111/2]

- Interdisciplinary Computing and Complex BioSystems Group (ICOS)

- School of Computing Science, Newcastle University

- National Science Foundation (USA)





== LOCAL CHAIRS ==

Paolo Zuliani & Anil Wipat, ICOS Group, School of Computing Science,
Newcastle University.





== LOCAL ORGANISERS ==

Keith Flanagan & Claire Smith, ICOS Group, School of Computing Science,
Newcastle University.





== COMBINE COORDINATORS ==

Gary Bader (Toronto)

Martin Golebiewski (Heidelberg)

Michael Hucka (Caltech)

Nicolas Le Novère (Babraham)

Chris J. Myers (Utah)

David Nickerson (Auckland)

Falk Schreiber (Monash)

Dagmar Waltemath (Rostock)

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Matthias K. <kon...@go...>]

Hi Chris,
I am using the python bindings to libsedml.
Sorry for the confusion with the model.

Here the correct example using the SedDocument (code just for
demonstration, not working example).
Via the function one can get the element based on the id independent of the
class. This is quit useful if one does not want to question all the listOfs.
I use this a lot in libsbml which has an analogue function, but also in
libsedml to quickly O(1) lookup an object without the need to look in all
listOfs.

import libsedml

sid = "abd"
doc = libsedml.SedDocument()
element = doc.getElementBySId(sid)

Matthias

On Mon, Jul 11, 2016 at 3:56 PM, Chris Myers <my...@ec...> wrote:

> Agreed.  I would just like to gauge the pros and cons.
>
> I’m not sure what you mean by model = Model().  Is this just the Model
> elements of SED-ML or are you getting all SED-ML objects?  I use jlibSEDML,
> and there Model is only the Model elements of SED-ML.  Within any single
> class, there would still be unique ids.
>
> Chris
>
>
> On Jul 11, 2016, at 1:23 AM, Matthias König <kon...@go...>
> wrote:
>
> Hi Chris,
> the method is
>
> model = Model()
> model.getElementBySId(sid)
>
> I use this method to get my unique objects based on unique ids and to
> store things in HashMaps with ids as keys.
> As soon as keys, i.e. ids are not unique anymore, the objects in the
> hashmaps are overwritten (this is a silent difficult bug, because all code
> will work, but will not give the correct results).
> Anybody storing anything for lookup via id will have similar issues.
>
> @Chris I don't have a problem to rewrite code, but I fear similar lookups
> via id will be part of many code bases. So the unique id constraint should
> only be changed if the advantages are much larger than the costs.
>
> Matthias
>
>
> On Sun, Jul 10, 2016 at 12:11 AM, Chris Myers <my...@ec...> wrote:
>
>> Lucian, if you had read the whole message, I do mention what Matthias
>> said.  My concern with his statement is I’m not sure why he is using Id’s
>> for annotations.  In SBML, they are linked to meta-ids, which would still
>> be globally unique.  If this is the only use by anyone in the community of
>> the global unique property, then I still think this is worthy of
>> discussion.  Namely, is using id’s in this way correct?  If not, is there
>> another use case for global ids that is important to people?  If so, how
>> much effort is it to loosen this requirement.
>>
>> Maintaining global id uniqueness in a large document places a huge burden
>> on software. There is a reason why programming languages use scoping rules,
>> so you don’t need global variable uniqueness.  With this rule, every time
>> you mint an id, you must check if it is in use somewhere else, and if so
>> have a scheme to try again.  Currently, there is no easy way to do this in
>> jlibSEDML.
>>
>> I think the jury is still out on whether this rule adds more burden on
>> software developers than not having this rule.  Having this rule means my
>> code is broken, and there is no clean and easy way to fix it currently.
>> There are not a lot of SED-ML implementations yet, so if we are to ever
>> consider changing this rule, it should be sooner than later before more
>> implementations come to rely on it.
>>
>> If having this rule helps more people than it hurts, we will clearly keep
>> it, but if it is the other way around, we need to consider removing it.  So
>> far, Matthias has explained how his code relies on the rule, and I’ve
>> explained that my code is flawed due to this rule.  How do others feel
>> about the rule and its impact on their code?
>>
>> Chris
>>
>> On Jul 9, 2016, at 3:57 PM, Lucian Smith <luc...@gm...>
>> wrote:
>>
>> On Jul 9, 2016 1:10 PM, "Chris Myers" <my...@ec...> wrote:
>> >
>> > But will it really break things?
>>
>> Yes, Matthias said it would break his code.
>>
>> -Lucian
>>
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape_______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>>
>
>
> --
> Matthias König
> Junior Group Leader LiSym - Systems Medicine of the Liver
> Humboldt-University Berlin, Institute for Theoretical Biology
>   https://www.livermetabolism.com
> kon...@go...
> Tel: +49 30 20938450
> Tel: +49 176 81168480
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>


-- 
Matthias König
Junior Group Leader LiSym - Systems Medicine of the Liver
Humboldt-University Berlin, Institute for Theoretical Biology
  https://www.livermetabolism.com
kon...@go...
Tel: +49 30 20938450
Tel: +49 176 81168480

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Chris M. <my...@ec...>]

Agreed.  I would just like to gauge the pros and cons.  

I’m not sure what you mean by model = Model().  Is this just the Model elements of SED-ML or are you getting all SED-ML objects?  I use jlibSEDML, and there Model is only the Model elements of SED-ML.  Within any single class, there would still be unique ids.

Chris

> On Jul 11, 2016, at 1:23 AM, Matthias König <kon...@go...> wrote:
> 
> Hi Chris,
> the method is
> model = Model()
> model.getElementBySId(sid)
> I use this method to get my unique objects based on unique ids and to store things in HashMaps with ids as keys.
> As soon as keys, i.e. ids are not unique anymore, the objects in the hashmaps are overwritten (this is a silent difficult bug, because all code will work, but will not give the correct results).
> Anybody storing anything for lookup via id will have similar issues.
> 
> @Chris I don't have a problem to rewrite code, but I fear similar lookups via id will be part of many code bases. So the unique id constraint should only be changed if the advantages are much larger than the costs.
> 
> Matthias
> 
> 
> On Sun, Jul 10, 2016 at 12:11 AM, Chris Myers <my...@ec... <mailto:my...@ec...>> wrote:
> Lucian, if you had read the whole message, I do mention what Matthias said.  My concern with his statement is I’m not sure why he is using Id’s for annotations.  In SBML, they are linked to meta-ids, which would still be globally unique.  If this is the only use by anyone in the community of the global unique property, then I still think this is worthy of discussion.  Namely, is using id’s in this way correct?  If not, is there another use case for global ids that is important to people?  If so, how much effort is it to loosen this requirement.  
> 
> Maintaining global id uniqueness in a large document places a huge burden on software. There is a reason why programming languages use scoping rules, so you don’t need global variable uniqueness.  With this rule, every time you mint an id, you must check if it is in use somewhere else, and if so have a scheme to try again.  Currently, there is no easy way to do this in jlibSEDML. 
> 
> I think the jury is still out on whether this rule adds more burden on software developers than not having this rule.  Having this rule means my code is broken, and there is no clean and easy way to fix it currently.  There are not a lot of SED-ML implementations yet, so if we are to ever consider changing this rule, it should be sooner than later before more implementations come to rely on it.
> 
> If having this rule helps more people than it hurts, we will clearly keep it, but if it is the other way around, we need to consider removing it.  So far, Matthias has explained how his code relies on the rule, and I’ve explained that my code is flawed due to this rule.  How do others feel about the rule and its impact on their code?  
> 
> Chris
> 
>> On Jul 9, 2016, at 3:57 PM, Lucian Smith <luc...@gm... <mailto:luc...@gm...>> wrote:
>> 
>> On Jul 9, 2016 1:10 PM, "Chris Myers" <my...@ec... <mailto:my...@ec...>> wrote:
>> >
>> > But will it really break things?
>> 
>> Yes, Matthias said it would break his code.
>> 
>> -Lucian
>> 
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape_______________________________________________ <http://sdm.link/attshape_______________________________________________>
>> SED-ML-discuss mailing list
>> SED...@li... <mailto:SED...@li...>
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> 
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape <http://sdm.link/attshape>
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li... <mailto:SED...@li...>
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> 
> 
> 
> 
> -- 
> Matthias König
> Junior Group Leader LiSym - Systems Medicine of the Liver
> Humboldt-University Berlin, Institute for Theoretical Biology
>   https://www.livermetabolism.com <https://www.livermetabolism.com/>
> kon...@go... <mailto:kon...@go...>
> Tel: +49 30 20938450
> Tel: +49 176 81168480
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Matthias K. <kon...@go...>]

Hi Chris,
the method is

model = Model()
model.getElementBySId(sid)

I use this method to get my unique objects based on unique ids and to store
things in HashMaps with ids as keys.
As soon as keys, i.e. ids are not unique anymore, the objects in the
hashmaps are overwritten (this is a silent difficult bug, because all code
will work, but will not give the correct results).
Anybody storing anything for lookup via id will have similar issues.

@Chris I don't have a problem to rewrite code, but I fear similar lookups
via id will be part of many code bases. So the unique id constraint should
only be changed if the advantages are much larger than the costs.

Matthias


On Sun, Jul 10, 2016 at 12:11 AM, Chris Myers <my...@ec...> wrote:

> Lucian, if you had read the whole message, I do mention what Matthias
> said.  My concern with his statement is I’m not sure why he is using Id’s
> for annotations.  In SBML, they are linked to meta-ids, which would still
> be globally unique.  If this is the only use by anyone in the community of
> the global unique property, then I still think this is worthy of
> discussion.  Namely, is using id’s in this way correct?  If not, is there
> another use case for global ids that is important to people?  If so, how
> much effort is it to loosen this requirement.
>
> Maintaining global id uniqueness in a large document places a huge burden
> on software. There is a reason why programming languages use scoping rules,
> so you don’t need global variable uniqueness.  With this rule, every time
> you mint an id, you must check if it is in use somewhere else, and if so
> have a scheme to try again.  Currently, there is no easy way to do this in
> jlibSEDML.
>
> I think the jury is still out on whether this rule adds more burden on
> software developers than not having this rule.  Having this rule means my
> code is broken, and there is no clean and easy way to fix it currently.
> There are not a lot of SED-ML implementations yet, so if we are to ever
> consider changing this rule, it should be sooner than later before more
> implementations come to rely on it.
>
> If having this rule helps more people than it hurts, we will clearly keep
> it, but if it is the other way around, we need to consider removing it.  So
> far, Matthias has explained how his code relies on the rule, and I’ve
> explained that my code is flawed due to this rule.  How do others feel
> about the rule and its impact on their code?
>
> Chris
>
> On Jul 9, 2016, at 3:57 PM, Lucian Smith <luc...@gm...>
> wrote:
>
> On Jul 9, 2016 1:10 PM, "Chris Myers" <my...@ec...> wrote:
> >
> > But will it really break things?
>
> Yes, Matthias said it would break his code.
>
> -Lucian
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>


-- 
Matthias König
Junior Group Leader LiSym - Systems Medicine of the Liver
Humboldt-University Berlin, Institute for Theoretical Biology
  https://www.livermetabolism.com
kon...@go...
Tel: +49 30 20938450
Tel: +49 176 81168480

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Chris M. <my...@ec...>]

Lucian, if you had read the whole message, I do mention what Matthias said.  My concern with his statement is I’m not sure why he is using Id’s for annotations.  In SBML, they are linked to meta-ids, which would still be globally unique.  If this is the only use by anyone in the community of the global unique property, then I still think this is worthy of discussion.  Namely, is using id’s in this way correct?  If not, is there another use case for global ids that is important to people?  If so, how much effort is it to loosen this requirement.  

Maintaining global id uniqueness in a large document places a huge burden on software. There is a reason why programming languages use scoping rules, so you don’t need global variable uniqueness.  With this rule, every time you mint an id, you must check if it is in use somewhere else, and if so have a scheme to try again.  Currently, there is no easy way to do this in jlibSEDML. 

I think the jury is still out on whether this rule adds more burden on software developers than not having this rule.  Having this rule means my code is broken, and there is no clean and easy way to fix it currently.  There are not a lot of SED-ML implementations yet, so if we are to ever consider changing this rule, it should be sooner than later before more implementations come to rely on it.

If having this rule helps more people than it hurts, we will clearly keep it, but if it is the other way around, we need to consider removing it.  So far, Matthias has explained how his code relies on the rule, and I’ve explained that my code is flawed due to this rule.  How do others feel about the rule and its impact on their code?  

Chris

> On Jul 9, 2016, at 3:57 PM, Lucian Smith <luc...@gm...> wrote:
> 
> On Jul 9, 2016 1:10 PM, "Chris Myers" <my...@ec... <mailto:my...@ec...>> wrote:
> >
> > But will it really break things?
> 
> Yes, Matthias said it would break his code.
> 
> -Lucian
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Lucian S. <luc...@gm...>]

On Jul 9, 2016 1:10 PM, "Chris Myers" <my...@ec...> wrote:
>
> But will it really break things?

Yes, Matthias said it would break his code.

-Lucian

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Chris M. <my...@ec...>]

But will it really break things? I’m not so sure that we need all ids to be globally unique.  The reason I brought this up initially is there is no method even in jlibsedml to get an object by its id.  You have to loop through all different objects with ids to check to see if an id is in use.  This is very cumbersome and is most likely going to lead to very fragile software implementations.  I honestly feel that requiring global uniqueness makes it harder and not easier to make software that works.  Again, with the limited resources argument, why have a rule that makes it more difficult to make software that works.  It is much easier to write software to ensure local uniqueness, and if your software actually ensures global uniqueness then it is also satisfy local uniqueness rules.  So, software that generates SED-ML would benefit or at least not be harmed by this change.

The only question then is how much does software that reads SED-ML rely upon global id uniqueness.  Matthias mentioned that he uses this assumption for annotations, but shouldn’t annotations be connecting with the Meta-id?  That is the way it is done in SBML.  

Herbert: in what way does your software rely on this assumption?  Do you have code where you fetch an object by its Id then check what it is, and respond accordingly?  If so, what purpose is that code?  If not, then the changes I’m proposing would not cause any changes to your software.

In all places that I’m fetching by id currently, I know what type of object I’m fetching.  For example, if I’m working on a task, it has a model reference and a simulation reference.  If I fetch the model reference, I know to expect that I’m fetching a Model, so I fetch the object from the list of Models.  Same for simulation reference.  Therefore, if the Task, Model, and Simulation all have the same Id, I would not have any difficulty, since I always know the type of object that I’m looking for and thus which list to look for that object.

Maybe I’m missing something, but it seems that loosening the global id requirement actually ends up making better use of our limited resources than the opposite.

Chris

> On Jul 8, 2016, at 11:02 AM, Herbert Sauro <uw....@gm...> wrote:
> 
> I agree with Frank. Even for the next version if ids were made
> non-unique it would mean breaking a lot of existing code which would
> require resources (grants) to update etc. Unless the change is
> absolutely critical, ie there are use cases that cannot be handled as
> it currently stands then don't make the change. There are more
> important things to do with limited resources, eg the need to be able
> to specify more kinds of data, ie eigenvalues etc. and additonal
> simulation approaches, eg fba.
> 
> Herbert
> 
>> Chris ... i think the whole point here is ... like it or not ... right now
>> all ids are unique ... even though we argued at the beginning whether that
>> would be an issue or not. Fact is ... there is no loss of generality with
>> having everything unique ... those application that depend on it will do
>> fine ... others can cope (as you can convert all models wehere you suggest
>> there would not be a conflict if you had them non-unique to one with unique
>> ids). So why change at this point? Clearly we would argue for a long time,
>> then another proposal would be made, then there would be support for it
>> before it is accepted, minted and verified.
> 
>> Cheers
>> Frank
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Herbert S. <uw....@gm...>]

I agree with Frank. Even for the next version if ids were made
non-unique it would mean breaking a lot of existing code which would
require resources (grants) to update etc. Unless the change is
absolutely critical, ie there are use cases that cannot be handled as
it currently stands then don't make the change. There are more
important things to do with limited resources, eg the need to be able
to specify more kinds of data, ie eigenvalues etc. and additonal
simulation approaches, eg fba.

Herbert

> Chris ... i think the whole point here is ... like it or not ... right now
> all ids are unique ... even though we argued at the beginning whether that
> would be an issue or not. Fact is ... there is no loss of generality with
> having everything unique ... those application that depend on it will do
> fine ... others can cope (as you can convert all models wehere you suggest
> there would not be a conflict if you had them non-unique to one with unique
> ids). So why change at this point? Clearly we would argue for a long time,
> then another proposal would be made, then there would be support for it
> before it is accepted, minted and verified.

>Cheers
>Frank

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Chris J. M. <my...@ec...>]

Yes it is exactly that a proposal for the next version. I'm not proposing an immediate change.

Chris

Sent from my iPhone

> On Jul 8, 2016, at 9:55 AM, Frank T. Bergmann <fbe...@ca...> wrote:
> 
> Chris ... i think the whole point here is ... like it or not ... right now all ids are unique ... even though we argued at the beginning whether that would be an issue or not. Fact is ... there is no loss of generality with having everything unique ... those application that depend on it will do fine ... others can cope (as you can convert all models wehere you suggest there would not be a conflict if you had them non-unique to one with unique ids). So why change at this point? Clearly we would argue for a long time, then another proposal would be made, then there would be support for it before it is accepted, minted and verified. 
> 
> Cheers
> Frank
> 
>> On Fri, Jul 8, 2016 at 4:25 PM, Chris Myers <my...@ec...> wrote:
>> If you really need a unique id for your work, there is always the MetaId.  In fact, it is supposed to be that id used by annotations.  Also, it would not be difficult to write a converter to “uniquefy” ids, so there would not be any loss of backwards compatibility.  If you want to down convert to an earlier version with unique ids, you would just run this function.  Furthermore, if your application requires unique ids, you could run this function on any file you get.  
>> 
>> Generating unique ids that have some meaningful value for a large file is basically impossible.  The only viable solution to have unique ids is to use hashcodes like Herbert suggested which make them unreadable for use in the application or debugging.  Otherwise, you code must perpetually be checking each generated id against all others, and implement some scheme to vary the id when it is not unique.
>> 
>> Very few languages that I’m aware of do not use scoping for identifiers.  Imagine if you had to write your software with globally unique ids for your variables.  It would be rather unpleasant.  Writing code to write a language with globally unique ids is equally so.
>> 
>> Chris
>> 
>>> On Jul 8, 2016, at 1:37 AM, Matthias König <kon...@go...> wrote:
>>> 
>>> Sorry, forgot to add.
>>> - removing id uniqueness will break backwards-compatibility in a brutal way. At least I rely in large parts of my code base on id uniqueness. 
>>> The main argument in SBML about the unability to remove a timestamp in an annotation was backwards-compatibility. 
>>> Changing one of the core premises about the SEDML document (id uniqueness), should have very good arguments to make such a big step.
>>> 
>>> From my point of view this is more a problem of generating unique ids. Allowing an additional separator character in the ids could solve this.
>>> 
>>> 
>>> 
>>>> On Fri, Jul 8, 2016 at 9:28 AM, Matthias König <kon...@go...> wrote:
>>>> A thing I really like about id uniqueness is to be able to get elements by their ids without the need to know their class.
>>>> This is for instance very helpful if one implements functionality which only requires the common base class.
>>>> For instance working with annotations.
>>>> 
>>>> Breaking the id uniqueness will make the following things like the following more difficult
>>>> model = Model()
>>>> model.getElementBySId(sid)
>>>> Another thing is storing elements in a hashmap for lookup via id.
>>>> One has to create separate hashmaps for the various classes and do a lot of type checking.
>>>> 
>>>> Matthias
>>>> 
>>>> 
>>>>> On Thu, Jul 7, 2016 at 10:52 PM, Lucian Smith <luc...@gm...> wrote:
>>>>> Well, I'll agree that it's better than XPath. But I would rather not use either, and just write the uniqueness rules appropriately.
>>>>> 
>>>>> -Lucian
>>>>> 
>>>>>> On Thu, Jul 7, 2016 at 1:22 PM, Chris Myers <my...@ec...> wrote:
>>>>>> Hmm, I don’t see it as a “hack”, but I guess it is in the eye of the beholder.  I see it as an elegant solution compare with the XPath sledgehammer which I really do not like.
>>>>>> 
>>>>>> I would be happy if we never have to use it, but Frank has indicated at least one case where we need to reference a child and he has promised that it will be needed more in the future.  I would prefer to have a more elegant solution to this problem than XPath.
>>>>>> 
>>>>>> Chris
>>>>>> 
>>>>>>>> On Jul 7, 2016, at 2:16 PM, Lucian Smith <luc...@gm...> wrote:
>>>>>>>> 
>>>>>>> 
>>>>>>>> I think you are confused.  We are not talking about SBML or removing XPath for targets.  What we are suggesting is to remove the requirement for SED-ML file wide id uniqueness.
>>>>>>> 
>>>>>>> Nope, that's exactly what I thought you were proposing.
>>>>>>>  
>>>>>>>> 3) If you must refer to a Child Id (which appears to be rare, Frank mentioned a reference to a Range as an example), you would do so using a scheme with a delimiter.  For example, if you need to refer to a Variable v within a DataGenerator dg (not sure why, but lets assume you do need to), then you would refer to it as: dg.v OR dg/v OR dg\v 
>>>>>>> 
>>>>>>> This is the part I was wondering about.  I want to figure out exactly why you would want to refer to a Child, what other things you might get it confused with, and *not* relax the requirement for uniqueness across that set of things.  The parent/separator/child hack is a new scheme that I feel is almost certainly not worth adding to SED-ML, because we clearly don't need it now, and we probably wouldn't need it even after relaxing most (if not all) of the current uniqueness requirements.
>>>>>>> 
>>>>>>> -Lucian
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>>>> present their vision of the future. This family event has something for
>>>>>>> everyone, including kids. Get more information and register today.
>>>>>>> http://sdm.link/attshape_______________________________________________
>>>>>>> SED-ML-discuss mailing list
>>>>>>> SED...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>>> present their vision of the future. This family event has something for
>>>>>> everyone, including kids. Get more information and register today.
>>>>>> http://sdm.link/attshape
>>>>>> _______________________________________________
>>>>>> SED-ML-discuss mailing list
>>>>>> SED...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>> present their vision of the future. This family event has something for
>>>>> everyone, including kids. Get more information and register today.
>>>>> http://sdm.link/attshape
>>>>> _______________________________________________
>>>>> SED-ML-discuss mailing list
>>>>> SED...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Matthias König
>>>> Junior Group Leader LiSym - Systems Medicine of the Liver
>>>> Humboldt-University Berlin, Institute for Theoretical Biology
>>>>   https://www.livermetabolism.com
>>>> kon...@go...
>>>> Tel: +49 30 20938450
>>>> Tel: +49 176 81168480
>>> 
>>> 
>>> 
>>> -- 
>>> Matthias König
>>> Junior Group Leader LiSym - Systems Medicine of the Liver
>>> Humboldt-University Berlin, Institute for Theoretical Biology
>>>   https://www.livermetabolism.com
>>> kon...@go...
>>> Tel: +49 30 20938450
>>> Tel: +49 176 81168480
>>> ------------------------------------------------------------------------------
>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>> present their vision of the future. This family event has something for
>>> everyone, including kids. Get more information and register today.
>>> http://sdm.link/attshape_______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>> 
>> 
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Frank T. B. <fbe...@ca...>]

Chris ... i think the whole point here is ... like it or not ... right now
all ids are unique ... even though we argued at the beginning whether that
would be an issue or not. Fact is ... there is no loss of generality with
having everything unique ... those application that depend on it will do
fine ... others can cope (as you can convert all models wehere you suggest
there would not be a conflict if you had them non-unique to one with unique
ids). So why change at this point? Clearly we would argue for a long time,
then another proposal would be made, then there would be support for it
before it is accepted, minted and verified.

Cheers
Frank

On Fri, Jul 8, 2016 at 4:25 PM, Chris Myers <my...@ec...> wrote:

> If you really need a unique id for your work, there is always the MetaId.
> In fact, it is supposed to be that id used by annotations.  Also, it would
> not be difficult to write a converter to “uniquefy” ids, so there would not
> be any loss of backwards compatibility.  If you want to down convert to an
> earlier version with unique ids, you would just run this function.
> Furthermore, if your application requires unique ids, you could run this
> function on any file you get.
>
> Generating unique ids that have some meaningful value for a large file is
> basically impossible.  The only viable solution to have unique ids is to
> use hashcodes like Herbert suggested which make them unreadable for use in
> the application or debugging.  Otherwise, you code must perpetually be
> checking each generated id against all others, and implement some scheme to
> vary the id when it is not unique.
>
> Very few languages that I’m aware of do not use scoping for identifiers.
> Imagine if you had to write your software with globally unique ids for your
> variables.  It would be rather unpleasant.  Writing code to write a
> language with globally unique ids is equally so.
>
> Chris
>
> On Jul 8, 2016, at 1:37 AM, Matthias König <kon...@go...>
> wrote:
>
> Sorry, forgot to add.
> - removing id uniqueness will break backwards-compatibility in a brutal
> way. At least I rely in large parts of my code base on id uniqueness.
> The main argument in SBML about the unability to remove a timestamp in an
> annotation was backwards-compatibility.
> Changing one of the core premises about the SEDML document (id
> uniqueness), should have very good arguments to make such a big step.
>
> From my point of view this is more a problem of generating unique ids.
> Allowing an additional separator character in the ids could solve this.
>
>
>
> On Fri, Jul 8, 2016 at 9:28 AM, Matthias König <kon...@go...>
> wrote:
>
>> A thing I really like about id uniqueness is to be able to get elements
>> by their ids without the need to know their class.
>> This is for instance very helpful if one implements functionality which
>> only requires the common base class.
>> For instance working with annotations.
>>
>> Breaking the id uniqueness will make the following things like the
>> following more difficult
>>
>> model = Model()
>> model.getElementBySId(sid)
>>
>> Another thing is storing elements in a hashmap for lookup via id.
>> One has to create separate hashmaps for the various classes and do a lot
>> of type checking.
>>
>> Matthias
>>
>>
>> On Thu, Jul 7, 2016 at 10:52 PM, Lucian Smith <luc...@gm...>
>> wrote:
>>
>>> Well, I'll agree that it's better than XPath. But I would rather not use
>>> either, and just write the uniqueness rules appropriately.
>>>
>>> -Lucian
>>>
>>> On Thu, Jul 7, 2016 at 1:22 PM, Chris Myers <my...@ec...> wrote:
>>>
>>>> Hmm, I don’t see it as a “hack”, but I guess it is in the eye of the
>>>> beholder.  I see it as an elegant solution compare with the XPath
>>>> sledgehammer which I really do not like.
>>>>
>>>> I would be happy if we never have to use it, but Frank has indicated at
>>>> least one case where we need to reference a child and he has promised that
>>>> it will be needed more in the future.  I would prefer to have a more
>>>> elegant solution to this problem than XPath.
>>>>
>>>> Chris
>>>>
>>>> On Jul 7, 2016, at 2:16 PM, Lucian Smith <luc...@gm...>
>>>> wrote:
>>>>
>>>> I think you are confused.  We are not talking about SBML or removing
>>>>> XPath for targets.  What we are suggesting is to remove the requirement for
>>>>> SED-ML file wide id uniqueness.
>>>>>
>>>>
>>>> Nope, that's exactly what I thought you were proposing.
>>>>
>>>>
>>>>> 3) If you must refer to a Child Id (which appears to be rare, Frank
>>>>> mentioned a reference to a Range as an example), you would do so using a
>>>>> scheme with a delimiter.  For example, if you need to refer to a Variable v
>>>>> within a DataGenerator dg (not sure why, but lets assume you do need to),
>>>>> then you would refer to it as: dg.v OR dg/v OR dg\v
>>>>>
>>>>
>>>> This is the part I was wondering about.  I want to figure out exactly
>>>> why you would want to refer to a Child, what other things you might get it
>>>> confused with, and *not* relax the requirement for uniqueness across that
>>>> set of things.  The parent/separator/child hack is a new scheme that I feel
>>>> is almost certainly not worth adding to SED-ML, because we clearly don't
>>>> need it now, and we probably wouldn't need it even after relaxing most (if
>>>> not all) of the current uniqueness requirements.
>>>>
>>>> -Lucian
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>> present their vision of the future. This family event has something for
>>>> everyone, including kids. Get more information and register today.
>>>> http://sdm.link/attshape_______________________________________________
>>>> SED-ML-discuss mailing list
>>>> SED...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>> present their vision of the future. This family event has something for
>>>> everyone, including kids. Get more information and register today.
>>>> http://sdm.link/attshape
>>>> _______________________________________________
>>>> SED-ML-discuss mailing list
>>>> SED...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>> present their vision of the future. This family event has something for
>>> everyone, including kids. Get more information and register today.
>>> http://sdm.link/attshape
>>> _______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>
>>>
>>
>>
>> --
>> Matthias König
>> Junior Group Leader LiSym - Systems Medicine of the Liver
>> Humboldt-University Berlin, Institute for Theoretical Biology
>>   https://www.livermetabolism.com
>> kon...@go...
>> Tel: +49 30 20938450
>> Tel: +49 176 81168480
>>
>
>
>
> --
> Matthias König
> Junior Group Leader LiSym - Systems Medicine of the Liver
> Humboldt-University Berlin, Institute for Theoretical Biology
>   https://www.livermetabolism.com
> kon...@go...
> Tel: +49 30 20938450
> Tel: +49 176 81168480
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Chris M. <my...@ec...>]

If you really need a unique id for your work, there is always the MetaId.  In fact, it is supposed to be that id used by annotations.  Also, it would not be difficult to write a converter to “uniquefy” ids, so there would not be any loss of backwards compatibility.  If you want to down convert to an earlier version with unique ids, you would just run this function.  Furthermore, if your application requires unique ids, you could run this function on any file you get.  

Generating unique ids that have some meaningful value for a large file is basically impossible.  The only viable solution to have unique ids is to use hashcodes like Herbert suggested which make them unreadable for use in the application or debugging.  Otherwise, you code must perpetually be checking each generated id against all others, and implement some scheme to vary the id when it is not unique.

Very few languages that I’m aware of do not use scoping for identifiers.  Imagine if you had to write your software with globally unique ids for your variables.  It would be rather unpleasant.  Writing code to write a language with globally unique ids is equally so.

Chris

> On Jul 8, 2016, at 1:37 AM, Matthias König <kon...@go...> wrote:
> 
> Sorry, forgot to add.
> - removing id uniqueness will break backwards-compatibility in a brutal way. At least I rely in large parts of my code base on id uniqueness. 
> The main argument in SBML about the unability to remove a timestamp in an annotation was backwards-compatibility. 
> Changing one of the core premises about the SEDML document (id uniqueness), should have very good arguments to make such a big step.
> 
> From my point of view this is more a problem of generating unique ids. Allowing an additional separator character in the ids could solve this.
> 
> 
> 
> On Fri, Jul 8, 2016 at 9:28 AM, Matthias König <kon...@go... <mailto:kon...@go...>> wrote:
> A thing I really like about id uniqueness is to be able to get elements by their ids without the need to know their class.
> This is for instance very helpful if one implements functionality which only requires the common base class.
> For instance working with annotations.
> 
> Breaking the id uniqueness will make the following things like the following more difficult
> model = Model()
> model.getElementBySId(sid)
> Another thing is storing elements in a hashmap for lookup via id.
> One has to create separate hashmaps for the various classes and do a lot of type checking.
> 
> Matthias
> 
> 
> On Thu, Jul 7, 2016 at 10:52 PM, Lucian Smith <luc...@gm... <mailto:luc...@gm...>> wrote:
> Well, I'll agree that it's better than XPath. But I would rather not use either, and just write the uniqueness rules appropriately.
> 
> -Lucian
> 
> On Thu, Jul 7, 2016 at 1:22 PM, Chris Myers <my...@ec... <mailto:my...@ec...>> wrote:
> Hmm, I don’t see it as a “hack”, but I guess it is in the eye of the beholder.  I see it as an elegant solution compare with the XPath sledgehammer which I really do not like.
> 
> I would be happy if we never have to use it, but Frank has indicated at least one case where we need to reference a child and he has promised that it will be needed more in the future.  I would prefer to have a more elegant solution to this problem than XPath.
> 
> Chris
> 
>> On Jul 7, 2016, at 2:16 PM, Lucian Smith <luc...@gm... <mailto:luc...@gm...>> wrote:
>> 
>> I think you are confused.  We are not talking about SBML or removing XPath for targets.  What we are suggesting is to remove the requirement for SED-ML file wide id uniqueness.
>> 
>> Nope, that's exactly what I thought you were proposing.
>>  
>> 3) If you must refer to a Child Id (which appears to be rare, Frank mentioned a reference to a Range as an example), you would do so using a scheme with a delimiter.  For example, if you need to refer to a Variable v within a DataGenerator dg (not sure why, but lets assume you do need to), then you would refer to it as: dg.v OR dg/v OR dg\v 
>> 
>> This is the part I was wondering about.  I want to figure out exactly why you would want to refer to a Child, what other things you might get it confused with, and *not* relax the requirement for uniqueness across that set of things.  The parent/separator/child hack is a new scheme that I feel is almost certainly not worth adding to SED-ML, because we clearly don't need it now, and we probably wouldn't need it even after relaxing most (if not all) of the current uniqueness requirements.
>> 
>> -Lucian
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape_______________________________________________ <http://sdm.link/attshape_______________________________________________>
>> SED-ML-discuss mailing list
>> SED...@li... <mailto:SED...@li...>
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> 
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape <http://sdm.link/attshape>
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li... <mailto:SED...@li...>
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> 
> 
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape <http://sdm.link/attshape>
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li... <mailto:SED...@li...>
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> 
> 
> 
> 
> -- 
> Matthias König
> Junior Group Leader LiSym - Systems Medicine of the Liver
> Humboldt-University Berlin, Institute for Theoretical Biology
>   https://www.livermetabolism.com <https://www.livermetabolism.com/>
> kon...@go... <mailto:kon...@go...>
> Tel: +49 30 20938450
> Tel: +49 176 81168480 <tel:%2B49%20176%2081168480>
> 
> 
> 
> -- 
> Matthias König
> Junior Group Leader LiSym - Systems Medicine of the Liver
> Humboldt-University Berlin, Institute for Theoretical Biology
>   https://www.livermetabolism.com <https://www.livermetabolism.com/>
> kon...@go... <mailto:kon...@go...>
> Tel: +49 30 20938450
> Tel: +49 176 81168480
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Matthias K. <kon...@go...>]

Sorry, forgot to add.
- removing id uniqueness will break backwards-compatibility in a brutal
way. At least I rely in large parts of my code base on id uniqueness.
The main argument in SBML about the unability to remove a timestamp in an
annotation was backwards-compatibility.
Changing one of the core premises about the SEDML document (id uniqueness),
should have very good arguments to make such a big step.

>From my point of view this is more a problem of generating unique ids.
Allowing an additional separator character in the ids could solve this.



On Fri, Jul 8, 2016 at 9:28 AM, Matthias König <kon...@go...>
wrote:

> A thing I really like about id uniqueness is to be able to get elements by
> their ids without the need to know their class.
> This is for instance very helpful if one implements functionality which
> only requires the common base class.
> For instance working with annotations.
>
> Breaking the id uniqueness will make the following things like the
> following more difficult
>
> model = Model()
> model.getElementBySId(sid)
>
> Another thing is storing elements in a hashmap for lookup via id.
> One has to create separate hashmaps for the various classes and do a lot
> of type checking.
>
> Matthias
>
>
> On Thu, Jul 7, 2016 at 10:52 PM, Lucian Smith <luc...@gm...>
> wrote:
>
>> Well, I'll agree that it's better than XPath. But I would rather not use
>> either, and just write the uniqueness rules appropriately.
>>
>> -Lucian
>>
>> On Thu, Jul 7, 2016 at 1:22 PM, Chris Myers <my...@ec...> wrote:
>>
>>> Hmm, I don’t see it as a “hack”, but I guess it is in the eye of the
>>> beholder.  I see it as an elegant solution compare with the XPath
>>> sledgehammer which I really do not like.
>>>
>>> I would be happy if we never have to use it, but Frank has indicated at
>>> least one case where we need to reference a child and he has promised that
>>> it will be needed more in the future.  I would prefer to have a more
>>> elegant solution to this problem than XPath.
>>>
>>> Chris
>>>
>>> On Jul 7, 2016, at 2:16 PM, Lucian Smith <luc...@gm...>
>>> wrote:
>>>
>>> I think you are confused.  We are not talking about SBML or removing
>>>> XPath for targets.  What we are suggesting is to remove the requirement for
>>>> SED-ML file wide id uniqueness.
>>>>
>>>
>>> Nope, that's exactly what I thought you were proposing.
>>>
>>>
>>>> 3) If you must refer to a Child Id (which appears to be rare, Frank
>>>> mentioned a reference to a Range as an example), you would do so using a
>>>> scheme with a delimiter.  For example, if you need to refer to a Variable v
>>>> within a DataGenerator dg (not sure why, but lets assume you do need to),
>>>> then you would refer to it as: dg.v OR dg/v OR dg\v
>>>>
>>>
>>> This is the part I was wondering about.  I want to figure out exactly
>>> why you would want to refer to a Child, what other things you might get it
>>> confused with, and *not* relax the requirement for uniqueness across that
>>> set of things.  The parent/separator/child hack is a new scheme that I feel
>>> is almost certainly not worth adding to SED-ML, because we clearly don't
>>> need it now, and we probably wouldn't need it even after relaxing most (if
>>> not all) of the current uniqueness requirements.
>>>
>>> -Lucian
>>>
>>> ------------------------------------------------------------------------------
>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>> present their vision of the future. This family event has something for
>>> everyone, including kids. Get more information and register today.
>>> http://sdm.link/attshape_______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>> present their vision of the future. This family event has something for
>>> everyone, including kids. Get more information and register today.
>>> http://sdm.link/attshape
>>> _______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>>
>
>
> --
> Matthias König
> Junior Group Leader LiSym - Systems Medicine of the Liver
> Humboldt-University Berlin, Institute for Theoretical Biology
>   https://www.livermetabolism.com
> kon...@go...
> Tel: +49 30 20938450
> Tel: +49 176 81168480
>



-- 
Matthias König
Junior Group Leader LiSym - Systems Medicine of the Liver
Humboldt-University Berlin, Institute for Theoretical Biology
  https://www.livermetabolism.com
kon...@go...
Tel: +49 30 20938450
Tel: +49 176 81168480

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Matthias K. <kon...@go...>]

A thing I really like about id uniqueness is to be able to get elements by
their ids without the need to know their class.
This is for instance very helpful if one implements functionality which
only requires the common base class.
For instance working with annotations.

Breaking the id uniqueness will make the following things like the
following more difficult

model = Model()
model.getElementBySId(sid)

Another thing is storing elements in a hashmap for lookup via id.
One has to create separate hashmaps for the various classes and do a lot of
type checking.

Matthias


On Thu, Jul 7, 2016 at 10:52 PM, Lucian Smith <luc...@gm...>
wrote:

> Well, I'll agree that it's better than XPath. But I would rather not use
> either, and just write the uniqueness rules appropriately.
>
> -Lucian
>
> On Thu, Jul 7, 2016 at 1:22 PM, Chris Myers <my...@ec...> wrote:
>
>> Hmm, I don’t see it as a “hack”, but I guess it is in the eye of the
>> beholder.  I see it as an elegant solution compare with the XPath
>> sledgehammer which I really do not like.
>>
>> I would be happy if we never have to use it, but Frank has indicated at
>> least one case where we need to reference a child and he has promised that
>> it will be needed more in the future.  I would prefer to have a more
>> elegant solution to this problem than XPath.
>>
>> Chris
>>
>> On Jul 7, 2016, at 2:16 PM, Lucian Smith <luc...@gm...>
>> wrote:
>>
>> I think you are confused.  We are not talking about SBML or removing
>>> XPath for targets.  What we are suggesting is to remove the requirement for
>>> SED-ML file wide id uniqueness.
>>>
>>
>> Nope, that's exactly what I thought you were proposing.
>>
>>
>>> 3) If you must refer to a Child Id (which appears to be rare, Frank
>>> mentioned a reference to a Range as an example), you would do so using a
>>> scheme with a delimiter.  For example, if you need to refer to a Variable v
>>> within a DataGenerator dg (not sure why, but lets assume you do need to),
>>> then you would refer to it as: dg.v OR dg/v OR dg\v
>>>
>>
>> This is the part I was wondering about.  I want to figure out exactly why
>> you would want to refer to a Child, what other things you might get it
>> confused with, and *not* relax the requirement for uniqueness across that
>> set of things.  The parent/separator/child hack is a new scheme that I feel
>> is almost certainly not worth adding to SED-ML, because we clearly don't
>> need it now, and we probably wouldn't need it even after relaxing most (if
>> not all) of the current uniqueness requirements.
>>
>> -Lucian
>>
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape_______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>


-- 
Matthias König
Junior Group Leader LiSym - Systems Medicine of the Liver
Humboldt-University Berlin, Institute for Theoretical Biology
  https://www.livermetabolism.com
kon...@go...
Tel: +49 30 20938450
Tel: +49 176 81168480

Re: [SED-ML-discuss] SED-ML-discuss Digest, Vol 56, Issue 4

[Chris M. <my...@ec...>]

Hmm, those would not be very pleasant to debug…

Chris

> On Jul 7, 2016, at 1:55 PM, Herbert Sauro <uw....@gm...> wrote:
> 
> For SBML in places where the Ids have to be generated by computer, eg
> in events, I generate unique ids using GUIDS (Globally Unique
> Identifier). I think Java has methods to generate these.
> 
> Herbert
> 
> On Thu, Jul 7, 2016 at 12:40 PM,
> <sed...@li...> wrote:
>> Send SED-ML-discuss mailing list submissions to
>>        sed...@li...
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>> or, via email, send a message with subject or body 'help' to
>>        sed...@li...
>> 
>> You can reach the person managing the list at
>>        sed...@li...
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of SED-ML-discuss digest..."
>> 
>> 
>> Today's Topics:
>> 
>>   1. Re: Id uniqueness in SED-ML files (Chris Myers)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Thu, 7 Jul 2016 13:40:20 -0600
>> From: Chris Myers <my...@ec...>
>> Subject: Re: [SED-ML-discuss] Id uniqueness in SED-ML files
>> To: sed...@li...
>> Message-ID: <B13...@ec...>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Hi Lucian,
>> 
>> I think you are confused.  We are not talking about SBML or removing XPath for targets.  What we are suggesting is to remove the requirement for SED-ML file wide id uniqueness.  My proposal is specifically:
>> 
>> 1) Top-level Ids (Model, Simulation, Task, DG, and Output) only need to be unique within their respective class.  In other words, you can have both a Task and Output with the same Id, since it is clear from context which you are referring to.
>> 
>> 2) Child Ids (Variable, Parameter, Curve, DataSet, etc.) only need to be unique within the scope of the Parent class in which they are contained.  This would mean you could have two Variables with the same Id within different DataGenerators.  This one is EXTREMELY useful.
>> 
>> 3) If you must refer to a Child Id (which appears to be rare, Frank mentioned a reference to a Range as an example), you would do so using a scheme with a delimiter.  For example, if you need to refer to a Variable v within a DataGenerator dg (not sure why, but lets assume you do need to), then you would refer to it as: dg.v OR dg/v OR dg\v
>> 
>> BTW: I would love to make this proposal also for SBML at some point in the future as global Id uniqueness is a real pain. :-)
>> 
>> Chris
>> 
>>> On Jul 7, 2016, at 1:21 PM, Lucian Smith <luc...@gm...> wrote:
>>> 
>>> Can we back up a second--what exactly do people want to reference with the parent/separator/child format?  Right now, all you have to do is use 'child' because of model-wide ID uniqueness.  If we relax model-wide uniqueness, what situations does this bring up that requires a parent/separator/child ID instead?  And can we simply not relax model-wide uniqueness so much that this is necessary, so we can continue to just use "child"?
>>> 
>>> -Lucian
>>> 
>>> On Thu, Jul 7, 2016 at 12:04 PM, David Brooks <d.b...@au... <mailto:d.b...@au...>> wrote:
>>> Let's stick with forward slashes :-). Backslashes, especially when used
>>> in string constants when writing code, is likely to cause other issues...
>>> 
>>> 
>>> Dave
>>> 
>>> 
>>> On 7/07/16 3:26 PM, Chris Myers wrote:
>>>> I like the backslash form a lot.
>>>> 
>>>> XPath is horrible, and we should not add even more uses of it.  It really does not make sense within a file.  The motivation for XPath is that you are references Ids in multiple file types.  References within a file do not have this complication, so using XPath is like using a sledgehammer to open an egg. :-)
>>>> 
>>>> Chris
>>>> 
>>>>> On Jul 7, 2016, at 6:04 AM, Frank T. Bergmann <fbe...@ca... <mailto:fbe...@ca...>> wrote:
>>>>> 
>>>>> I am still not sure why we need to introduce another scheme here. We
>>>>> already have XPath over the model. Why not allow xpath over the sed-ml
>>>>> document as well? seems kind of arbitrary to use another scheme.
>>>>> 
>>>>> Frank
>>>>> 
>>>>> On Thu, Jul 7, 2016 at 1:08 PM, David Brooks <d.b...@au... <mailto:d.b...@au...>> wrote:
>>>>>> Hmm, why not use "/" as the separator between a parent and child id?
>>>>>> That way, absolute ids would have the form
>>>>>> "/top-parent-id/parent-id/child-id" which map very nicely to URls, for
>>>>>> say making RDF statements about the element.
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Dave
>>>>>> 
>>>>>> 
>>>>>> On 6/07/16 11:22 PM, David Nickerson wrote:
>>>>>>> seems sensible to me.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> David.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Jul 7, 2016 at 7:40 AM, Chris Myers <my...@ec... <mailto:my...@ec...>> wrote:
>>>>>>>> In these cases, I would like to see a scheme where you refer to a child id through its parent id.  For example, if the parentId is p and the child is c, then refer to it as ?p.c?.  Effectively, this is what I?m doing to try to make things unique by calling the child ?p_c?.  The problem with this scheme is that ?_? is a valid id character, so a person wanting to make my life difficult could create another object called ?p_c?.  This necessitates a program to spend a lot of effort every time it creates an id to check it against all other ids rather than just relevant ones.  I believe, for example, with scoping, the reference scheme I just mentioned, and consideration of types in references, you can greatly simplify this.
>>>>>>>> 
>>>>>>>> For example, one could restrict the ids of DataGenerators to be unique with respect to all other DataGenerators, but if you want to name a curve with the same Id, it should be okay, since you would never refer to a Curve in the same reference that refers to a DataGenerator.  Also, the id for the Variable in the DataGenerator, should be locally scoped to that DataGenerator, so if you want to give it the same Id as the Species and not worry about another DataGenerator trying to also refer to this same species using the same Variable Id.  If we ever need to refer to the Variable in a DG, then, you could do so with the ?.? scheme I described above.
>>>>>>>> 
>>>>>>>> The nice thing about this proposal is that at least the scoping of ids is that I think all that changes is validation.  At least for jlibSEDML, I seem to be able to create duplicate ids and use them with no problems, but I do get validation errors, if I check for them.
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> 
>>>>>>>> Chris
>>>>>>>> 
>>>>>>>>> On Jul 6, 2016, at 7:24 AM, Frank T. Bergmann <fbe...@ca... <mailto:fbe...@ca...>> wrote:
>>>>>>>>> 
>>>>>>>>> in 1.2 you are able to refer to ranges in variables by using the '#'
>>>>>>>>> + range.id <http://range.id/> syntax. In the 1.3 proposal this is extended to also allow
>>>>>>>>> refering to datasources / slices and of datagenerators. so care should
>>>>>>>>> be taken in relaxing the requirements. But in principle I agree that
>>>>>>>>> there are many places where a unique id is not necessary.
>>>>>>>>> 
>>>>>>>>> cheers
>>>>>>>>> Frank
>>>>>>>>> 
>>>>>>>>> On Wed, Jul 6, 2016 at 7:58 AM, Chris Myers <my...@ec... <mailto:my...@ec...>> wrote:
>>>>>>>>>> Actually, I think we could go even a step further than this.  In all cases where ids are referenced, the type of the object being referenced is clear, so as long as each list has uniqueIds, we should be fine.  I cannot think of any situation where the type of object is not known.  Each reference to another object by Id, it is clear the type of the referenced object, so the id only needs to be unique within that type.
>>>>>>>>>> 
>>>>>>>>>> This would substantially simplify id creation and maintenance allowing for larger SED-ML files to be created without the worry of id clashes.
>>>>>>>>>> 
>>>>>>>>>> Chris
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Jul 5, 2016, at 11:08 PM, Chris Myers <my...@ec... <mailto:my...@ec...>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> HI,
>>>>>>>>>>> 
>>>>>>>>>>> I?m finding it extremely difficult to maintain id uniqueness in a large SED-ML file.  I would strongly suggest that Variables, Curves, DataSets, and any other child with an Id be locally scoped.  As far as I can tell, there is no use of their id?s outside their parent object.  This would greatly simplify things, since it would allow me to check id uniqueness by just looking at the top-level classes ids.
>>>>>>>>>>> 
>>>>>>>>>>> Is there any problem that I?m missing with this?
>>>>>>>>>>> 
>>>>>>>>>>> Chris
>>>>>>>>>>> 
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>>>>>>> present their vision of the future. This family event has something for
>>>>>>>>>> everyone, including kids. Get more information and register today.
>>>>>>>>>> http://sdm.link/attshape <http://sdm.link/attshape>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SED-ML-discuss mailing list
>>>>>>>>>> SED...@li... <mailto:SED...@li...>
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>>>>>> present their vision of the future. This family event has something for
>>>>>>>>> everyone, including kids. Get more information and register today.
>>>>>>>>> http://sdm.link/attshape <http://sdm.link/attshape>
>>>>>>>>> _______________________________________________
>>>>>>>>> SED-ML-discuss mailing list
>>>>>>>>> SED...@li... <mailto:SED...@li...>
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>>>>> present their vision of the future. This family event has something for
>>>>>>>> everyone, including kids. Get more information and register today.
>>>>>>>> http://sdm.link/attshape <http://sdm.link/attshape>
>>>>>>>> _______________________________________________
>>>>>>>> SED-ML-discuss mailing list
>>>>>>>> SED...@li... <mailto:SED...@li...>
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>>> present their vision of the future. This family event has something for
>>>>>> everyone, including kids. Get more information and register today.
>>>>>> http://sdm.link/attshape <http://sdm.link/attshape>
>>>>>> _______________________________________________
>>>>>> SED-ML-discuss mailing list
>>>>>> SED...@li... <mailto:SED...@li...>
>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>>>>> ------------------------------------------------------------------------------
>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>> present their vision of the future. This family event has something for
>>>>> everyone, including kids. Get more information and register today.
>>>>> http://sdm.link/attshape <http://sdm.link/attshape>
>>>>> _______________________________________________
>>>>> SED-ML-discuss mailing list
>>>>> SED...@li... <mailto:SED...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>> present their vision of the future. This family event has something for
>>>> everyone, including kids. Get more information and register today.
>>>> http://sdm.link/attshape <http://sdm.link/attshape>
>>>> _______________________________________________
>>>> SED-ML-discuss mailing list
>>>> SED...@li... <mailto:SED...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>> present their vision of the future. This family event has something for
>>> everyone, including kids. Get more information and register today.
>>> http://sdm.link/attshape <http://sdm.link/attshape>
>>> _______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li... <mailto:SED...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>>> 
>>> ------------------------------------------------------------------------------
>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>> present their vision of the future. This family event has something for
>>> everyone, including kids. Get more information and register today.
>>> http://sdm.link/attshape_______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> 
>> ------------------------------
>> 
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> 
>> ------------------------------
>> 
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>> 
>> 
>> End of SED-ML-discuss Digest, Vol 56, Issue 4
>> *********************************************
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Lucian S. <luc...@gm...>]

Well, I'll agree that it's better than XPath. But I would rather not use
either, and just write the uniqueness rules appropriately.

-Lucian

On Thu, Jul 7, 2016 at 1:22 PM, Chris Myers <my...@ec...> wrote:

> Hmm, I don’t see it as a “hack”, but I guess it is in the eye of the
> beholder.  I see it as an elegant solution compare with the XPath
> sledgehammer which I really do not like.
>
> I would be happy if we never have to use it, but Frank has indicated at
> least one case where we need to reference a child and he has promised that
> it will be needed more in the future.  I would prefer to have a more
> elegant solution to this problem than XPath.
>
> Chris
>
> On Jul 7, 2016, at 2:16 PM, Lucian Smith <luc...@gm...>
> wrote:
>
> I think you are confused.  We are not talking about SBML or removing XPath
>> for targets.  What we are suggesting is to remove the requirement for
>> SED-ML file wide id uniqueness.
>>
>
> Nope, that's exactly what I thought you were proposing.
>
>
>> 3) If you must refer to a Child Id (which appears to be rare, Frank
>> mentioned a reference to a Range as an example), you would do so using a
>> scheme with a delimiter.  For example, if you need to refer to a Variable v
>> within a DataGenerator dg (not sure why, but lets assume you do need to),
>> then you would refer to it as: dg.v OR dg/v OR dg\v
>>
>
> This is the part I was wondering about.  I want to figure out exactly why
> you would want to refer to a Child, what other things you might get it
> confused with, and *not* relax the requirement for uniqueness across that
> set of things.  The parent/separator/child hack is a new scheme that I feel
> is almost certainly not worth adding to SED-ML, because we clearly don't
> need it now, and we probably wouldn't need it even after relaxing most (if
> not all) of the current uniqueness requirements.
>
> -Lucian
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Chris M. <my...@ec...>]

Hmm, I don’t see it as a “hack”, but I guess it is in the eye of the beholder.  I see it as an elegant solution compare with the XPath sledgehammer which I really do not like.

I would be happy if we never have to use it, but Frank has indicated at least one case where we need to reference a child and he has promised that it will be needed more in the future.  I would prefer to have a more elegant solution to this problem than XPath.

Chris

> On Jul 7, 2016, at 2:16 PM, Lucian Smith <luc...@gm...> wrote:
> 
> I think you are confused.  We are not talking about SBML or removing XPath for targets.  What we are suggesting is to remove the requirement for SED-ML file wide id uniqueness.
> 
> Nope, that's exactly what I thought you were proposing.
>  
> 3) If you must refer to a Child Id (which appears to be rare, Frank mentioned a reference to a Range as an example), you would do so using a scheme with a delimiter.  For example, if you need to refer to a Variable v within a DataGenerator dg (not sure why, but lets assume you do need to), then you would refer to it as: dg.v OR dg/v OR dg\v 
> 
> This is the part I was wondering about.  I want to figure out exactly why you would want to refer to a Child, what other things you might get it confused with, and *not* relax the requirement for uniqueness across that set of things.  The parent/separator/child hack is a new scheme that I feel is almost certainly not worth adding to SED-ML, because we clearly don't need it now, and we probably wouldn't need it even after relaxing most (if not all) of the current uniqueness requirements.
> 
> -Lucian
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Lucian S. <luc...@gm...>]

>
> I think you are confused.  We are not talking about SBML or removing XPath
> for targets.  What we are suggesting is to remove the requirement for
> SED-ML file wide id uniqueness.
>

Nope, that's exactly what I thought you were proposing.


> 3) If you must refer to a Child Id (which appears to be rare, Frank
> mentioned a reference to a Range as an example), you would do so using a
> scheme with a delimiter.  For example, if you need to refer to a Variable v
> within a DataGenerator dg (not sure why, but lets assume you do need to),
> then you would refer to it as: dg.v OR dg/v OR dg\v
>

This is the part I was wondering about.  I want to figure out exactly why
you would want to refer to a Child, what other things you might get it
confused with, and *not* relax the requirement for uniqueness across that
set of things.  The parent/separator/child hack is a new scheme that I feel
is almost certainly not worth adding to SED-ML, because we clearly don't
need it now, and we probably wouldn't need it even after relaxing most (if
not all) of the current uniqueness requirements.

-Lucian

Re: [SED-ML-discuss] SED-ML-discuss Digest, Vol 56, Issue 4

[Herbert S. <uw....@gm...>]

For SBML in places where the Ids have to be generated by computer, eg
in events, I generate unique ids using GUIDS (Globally Unique
Identifier). I think Java has methods to generate these.

Herbert

On Thu, Jul 7, 2016 at 12:40 PM,
<sed...@li...> wrote:
> Send SED-ML-discuss mailing list submissions to
>         sed...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> or, via email, send a message with subject or body 'help' to
>         sed...@li...
>
> You can reach the person managing the list at
>         sed...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SED-ML-discuss digest..."
>
>
> Today's Topics:
>
>    1. Re: Id uniqueness in SED-ML files (Chris Myers)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 7 Jul 2016 13:40:20 -0600
> From: Chris Myers <my...@ec...>
> Subject: Re: [SED-ML-discuss] Id uniqueness in SED-ML files
> To: sed...@li...
> Message-ID: <B13...@ec...>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Lucian,
>
> I think you are confused.  We are not talking about SBML or removing XPath for targets.  What we are suggesting is to remove the requirement for SED-ML file wide id uniqueness.  My proposal is specifically:
>
> 1) Top-level Ids (Model, Simulation, Task, DG, and Output) only need to be unique within their respective class.  In other words, you can have both a Task and Output with the same Id, since it is clear from context which you are referring to.
>
> 2) Child Ids (Variable, Parameter, Curve, DataSet, etc.) only need to be unique within the scope of the Parent class in which they are contained.  This would mean you could have two Variables with the same Id within different DataGenerators.  This one is EXTREMELY useful.
>
> 3) If you must refer to a Child Id (which appears to be rare, Frank mentioned a reference to a Range as an example), you would do so using a scheme with a delimiter.  For example, if you need to refer to a Variable v within a DataGenerator dg (not sure why, but lets assume you do need to), then you would refer to it as: dg.v OR dg/v OR dg\v
>
> BTW: I would love to make this proposal also for SBML at some point in the future as global Id uniqueness is a real pain. :-)
>
> Chris
>
>> On Jul 7, 2016, at 1:21 PM, Lucian Smith <luc...@gm...> wrote:
>>
>> Can we back up a second--what exactly do people want to reference with the parent/separator/child format?  Right now, all you have to do is use 'child' because of model-wide ID uniqueness.  If we relax model-wide uniqueness, what situations does this bring up that requires a parent/separator/child ID instead?  And can we simply not relax model-wide uniqueness so much that this is necessary, so we can continue to just use "child"?
>>
>> -Lucian
>>
>> On Thu, Jul 7, 2016 at 12:04 PM, David Brooks <d.b...@au... <mailto:d.b...@au...>> wrote:
>> Let's stick with forward slashes :-). Backslashes, especially when used
>> in string constants when writing code, is likely to cause other issues...
>>
>>
>> Dave
>>
>>
>> On 7/07/16 3:26 PM, Chris Myers wrote:
>> > I like the backslash form a lot.
>> >
>> > XPath is horrible, and we should not add even more uses of it.  It really does not make sense within a file.  The motivation for XPath is that you are references Ids in multiple file types.  References within a file do not have this complication, so using XPath is like using a sledgehammer to open an egg. :-)
>> >
>> > Chris
>> >
>> >> On Jul 7, 2016, at 6:04 AM, Frank T. Bergmann <fbe...@ca... <mailto:fbe...@ca...>> wrote:
>> >>
>> >> I am still not sure why we need to introduce another scheme here. We
>> >> already have XPath over the model. Why not allow xpath over the sed-ml
>> >> document as well? seems kind of arbitrary to use another scheme.
>> >>
>> >> Frank
>> >>
>> >> On Thu, Jul 7, 2016 at 1:08 PM, David Brooks <d.b...@au... <mailto:d.b...@au...>> wrote:
>> >>> Hmm, why not use "/" as the separator between a parent and child id?
>> >>> That way, absolute ids would have the form
>> >>> "/top-parent-id/parent-id/child-id" which map very nicely to URls, for
>> >>> say making RDF statements about the element.
>> >>>
>> >>>
>> >>> Regards,
>> >>>
>> >>> Dave
>> >>>
>> >>>
>> >>> On 6/07/16 11:22 PM, David Nickerson wrote:
>> >>>> seems sensible to me.
>> >>>>
>> >>>> Cheers,
>> >>>> David.
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Thu, Jul 7, 2016 at 7:40 AM, Chris Myers <my...@ec... <mailto:my...@ec...>> wrote:
>> >>>>> In these cases, I would like to see a scheme where you refer to a child id through its parent id.  For example, if the parentId is p and the child is c, then refer to it as ?p.c?.  Effectively, this is what I?m doing to try to make things unique by calling the child ?p_c?.  The problem with this scheme is that ?_? is a valid id character, so a person wanting to make my life difficult could create another object called ?p_c?.  This necessitates a program to spend a lot of effort every time it creates an id to check it against all other ids rather than just relevant ones.  I believe, for example, with scoping, the reference scheme I just mentioned, and consideration of types in references, you can greatly simplify this.
>> >>>>>
>> >>>>> For example, one could restrict the ids of DataGenerators to be unique with respect to all other DataGenerators, but if you want to name a curve with the same Id, it should be okay, since you would never refer to a Curve in the same reference that refers to a DataGenerator.  Also, the id for the Variable in the DataGenerator, should be locally scoped to that DataGenerator, so if you want to give it the same Id as the Species and not worry about another DataGenerator trying to also refer to this same species using the same Variable Id.  If we ever need to refer to the Variable in a DG, then, you could do so with the ?.? scheme I described above.
>> >>>>>
>> >>>>> The nice thing about this proposal is that at least the scoping of ids is that I think all that changes is validation.  At least for jlibSEDML, I seem to be able to create duplicate ids and use them with no problems, but I do get validation errors, if I check for them.
>> >>>>>
>> >>>>> Cheers,
>> >>>>>
>> >>>>> Chris
>> >>>>>
>> >>>>>> On Jul 6, 2016, at 7:24 AM, Frank T. Bergmann <fbe...@ca... <mailto:fbe...@ca...>> wrote:
>> >>>>>>
>> >>>>>> in 1.2 you are able to refer to ranges in variables by using the '#'
>> >>>>>> + range.id <http://range.id/> syntax. In the 1.3 proposal this is extended to also allow
>> >>>>>> refering to datasources / slices and of datagenerators. so care should
>> >>>>>> be taken in relaxing the requirements. But in principle I agree that
>> >>>>>> there are many places where a unique id is not necessary.
>> >>>>>>
>> >>>>>> cheers
>> >>>>>> Frank
>> >>>>>>
>> >>>>>> On Wed, Jul 6, 2016 at 7:58 AM, Chris Myers <my...@ec... <mailto:my...@ec...>> wrote:
>> >>>>>>> Actually, I think we could go even a step further than this.  In all cases where ids are referenced, the type of the object being referenced is clear, so as long as each list has uniqueIds, we should be fine.  I cannot think of any situation where the type of object is not known.  Each reference to another object by Id, it is clear the type of the referenced object, so the id only needs to be unique within that type.
>> >>>>>>>
>> >>>>>>> This would substantially simplify id creation and maintenance allowing for larger SED-ML files to be created without the worry of id clashes.
>> >>>>>>>
>> >>>>>>> Chris
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> On Jul 5, 2016, at 11:08 PM, Chris Myers <my...@ec... <mailto:my...@ec...>> wrote:
>> >>>>>>>>
>> >>>>>>>> HI,
>> >>>>>>>>
>> >>>>>>>> I?m finding it extremely difficult to maintain id uniqueness in a large SED-ML file.  I would strongly suggest that Variables, Curves, DataSets, and any other child with an Id be locally scoped.  As far as I can tell, there is no use of their id?s outside their parent object.  This would greatly simplify things, since it would allow me to check id uniqueness by just looking at the top-level classes ids.
>> >>>>>>>>
>> >>>>>>>> Is there any problem that I?m missing with this?
>> >>>>>>>>
>> >>>>>>>> Chris
>> >>>>>>>>
>> >>>>>>> ------------------------------------------------------------------------------
>> >>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> >>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> >>>>>>> present their vision of the future. This family event has something for
>> >>>>>>> everyone, including kids. Get more information and register today.
>> >>>>>>> http://sdm.link/attshape <http://sdm.link/attshape>
>> >>>>>>> _______________________________________________
>> >>>>>>> SED-ML-discuss mailing list
>> >>>>>>> SED...@li... <mailto:SED...@li...>
>> >>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>> >>>>>> ------------------------------------------------------------------------------
>> >>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> >>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> >>>>>> present their vision of the future. This family event has something for
>> >>>>>> everyone, including kids. Get more information and register today.
>> >>>>>> http://sdm.link/attshape <http://sdm.link/attshape>
>> >>>>>> _______________________________________________
>> >>>>>> SED-ML-discuss mailing list
>> >>>>>> SED...@li... <mailto:SED...@li...>
>> >>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>> >>>>> ------------------------------------------------------------------------------
>> >>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> >>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> >>>>> present their vision of the future. This family event has something for
>> >>>>> everyone, including kids. Get more information and register today.
>> >>>>> http://sdm.link/attshape <http://sdm.link/attshape>
>> >>>>> _______________________________________________
>> >>>>> SED-ML-discuss mailing list
>> >>>>> SED...@li... <mailto:SED...@li...>
>> >>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>> >>>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> >>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> >>> present their vision of the future. This family event has something for
>> >>> everyone, including kids. Get more information and register today.
>> >>> http://sdm.link/attshape <http://sdm.link/attshape>
>> >>> _______________________________________________
>> >>> SED-ML-discuss mailing list
>> >>> SED...@li... <mailto:SED...@li...>
>> >>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>> >> ------------------------------------------------------------------------------
>> >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> >> present their vision of the future. This family event has something for
>> >> everyone, including kids. Get more information and register today.
>> >> http://sdm.link/attshape <http://sdm.link/attshape>
>> >> _______________________________________________
>> >> SED-ML-discuss mailing list
>> >> SED...@li... <mailto:SED...@li...>
>> >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>> >
>> > ------------------------------------------------------------------------------
>> > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> > Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> > present their vision of the future. This family event has something for
>> > everyone, including kids. Get more information and register today.
>> > http://sdm.link/attshape <http://sdm.link/attshape>
>> > _______________________________________________
>> > SED-ML-discuss mailing list
>> > SED...@li... <mailto:SED...@li...>
>> > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>>
>>
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape <http://sdm.link/attshape>
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li... <mailto:SED...@li...>
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
>>
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape_______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
>
> ------------------------------
>
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
> End of SED-ML-discuss Digest, Vol 56, Issue 4
> *********************************************

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Chris M. <my...@ec...>]

Hi Lucian,

I think you are confused.  We are not talking about SBML or removing XPath for targets.  What we are suggesting is to remove the requirement for SED-ML file wide id uniqueness.  My proposal is specifically:

1) Top-level Ids (Model, Simulation, Task, DG, and Output) only need to be unique within their respective class.  In other words, you can have both a Task and Output with the same Id, since it is clear from context which you are referring to.

2) Child Ids (Variable, Parameter, Curve, DataSet, etc.) only need to be unique within the scope of the Parent class in which they are contained.  This would mean you could have two Variables with the same Id within different DataGenerators.  This one is EXTREMELY useful.

3) If you must refer to a Child Id (which appears to be rare, Frank mentioned a reference to a Range as an example), you would do so using a scheme with a delimiter.  For example, if you need to refer to a Variable v within a DataGenerator dg (not sure why, but lets assume you do need to), then you would refer to it as: dg.v OR dg/v OR dg\v 

BTW: I would love to make this proposal also for SBML at some point in the future as global Id uniqueness is a real pain. :-)

Chris

> On Jul 7, 2016, at 1:21 PM, Lucian Smith <luc...@gm...> wrote:
> 
> Can we back up a second--what exactly do people want to reference with the parent/separator/child format?  Right now, all you have to do is use 'child' because of model-wide ID uniqueness.  If we relax model-wide uniqueness, what situations does this bring up that requires a parent/separator/child ID instead?  And can we simply not relax model-wide uniqueness so much that this is necessary, so we can continue to just use "child"?
> 
> -Lucian
> 
> On Thu, Jul 7, 2016 at 12:04 PM, David Brooks <d.b...@au... <mailto:d.b...@au...>> wrote:
> Let's stick with forward slashes :-). Backslashes, especially when used
> in string constants when writing code, is likely to cause other issues...
> 
> 
> Dave
> 
> 
> On 7/07/16 3:26 PM, Chris Myers wrote:
> > I like the backslash form a lot.
> >
> > XPath is horrible, and we should not add even more uses of it.  It really does not make sense within a file.  The motivation for XPath is that you are references Ids in multiple file types.  References within a file do not have this complication, so using XPath is like using a sledgehammer to open an egg. :-)
> >
> > Chris
> >
> >> On Jul 7, 2016, at 6:04 AM, Frank T. Bergmann <fbe...@ca... <mailto:fbe...@ca...>> wrote:
> >>
> >> I am still not sure why we need to introduce another scheme here. We
> >> already have XPath over the model. Why not allow xpath over the sed-ml
> >> document as well? seems kind of arbitrary to use another scheme.
> >>
> >> Frank
> >>
> >> On Thu, Jul 7, 2016 at 1:08 PM, David Brooks <d.b...@au... <mailto:d.b...@au...>> wrote:
> >>> Hmm, why not use "/" as the separator between a parent and child id?
> >>> That way, absolute ids would have the form
> >>> "/top-parent-id/parent-id/child-id" which map very nicely to URls, for
> >>> say making RDF statements about the element.
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Dave
> >>>
> >>>
> >>> On 6/07/16 11:22 PM, David Nickerson wrote:
> >>>> seems sensible to me.
> >>>>
> >>>> Cheers,
> >>>> David.
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Jul 7, 2016 at 7:40 AM, Chris Myers <my...@ec... <mailto:my...@ec...>> wrote:
> >>>>> In these cases, I would like to see a scheme where you refer to a child id through its parent id.  For example, if the parentId is p and the child is c, then refer to it as “p.c”.  Effectively, this is what I’m doing to try to make things unique by calling the child “p_c”.  The problem with this scheme is that “_” is a valid id character, so a person wanting to make my life difficult could create another object called “p_c”.  This necessitates a program to spend a lot of effort every time it creates an id to check it against all other ids rather than just relevant ones.  I believe, for example, with scoping, the reference scheme I just mentioned, and consideration of types in references, you can greatly simplify this.
> >>>>>
> >>>>> For example, one could restrict the ids of DataGenerators to be unique with respect to all other DataGenerators, but if you want to name a curve with the same Id, it should be okay, since you would never refer to a Curve in the same reference that refers to a DataGenerator.  Also, the id for the Variable in the DataGenerator, should be locally scoped to that DataGenerator, so if you want to give it the same Id as the Species and not worry about another DataGenerator trying to also refer to this same species using the same Variable Id.  If we ever need to refer to the Variable in a DG, then, you could do so with the “.” scheme I described above.
> >>>>>
> >>>>> The nice thing about this proposal is that at least the scoping of ids is that I think all that changes is validation.  At least for jlibSEDML, I seem to be able to create duplicate ids and use them with no problems, but I do get validation errors, if I check for them.
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Chris
> >>>>>
> >>>>>> On Jul 6, 2016, at 7:24 AM, Frank T. Bergmann <fbe...@ca... <mailto:fbe...@ca...>> wrote:
> >>>>>>
> >>>>>> in 1.2 you are able to refer to ranges in variables by using the '#'
> >>>>>> + range.id <http://range.id/> syntax. In the 1.3 proposal this is extended to also allow
> >>>>>> refering to datasources / slices and of datagenerators. so care should
> >>>>>> be taken in relaxing the requirements. But in principle I agree that
> >>>>>> there are many places where a unique id is not necessary.
> >>>>>>
> >>>>>> cheers
> >>>>>> Frank
> >>>>>>
> >>>>>> On Wed, Jul 6, 2016 at 7:58 AM, Chris Myers <my...@ec... <mailto:my...@ec...>> wrote:
> >>>>>>> Actually, I think we could go even a step further than this.  In all cases where ids are referenced, the type of the object being referenced is clear, so as long as each list has uniqueIds, we should be fine.  I cannot think of any situation where the type of object is not known.  Each reference to another object by Id, it is clear the type of the referenced object, so the id only needs to be unique within that type.
> >>>>>>>
> >>>>>>> This would substantially simplify id creation and maintenance allowing for larger SED-ML files to be created without the worry of id clashes.
> >>>>>>>
> >>>>>>> Chris
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Jul 5, 2016, at 11:08 PM, Chris Myers <my...@ec... <mailto:my...@ec...>> wrote:
> >>>>>>>>
> >>>>>>>> HI,
> >>>>>>>>
> >>>>>>>> I’m finding it extremely difficult to maintain id uniqueness in a large SED-ML file.  I would strongly suggest that Variables, Curves, DataSets, and any other child with an Id be locally scoped.  As far as I can tell, there is no use of their id’s outside their parent object.  This would greatly simplify things, since it would allow me to check id uniqueness by just looking at the top-level classes ids.
> >>>>>>>>
> >>>>>>>> Is there any problem that I’m missing with this?
> >>>>>>>>
> >>>>>>>> Chris
> >>>>>>>>
> >>>>>>> ------------------------------------------------------------------------------
> >>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> >>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> >>>>>>> present their vision of the future. This family event has something for
> >>>>>>> everyone, including kids. Get more information and register today.
> >>>>>>> http://sdm.link/attshape <http://sdm.link/attshape>
> >>>>>>> _______________________________________________
> >>>>>>> SED-ML-discuss mailing list
> >>>>>>> SED...@li... <mailto:SED...@li...>
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> >>>>>> ------------------------------------------------------------------------------
> >>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> >>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> >>>>>> present their vision of the future. This family event has something for
> >>>>>> everyone, including kids. Get more information and register today.
> >>>>>> http://sdm.link/attshape <http://sdm.link/attshape>
> >>>>>> _______________________________________________
> >>>>>> SED-ML-discuss mailing list
> >>>>>> SED...@li... <mailto:SED...@li...>
> >>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> >>>>> ------------------------------------------------------------------------------
> >>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> >>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> >>>>> present their vision of the future. This family event has something for
> >>>>> everyone, including kids. Get more information and register today.
> >>>>> http://sdm.link/attshape <http://sdm.link/attshape>
> >>>>> _______________________________________________
> >>>>> SED-ML-discuss mailing list
> >>>>> SED...@li... <mailto:SED...@li...>
> >>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> >>>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> >>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> >>> present their vision of the future. This family event has something for
> >>> everyone, including kids. Get more information and register today.
> >>> http://sdm.link/attshape <http://sdm.link/attshape>
> >>> _______________________________________________
> >>> SED-ML-discuss mailing list
> >>> SED...@li... <mailto:SED...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> >> ------------------------------------------------------------------------------
> >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> >> present their vision of the future. This family event has something for
> >> everyone, including kids. Get more information and register today.
> >> http://sdm.link/attshape <http://sdm.link/attshape>
> >> _______________________________________________
> >> SED-ML-discuss mailing list
> >> SED...@li... <mailto:SED...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> >
> > ------------------------------------------------------------------------------
> > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> > Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> > present their vision of the future. This family event has something for
> > everyone, including kids. Get more information and register today.
> > http://sdm.link/attshape <http://sdm.link/attshape>
> > _______________________________________________
> > SED-ML-discuss mailing list
> > SED...@li... <mailto:SED...@li...>
> > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> 
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape <http://sdm.link/attshape>
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li... <mailto:SED...@li...>
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss <https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss>
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Lucian S. <luc...@gm...>]

Can we back up a second--what exactly do people want to reference with the
parent/separator/child format?  Right now, all you have to do is use
'child' because of model-wide ID uniqueness.  If we relax model-wide
uniqueness, what situations does this bring up that requires a
parent/separator/child ID instead?  And can we simply not relax model-wide
uniqueness so much that this is necessary, so we can continue to just use
"child"?

-Lucian

On Thu, Jul 7, 2016 at 12:04 PM, David Brooks <d.b...@au...>
wrote:

> Let's stick with forward slashes :-). Backslashes, especially when used
> in string constants when writing code, is likely to cause other issues...
>
>
> Dave
>
>
> On 7/07/16 3:26 PM, Chris Myers wrote:
> > I like the backslash form a lot.
> >
> > XPath is horrible, and we should not add even more uses of it.  It
> really does not make sense within a file.  The motivation for XPath is that
> you are references Ids in multiple file types.  References within a file do
> not have this complication, so using XPath is like using a sledgehammer to
> open an egg. :-)
> >
> > Chris
> >
> >> On Jul 7, 2016, at 6:04 AM, Frank T. Bergmann <fbe...@ca...>
> wrote:
> >>
> >> I am still not sure why we need to introduce another scheme here. We
> >> already have XPath over the model. Why not allow xpath over the sed-ml
> >> document as well? seems kind of arbitrary to use another scheme.
> >>
> >> Frank
> >>
> >> On Thu, Jul 7, 2016 at 1:08 PM, David Brooks <d.b...@au...>
> wrote:
> >>> Hmm, why not use "/" as the separator between a parent and child id?
> >>> That way, absolute ids would have the form
> >>> "/top-parent-id/parent-id/child-id" which map very nicely to URls, for
> >>> say making RDF statements about the element.
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Dave
> >>>
> >>>
> >>> On 6/07/16 11:22 PM, David Nickerson wrote:
> >>>> seems sensible to me.
> >>>>
> >>>> Cheers,
> >>>> David.
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Jul 7, 2016 at 7:40 AM, Chris Myers <my...@ec...>
> wrote:
> >>>>> In these cases, I would like to see a scheme where you refer to a
> child id through its parent id.  For example, if the parentId is p and the
> child is c, then refer to it as “p.c”.  Effectively, this is what I’m doing
> to try to make things unique by calling the child “p_c”.  The problem with
> this scheme is that “_” is a valid id character, so a person wanting to
> make my life difficult could create another object called “p_c”.  This
> necessitates a program to spend a lot of effort every time it creates an id
> to check it against all other ids rather than just relevant ones.  I
> believe, for example, with scoping, the reference scheme I just mentioned,
> and consideration of types in references, you can greatly simplify this.
> >>>>>
> >>>>> For example, one could restrict the ids of DataGenerators to be
> unique with respect to all other DataGenerators, but if you want to name a
> curve with the same Id, it should be okay, since you would never refer to a
> Curve in the same reference that refers to a DataGenerator.  Also, the id
> for the Variable in the DataGenerator, should be locally scoped to that
> DataGenerator, so if you want to give it the same Id as the Species and not
> worry about another DataGenerator trying to also refer to this same species
> using the same Variable Id.  If we ever need to refer to the Variable in a
> DG, then, you could do so with the “.” scheme I described above.
> >>>>>
> >>>>> The nice thing about this proposal is that at least the scoping of
> ids is that I think all that changes is validation.  At least for
> jlibSEDML, I seem to be able to create duplicate ids and use them with no
> problems, but I do get validation errors, if I check for them.
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Chris
> >>>>>
> >>>>>> On Jul 6, 2016, at 7:24 AM, Frank T. Bergmann <fbe...@ca...>
> wrote:
> >>>>>>
> >>>>>> in 1.2 you are able to refer to ranges in variables by using the '#'
> >>>>>> + range.id syntax. In the 1.3 proposal this is extended to also
> allow
> >>>>>> refering to datasources / slices and of datagenerators. so care
> should
> >>>>>> be taken in relaxing the requirements. But in principle I agree that
> >>>>>> there are many places where a unique id is not necessary.
> >>>>>>
> >>>>>> cheers
> >>>>>> Frank
> >>>>>>
> >>>>>> On Wed, Jul 6, 2016 at 7:58 AM, Chris Myers <my...@ec...>
> wrote:
> >>>>>>> Actually, I think we could go even a step further than this.  In
> all cases where ids are referenced, the type of the object being referenced
> is clear, so as long as each list has uniqueIds, we should be fine.  I
> cannot think of any situation where the type of object is not known.  Each
> reference to another object by Id, it is clear the type of the referenced
> object, so the id only needs to be unique within that type.
> >>>>>>>
> >>>>>>> This would substantially simplify id creation and maintenance
> allowing for larger SED-ML files to be created without the worry of id
> clashes.
> >>>>>>>
> >>>>>>> Chris
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Jul 5, 2016, at 11:08 PM, Chris Myers <my...@ec...>
> wrote:
> >>>>>>>>
> >>>>>>>> HI,
> >>>>>>>>
> >>>>>>>> I’m finding it extremely difficult to maintain id uniqueness in a
> large SED-ML file.  I would strongly suggest that Variables, Curves,
> DataSets, and any other child with an Id be locally scoped.  As far as I
> can tell, there is no use of their id’s outside their parent object.  This
> would greatly simplify things, since it would allow me to check id
> uniqueness by just looking at the top-level classes ids.
> >>>>>>>>
> >>>>>>>> Is there any problem that I’m missing with this?
> >>>>>>>>
> >>>>>>>> Chris
> >>>>>>>>
> >>>>>>>
> ------------------------------------------------------------------------------
> >>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park
> in San
> >>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech
> luminaries
> >>>>>>> present their vision of the future. This family event has
> something for
> >>>>>>> everyone, including kids. Get more information and register today.
> >>>>>>> http://sdm.link/attshape
> >>>>>>> _______________________________________________
> >>>>>>> SED-ML-discuss mailing list
> >>>>>>> SED...@li...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> >>>>>>
> ------------------------------------------------------------------------------
> >>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in
> San
> >>>>>> Francisco, CA to explore cutting-edge tech and listen to tech
> luminaries
> >>>>>> present their vision of the future. This family event has something
> for
> >>>>>> everyone, including kids. Get more information and register today.
> >>>>>> http://sdm.link/attshape
> >>>>>> _______________________________________________
> >>>>>> SED-ML-discuss mailing list
> >>>>>> SED...@li...
> >>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> >>>>>
> ------------------------------------------------------------------------------
> >>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in
> San
> >>>>> Francisco, CA to explore cutting-edge tech and listen to tech
> luminaries
> >>>>> present their vision of the future. This family event has something
> for
> >>>>> everyone, including kids. Get more information and register today.
> >>>>> http://sdm.link/attshape
> >>>>> _______________________________________________
> >>>>> SED-ML-discuss mailing list
> >>>>> SED...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> >>>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> >>> Francisco, CA to explore cutting-edge tech and listen to tech
> luminaries
> >>> present their vision of the future. This family event has something for
> >>> everyone, including kids. Get more information and register today.
> >>> http://sdm.link/attshape
> >>> _______________________________________________
> >>> SED-ML-discuss mailing list
> >>> SED...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> >>
> ------------------------------------------------------------------------------
> >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> >> present their vision of the future. This family event has something for
> >> everyone, including kids. Get more information and register today.
> >> http://sdm.link/attshape
> >> _______________________________________________
> >> SED-ML-discuss mailing list
> >> SED...@li...
> >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> >
> >
> ------------------------------------------------------------------------------
> > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> > Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> > present their vision of the future. This family event has something for
> > everyone, including kids. Get more information and register today.
> > http://sdm.link/attshape
> > _______________________________________________
> > SED-ML-discuss mailing list
> > SED...@li...
> > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[David B. <d.b...@au...>]

Let's stick with forward slashes :-). Backslashes, especially when used 
in string constants when writing code, is likely to cause other issues...


Dave


On 7/07/16 3:26 PM, Chris Myers wrote:
> I like the backslash form a lot.
>
> XPath is horrible, and we should not add even more uses of it.  It really does not make sense within a file.  The motivation for XPath is that you are references Ids in multiple file types.  References within a file do not have this complication, so using XPath is like using a sledgehammer to open an egg. :-)
>
> Chris
>
>> On Jul 7, 2016, at 6:04 AM, Frank T. Bergmann <fbe...@ca...> wrote:
>>
>> I am still not sure why we need to introduce another scheme here. We
>> already have XPath over the model. Why not allow xpath over the sed-ml
>> document as well? seems kind of arbitrary to use another scheme.
>>
>> Frank
>>
>> On Thu, Jul 7, 2016 at 1:08 PM, David Brooks <d.b...@au...> wrote:
>>> Hmm, why not use "/" as the separator between a parent and child id?
>>> That way, absolute ids would have the form
>>> "/top-parent-id/parent-id/child-id" which map very nicely to URls, for
>>> say making RDF statements about the element.
>>>
>>>
>>> Regards,
>>>
>>> Dave
>>>
>>>
>>> On 6/07/16 11:22 PM, David Nickerson wrote:
>>>> seems sensible to me.
>>>>
>>>> Cheers,
>>>> David.
>>>>
>>>>
>>>>
>>>> On Thu, Jul 7, 2016 at 7:40 AM, Chris Myers <my...@ec...> wrote:
>>>>> In these cases, I would like to see a scheme where you refer to a child id through its parent id.  For example, if the parentId is p and the child is c, then refer to it as “p.c”.  Effectively, this is what I’m doing to try to make things unique by calling the child “p_c”.  The problem with this scheme is that “_” is a valid id character, so a person wanting to make my life difficult could create another object called “p_c”.  This necessitates a program to spend a lot of effort every time it creates an id to check it against all other ids rather than just relevant ones.  I believe, for example, with scoping, the reference scheme I just mentioned, and consideration of types in references, you can greatly simplify this.
>>>>>
>>>>> For example, one could restrict the ids of DataGenerators to be unique with respect to all other DataGenerators, but if you want to name a curve with the same Id, it should be okay, since you would never refer to a Curve in the same reference that refers to a DataGenerator.  Also, the id for the Variable in the DataGenerator, should be locally scoped to that DataGenerator, so if you want to give it the same Id as the Species and not worry about another DataGenerator trying to also refer to this same species using the same Variable Id.  If we ever need to refer to the Variable in a DG, then, you could do so with the “.” scheme I described above.
>>>>>
>>>>> The nice thing about this proposal is that at least the scoping of ids is that I think all that changes is validation.  At least for jlibSEDML, I seem to be able to create duplicate ids and use them with no problems, but I do get validation errors, if I check for them.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Chris
>>>>>
>>>>>> On Jul 6, 2016, at 7:24 AM, Frank T. Bergmann <fbe...@ca...> wrote:
>>>>>>
>>>>>> in 1.2 you are able to refer to ranges in variables by using the '#'
>>>>>> + range.id syntax. In the 1.3 proposal this is extended to also allow
>>>>>> refering to datasources / slices and of datagenerators. so care should
>>>>>> be taken in relaxing the requirements. But in principle I agree that
>>>>>> there are many places where a unique id is not necessary.
>>>>>>
>>>>>> cheers
>>>>>> Frank
>>>>>>
>>>>>> On Wed, Jul 6, 2016 at 7:58 AM, Chris Myers <my...@ec...> wrote:
>>>>>>> Actually, I think we could go even a step further than this.  In all cases where ids are referenced, the type of the object being referenced is clear, so as long as each list has uniqueIds, we should be fine.  I cannot think of any situation where the type of object is not known.  Each reference to another object by Id, it is clear the type of the referenced object, so the id only needs to be unique within that type.
>>>>>>>
>>>>>>> This would substantially simplify id creation and maintenance allowing for larger SED-ML files to be created without the worry of id clashes.
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>> On Jul 5, 2016, at 11:08 PM, Chris Myers <my...@ec...> wrote:
>>>>>>>>
>>>>>>>> HI,
>>>>>>>>
>>>>>>>> I’m finding it extremely difficult to maintain id uniqueness in a large SED-ML file.  I would strongly suggest that Variables, Curves, DataSets, and any other child with an Id be locally scoped.  As far as I can tell, there is no use of their id’s outside their parent object.  This would greatly simplify things, since it would allow me to check id uniqueness by just looking at the top-level classes ids.
>>>>>>>>
>>>>>>>> Is there any problem that I’m missing with this?
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>>>> present their vision of the future. This family event has something for
>>>>>>> everyone, including kids. Get more information and register today.
>>>>>>> http://sdm.link/attshape
>>>>>>> _______________________________________________
>>>>>>> SED-ML-discuss mailing list
>>>>>>> SED...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>>>> ------------------------------------------------------------------------------
>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>>> present their vision of the future. This family event has something for
>>>>>> everyone, including kids. Get more information and register today.
>>>>>> http://sdm.link/attshape
>>>>>> _______________________________________________
>>>>>> SED-ML-discuss mailing list
>>>>>> SED...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>>> ------------------------------------------------------------------------------
>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>> present their vision of the future. This family event has something for
>>>>> everyone, including kids. Get more information and register today.
>>>>> http://sdm.link/attshape
>>>>> _______________________________________________
>>>>> SED-ML-discuss mailing list
>>>>> SED...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>> present their vision of the future. This family event has something for
>>> everyone, including kids. Get more information and register today.
>>> http://sdm.link/attshape
>>> _______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Chris M. <my...@ec...>]

I like the backslash form a lot.

XPath is horrible, and we should not add even more uses of it.  It really does not make sense within a file.  The motivation for XPath is that you are references Ids in multiple file types.  References within a file do not have this complication, so using XPath is like using a sledgehammer to open an egg. :-)

Chris

> On Jul 7, 2016, at 6:04 AM, Frank T. Bergmann <fbe...@ca...> wrote:
> 
> I am still not sure why we need to introduce another scheme here. We
> already have XPath over the model. Why not allow xpath over the sed-ml
> document as well? seems kind of arbitrary to use another scheme.
> 
> Frank
> 
> On Thu, Jul 7, 2016 at 1:08 PM, David Brooks <d.b...@au...> wrote:
>> Hmm, why not use "/" as the separator between a parent and child id?
>> That way, absolute ids would have the form
>> "/top-parent-id/parent-id/child-id" which map very nicely to URls, for
>> say making RDF statements about the element.
>> 
>> 
>> Regards,
>> 
>> Dave
>> 
>> 
>> On 6/07/16 11:22 PM, David Nickerson wrote:
>>> seems sensible to me.
>>> 
>>> Cheers,
>>> David.
>>> 
>>> 
>>> 
>>> On Thu, Jul 7, 2016 at 7:40 AM, Chris Myers <my...@ec...> wrote:
>>>> In these cases, I would like to see a scheme where you refer to a child id through its parent id.  For example, if the parentId is p and the child is c, then refer to it as “p.c”.  Effectively, this is what I’m doing to try to make things unique by calling the child “p_c”.  The problem with this scheme is that “_” is a valid id character, so a person wanting to make my life difficult could create another object called “p_c”.  This necessitates a program to spend a lot of effort every time it creates an id to check it against all other ids rather than just relevant ones.  I believe, for example, with scoping, the reference scheme I just mentioned, and consideration of types in references, you can greatly simplify this.
>>>> 
>>>> For example, one could restrict the ids of DataGenerators to be unique with respect to all other DataGenerators, but if you want to name a curve with the same Id, it should be okay, since you would never refer to a Curve in the same reference that refers to a DataGenerator.  Also, the id for the Variable in the DataGenerator, should be locally scoped to that DataGenerator, so if you want to give it the same Id as the Species and not worry about another DataGenerator trying to also refer to this same species using the same Variable Id.  If we ever need to refer to the Variable in a DG, then, you could do so with the “.” scheme I described above.
>>>> 
>>>> The nice thing about this proposal is that at least the scoping of ids is that I think all that changes is validation.  At least for jlibSEDML, I seem to be able to create duplicate ids and use them with no problems, but I do get validation errors, if I check for them.
>>>> 
>>>> Cheers,
>>>> 
>>>> Chris
>>>> 
>>>>> On Jul 6, 2016, at 7:24 AM, Frank T. Bergmann <fbe...@ca...> wrote:
>>>>> 
>>>>> in 1.2 you are able to refer to ranges in variables by using the '#'
>>>>> + range.id syntax. In the 1.3 proposal this is extended to also allow
>>>>> refering to datasources / slices and of datagenerators. so care should
>>>>> be taken in relaxing the requirements. But in principle I agree that
>>>>> there are many places where a unique id is not necessary.
>>>>> 
>>>>> cheers
>>>>> Frank
>>>>> 
>>>>> On Wed, Jul 6, 2016 at 7:58 AM, Chris Myers <my...@ec...> wrote:
>>>>>> Actually, I think we could go even a step further than this.  In all cases where ids are referenced, the type of the object being referenced is clear, so as long as each list has uniqueIds, we should be fine.  I cannot think of any situation where the type of object is not known.  Each reference to another object by Id, it is clear the type of the referenced object, so the id only needs to be unique within that type.
>>>>>> 
>>>>>> This would substantially simplify id creation and maintenance allowing for larger SED-ML files to be created without the worry of id clashes.
>>>>>> 
>>>>>> Chris
>>>>>> 
>>>>>> 
>>>>>>> On Jul 5, 2016, at 11:08 PM, Chris Myers <my...@ec...> wrote:
>>>>>>> 
>>>>>>> HI,
>>>>>>> 
>>>>>>> I’m finding it extremely difficult to maintain id uniqueness in a large SED-ML file.  I would strongly suggest that Variables, Curves, DataSets, and any other child with an Id be locally scoped.  As far as I can tell, there is no use of their id’s outside their parent object.  This would greatly simplify things, since it would allow me to check id uniqueness by just looking at the top-level classes ids.
>>>>>>> 
>>>>>>> Is there any problem that I’m missing with this?
>>>>>>> 
>>>>>>> Chris
>>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>>> present their vision of the future. This family event has something for
>>>>>> everyone, including kids. Get more information and register today.
>>>>>> http://sdm.link/attshape
>>>>>> _______________________________________________
>>>>>> SED-ML-discuss mailing list
>>>>>> SED...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>>> ------------------------------------------------------------------------------
>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>> present their vision of the future. This family event has something for
>>>>> everyone, including kids. Get more information and register today.
>>>>> http://sdm.link/attshape
>>>>> _______________________________________________
>>>>> SED-ML-discuss mailing list
>>>>> SED...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>> present their vision of the future. This family event has something for
>>>> everyone, including kids. Get more information and register today.
>>>> http://sdm.link/attshape
>>>> _______________________________________________
>>>> SED-ML-discuss mailing list
>>>> SED...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>> 
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[Frank T. B. <fbe...@ca...>]

I am still not sure why we need to introduce another scheme here. We
already have XPath over the model. Why not allow xpath over the sed-ml
document as well? seems kind of arbitrary to use another scheme.

Frank

On Thu, Jul 7, 2016 at 1:08 PM, David Brooks <d.b...@au...> wrote:
> Hmm, why not use "/" as the separator between a parent and child id?
> That way, absolute ids would have the form
> "/top-parent-id/parent-id/child-id" which map very nicely to URls, for
> say making RDF statements about the element.
>
>
> Regards,
>
> Dave
>
>
> On 6/07/16 11:22 PM, David Nickerson wrote:
>> seems sensible to me.
>>
>> Cheers,
>> David.
>>
>>
>>
>> On Thu, Jul 7, 2016 at 7:40 AM, Chris Myers <my...@ec...> wrote:
>>> In these cases, I would like to see a scheme where you refer to a child id through its parent id.  For example, if the parentId is p and the child is c, then refer to it as “p.c”.  Effectively, this is what I’m doing to try to make things unique by calling the child “p_c”.  The problem with this scheme is that “_” is a valid id character, so a person wanting to make my life difficult could create another object called “p_c”.  This necessitates a program to spend a lot of effort every time it creates an id to check it against all other ids rather than just relevant ones.  I believe, for example, with scoping, the reference scheme I just mentioned, and consideration of types in references, you can greatly simplify this.
>>>
>>> For example, one could restrict the ids of DataGenerators to be unique with respect to all other DataGenerators, but if you want to name a curve with the same Id, it should be okay, since you would never refer to a Curve in the same reference that refers to a DataGenerator.  Also, the id for the Variable in the DataGenerator, should be locally scoped to that DataGenerator, so if you want to give it the same Id as the Species and not worry about another DataGenerator trying to also refer to this same species using the same Variable Id.  If we ever need to refer to the Variable in a DG, then, you could do so with the “.” scheme I described above.
>>>
>>> The nice thing about this proposal is that at least the scoping of ids is that I think all that changes is validation.  At least for jlibSEDML, I seem to be able to create duplicate ids and use them with no problems, but I do get validation errors, if I check for them.
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>>>> On Jul 6, 2016, at 7:24 AM, Frank T. Bergmann <fbe...@ca...> wrote:
>>>>
>>>> in 1.2 you are able to refer to ranges in variables by using the '#'
>>>> + range.id syntax. In the 1.3 proposal this is extended to also allow
>>>> refering to datasources / slices and of datagenerators. so care should
>>>> be taken in relaxing the requirements. But in principle I agree that
>>>> there are many places where a unique id is not necessary.
>>>>
>>>> cheers
>>>> Frank
>>>>
>>>> On Wed, Jul 6, 2016 at 7:58 AM, Chris Myers <my...@ec...> wrote:
>>>>> Actually, I think we could go even a step further than this.  In all cases where ids are referenced, the type of the object being referenced is clear, so as long as each list has uniqueIds, we should be fine.  I cannot think of any situation where the type of object is not known.  Each reference to another object by Id, it is clear the type of the referenced object, so the id only needs to be unique within that type.
>>>>>
>>>>> This would substantially simplify id creation and maintenance allowing for larger SED-ML files to be created without the worry of id clashes.
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>> On Jul 5, 2016, at 11:08 PM, Chris Myers <my...@ec...> wrote:
>>>>>>
>>>>>> HI,
>>>>>>
>>>>>> I’m finding it extremely difficult to maintain id uniqueness in a large SED-ML file.  I would strongly suggest that Variables, Curves, DataSets, and any other child with an Id be locally scoped.  As far as I can tell, there is no use of their id’s outside their parent object.  This would greatly simplify things, since it would allow me to check id uniqueness by just looking at the top-level classes ids.
>>>>>>
>>>>>> Is there any problem that I’m missing with this?
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>>> present their vision of the future. This family event has something for
>>>>> everyone, including kids. Get more information and register today.
>>>>> http://sdm.link/attshape
>>>>> _______________________________________________
>>>>> SED-ML-discuss mailing list
>>>>> SED...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>> ------------------------------------------------------------------------------
>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>> present their vision of the future. This family event has something for
>>>> everyone, including kids. Get more information and register today.
>>>> http://sdm.link/attshape
>>>> _______________________________________________
>>>> SED-ML-discuss mailing list
>>>> SED...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>
>>> ------------------------------------------------------------------------------
>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>> present their vision of the future. This family event has something for
>>> everyone, including kids. Get more information and register today.
>>> http://sdm.link/attshape
>>> _______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>>
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Id uniqueness in SED-ML files

[David B. <d.b...@au...>]

Hmm, why not use "/" as the separator between a parent and child id? 
That way, absolute ids would have the form 
"/top-parent-id/parent-id/child-id" which map very nicely to URls, for 
say making RDF statements about the element.


Regards,

Dave


On 6/07/16 11:22 PM, David Nickerson wrote:
> seems sensible to me.
>
> Cheers,
> David.
>
>
>
> On Thu, Jul 7, 2016 at 7:40 AM, Chris Myers <my...@ec...> wrote:
>> In these cases, I would like to see a scheme where you refer to a child id through its parent id.  For example, if the parentId is p and the child is c, then refer to it as “p.c”.  Effectively, this is what I’m doing to try to make things unique by calling the child “p_c”.  The problem with this scheme is that “_” is a valid id character, so a person wanting to make my life difficult could create another object called “p_c”.  This necessitates a program to spend a lot of effort every time it creates an id to check it against all other ids rather than just relevant ones.  I believe, for example, with scoping, the reference scheme I just mentioned, and consideration of types in references, you can greatly simplify this.
>>
>> For example, one could restrict the ids of DataGenerators to be unique with respect to all other DataGenerators, but if you want to name a curve with the same Id, it should be okay, since you would never refer to a Curve in the same reference that refers to a DataGenerator.  Also, the id for the Variable in the DataGenerator, should be locally scoped to that DataGenerator, so if you want to give it the same Id as the Species and not worry about another DataGenerator trying to also refer to this same species using the same Variable Id.  If we ever need to refer to the Variable in a DG, then, you could do so with the “.” scheme I described above.
>>
>> The nice thing about this proposal is that at least the scoping of ids is that I think all that changes is validation.  At least for jlibSEDML, I seem to be able to create duplicate ids and use them with no problems, but I do get validation errors, if I check for them.
>>
>> Cheers,
>>
>> Chris
>>
>>> On Jul 6, 2016, at 7:24 AM, Frank T. Bergmann <fbe...@ca...> wrote:
>>>
>>> in 1.2 you are able to refer to ranges in variables by using the '#'
>>> + range.id syntax. In the 1.3 proposal this is extended to also allow
>>> refering to datasources / slices and of datagenerators. so care should
>>> be taken in relaxing the requirements. But in principle I agree that
>>> there are many places where a unique id is not necessary.
>>>
>>> cheers
>>> Frank
>>>
>>> On Wed, Jul 6, 2016 at 7:58 AM, Chris Myers <my...@ec...> wrote:
>>>> Actually, I think we could go even a step further than this.  In all cases where ids are referenced, the type of the object being referenced is clear, so as long as each list has uniqueIds, we should be fine.  I cannot think of any situation where the type of object is not known.  Each reference to another object by Id, it is clear the type of the referenced object, so the id only needs to be unique within that type.
>>>>
>>>> This would substantially simplify id creation and maintenance allowing for larger SED-ML files to be created without the worry of id clashes.
>>>>
>>>> Chris
>>>>
>>>>
>>>>> On Jul 5, 2016, at 11:08 PM, Chris Myers <my...@ec...> wrote:
>>>>>
>>>>> HI,
>>>>>
>>>>> I’m finding it extremely difficult to maintain id uniqueness in a large SED-ML file.  I would strongly suggest that Variables, Curves, DataSets, and any other child with an Id be locally scoped.  As far as I can tell, there is no use of their id’s outside their parent object.  This would greatly simplify things, since it would allow me to check id uniqueness by just looking at the top-level classes ids.
>>>>>
>>>>> Is there any problem that I’m missing with this?
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>>> present their vision of the future. This family event has something for
>>>> everyone, including kids. Get more information and register today.
>>>> http://sdm.link/attshape
>>>> _______________________________________________
>>>> SED-ML-discuss mailing list
>>>> SED...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>> ------------------------------------------------------------------------------
>>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>> present their vision of the future. This family event has something for
>>> everyone, including kids. Get more information and register today.
>>> http://sdm.link/attshape
>>> _______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>