2 Dec 2007 21:12
Auckland CellML Group Meeting Minutes (20071128)
Greetings, The minutes of the Auckland CellML group meeting of 2007-11-28 can now be found at: http://www.cellml.org/meeting_minutes/latest Kind Regards, Tommy.
3 Dec 2007 23:55
CellML Workshop 2008
Following on from the success of the inaugural CellML workshop in 2007, we will be hosting a second meeting on Wednesday 26th March 2008. This event will be held at Old Government House at The University of Auckland, just before the workshop on Multiscale Modelling of the Heart - 27th-29th March, (http://www.bioeng.auckland.ac.nz/events/msmh/) which is to be held on Waiheke Island, Auckland, New Zealand. We are expecting the 2008 meeting to follow a similar format to the first workshop; with a series of short presentations and with time allocated for group discussions. The full programme will be published shortly. For more information please see the CellML Workshop 2008 announcement page: http://www.cellml.org/workshop/workshop2008/ or contact Catherine Lloyd, Poul Nielsen or Peter Hunter. Registration is free, and can be arranged my emailing Catherine at c.lloyd@... We look forward to seeing many of you at the meeting in March.
4 Dec 2007 23:48
Announcement of CellML DOM API version 1.3 and PCEnv version 0.3
Hi all, The CellML DOM API 1.3 has now been released at http://www.cellml.org/downloads/cellml_api/releases/1.3 PCEnv 0.3 has been released at http://www.cellml.org/downloads/pcenv/releases/0.3 Should you find any bugs in the releases, or have feature requests, please report it to our bugtracker at https://tracker.physiomeproject.org, or alternatively email me at j.marsh@... Best Regards, Justin Marsh.
6 Dec 2007 23:40
[Fwd: [Synthetic Biology] SB4.0, 10-12 October 2008, Hong Kong]
Subject: [Synthetic Biology] SB4.0, 10-12 October 2008, Hong Kong
Date: 2007-12-06 13:11:31 GMT
The Fourth International Meeting on Synthetic Biology (SB4.0) will be held from 10-12 October 2008 at the Hong Kong University of Science and Technology in Clear Water Bay, Kowloon, Hong Kong. The organization of the event is being led by the BioBricks Foundation in partnership with the Hong Kong University of Science and Technology (HKUST), the University of Hong Kong (HKU), and the Chinese University of Hong Kong (CUHK). SB4.0 will be a significant meeting, building on the past successes of SB1.0 (MIT), 2.0 (UC Berkeley), and 3.0 (ETH Zurich). Please mark your calendars now and plan to attend. Fund raising in support of travel stipends is well underway. More information will be available via the links below as things develop: http://syntheticbiology.org/(Continue reading)
7 Dec 2007 04:52
Re: My specification draft in progress is nowpushed to the CellML site
Hi Andrew, > 1) Viewing a static page generated from the specification: > > My current version of the specification (which may or may not represent > community consensus) gets pushed into Zope automatically every hour as a > static page. The URL is: > http://www.cellml.org/Members/miller/draft-normative-spec/toplevel.xhtml > > Others may modify the script used to do this to push into their own > members area if they want to do something similar. Not sure if you have noticed, but this page doesn't appear to be updated with the changes you're making in the git repository. Andre.
10 Dec 2007 00:41
specification draft and docbook
Hi all
There has already been some discussion regarding whether the term "CellML file" or "CellML document" is preferred. Current view is that "CellML file" is preferred.
Since XML encourages reuse, it is foreseeable that CellML-XML could be embedded in a containing XML file of some other kind. In that case, the term
"CellML model element" may be preferable.
I have created tracker item 312 for this (https://tracker.physiomeproject.org/show_bug.cgi?id=312).
Regards,
Randall
_______________________________________________ cellml-discussion mailing list cellml-discussion@... http://www.cellml.org/mailman/listinfo/cellml-discussion
12 Dec 2007 00:22
CellML terminology: distinguishing CellML models from the XML in which they are represented
Hi all, I have been working on resolving the current terminology issues in CellML 1.1 where 'model' is used to mean both the XML file in which the model element resides, and the abstract mathematical model represented by that XML file when any imports have been processed. This overloading has occurred as a result of the transition from CellML 1.0 to CellML 1.1. It is an issue which is worth trying to resolve, because issues like this cause the CellML 1.1 text lacks the precision that a well specified format should have. In my initial drafting work, I used the terms 'CellML File' and 'CellML Model' to distinguish the two concepts. These terms were defined, but the aim was that they could be understood without needing to refer to the definitions. However, concerns about this have been raised, because what is being referred to as a CellML File could be embedded into another XML document. This could be addressed by ensuring the definition of CellML File allows for that, but confusion could still occur from this. There were several alternatives proposed at today's CellML meeting: 1) 'CellML Model with no imports or with uninstantiated imports' vs 'CellML Model with all imports instantiated'. The problems with this is that it is cumbersome especially when it appears multiple times in the same sentence (and would possibly be unambiguous in that case), it is confusing to use these terms before imports have been explained, or in the section explaining imports, and it doesn't create a very clear conceptual separation between the representational layer and the model represented in that representational layer. 2) 'CellML model element information item and all descendant information items' vs 'CellML Model'. The former is reasonably cumbersome and would probably be confusing when used in a sentences. Examples from the beginning of the specification of how it could sound... "Every CellML model element information item and all descendant information items SHALL be represented in an XML document which conforms with the well-formedness requirements of the XML 1.0 specification" "Two CellML model element information items and all descendant information items shall be equivalent if one can be transformed to another by making zero or more of the following changes" 3) Make up an acronym of some kind. I have looked into other specifications which may have similar requirements. XInclude uses the phrases 'source infoset' and 'result infoset', and writes the specification as a transformation between the two. I don't think this could work for CellML because import processing is not easily described as a simple transformation, and it is part of a large specification which also cannot easily be written as a transformation (unless we want to describe CellML with imports as a transformation to a single CellML model file with no imports, and then describe that in terms of a transformation into MathML, which might work but would be radically different from the approach we have taken so far). I think we have a few remaining options: 1) Retain the CellML File / CellML Model terminology, and then create another mini-specification for how to embed CellML into other documents which explains that a CellML File is not necessarily the document element. This would probably be a good way to take the specification from a standardisation point of view, because by and large we want people to be exchanging files which have the CellML model element as the document element if they are calling it a CellML File - otherwise it is some other type of document which happens to have CellML embedded in it, and it is not possible to use it from standard CellML tools. 2) Invent an abbreviation. I suggest 'CellML Model Representation (CMR)' vs 'CellML Model Instantiation (CMI)', as one option, although this again could be confusing. However, upon seeing these for the first the reader is likely to look them up in the definitions section rather than relying on any prior knowledge (which may be a good thing if there is a chance that their prior understanding of what the word means is incorrect within the current context). Please let me know what you think on this issue. I personally think that option 1 is the best, but based on the discussion at the CellML meeting today it doesn't seem likely that I will get much support for that approach. Best regards, Andrew
12 Dec 2007 02:05
Re: CellML terminology: distinguishing CellMLmodels from the XML in which they are represented
I think option 1 would be much better than 2. An alternative might be the RDF and RDF/XML approach? Not too sure what that implies, but personally I see it as an RDF graph and then the XML serialisation of that graph. Could we use something like CellML Model and CellML Model/XML or maybe CellML/XML ? Andre. Andrew Miller wrote: > Hi all, > > I have been working on resolving the current terminology issues in > CellML 1.1 where 'model' is used to mean both the XML file in which the > model element resides, and the abstract mathematical model represented > by that XML file when any imports have been processed. This overloading > has occurred as a result of the transition from CellML 1.0 to CellML > 1.1. It is an issue which is worth trying to resolve, because issues > like this cause the CellML 1.1 text lacks the precision that a well > specified format should have. > > In my initial drafting work, I used the terms 'CellML File' and 'CellML > Model' to distinguish the two concepts. These terms were defined, but > the aim was that they could be understood without needing to refer to > the definitions. > > However, concerns about this have been raised, because what is being > referred to as a CellML File could be embedded into another XML > document. This could be addressed by ensuring the definition of CellML > File allows for that, but confusion could still occur from this. > > There were several alternatives proposed at today's CellML meeting: > 1) 'CellML Model with no imports or with uninstantiated imports' vs > 'CellML Model with all imports instantiated'. The problems with this is > that it is cumbersome especially when it appears multiple times in the > same sentence (and would possibly be unambiguous in that case), it is > confusing to use these terms before imports have been explained, or in > the section explaining imports, and it doesn't create a very clear > conceptual separation between the representational layer and the model > represented in that representational layer. > 2) 'CellML model element information item and all descendant information > items' vs 'CellML Model'. The former is reasonably cumbersome and would > probably be confusing when used in a sentences. > Examples from the beginning of the specification of how it could sound... > "Every CellML model element information item and all descendant > information items SHALL be represented in an XML document which conforms > with the well-formedness requirements of the XML 1.0 specification" > "Two CellML model element information items and all descendant > information items shall be equivalent if one can be transformed to > another by making zero or more of the following changes" > 3) Make up an acronym of some kind. > > I have looked into other specifications which may have similar > requirements. XInclude uses the phrases 'source infoset' and 'result > infoset', and writes the specification as a transformation between the > two. I don't think this could work for CellML because import processing > is not easily described as a simple transformation, and it is part of a > large specification which also cannot easily be written as a > transformation (unless we want to describe CellML with imports as a > transformation to a single CellML model file with no imports, and then > describe that in terms of a transformation into MathML, which might work > but would be radically different from the approach we have taken so far). > > I think we have a few remaining options: > 1) Retain the CellML File / CellML Model terminology, and then create > another mini-specification for how to embed CellML into other documents > which explains that a CellML File is not necessarily the document > element. This would probably be a good way to take the specification > from a standardisation point of view, because by and large we want > people to be exchanging files which have the CellML model element as the > document element if they are calling it a CellML File - otherwise it is > some other type of document which happens to have CellML embedded in it, > and it is not possible to use it from standard CellML tools. > 2) Invent an abbreviation. I suggest 'CellML Model Representation (CMR)' > vs 'CellML Model Instantiation (CMI)', as one option, although this > again could be confusing. However, upon seeing these for the first the > reader is likely to look them up in the definitions section rather than > relying on any prior knowledge (which may be a good thing if there is a > chance that their prior understanding of what the word means is > incorrect within the current context). > > Please let me know what you think on this issue. I personally think that > option 1 is the best, but based on the discussion at the CellML meeting > today it doesn't seem likely that I will get much support for that approach. > > Best regards, > Andrew > > _______________________________________________ > cellml-discussion mailing list > cellml-discussion@... > http://www.cellml.org/mailman/listinfo/cellml-discussion -- -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: david.nickerson@...
12 Dec 2007 02:10
Should groups be allowed to imply metadata information?
Hi all, The CellML 1.1 specification says: " 6.5.3 Groups must not imply metadata information Modellers must not use CellML groups to associate properties or classification information with sets of components. The metadata functionality is the proper method for making such associations. This increases the chance of that information being used by a range of CellML processing software. " If extension groups cannot be used to imply metadata or mathematical information, then there is not really anything left for them to imply. I think that we should do one of the following: 1) Non-standard relationship types be disallowed, and only encapsulation and containment be kept (encapsulation does affect the mathematical formulation of the model, while containment is really metadata information), or perhaps only encapsulation should be kept, with containment data represented in metadata, or, 2) Allow groups to be used for metadata information, but in the informatively annotated specification encourage the CellML community to standardise on exactly how a certain type of metadata should be represented (this is required whether RDF/XML or groups is used to express the metadata anyway). I would welcome any opinions that anyone might have on this. Best wishes, Andrew
12 Dec 2007 02:23
Re: CellML terminology: distinguishing CellMLmodels from the XML in which they are represented
David Nickerson wrote: > I think option 1 would be much better than 2. > > An alternative might be the RDF and RDF/XML approach? Not too sure what > that implies, but personally I see it as an RDF graph and then the XML > serialisation of that graph. Could we use something like CellML Model > and CellML Model/XML or maybe CellML/XML ? > I think that this could be heading towards the right approach, although I'm not sure that the XML serialisation is automatically the right layer of abstraction to refer to (we are only defining XML parsing by reference, although RDF/XML does as well) - perhaps the XML Information Set could be the lowest level, and we describe how that relates to the conceptual componentised model after import processing, and ultimately the conceptual non-componentised mathematical model (when mathematical equations are present). How about CellML Infoset, CellML Model, and Mathematical Model? Best regards, Andrew > > Andre. > > Andrew Miller wrote: > >> Hi all, >> >> I have been working on resolving the current terminology issues in >> CellML 1.1 where 'model' is used to mean both the XML file in which the >> model element resides, and the abstract mathematical model represented >> by that XML file when any imports have been processed. This overloading >> has occurred as a result of the transition from CellML 1.0 to CellML >> 1.1. It is an issue which is worth trying to resolve, because issues >> like this cause the CellML 1.1 text lacks the precision that a well >> specified format should have. >> >> In my initial drafting work, I used the terms 'CellML File' and 'CellML >> Model' to distinguish the two concepts. These terms were defined, but >> the aim was that they could be understood without needing to refer to >> the definitions. >> >> However, concerns about this have been raised, because what is being >> referred to as a CellML File could be embedded into another XML >> document. This could be addressed by ensuring the definition of CellML >> File allows for that, but confusion could still occur from this. >> >> There were several alternatives proposed at today's CellML meeting: >> 1) 'CellML Model with no imports or with uninstantiated imports' vs >> 'CellML Model with all imports instantiated'. The problems with this is >> that it is cumbersome especially when it appears multiple times in the >> same sentence (and would possibly be unambiguous in that case), it is >> confusing to use these terms before imports have been explained, or in >> the section explaining imports, and it doesn't create a very clear >> conceptual separation between the representational layer and the model >> represented in that representational layer. >> 2) 'CellML model element information item and all descendant information >> items' vs 'CellML Model'. The former is reasonably cumbersome and would >> probably be confusing when used in a sentences. >> Examples from the beginning of the specification of how it could sound... >> "Every CellML model element information item and all descendant >> information items SHALL be represented in an XML document which conforms >> with the well-formedness requirements of the XML 1.0 specification" >> "Two CellML model element information items and all descendant >> information items shall be equivalent if one can be transformed to >> another by making zero or more of the following changes" >> 3) Make up an acronym of some kind. >> >> I have looked into other specifications which may have similar >> requirements. XInclude uses the phrases 'source infoset' and 'result >> infoset', and writes the specification as a transformation between the >> two. I don't think this could work for CellML because import processing >> is not easily described as a simple transformation, and it is part of a >> large specification which also cannot easily be written as a >> transformation (unless we want to describe CellML with imports as a >> transformation to a single CellML model file with no imports, and then >> describe that in terms of a transformation into MathML, which might work >> but would be radically different from the approach we have taken so far). >> >> I think we have a few remaining options: >> 1) Retain the CellML File / CellML Model terminology, and then create >> another mini-specification for how to embed CellML into other documents >> which explains that a CellML File is not necessarily the document >> element. This would probably be a good way to take the specification >> from a standardisation point of view, because by and large we want >> people to be exchanging files which have the CellML model element as the >> document element if they are calling it a CellML File - otherwise it is >> some other type of document which happens to have CellML embedded in it, >> and it is not possible to use it from standard CellML tools. >> 2) Invent an abbreviation. I suggest 'CellML Model Representation (CMR)' >> vs 'CellML Model Instantiation (CMI)', as one option, although this >> again could be confusing. However, upon seeing these for the first the >> reader is likely to look them up in the definitions section rather than >> relying on any prior knowledge (which may be a good thing if there is a >> chance that their prior understanding of what the word means is >> incorrect within the current context). >> >> Please let me know what you think on this issue. I personally think that >> option 1 is the best, but based on the discussion at the CellML meeting >> today it doesn't seem likely that I will get much support for that approach. >> >> Best regards, >> Andrew >> >> _______________________________________________ >> cellml-discussion mailing list >> cellml-discussion@... >> http://www.cellml.org/mailman/listinfo/cellml-discussion >> > >
RSS Feed