You can subscribe to this list here.
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
(32) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
(42) |
May
(4) |
Jun
|
Jul
(12) |
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
2016 |
Jan
(4) |
Feb
(28) |
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Chris J. M. <my...@ec...> - 2013-04-17 19:20:01
|
I'm really just thinking ahead to using groups in math as sets and adding the set operators to supported mathML to operate upon them. Chris On Apr 17, 2013, at 9:11 AM, Lucian Smith <lp...@sp...> wrote: > Well, hmm. What are you thinking, exactly, when you say 'set of sets'? > What sort of semantics does that imply? > > In my 'union'-ish interpretation, I'm actually thinking more about all the > existing rules for sets: asignment of SBO terms, Notes, and Annotations; > the 'kind' attribute, and the new validation rules. Do you care about any > of those in terms of this set-of-sets vs. union interpretation? Maybe we > could make this a per-feature interpretation. > > -Lucian > > * Chris J. Myers <my...@ec...> [2013-04-17 15:08] writes: >> I agree that allowing them to be different may be possibly useful. >> >> I do want to be able to express sets of sets as Lucian points out. In this case, it is clear that different can be meaningful. I think if the interpretation is union of the included sets, then I'm not as sure about that. >> >> Chris >> >> On Apr 16, 2013, at 11:21 PM, Lucian Smith <lp...@sp...> wrote: >> >>> * Zhang, Fengkai <zha...@ni...> [2013-04-17 05:24] writes: >>>> Hi Lucian, >>>> >>>> I have one question regarding a group (say "subG") referenced as a >>>> member of another group (say "G"). Is there any restriction to the >>>> "kind" attributes of "subG" and "G"? Are they allowed to be different or >>>> implicitly required to be the same? It may already be addressed in the >>>> spec but I missed it. >>> >>> That's an interesting question, and it probably should be addressed >>> specifically in the spec. But no, they would be allowed to be different. >>> You could imagine, say, a group of species involved in a particular thing >>> that had one kind, another group of reactions that had one kind, and then >>> a group that was the union of those two groups, serving an entirely >>> different purpose. >>> >>> It also makes a difference whether it's semantically considered that >>> recursive groups refer to the group itself, or if it refers to the members >>> of the group. In other words, if G includes 'subG', is it including that >>> because of the members of subG, or is it a reference to the grouping >>> itself? If subG contains all species members, does G's reference to subG >>> mean 'these species' or does it mean 'this group'? >>> >>> The answer might end up being "Both, in different contexts." The spec as >>> currently written implies 'these species'; I think Chris wants it to mean >>> 'this group'. There might be a compromise in there somewhere... >>> >>> -Lucian >>> >>> ------------------------------------------------------------------------------ >>> Precog is a next-generation analytics platform capable of advanced >>> analytics on semi-structured data. The platform includes APIs for building >>> apps and a phenomenal toolset for data science. Developers can use >>> our toolset for easy data analysis & visualization. Get a free account! >>> http://www2.precog.com/precogplatform/slashdotnewsletter >>> _______________________________________________ >>> sbml-groups mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-groups >> >> >> ------------------------------------------------------------------------------ >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> _______________________________________________ >> sbml-groups mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-groups > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > sbml-groups mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-groups |
From: Lucian S. <lp...@sp...> - 2013-04-17 15:11:30
|
Well, hmm. What are you thinking, exactly, when you say 'set of sets'? What sort of semantics does that imply? In my 'union'-ish interpretation, I'm actually thinking more about all the existing rules for sets: asignment of SBO terms, Notes, and Annotations; the 'kind' attribute, and the new validation rules. Do you care about any of those in terms of this set-of-sets vs. union interpretation? Maybe we could make this a per-feature interpretation. -Lucian * Chris J. Myers <my...@ec...> [2013-04-17 15:08] writes: > I agree that allowing them to be different may be possibly useful. > > I do want to be able to express sets of sets as Lucian points out. In this case, it is clear that different can be meaningful. I think if the interpretation is union of the included sets, then I'm not as sure about that. > > Chris > > On Apr 16, 2013, at 11:21 PM, Lucian Smith <lp...@sp...> wrote: > > > * Zhang, Fengkai <zha...@ni...> [2013-04-17 05:24] writes: > >> Hi Lucian, > >> > >> I have one question regarding a group (say "subG") referenced as a > >> member of another group (say "G"). Is there any restriction to the > >> "kind" attributes of "subG" and "G"? Are they allowed to be different or > >> implicitly required to be the same? It may already be addressed in the > >> spec but I missed it. > > > > That's an interesting question, and it probably should be addressed > > specifically in the spec. But no, they would be allowed to be different. > > You could imagine, say, a group of species involved in a particular thing > > that had one kind, another group of reactions that had one kind, and then > > a group that was the union of those two groups, serving an entirely > > different purpose. > > > > It also makes a difference whether it's semantically considered that > > recursive groups refer to the group itself, or if it refers to the members > > of the group. In other words, if G includes 'subG', is it including that > > because of the members of subG, or is it a reference to the grouping > > itself? If subG contains all species members, does G's reference to subG > > mean 'these species' or does it mean 'this group'? > > > > The answer might end up being "Both, in different contexts." The spec as > > currently written implies 'these species'; I think Chris wants it to mean > > 'this group'. There might be a compromise in there somewhere... > > > > -Lucian > > > > ------------------------------------------------------------------------------ > > Precog is a next-generation analytics platform capable of advanced > > analytics on semi-structured data. The platform includes APIs for building > > apps and a phenomenal toolset for data science. Developers can use > > our toolset for easy data analysis & visualization. Get a free account! > > http://www2.precog.com/precogplatform/slashdotnewsletter > > _______________________________________________ > > sbml-groups mailing list > > sbm...@li... > > https://lists.sourceforge.net/lists/listinfo/sbml-groups > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > sbml-groups mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-groups |
From: Zhang, F. (NIH/N. [E] <zha...@ni...> - 2013-04-17 14:25:01
|
Right, it makes sense to me to be different when interpreted as sets of sets. On 04/17/2013 10:04 AM, Chris J. Myers wrote: > I agree that allowing them to be different may be possibly useful. > > I do want to be able to express sets of sets as Lucian points out. In this case, it is clear that different can be meaningful. I think if the interpretation is union of the included sets, then I'm not as sure about that. > > Chris > > On Apr 16, 2013, at 11:21 PM, Lucian Smith <lp...@sp...> wrote: > >> * Zhang, Fengkai <zha...@ni...> [2013-04-17 05:24] writes: >>> Hi Lucian, >>> >>> I have one question regarding a group (say "subG") referenced as a >>> member of another group (say "G"). Is there any restriction to the >>> "kind" attributes of "subG" and "G"? Are they allowed to be different or >>> implicitly required to be the same? It may already be addressed in the >>> spec but I missed it. >> >> That's an interesting question, and it probably should be addressed >> specifically in the spec. But no, they would be allowed to be different. >> You could imagine, say, a group of species involved in a particular thing >> that had one kind, another group of reactions that had one kind, and then >> a group that was the union of those two groups, serving an entirely >> different purpose. >> >> It also makes a difference whether it's semantically considered that >> recursive groups refer to the group itself, or if it refers to the members >> of the group. In other words, if G includes 'subG', is it including that >> because of the members of subG, or is it a reference to the grouping >> itself? If subG contains all species members, does G's reference to subG >> mean 'these species' or does it mean 'this group'? >> >> The answer might end up being "Both, in different contexts." The spec as >> currently written implies 'these species'; I think Chris wants it to mean >> 'this group'. There might be a compromise in there somewhere... >> >> -Lucian >> >> ------------------------------------------------------------------------------ >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> _______________________________________________ >> sbml-groups mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-groups > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > sbml-groups mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-groups > -- Tony Fengkai Zhang, MD, MMath Staff Scientist Laboratory of Systems Biology, DIR, NIAID 9000 Rockville Pike Building 4, Room 137 MSC 0421 Bethesda MD 20892 Phone: 301.496.0985 Fax: 301.480.1660 NIAID, National Institutes of Health, DHHS "Disclaimer: The information in this e-mail and any of its attachments is confidential and may contain sensitive information. It should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage devices. National Institute of Allergy and Infectious Diseases shall not accept liability for any statements made that are sender's own and not expressly made on behalf of the NIAID by one of its representatives. " |
From: Chris J. M. <my...@ec...> - 2013-04-17 14:04:57
|
I agree that allowing them to be different may be possibly useful. I do want to be able to express sets of sets as Lucian points out. In this case, it is clear that different can be meaningful. I think if the interpretation is union of the included sets, then I'm not as sure about that. Chris On Apr 16, 2013, at 11:21 PM, Lucian Smith <lp...@sp...> wrote: > * Zhang, Fengkai <zha...@ni...> [2013-04-17 05:24] writes: >> Hi Lucian, >> >> I have one question regarding a group (say "subG") referenced as a >> member of another group (say "G"). Is there any restriction to the >> "kind" attributes of "subG" and "G"? Are they allowed to be different or >> implicitly required to be the same? It may already be addressed in the >> spec but I missed it. > > That's an interesting question, and it probably should be addressed > specifically in the spec. But no, they would be allowed to be different. > You could imagine, say, a group of species involved in a particular thing > that had one kind, another group of reactions that had one kind, and then > a group that was the union of those two groups, serving an entirely > different purpose. > > It also makes a difference whether it's semantically considered that > recursive groups refer to the group itself, or if it refers to the members > of the group. In other words, if G includes 'subG', is it including that > because of the members of subG, or is it a reference to the grouping > itself? If subG contains all species members, does G's reference to subG > mean 'these species' or does it mean 'this group'? > > The answer might end up being "Both, in different contexts." The spec as > currently written implies 'these species'; I think Chris wants it to mean > 'this group'. There might be a compromise in there somewhere... > > -Lucian > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > sbml-groups mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-groups |
From: Lucian S. <lp...@sp...> - 2013-04-17 05:21:47
|
* Zhang, Fengkai <zha...@ni...> [2013-04-17 05:24] writes: > Hi Lucian, > > I have one question regarding a group (say "subG") referenced as a > member of another group (say "G"). Is there any restriction to the > "kind" attributes of "subG" and "G"? Are they allowed to be different or > implicitly required to be the same? It may already be addressed in the > spec but I missed it. That's an interesting question, and it probably should be addressed specifically in the spec. But no, they would be allowed to be different. You could imagine, say, a group of species involved in a particular thing that had one kind, another group of reactions that had one kind, and then a group that was the union of those two groups, serving an entirely different purpose. It also makes a difference whether it's semantically considered that recursive groups refer to the group itself, or if it refers to the members of the group. In other words, if G includes 'subG', is it including that because of the members of subG, or is it a reference to the grouping itself? If subG contains all species members, does G's reference to subG mean 'these species' or does it mean 'this group'? The answer might end up being "Both, in different contexts." The spec as currently written implies 'these species'; I think Chris wants it to mean 'this group'. There might be a compromise in there somewhere... -Lucian |
From: Zhang, F. (NIH/N. [E] <zha...@ni...> - 2013-04-17 04:20:57
|
Hi Lucian, I have one question regarding a group (say "subG") referenced as a member of another group (say "G"). Is there any restriction to the "kind" attributes of "subG" and "G"? Are they allowed to be different or implicitly required to be the same? It may already be addressed in the spec but I missed it. On 4/15/13 8:48 PM, Lucian Smith wrote: > A new version of the 'Groups' specification is available at: > > https://docs.google.com/file/d/0B71r5kLs3FliX1Zxc1plbHhxQ1E/edit > > > This version incorporates the comments that people made on the last > version of the spec that Mike created, and adds an entirely new construct > to it, with the purpose of allowing attribute validation (among a few > other things). This new addition allows groups to *completely* replace > the old SpeciesType class from SBML L2! It also allows new restrictions > to be put in place in a hopefully clear and extensible manner. > > The UML diagram of the Group class can be found at: > > https://docs.google.com/drawings/d/1v1UjXujZtmVutCuCM8PKuB8jGfXrrM6X_IhQatqzPP4 > > if you want to make comments there. > > I was hoping that posting a PDF to google docs would allow people to > comment directly inside the PDF, but this capability does not yet seem to > be implemented--you can make comments on the document as a whole, but you > cannot highlight and otherwise make comments; more's the pity. > > If you are so inclined, I am particularly interested in opinions about the > following: > > Things I am prepared to defend, but welcome criticism of: > > * The concept of the new MemberConstraints class > * Recursive groups referencing the actual referenced elements, rather than > the Group element itself. > * The groups/comp interaction (referencing elements from other Models). > > > Things I am not sure on: > > * The particular format of the MemberConstraints class > * The usefulness of the 'membersShareParent' attribute > * Whether my descriptions are clear enough. > * Whether annotations of the ListOfMembers should add to or be overridden > by annotations of the referenced members. > > Thank you! > > -Lucian > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > sbml-groups mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-groups > -- Tony Fengkai Zhang, MD, MMath Staff Scientist Laboratory of Systems Biology, DIR, NIAID 9000 Rockville Pike Building 4, Room 137 MSC 0421 Bethesda MD 20892 Phone: 301.496.0985 Fax: 301.480.1660 NIAID, National Institutes of Health, DHHS "Disclaimer: The information in this e-mail and any of its attachments is confidential and may contain sensitive information. It should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage devices. National Institute of Allergy and Infectious Diseases shall not accept liability for any statements made that are sender's own and not expressly made on behalf of the NIAID by one of its representatives. " |
From: Chris J. M. <my...@ec...> - 2013-04-16 22:33:11
|
>>> I strongly prefer the set-of-sets interpretation. I would like to see groups evolving into sets, and this would make the most sense in that context. > > Well, that's certainly possible. This would mean that you could not > perform the 'same class' and 'different compartments' "SpeciesType-style" > validation on groups of groups; you'd have to do that validation on direct > groups of species. Is that what you want? Do any others have opinions > about this? > Well, I don't really care about speciesType. I would though like to have the ability to construct sets. >>>>> >> I think if you want to group objects that exist in subModels then you should use replacements and bring them up top then group them. This is what you need to do to create any other types of relationships such as species being involved together in the same reaction. > > Well, hmm. Let's say you have this model: > > Submodel A: > species s1 in compartment c1 > species s2 in compartment c1 > > main model: > Submodel A > species S1 in compartment C1, replaced by species A.s1 > species S2 in compartment C2, replaced by species A.s2 > Group G1 = [S1, S2] > > This will end up with two species in the same compartment. But if you > told group G1, "The species in this set must have different compartments" > if you didn't follow the replacements, it would look like it passed > validation (conversely, you could have a parallel situation where it > looked like it failed validation, but actually passed). > > I suppose this argues for your point--that referencing other Models > directly is not very useful. It also means I need to explicitly state > that hierarchical rules should be followed before applying Group > validation. > Thanks for arguing my point :-) >>>>> >> Are we actually planning to put Id and Names on subObjects such as Delay and Priority? I would have thought that we would restrict the Id/Name to first class objects only. > > That was indeed the plan, the last I heard of it. We still haven't talked > about it on sbml-discuss, though. > Hmm, I guess we may have thought about wanting to reference a delay in layout or something. If we do put it on everything, couldn't this be in sbase? If so, couldn't this mean we could remove metaId. Probably the wrong list for this discussion. :-) Chris |
From: Lucian S. <lp...@sp...> - 2013-04-16 22:18:35
|
* Chris J. Myers <my...@ec...> [2013-04-16 23:00] writes: > >>> * Recursive groups referencing the actual referenced elements, rather than > >>> the Group element itself. > >> > >> What do you mean by this? Can you give an example? > > > > Let's say that you have three groups: > > > > G1: [S1, S2, S3] > > G2: [S4, S5] > > G3: [S6] > > > > All of these are grouped for some other reason. Then you want to create a > > group with all the S's, including some that haven't been grouped yet: > > > > G4: [G1, G2, G3, S7, S8] > > > > I claim, in the spec, that this is exactly equivalent to having a group of > > S1-S7. So you could have the restriction "All these have to be the same > > class" or "All of these have have the same 'constant' flag", even though > > that's not literally true. > > > > The drawback of this approach is that you can't group groups *as groups*, > > and use a group to say "These are all my thus-and-so groups" or "These > > groups are all partonomies". > > > > I don't know which version people envision themselves using; I guessed > > that the 'follow group references' version would be more intuitive and > > useful. > > > I strongly prefer the set-of-sets interpretation. I would like to see groups evolving into sets, and this would make the most sense in that context. Well, that's certainly possible. This would mean that you could not perform the 'same class' and 'different compartments' "SpeciesType-style" validation on groups of groups; you'd have to do that validation on direct groups of species. Is that what you want? Do any others have opinions about this? > >>> * The groups/comp interaction (referencing elements from other Models). > >>> > >> Yuck! I think this should be disallowed. What is the use case? I don't like the fact that you have something that you would lose if you split a hierarchical model into multiple files. It should never matter if the models are all in one file or in multiple files. > > > > This is so you can group submodel elements without resorting to an > > 'SBaseRef'-type reference system. I'm not sure why you'd be against it > > because you lose it if it's split into multiple files, since you couldn't > > have it at all in the first place if it was in multiple files? This at > > least allows basic grouping at a very low overhead cost. If it turns out > > that people really really want multiple-file groups, we could extend it in > > the future, perhaps? > > > I think if you want to group objects that exist in subModels then you should use replacements and bring them up top then group them. This is what you need to do to create any other types of relationships such as species being involved together in the same reaction. Well, hmm. Let's say you have this model: Submodel A: species s1 in compartment c1 species s2 in compartment c1 main model: Submodel A species S1 in compartment C1, replaced by species A.s1 species S2 in compartment C2, replaced by species A.s2 Group G1 = [S1, S2] This will end up with two species in the same compartment. But if you told group G1, "The species in this set must have different compartments" if you didn't follow the replacements, it would look like it passed validation (conversely, you could have a parallel situation where it looked like it failed validation, but actually passed). I suppose this argues for your point--that referencing other Models directly is not very useful. It also means I need to explicitly state that hierarchical rules should be followed before applying Group validation. > >>> Things I am not sure on: > >>> > >>> * The particular format of the MemberConstraints class > >> > >> Fine but drop Id/Name unless you see some use. We are getting too Id/Name happy. > > > > Enh. The plan for L3v2 is to literally put a name/id on everything but > > ListOfs. It's easier to have a consistent system in place beforehand than > > it is to patch it later. And in any event, there's already a use-case for > > Comp and Layout, which both manipulate elements by ID if possible. > > > Are we actually planning to put Id and Names on subObjects such as Delay and Priority? I would have thought that we would restrict the Id/Name to first class objects only. That was indeed the plan, the last I heard of it. We still haven't talked about it on sbml-discuss, though. -Lucian |
From: Chris J. M. <my...@ec...> - 2013-04-16 21:53:42
|
>>> * Recursive groups referencing the actual referenced elements, rather than >>> the Group element itself. >> >> What do you mean by this? Can you give an example? > > Let's say that you have three groups: > > G1: [S1, S2, S3] > G2: [S4, S5] > G3: [S6] > > All of these are grouped for some other reason. Then you want to create a > group with all the S's, including some that haven't been grouped yet: > > G4: [G1, G2, G3, S7, S8] > > I claim, in the spec, that this is exactly equivalent to having a group of > S1-S7. So you could have the restriction "All these have to be the same > class" or "All of these have have the same 'constant' flag", even though > that's not literally true. > > The drawback of this approach is that you can't group groups *as groups*, > and use a group to say "These are all my thus-and-so groups" or "These > groups are all partonomies". > > I don't know which version people envision themselves using; I guessed > that the 'follow group references' version would be more intuitive and > useful. > I strongly prefer the set-of-sets interpretation. I would like to see groups evolving into sets, and this would make the most sense in that context. >>> * The groups/comp interaction (referencing elements from other Models). >>> >> Yuck! I think this should be disallowed. What is the use case? I don't like the fact that you have something that you would lose if you split a hierarchical model into multiple files. It should never matter if the models are all in one file or in multiple files. > > This is so you can group submodel elements without resorting to an > 'SBaseRef'-type reference system. I'm not sure why you'd be against it > because you lose it if it's split into multiple files, since you couldn't > have it at all in the first place if it was in multiple files? This at > least allows basic grouping at a very low overhead cost. If it turns out > that people really really want multiple-file groups, we could extend it in > the future, perhaps? > I think if you want to group objects that exist in subModels then you should use replacements and bring them up top then group them. This is what you need to do to create any other types of relationships such as species being involved together in the same reaction. >>> Things I am not sure on: >>> >>> * The particular format of the MemberConstraints class >> >> Fine but drop Id/Name unless you see some use. We are getting too Id/Name happy. > > Enh. The plan for L3v2 is to literally put a name/id on everything but > ListOfs. It's easier to have a consistent system in place beforehand than > it is to patch it later. And in any event, there's already a use-case for > Comp and Layout, which both manipulate elements by ID if possible. > Are we actually planning to put Id and Names on subObjects such as Delay and Priority? I would have thought that we would restrict the Id/Name to first class objects only. Cheers, Chris |
From: Lucian S. <lp...@sp...> - 2013-04-16 20:42:32
|
* Chris J. Myers <my...@ec...> [2013-04-16 19:24] writes: > Hi Lucian, > > It looks pretty good. My comments are included in the attachment. > > > > * The concept of the new MemberConstraints class > > Seems good though I'm not sure of the use case for membersShareParent, is this really needed? As I mention below, I wasn't sure about that one; I thought of the idea and added it in case anyone else thought it was useful. > > * Recursive groups referencing the actual referenced elements, rather than > > the Group element itself. > > What do you mean by this? Can you give an example? Let's say that you have three groups: G1: [S1, S2, S3] G2: [S4, S5] G3: [S6] All of these are grouped for some other reason. Then you want to create a group with all the S's, including some that haven't been grouped yet: G4: [G1, G2, G3, S7, S8] I claim, in the spec, that this is exactly equivalent to having a group of S1-S7. So you could have the restriction "All these have to be the same class" or "All of these have have the same 'constant' flag", even though that's not literally true. The drawback of this approach is that you can't group groups *as groups*, and use a group to say "These are all my thus-and-so groups" or "These groups are all partonomies". I don't know which version people envision themselves using; I guessed that the 'follow group references' version would be more intuitive and useful. > > * The groups/comp interaction (referencing elements from other Models). > > > Yuck! I think this should be disallowed. What is the use case? I don't like the fact that you have something that you would lose if you split a hierarchical model into multiple files. It should never matter if the models are all in one file or in multiple files. This is so you can group submodel elements without resorting to an 'SBaseRef'-type reference system. I'm not sure why you'd be against it because you lose it if it's split into multiple files, since you couldn't have it at all in the first place if it was in multiple files? This at least allows basic grouping at a very low overhead cost. If it turns out that people really really want multiple-file groups, we could extend it in the future, perhaps? > > Things I am not sure on: > > > > * The particular format of the MemberConstraints class > > Fine but drop Id/Name unless you see some use. We are getting too Id/Name happy. Enh. The plan for L3v2 is to literally put a name/id on everything but ListOfs. It's easier to have a consistent system in place beforehand than it is to patch it later. And in any event, there's already a use-case for Comp and Layout, which both manipulate elements by ID if possible. > > * The usefulness of the 'membersShareParent' attribute > > Yeah, what is it good for? MEMBERSHAREPARENT! UNH! WHAT IS IT GOOD FOR? ABSOLUTELY NOTHING! [repeat] > > * Whether my descriptions are clear enough. > > To me, yes. Good! > > * Whether annotations of the ListOfMembers should add to or be overridden > > by annotations of the referenced members. > > > Hmm, I think add to, but not a strong opinion. I'm leaning that way too, but it's inconsistent with SBO and Notes, which is why I made it this way at first. -Lucian |
From: Chris J. M. <my...@ec...> - 2013-04-16 18:20:51
|
Hi Lucian, It looks pretty good. My comments are included in the attachment. > > * The concept of the new MemberConstraints class Seems good though I'm not sure of the use case for membersShareParent, is this really needed? > * Recursive groups referencing the actual referenced elements, rather than > the Group element itself. What do you mean by this? Can you give an example? > * The groups/comp interaction (referencing elements from other Models). > Yuck! I think this should be disallowed. What is the use case? I don't like the fact that you have something that you would lose if you split a hierarchical model into multiple files. It should never matter if the models are all in one file or in multiple files. > > Things I am not sure on: > > * The particular format of the MemberConstraints class Fine but drop Id/Name unless you see some use. We are getting too Id/Name happy. > * The usefulness of the 'membersShareParent' attribute Yeah, what is it good for? > * Whether my descriptions are clear enough. To me, yes. > * Whether annotations of the ListOfMembers should add to or be overridden > by annotations of the referenced members. > Hmm, I think add to, but not a strong opinion. Chris |
From: Lucian S. <lp...@sp...> - 2013-04-16 00:48:39
|
A new version of the 'Groups' specification is available at: https://docs.google.com/file/d/0B71r5kLs3FliX1Zxc1plbHhxQ1E/edit This version incorporates the comments that people made on the last version of the spec that Mike created, and adds an entirely new construct to it, with the purpose of allowing attribute validation (among a few other things). This new addition allows groups to *completely* replace the old SpeciesType class from SBML L2! It also allows new restrictions to be put in place in a hopefully clear and extensible manner. The UML diagram of the Group class can be found at: https://docs.google.com/drawings/d/1v1UjXujZtmVutCuCM8PKuB8jGfXrrM6X_IhQatqzPP4 if you want to make comments there. I was hoping that posting a PDF to google docs would allow people to comment directly inside the PDF, but this capability does not yet seem to be implemented--you can make comments on the document as a whole, but you cannot highlight and otherwise make comments; more's the pity. If you are so inclined, I am particularly interested in opinions about the following: Things I am prepared to defend, but welcome criticism of: * The concept of the new MemberConstraints class * Recursive groups referencing the actual referenced elements, rather than the Group element itself. * The groups/comp interaction (referencing elements from other Models). Things I am not sure on: * The particular format of the MemberConstraints class * The usefulness of the 'membersShareParent' attribute * Whether my descriptions are clear enough. * Whether annotations of the ListOfMembers should add to or be overridden by annotations of the referenced members. Thank you! -Lucian |
From: Brett G. O. <b.g...@vu...> - 2013-04-03 13:51:16
|
On 03/04/13 15:42, Chris J. Myers wrote: > No hurry. Let's hold off adding the new set math for now, if you think it will delay release significantly. > > Brett: why version 3, what do you have in mind for version 2? Version 2 is good, (I left a version open for fixes/enhancements) simply meant some future version ... b. > Chris > > On Apr 3, 2013, at 4:34 AM, Nicolas Le Novere <n.l...@gm...> wrote: > >> Chris, >> >> You may be right (actually, I am convinced you are right). But could-we >> postponed that to a future version? We need the basic groups to cover for >> SBML Level 2 Species and Compartment types, but also to convert from BioPAX >> pathways and encode SBGN groups. I think support for the group package as >> it stands is pretty easy. However, support for a proper set package, with >> all the semantic behind may be a little bit more difficult. The good thing >> with the current group package is that it covers needs outside the >> mathematics (although I can easily see how it will provide bricks for >> rule-based modelling). >> >> On 03/04/13 11:23, Brett G. Olivier wrote: >>> On 29/03/13 16:32, Chris J. Myers wrote: >>>> I've been wondering if the groups package is not simply the beginnings of a sets package. We can think of a group as a set of objects. I could imagine using things like subset, superset to compare groups. I could also imagine creating groups that are not statically defined but could be changed dynamically with set operations like union and intersection. I was thinking that perhaps the groups package could use the theory of sets portion of mathML. What do others think? >>> Hi Chris. In principle this is a good idea, however, I'm not sure >>> exactly what sort of use case their would be right now, something like: >>> >>> intersection(set(metabolites_in_glycolysis), >>> set(metabolites_in_ATP_synthesis)) >>> or >>> intersection(set(reaction_rates != 0), set(reactions_in_glycolysis)) >>> or >>> intersection(set(exchange_reactions_GSmodel_2), >>> set(exchange_reactions_GSmodel_2)) ? >>> >>> What I would be careful of is trying to implement this in version 1, for >>> the simple fact that the speciesType users and I suspect, soon, also the >>> FBC modellers will want groups official and in libSBML asap. So if >>> possible I'd target version 3 for this try make version 1 (as we have >>> it) lay the foundation for this. Viable? >>> >>> Cheers, Brett >>> >> >> -- >> Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT >> Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere >> Skype:n.lenovere, n.l...@gm..., orcid.org/0000-0001-2345-6789 >> http://lenoverelab.org/, http://lenoverelab.org/perso/lenov/ >> >> >> ------------------------------------------------------------------------------ >> Minimize network downtime and maximize team effectiveness. >> Reduce network management and security costs.Learn how to hire >> the most talented Cisco Certified professionals. Visit the >> Employer Resources Portal >> http://www.cisco.com/web/learning/employer_resources/index.html >> _______________________________________________ >> sbml-groups mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-groups > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > sbml-groups mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-groups -- Brett G. Olivier PhD Researcher in Computational Systems Biology Systems Bioinformatics VU University Amsterdam Amsterdam, The Netherlands Email: b.g.olivier[AT]vu[dot]nl Tel (office) +31 20 5987248 |
From: Chris J. M. <my...@ec...> - 2013-04-03 13:42:18
|
No hurry. Let's hold off adding the new set math for now, if you think it will delay release significantly. Brett: why version 3, what do you have in mind for version 2? Chris On Apr 3, 2013, at 4:34 AM, Nicolas Le Novere <n.l...@gm...> wrote: > Chris, > > You may be right (actually, I am convinced you are right). But could-we > postponed that to a future version? We need the basic groups to cover for > SBML Level 2 Species and Compartment types, but also to convert from BioPAX > pathways and encode SBGN groups. I think support for the group package as > it stands is pretty easy. However, support for a proper set package, with > all the semantic behind may be a little bit more difficult. The good thing > with the current group package is that it covers needs outside the > mathematics (although I can easily see how it will provide bricks for > rule-based modelling). > > On 03/04/13 11:23, Brett G. Olivier wrote: >> On 29/03/13 16:32, Chris J. Myers wrote: >>> I've been wondering if the groups package is not simply the beginnings of a sets package. We can think of a group as a set of objects. I could imagine using things like subset, superset to compare groups. I could also imagine creating groups that are not statically defined but could be changed dynamically with set operations like union and intersection. I was thinking that perhaps the groups package could use the theory of sets portion of mathML. What do others think? >> >> Hi Chris. In principle this is a good idea, however, I'm not sure >> exactly what sort of use case their would be right now, something like: >> >> intersection(set(metabolites_in_glycolysis), >> set(metabolites_in_ATP_synthesis)) >> or >> intersection(set(reaction_rates != 0), set(reactions_in_glycolysis)) >> or >> intersection(set(exchange_reactions_GSmodel_2), >> set(exchange_reactions_GSmodel_2)) ? >> >> What I would be careful of is trying to implement this in version 1, for >> the simple fact that the speciesType users and I suspect, soon, also the >> FBC modellers will want groups official and in libSBML asap. So if >> possible I'd target version 3 for this try make version 1 (as we have >> it) lay the foundation for this. Viable? >> >> Cheers, Brett >> > > > -- > Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT > Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere > Skype:n.lenovere, n.l...@gm..., orcid.org/0000-0001-2345-6789 > http://lenoverelab.org/, http://lenoverelab.org/perso/lenov/ > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > sbml-groups mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-groups |
From: Nicolas Le N. <n.l...@gm...> - 2013-04-03 10:34:15
|
Chris, You may be right (actually, I am convinced you are right). But could-we postponed that to a future version? We need the basic groups to cover for SBML Level 2 Species and Compartment types, but also to convert from BioPAX pathways and encode SBGN groups. I think support for the group package as it stands is pretty easy. However, support for a proper set package, with all the semantic behind may be a little bit more difficult. The good thing with the current group package is that it covers needs outside the mathematics (although I can easily see how it will provide bricks for rule-based modelling). On 03/04/13 11:23, Brett G. Olivier wrote: > On 29/03/13 16:32, Chris J. Myers wrote: >> I've been wondering if the groups package is not simply the beginnings of a sets package. We can think of a group as a set of objects. I could imagine using things like subset, superset to compare groups. I could also imagine creating groups that are not statically defined but could be changed dynamically with set operations like union and intersection. I was thinking that perhaps the groups package could use the theory of sets portion of mathML. What do others think? > > Hi Chris. In principle this is a good idea, however, I'm not sure > exactly what sort of use case their would be right now, something like: > > intersection(set(metabolites_in_glycolysis), > set(metabolites_in_ATP_synthesis)) > or > intersection(set(reaction_rates != 0), set(reactions_in_glycolysis)) > or > intersection(set(exchange_reactions_GSmodel_2), > set(exchange_reactions_GSmodel_2)) ? > > What I would be careful of is trying to implement this in version 1, for > the simple fact that the speciesType users and I suspect, soon, also the > FBC modellers will want groups official and in libSBML asap. So if > possible I'd target version 3 for this try make version 1 (as we have > it) lay the foundation for this. Viable? > > Cheers, Brett > -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, n.l...@gm..., orcid.org/0000-0001-2345-6789 http://lenoverelab.org/, http://lenoverelab.org/perso/lenov/ |
From: Brett G. O. <b.g...@vu...> - 2013-04-03 10:25:19
|
On 29/03/13 16:32, Chris J. Myers wrote: > I've been wondering if the groups package is not simply the beginnings of a sets package. We can think of a group as a set of objects. I could imagine using things like subset, superset to compare groups. I could also imagine creating groups that are not statically defined but could be changed dynamically with set operations like union and intersection. I was thinking that perhaps the groups package could use the theory of sets portion of mathML. What do others think? Hi Chris. In principle this is a good idea, however, I'm not sure exactly what sort of use case their would be right now, something like: intersection(set(metabolites_in_glycolysis), set(metabolites_in_ATP_synthesis)) or intersection(set(reaction_rates != 0), set(reactions_in_glycolysis)) or intersection(set(exchange_reactions_GSmodel_2), set(exchange_reactions_GSmodel_2)) ? What I would be careful of is trying to implement this in version 1, for the simple fact that the speciesType users and I suspect, soon, also the FBC modellers will want groups official and in libSBML asap. So if possible I'd target version 3 for this try make version 1 (as we have it) lay the foundation for this. Viable? Cheers, Brett -- Brett G. Olivier PhD Systems Bioinformatics VU University Amsterdam Amsterdam, The Netherlands Email: b.g.olivier[AT]vu[dot]nl Tel (office) +31 20 5987248 |
From: Chris J. M. <my...@ec...> - 2013-03-29 15:32:19
|
Hi, I've been wondering if the groups package is not simply the beginnings of a sets package. We can think of a group as a set of objects. I could imagine using things like subset, superset to compare groups. I could also imagine creating groups that are not statically defined but could be changed dynamically with set operations like union and intersection. I was thinking that perhaps the groups package could use the theory of sets portion of mathML. What do others think? Chris |
From: Chris J. M. <my...@ec...> - 2012-12-17 14:53:48
|
Thanks for the info. I think that groups will largely be used as a sort of annotation as you describe. Though my definition of annotation and Nicolas's likely differ. I see annotations as anything that does not affect the mathematical meaning, but he has a somewhat broader view of how models are to be interpreted. One use case I have in mind is grouping objects that come from a subModel. This could be used as a way of recording information about structure after flattening of the model for simulation. This could be useful for presentation of results as you could have a grapher that sorts the results hierarchically for you. So, you could select a subModel and then an object within a subModel that you want graphed. Currently, we do this with a naming convention, but that is a bit of hack. We should perhaps put some example use cases into the specification for groups. Cheers, Chris On Dec 17, 2012, at 4:26 AM, "Brett G. Olivier" <b.g...@vu...> wrote: > On 15/12/12 18:40, Chris J. Myers wrote: >> As a side item, I'm curious if anyone on this list has a good use case >> for groups as that will help us understand the needs for the package >> better. If anyone is or is going to use them, I would find it >> interesting to hear about it. Cheers, Chris > > I've been playing around with a very simple use case where I started > grouping things like "exchange reactions", "subsystems" etc in genome > scale models. Not very exciting as groups go, they are just collections > of reactions (fluxes), but my feeling is they may be extremely useful > for this sort of annotation. > > -- > Brett G. Olivier PhD > Researcher in Computational Systems Biology > > Systems Bioinformatics > Dept. Molecular Cell Physiology > VU University Amsterdam > Amsterdam, The Netherlands > > Email: b.g.olivier[AT]vu[dot]nl > Tel (office) +31 20 5987248 > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > sbml-groups mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-groups |
From: Brett G. O. <b.g...@vu...> - 2012-12-17 11:27:44
|
On 15/12/12 18:40, Chris J. Myers wrote: > As a side item, I'm curious if anyone on this list has a good use case > for groups as that will help us understand the needs for the package > better. If anyone is or is going to use them, I would find it > interesting to hear about it. Cheers, Chris I've been playing around with a very simple use case where I started grouping things like "exchange reactions", "subsystems" etc in genome scale models. Not very exciting as groups go, they are just collections of reactions (fluxes), but my feeling is they may be extremely useful for this sort of annotation. -- Brett G. Olivier PhD Researcher in Computational Systems Biology Systems Bioinformatics Dept. Molecular Cell Physiology VU University Amsterdam Amsterdam, The Netherlands Email: b.g.olivier[AT]vu[dot]nl Tel (office) +31 20 5987248 |
From: Nicolas Le N. <n.l...@gm...> - 2012-12-16 18:43:47
|
On 16/12/12 18:17, Chris J. Myers wrote: >> If we use SBO to characterise the group, we basically flag this >> information as annotation, not needed to interpret the model. > > Groups do not change the mathematical meaning of a model. So, in what > way do you see groups changing model interpretation? Groups do not change the math of a model. But they can change the way the model is processed and interpreted. The days where SBML was supposed to be used solely by numerical simulators running timecourses have been gone for a while. There is more in "interpreting a model" than "running a simulation". Moreover SBML files are used at different steps of a modelling pipeline. To give a practical example: One person in my group is reconstructing signalling pathways. Ultimately the goal is to run dynamic simulations for part of them. However, at the moment, we are far from that. Our species are not "pools" in the SBML sense. We have overlapping and nested pools. Knowing that CaMKII_PSD and CaMKII_Cytoplasm are part of a superpool of CaMKII as well as knowing that CaMKII_T286P and CaMKII_T306P are types of CaMKII will be very important down the road. Sure, we could use annotations (with bq:biol qualifiers) and write a software to extract the information and rebuild the group. In the first case, we could also use an assignment rule. But the groups can now be translated graphically (groups will be part of all three forthcoming spec of SBGN). Other cases are general reactions. It has been a bit forgotten now, but SpeciesTypes and CompartmentTypes has been created in part to allow for generalised reactions, where we would describe one reaction involving SpeciesTypes and all the necessary reactions would be instantiated at runtime (e.g. ATP->ADP+P in all 100 cells of the model). This case will not be supposed to be allowed by groups. But I can easily see how people will immediately do so (myself first). > FYI: SBO is > now being used by our tool in a way that is beyond simple annotation and > affects how we interpret our models. I am happy to know that :-) -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, n.l...@gm..., ORCID: 0000-0002-6309-7327 http://lenoverelab.org/, http://lenoverelab.org/perso/lenov/ |
From: Chris J. M. <my...@ec...> - 2012-12-16 18:17:18
|
On Dec 16, 2012, at 11:05 AM, Nicolas Le Novere <n.l...@gm...> wrote: > On 16/12/12 17:57, Chris J. Myers wrote: >>> >>> In the most extreme cases, we will get a dozen of values at the end >> >> This is exactly the reason to use SBO terms rather than kind. It is >> easier to extend it in the future to meet the needs, and I think it will >> in the end make groups more useful to more people. I > > I said in the most extreme cases! At the moment, I can only imagine a > couple more by stretching it. Come one, before HARMONY I was the only one > imagining there was more than *one* type of groups. > You were indeed the one with this great idea :-). >> also think it >> makes sense to use SBO as the ontology because we probably want more >> specific things than is-a and part-of. For example, why not have an SBO >> term "SpeciesType" and another "CompartmentType"? > > Is it not immediately emerging from the fact that all members are species > or all members are compartments? > You can perhaps group species because they are the same species in different compartments (i.e., what a speciesType was meant to be), but I could also just group species in a group of "my favorite species". Who knows. Kind does help differentiate, but if we could say this group is a "SpeciesType", then the meaning would be absolutely clear and well defined. >> Your >> semantics argument limitation also does not make sense to me. If you >> mark a group as a species type, I could easily see tools decide to >> report the total quantity of all members of that group. > > But ... the SpeciesType was not a partonomy. A group corresponding to the > SpeciesType would be a classification, not a parthood. The id of the group > would not represent a super-pool. > > This is exactly why we need to know if the kind of group is one or the > other. In the absence of this information, the group is only a fuzzy > annotation. > > If we use SBO to characterise the group, we basically flag this information > as annotation, not needed to interpret the model. Groups do not change the mathematical meaning of a model. So, in what way do you see groups changing model interpretation? I think their main use is a type of annotation. I think using SBO actually increases the likelihood of finding another use for them in the future. FYI: SBO is now being used by our tool in a way that is beyond simple annotation and affects how we interpret our models. By the way, since we have SBO terms on groups, in any case, we can have both kind and SBO terms for a group as well. While I'm not sure that we really need both, it won't hurt. Chris |
From: Nicolas Le N. <n.l...@gm...> - 2012-12-16 18:05:28
|
On 16/12/12 17:57, Chris J. Myers wrote: >> >> In the most extreme cases, we will get a dozen of values at the end > > This is exactly the reason to use SBO terms rather than kind. It is > easier to extend it in the future to meet the needs, and I think it will > in the end make groups more useful to more people. I I said in the most extreme cases! At the moment, I can only imagine a couple more by stretching it. Come one, before HARMONY I was the only one imagining there was more than *one* type of groups. > also think it > makes sense to use SBO as the ontology because we probably want more > specific things than is-a and part-of. For example, why not have an SBO > term "SpeciesType" and another "CompartmentType"? Is it not immediately emerging from the fact that all members are species or all members are compartments? > Your > semantics argument limitation also does not make sense to me. If you > mark a group as a species type, I could easily see tools decide to > report the total quantity of all members of that group. But ... the SpeciesType was not a partonomy. A group corresponding to the SpeciesType would be a classification, not a parthood. The id of the group would not represent a super-pool. This is exactly why we need to know if the kind of group is one or the other. In the absence of this information, the group is only a fuzzy annotation. If we use SBO to characterise the group, we basically flag this information as annotation, not needed to interpret the model. -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, n.l...@gm..., ORCID: 0000-0002-6309-7327 http://lenoverelab.org/, http://lenoverelab.org/perso/lenov/ |
From: Chris J. M. <my...@ec...> - 2012-12-16 17:57:24
|
> > In the most extreme cases, we will get a dozen of values at the end This is exactly the reason to use SBO terms rather than kind. It is easier to extend it in the future to meet the needs, and I think it will in the end make groups more useful to more people. I also think it makes sense to use SBO as the ontology because we probably want more specific things than is-a and part-of. For example, why not have an SBO term "SpeciesType" and another "CompartmentType"? If we did this, then we could immediately be able to up-convert L2 models with these constructs directly into groups. These would also be a lot more meaningful to tools as it makes clear what the purpose of the group is. The people who needed SpeciesType would have it again, and be happy :-). However, what we would have is something a lot more general. Your semantics argument limitation also does not make sense to me. If you mark a group as a species type, I could easily see tools decide to report the total quantity of all members of that group. Chris |
From: Nicolas Le N. <n.l...@gm...> - 2012-12-16 12:26:19
|
On 16/12/12 05:04, Lucian Smith wrote: >>> What if we did the same thing here? We create a really really basic >>> ontology to start with, with three items: >>> >>> collection >>> / \ >>> classification partonomy >>> >>> and then as more specific collection types are needed, they are added to >>> the ontology. >> >> But there are already ontologies for that, for instance the OBO >> relationships ontology. > > If we can use those instead, and they also include 'classification' and > 'partonomy', that would be fine. They do. Is_a and part_of are the two basic relationships. But using them at the moment would move that information to annotation. >>> And here's the clever part: we put these in SBO, >> >> Where do-you put them in SBO? > > In a new branch? I do not think that it is a good idea for two reasons, one fundamental, the other practical. Fundamental =========== I do think the "kind" of a group is part of the structure of the encoded model. SBO so far has been dealing with the semantic of the model in an SBML-independent way. If you read the model and renders it e.g. in MatLab, the SBO terms remain valid (for the bits that survived the conversion). But the model structure may be completely different. kind="partonomy" builds a superpool out of the member pools. So it affects the model structure. It is akin to something like rule="rate". In terms of ontology, this would correspond to the OWL representations of SBML developed over the years by Jeremy Zucker, Allyson Lister, Michel Dumontier/Robert Hoenhorf or Sarala Wimalaratne. In any case, since it affects the model structure, this also means the list of values must be controlled by the specification, as are units etc. We cannot externalise it to an open (in the sense of unbounded) ontology. Practical ========= I think SBO is used by most tools as an annotation, and through libSBML. Doing things useful by processing the ontology requests a bit more effort (An example of tool would be SBMLsqueezer). I think that is a bit over-engineered for a case where we really only need to know if the elements are part of or version of the group (or if this is none of those two). SBO is often used to brush something under the carpet. Let's not do that. Some people need groups (examples are the users of speciesType before, but also users of the SBGN groups). And those users need to know what the groups are meant to represent. People who do not need to know the kind only want group for annotation purpose ( I suspect that in some cases using the annotation meaningfully also may need the kind). In the most extreme cases, we will get a dozen of values at the end (I cannot imagine so many at the moment). So let's go with the current version of the package and three values. And see where we are heading and if we need more in the future. Let's not create structures to encode something we do not need or may not even exist. -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, n.l...@gm..., ORCID: 0000-0002-6309-7327 http://lenoverelab.org/, http://lenoverelab.org/perso/lenov/ |
From: Lucian S. <lp...@sp...> - 2012-12-16 05:04:52
|
* Nicolas Le Novere <n.l...@gm...> [2012-12-15 23:20] writes: > I am happy that suddenly everyone is excited about kind :-) > But maybe too excited ... > > On 15/12/12 21:03, Lucian Smith wrote: > > > OK, based on this I have an entirely different sort of suggestion. It > > sounds to me like there is research to be done in the 'kind' attribute of > > groups, and that sometimes, you might want a more-specific classification > > of a group: Zhang's suggestions are (I think?) more specific types than > > 'classification' or 'partonomy', but would also adhere to one of those > > types. > > What would be those types? We do not have to re-invent the wheel here. This > is done by philosophers. If we need this kind of concepts let's turn to > them. But more down to earth, could-we go back to practical cases? > > I can see two practically usefull types of groups for modelling, the > partonomy and the classification. The collection is useful for annotation, > but it is the default group. It means "I put those things together, but it > is a convenience grouping" > > > What if we did the same thing here? We create a really really basic > > ontology to start with, with three items: > > > > collection > > / \ > > classification partonomy > > > > and then as more specific collection types are needed, they are added to > > the ontology. > > But there are already ontologies for that, for instance the OBO > relationships ontology. If we can use those instead, and they also include 'classification' and 'partonomy', that would be fine. > > And here's the clever part: we put these in SBO, > > Where do-you put them in SBO? In a new branch? > > In essence, my suggestion is 'replace "kind" with "sboterm"'. > > Ah sorry, I should not have been so glad. Basically you want to get rid of > kind, making groups useless and unable to replace [Species|Compartment]Types So... 'partonomy' and 'classification' are *not* sufficient to replace *Types? And you want something different? I admit confusion. I don't want to get rid of the old 'kind' functionality; I suggested moving that exact functionality to 'sboterm' instead (and making sboterm required, as a result). If we go with an ontology that's not SBO, great; we can make 'kind' point to that (assuming it at least has the 'classification' and 'partonomy' options). -Lucian |