Tommy Yu | 2 Dec 21:12 2007
Picon
Picon

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. 
Catherine Lloyd | 3 Dec 23:55 2007
Picon
Picon

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.
Justin Marsh | 4 Dec 23:48 2007
Picon
Picon

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.
James Lawson | 6 Dec 23:40 2007
Picon
Picon

[Fwd: [Synthetic Biology] SB4.0, 10-12 October 2008, Hong Kong]


Picon
From: Drew Endy <endy@...>
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/

http://openwetware.org/wiki/Synthetic_Biology:Synthetic_Biology_4.0
(Continue reading)

David Nickerson | 7 Dec 04:52 2007
Picon

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.
Randall Britten | 10 Dec 00:41 2007
Picon
Picon

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
Andrew Miller | 12 Dec 00:22 2007
Picon
Picon

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
David Nickerson | 12 Dec 02:05 2007
Picon

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@...
Andrew Miller | 12 Dec 02:10 2007
Picon
Picon

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
Andrew Miller | 12 Dec 02:23 2007
Picon
Picon

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
>>     
>
>   

Gmane