Re: [cellml-discussion] CellML meetings - can we shift toconference calls?

[Tommy Yu]

Hi,

If there were conference calls I would likely just end up listening for 
the most part at the mean time. I am open to have this option, but I 
read the minutes anyway (when they are posted) to see what was discussed 
that relate to the development of the repository and the cellml site. In 
other words, I don't feel it's critical for me to attend them until I 
physically return to the institute (should be real soon (TM) anyway), 
that and I prefer to attend meetings in person.

Also, the current meeting time would put it at Sunday 4pm EST, which I 
will be busy as it is the afternoon of weekend. However, I _should_ 
receive my chest x-ray report by next week, and if it says I am healthy 
I should have my NZ work visa application sent sometime around mid next 
week (or first couple days of November). I heard the visa application 
itself takes 2-3 weeks to process, so I hope to be back asap after 
that's done.

Cheers,
Tommy.

PS feel free to start making a list on what should be done on the 
repository, or what should I be doing.

David Nickerson wrote:
> Hi Matt,
>
> Just wondering how you'd see such conference call meetings improving 
> community involvement over the current situation of the project being 
> managed in Auckland with discussion of relevant issues on the 
> cellml-discussion mailing list?
>
>
> Andre.
>
> Matt wrote:
>   
>> It seems very rare to need to use a whiteboard in the CellML meetings
>> themselves. It doesn't stop other community based standards/tools
>> groups from doing this.
>>
>> I would be more interested in getting this project addressing
>> community issues more directly now. I don't mind having any internal
>> ones about specific issues that people want to problem solve, but I
>> want CellML to be driven more widely by the community now.
>>
>> The first on the agenda will obviously be things like implementations
>> of the CellML API, simulation metadata, and repository workflows. But
>> I assume there are many niggles that people would like to bring up off
>> the cuff.
>>
>> cheers
>> Matt
>>
>>
>> On 10/27/06, Andrew Miller <[EMAIL PROTECTED]> wrote:
>> 
>>> Matt wrote:
>>>   
 Hi,

 I think it will now be beneficial to move CellML meetings to a
 conference call forum to include  contributors outside of the
 institute. Can people get back to me with the following:

 1) They are interested in this or not
 
>>> There are some downsides to such an approach (e.g. there is currently no
>>> easy way to quickly draw a diagram on the whiteboard, making files in an
>>> SVG editor and uploading them is difficult to do just to add something
>>> to the diagram in response to feedback from others / to explain
>>> something better), so I think we should only do this if external people
>>> are actually taking part. One option would be to have a physical
>>> meeting, but use teleconferencing to let external people hear what is
>>> going on, and contribute to the discussion if they want.
>>>
>>>   
 2) Their time zone and preference for times
 
>>> I will be happy with any time within Monday-Friday 8:00 - 18:00 NZDT.
>>>   
 3) How regularly they would like to have them
 
>>> Once a week, but with
>>>   
 4) Names of people who should attend that aren't in this immediate
 email list.
 
>>> Shane Blackett has been regularly attending CellML meetings, so he
>>> should be included (CCd).
>>>
>>> I believe Edmund has expressed a desire to attend CellML meetings, so I
>>> have sent this reply to him as well.
>>>
>>> I believe Nigel Lovell, Socrates Dokos, and some other members of the
>>> optics modelling group at UNSW have been using CellML, and some of their
>>> students have written tools, so I have also added them to the CC list.
>>>
>>> We should probably also see if some other members of the Oxford
>>> Physiology group are interested, such as Penny Noble (CCd). Steve
>>> McKeever and Jonathan Cooper from computer science at Oxford might also
>>> be interested. Vincent Rouilly has also been developing CellML models,
>>> as has Dan Beard, so might also be interested.
>>>
>>> Also, I believe Jagir is looking into using CellML for his PhD project,
>>> so it would be worthwhile to include him as well, if he is interested.
>>>
>>> I have also added cellml-discussion@cellml.org to the CC list. If I have
>>> missed anyone who is interested, please feel free to say so.
>>>
>>> Best regards,
>>> Andrew
>>>
>>>
>>>   
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>> 
>
>   

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] PCEnv questions

[Tommy Yu]

David Nickerson wrote:
>>> Three queries:
>>> 1. Regarding the saved session facility - if it is now possible to 
>>> save a session that includes the model as well as the graph layout, 
>>> could we not just load a session containing the model when you click 
>>> on the website link to a model?
>> Hi Peter,
>>
>> I have already asked Tommy about this,  but he was concerned that this 
>> would be difficult to do with the current repository.
> 
> one question - if we are planning on providing PCEnv specific data 
> within the CellML model repository, are we also happy storing and 
> providing access to other application specific data? And if so, what are 
> the requirements such applications would need to meet?
> 

My (new) proposal to deal with PCEnv specific data was to add a PCEnv
session file attachment field to a CellML model within the repository
(since the repository can't deal with anything but CellML 1.0 files, not
even 1.1), but I think this could be well expanded into a more general
file attachment field.  I would think supplementary files, such as
documentation, charts, images/diagrams will fit right into there also
because the current way of documentation is quite insufficient (the
Model Information/Model Status fields that is found in a model page is
hard coded into the CellML file, and the images are from who knows
where).  That would also allow the addition of other types of session
files (but you are right, how will a file be blessed enough to get into
the repository?).

To allow all sorts of attachments (actually, even *just* the PCEnv
session file attachment) will require quite a lot more work though; and
as I noted before, the repository code is loaded with too much cruft
right now and I am more keen on cleaning up the basics before adding
features to it.

Kind Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] new scholarpedia article on model sharing in computational neuroscience

[Tommy Yu]

Tom Morse wrote:
> Dear CellML'ers,
> 
> I wanted to solicit your feedback on an invited article I wrote for 
> Scholarpedia late last week on model sharing in computational neuroscience:
> 
> http://www.scholarpedia.org/article/Model_Sharing_in_Computational_Neuroscience
> 

The uri to the CellML site is 'http://www.cellml.org/', as 'cellml.org'
(without the 'www') does not point to anywhere.

Kind Regards,
Tommy.

> Your suggestions for improvement and/or comments would be gratefully 
> received,
> 
> Best wishes,
> 
> Tom Morse
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files

[Tommy Yu]

Matt wrote:
> This scratches a couple of important pending issues:
> 
> 1) I feel the term 'variant' is odd (even though I originally
> suggested it). It was intended to mean that the model labelled as a
> variant is a variation of the one it is a variant of. However, this
> isn't really a very applicable definition, especially if one may
> consider a model to be a variant of more than one other model. Since
> variant is bound up in the URI and name then this makes for dilemmas.
> My suggestion would be that we drop variants altogether. We can mark
> relations in a better way through metadata.
> 

My thoughts exactly.  In a perfect world, the models would start off as
version01 and finish at whatever version## and they are all sequential
changes, but then (I think) we have cases where we have models
originally written using COR but then PCEnv doesn't run it.  Now we have
a "new version" of the model which will work in PCEnv but may or may not
work in COR.  Now someone gets the latest version and may find COR no
longer reads it.  Version should signify improvement.

Okay, about variants. (bad example time).  We have variant01 and
variant02.  Which is PCEnv, which is COR?  That was just two, what if we
have a bigger and more developed model?  I agree, please drop variants.

> I am also querying whether the flatness of our URI scheme is
> appropriate for our uses.
> 
> e.g. perhaps:
> 
> http://www.cellml.org/models/bondarenko_szigeti_bett_kim_rasmusson_2004_version01
> 
> should be something like
> 
> http://www.cellml.org/models/bondarenko_szigeti_bett_kim_rasmusson/2004/ventricular?rev=1
> 
> (no that is not a formal proposal)
> 

I definitely like that second URI a lot better (I also discussed with
James briefly about this and that was similar to the idea I had), a very
brief statement that might explain which model I am looking at instead
of trying to find out what version01_variant01 might mean.  Also,
another benefit of treating the list of authors (and year-month-day as
publication date?) as a directory could potentially pave the way to
attaching files and clean URIs to point to them.  Of course, this is not
a formal proposal, but it's a good idea.

As for changing URIs again, I have to say it is necessary, but please do
make this one permanent (as in, design it good).

> But this doesn't really help you now. The technically correct method
> at the moment would be that the new models that are similar but
> different only in their parameterisations are added as variants.
> 
> Another alternative in the short term would to simply name the models
> as separate models (which they are) and we define now an rdf relation
> scheme that is very explicitly about how different models at different
> URIs relate to the one you are editing. This would mean that Tommy
> needs to update the rendering of the pages for these models to reflect
> this information.
> 

Ugh making me work ;).  Possible idea, but I will have to defer this for
a bit.  I do agree, the current lack of relationship between links
between updates bother me.  Let me finish fixing what's broken first.

> 2) These models should use imports so that we can at least point to
> the generic model and then the specialised parameterised ones. But
> that won't work right now because the repository can't handle 1.1
> models.
> 

I will be working on that when I finish up getting the metadata class
integrated into the repository.  The hiccup for 1.1 models (I think) is
the XSLT involved with the transformation (which is used by certain
chunks of code), but there may be more than that.  There is no real
special limitations as to why 1.1 models cannot be stored into the
repository.  As the requirements for the repository to properly support
1.1 models are much greater (recall the discussion during the CellML
workshop), I've been putting that off until it becomes absolutely
necessary.  I also have notes about the quirks to get 1.1 going written
down somewhere, but it's not up yet.

Cheers,
Tommy.


> cheers
> Matt
> 
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] broken tabs on the repository pages

[Tommy Yu]

Procedural code relies on the CCGS server provided by the CellML API, and if 
the server is down or being restarted that happens.

As for the model metadata and curation, they don't always have data populated 
properly due to various issues.  I've been aware of this issue for quite a 
while now (since last year, actually) but was not able to fix it reliably 
without a proper CellML metadata library.  Now that library is live, I am in 
the process of reparing that (and making the presentation of the related data 
with more clarity as bonus).

Tommy.

David Nickerson wrote:
> The model metadata, curation, and procedural code tabs on the model 
> repository model pages seem to be currently broken. For all the models I 
> try I get plone errors for each of them...
> 
> model metadata:
> 
> Error Type
>  AttributeError
> Error Value
>  CellMLMetadata instance has no attribute 'model_subject'
> 
> curation:
> 
> Error Type
>  AttributeError
> Error Value
>  CellMLMetadata instance has no attribute 'curation_subject'
> 
> procedural code:
> 
> Error Type
>  TRANSIENT
> Error Value
>  CORBA.TRANSIENT(omniORB.TRANSIENT_ConnectFailed, CORBA.COMPLETED_NO)
> 
> 
> although I did just randomly click on the Beard 2005 model and for that 
> one the model metadata tab correctly displayed some metadata. But no 
> curation or procedural code tabs.
> 
> 
> Andre.
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] broken tabs on the repository pages

[Tommy Yu]

>> As for the model metadata and curation, they don't always have data 
>> populated properly due to various issues.  I've been aware of this issue for 
>> quite a while now (since last year, actually) but was not able to fix it 
>> reliably without a proper CellML metadata library.  Now that library is 
>> live, I am in the process of reparing that (and making the presentation of 
>> the related data with more clarity as bonus).
> 
> any idea of a time frame on this? it would be much better to not present 
> users with links that are known not to work, but if the new workflow 
> will be in place very soon then I guess we don't need to worry about it...

Well, many cases it did work, and it does have useful data when it did work.  
It should be done before next week is over.  Currently I am working on the 
modification history editor which is tied to model curation.

I am thinking of combining those two tabs into one, as curation is from the RDF 
metadata itself.  What we have now is the 'curation' tab shows the model 
creator/modification metadata and 'model metadata' shows the citation 
(references in the form of Journal Article) along with other metadata that 
labels the components inside the CellML model.  Putting it all in a single page 
we can free up a tab, and user can select what they want to view in the 
collapsed page by expanding/collapsing inner panes.

Of course, for the mean time, I will be keeping things the way they were (with 
better presentation, and information that actually displays).

What are your thoughts?


Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] broken tabs on the repository pages

[Tommy Yu]

David Nickerson wrote:
> What I'd like to see is that for models which don't have any metadata 
> and/or curation information that rather than a complicated plone site 
> error users are presented with a simple message that the model doesn't 
> contain  any data of the type required for that particular view. 
> Similarly, I'd expect the same kind of page when I click the view math 
> tab for a model with no math in it. Just like the data tab typically 
> gives an "empty" page now.
> 

Seeing that as a critical issue, I have diverted my attention to create new 
pages that use my library to fetch the data.  The 'curation' tab should display 
a nice list of creator/modification data (if such data is present), and users 
of the model upload/editing facilities will be able to edit the modification 
data eventually (creator editing is already available).

However, you will still see that many of them do not actually have data 
populated, due to the various different "methods" of handling of RDF done by 
various software/code that messed up the graph (which more compliant RDF parser 
will further corrupt).  I have identified a couple models that have at least 
some data to demonstrate the new viewer:

http://www.cellml.org/models/boyett_zhang_garny_holden_2001_version01/pmr_view_history

These two will appear to have certain information mission as the RDF graph in 
the original file before it was uploaded to this repository was incomplete 
(certain nodes requiring rdf:parseType="Resource" attribute did not have them):
http://www.cellml.org/models/difrancesco_noble_1985_version01/pmr_view_history
http://www.cellml.org/models/beeler_reuter_1977_version01/pmr_view_history

That was just one of the many different ways the RDF was broken (I have 
encountered) that prevented data from being picked up.  There are many other 
files without the proper data and so nothing would even display.  They will 
need to be repaired eventually, and I have written tools for that for the 
people who are adding/managing the models in the repository.

As for the 'model metadata' tab, it only displays the citation information for 
now, but it will be expanded to include comments for other individual 
components within the CellML file, if they exist, much like the former 
functionality.

Again, it may not display because of bad RDF or mismatching cmeta:id (because 
they were renamed improperly, and they shouldn't be renamed anyway because 
those cmeta:id's could have been referenced by CellML 1.1 models, and so they 
do not get renamed anymore).

As for why I didn't do this sooner, it's because I placed my priorities on 
entering/editing the modification data (which the 'curation' tab displays) and 
move the 'model status' (really I think it should be more generalized, more 
like a comment about the file as a whole) in the tmp-documentation namespace 
into RDF (specifically into the cmeta:comment of the node about the file (i.e. 
rdf:Description node identified by rdf:about="")), as that is unused by all 
models in the repository (or elsewhere, I believe).  I digress.

I didn't touch them because they were not always working correctly and so no 
data gets displayed.  Actually, I did fix the page to trap the exception, but I 
did not see that there was a customized page that was overriding that and so 
the exception page still shows.  Took this change to raise that issue, that too 
has been fixed.

> Just to note that the first model list on the model repository page as 
> well as the first "starred" model both give the error for the model 
> metadata - these are probably the first models the casual repository 
> browser will click on. Hence they might be getting a bad first 
> impression of the model repository.
> 
> As for the tabs required, I guess we'll need to see how well the 
> navigation works on your combined pages. If it all works fine then there 
> shouldn't be any problems just having a single metadata tab. Otherwise 
> we might need to look at further categories into which to separate the 
> metadata (publication, curation, simulation, graphing, etc...). Whether 
> such separation is best accomplished via tabs or some other mechanism we 
> can leave that decision for now.

I have not combined the pages yet, but do check out the ability to collapse 
each pane (by selecting the labels in the upper left corner of each pane) and 
see if that will result in presenting all metadata in a single page as the 
better way.  Also, panes can be nested, so I can group all modification history 
into a single pane and all of them can be collapsed at one go.

Feel free to play with it.

Kind Regards,
Tommy.


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] broken tabs on the repository pages

[Tommy Yu]

> For those models with corrupt metadata you probably want to regenerate
> the RDF from the original model that was(is?) in CVS (I have an
> archive of those raw files if they are 'lost').
> 
> Can you identify what is actually corrupt and write a small proposal
> to fix it (which may involve the above?). I see this as being more
> critical than anything since we don't particularly want people
> downloading and trying to update essentially corrupt data.
> 

Okay, here it is.

*Caused by Repository and 4Suite, but repairable by script I wrote:*
- 4Suite's way of naming blank nodes, I doubt it should assign an http
  uri for that
  - fixed by renaming the url 'http://4suite.org/rdf/anonymous/' with
'rdf:#'
- 4Suite uses rdf:ID for rdf:Seq identifiers where rdf:about should be
  used.
  - can be repaired by search/replace rdf:ID="http://4suite.org/";
with rdf:about="http://4suite.org/";
  - or rdf:ID="rdf:#" with rdf:about="rdf:#"
  - or patch 4Suite.
  - this gets real fun when PCEnv tries to use that ID with the xml:base
and then pushing it back into 4Suite, you start getting really long
URIs that don't make sense.
- cmeta:id renaming was not done properly, resulting in id mismatch
  between the graph and the CellML model object (thus proper querying
  becomes impossible).
  - undo the renaming of cmeta:id, where possible.
  - It really shouldn't be renamed in the first place.
  - can be impossible to fix, see next section.
- cmeta:id renaming means recreation of many RDF nodes, and resource
  nodes were recreated as literal nodes, resulting in broken graphs.
  - regex replace of '>rdf:#' with
' rdf:resource="rdf:#..."/>
- rdf:type are resources and not literals
  - regex replace
- xml:base mishandling
  - RDF library issues, can be worked around
  - the CellML metadata library drops them when possible during
serialization.

The code that addresses the above issues currently resides in the
CellMLMetadata Library

https://svn.physiomeproject.org/svn/physiome/CellMLMetadata/trunk/CMLmetadata.py

Search for 'def repairRdf' and 'def repair4Rdf' for the logic I use.

Feel free to critique the code, there are various shortcomings (which
may or may not be documented in that file).


*Definitely impossible to fix, as data are truly missing:*
- Incorrectly coded RDF
  - the way the rdf was written originally was more easy for humans to
read, and so certain nodes required attribute rdf:parseType="Resource"
did not have them, resulting in graphs not being parsed properly.
  - Thus those nodes are not generated to be in the graph.
  - Only solution is to fix them and reupload them, or add in the missing
nodes.
- Programs that truncates data due to bugs or poor programming
  - PCEnv at one point did not save rdf:Seq properly due to a bug in the
Mozilla's RDF library.
  - Model Repository did not handle multiple JournalArticles properly,
and it collapses all lists of authors from all citations into one in
an undefined method (what the Python interpreter felt like doing at
that particular time of day).
- Original cmeta:id is definitely lost in almost all cases.
  - Model Repository used to rename/replace them.

Lost data is lost.

It is possible to go through each model one by one and fix what is broken,
and grab the data from CVS if it is truly missing, however the only way
to guarantee a clean slate is to upload all the models from CVS into the
repository all over again, but that is some drastic measures.

For now, I have been mostly doing damage control, and I have got the
repository to the point where a model with a valid RDF graph will stay
valid, and new data that gets inputted will also result in a valid RDF
graph (as defined by the metadata specification, and resulting graph has
been run through the W3C's RDF validation service).  I will be working on
making more formal test cases for my RDF metadata library after I get the
modification history editor onto the model repository so that James can
start using that to log down what he changes he made to the model in where
it should be going.

I am interested your ideas on how to tackle this, if any.

Kind Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] initial feedback on new repository metadata tools

[Tommy Yu]

David Nickerson wrote:
> Hi Tommy,
> 
> Thought I'd just jot down some initial thoughts after following your 
> invitation to have a play with the new metadata tools on the model 
> repository :-) These are generally cosmetic suggestions more for your 
> consideration than any urgent requirement you need to act on...
> 

Thank you for your input :). Some of the issues are the result of making this 
page in the short time between the time of your last email and my announcement, 
but I will address them in due time.

> The formatting of author/creator/modifier/etc names leaves a bit to be 
> desired. I'd suggest following a more standard pattern and removing the 
> '|' as the separation character. For example, something like:
>   G1 O1 F1, G2 O2 F2, & G3 O3 F3; or
>   F1, G1 O1, F2, G2 O2, & F3, G3 O3
> with F=Family, G=Given, O=other names where you drop O's where they are 
> not specified or add more in where needed. You'd imagine that then names 
> specified using the vCard:FN property would more naturally slot into 
> this kind of display.
> 

Thank you for showing me how it should be displayed.  I just tossed that part 
up in about 5 minutes without given much thought to it.  I did rush it, as you 
can see ;)

> If would be good to make the PubMed ID field a link to the PubMed page 
> for the given reference.
> 

That would be useful.

> Similarly, when editing a citation it would be good to simply specify a 
> PubMed ID or DOI or something similar and have the fields populated from 
> that database.
> 

The repository we have now originally only supported PubMed ID, and the editor 
only reads data from the CellML file.  If the database has an API to achieve 
that I would be interested in seeing how that could be done, but if not I will 
put the auto-population in the back burner.

> While its hard to judge until more metadata is presented to the user, I 
> suspect the collapsing pane view is not going to be particularly easy to 
> navigate around. But I guess we can wait and see once there are some 
> more complete examples to play with. Nesting similar properties would 
> probably be a good idea (modification history, as you pointed out).
> 

If you imagine the citation and the modification history being in the same 
page, you can see the benefits.  Also, I could start by making an index at the 
top that links to the anchors that is in the heading of the various panels.  
Just an idea for now.

> In the previous framework, each piece of metadata presented to the user 
> provided a link to the corresponding CellML/MathML code in the "view 
> cellml" tab. It would be good to keep this functionality.
> 

Yup, the only issue was I don't yet have code to pull other cmeta:comment from 
the CellML file fully in place yet, but I don't imagine this being too hard to 
do.

> While I haven't followed through with any changes, I'm hoping that 
> modifying a model's name or curation level will force the editor to also 
> add modification metadata to the model? You could perhaps pre-populate 
> the modification fields based on the changes the user is making...
> 

I am working on placing the modification entry form into the metadata editing 
form if the user is uploading a new model.  Curation level is not in the 
metadata specification yet, it only lives as an attribute on the repository 
(the edit page provides that).  As for pre-populating modification fields, how 
would my code know what changes the user made to the model between the last 
version and the one she is uploading?  There is no real version tracking code 
in the repository now, certainly no way to run diff between them.

> It would be good to have a consistent interface for editing a person's 
> name. Currently when editing metadata there is a different interface for 
> the file creator, comment authors, and citation authors. I think the 
> citation author interface is the best, although possibly with all three 
> fields having equal width. And while I guess we can force people into 
> using the full vCard:N structure when they are entering data using this 
> editor it probably gets a bit tricky to also support the abbreviated 
> vCard:FN property
> 

See below...

> In the metadata editor, there is really nothing special about the CellML 
> Model Metadata, it just happens to be "about" the cellml:model resource. 
> It would be nice to be able to use the same interface to enter the same 
> kinds of metadata about any resource in the model document. For example, 
> it is quite useful to cite a particular source(s) for a variable value 
> or a particular modification to an equation.
> 

While it wouldn't be too difficult to extend the editor to include that, I 
would think getting the basics down first before I start making further fancy 
additions, and I didn't want to start making drastic changes before I get the 
foundation solid.  The features I have completed so far pretty much mimics what 
this PMR originally had, except using a prop

Re: [cellml-discussion] PMR categories

[Tommy Yu]

Just had a discussion with Peter, Randall and James about this.

The keywords are in the metadata for the models, and there is no limit to what 
can go in there.  The concern about that is the list could get too big (for 
minor categories), or variations in the name (electrophysiology vs 
electrophysiological), or just spelling in general.  What was decided is to 
have the same category list, but it would act as a "blessed" list of keywords 
that will serve as a guide to what should be added to the model, and as a broad 
category filter for the main repository listing.  Users would still be able to 
add or search by other keywords (from the advance search interface) if they 
wish.

Tommy.

Matt wrote:
> On 6/6/07, David Nickerson <[EMAIL PROTECTED]> wrote:
>> James Lawson wrote:
>>> David Nickerson wrote:
 Would I be correct in assuming that these terms will be key words added
 to the model metadata and that the division into categories on the main
 repository page will be assembled from queries on each of these
 predefined key words?
>>> Well potentially, there could be many many different keywords, so Peter
>>> suggested that we might not necessarily want to base the categories on
>>> just the keywords. At the moment, Tommy's sorting function is based on
>>> keywords but he suggested that we could have both a keyword and a more
>>> general category selection system.
>> not sure I like the idea of a separate category, seems to me adding some
>> special piece of metadata to models just to make a repository dump look
>> pretty isn't the way to go. It would be nicer to make use of the
>> keywords (which are genuinely useful metadata to more than just the
>> model repository), possibly with the addition of a guided part of the
>> metadata editing workflow which prompts the user to choose at least one
>> of the predefined "category" keywords and a filter smart enough to put
>> models without one of the special keywords into an "other" category.
>> This way the main repository page layout could be easily changed to add
>> or remove keywords that get pulled out as categories without having to
>> change the models.
>>
>> It would also be nice if we can analyse all the repository searching to
>> keep track of the most popular keywords and adjust the categories on the
>> main page accordingly :-)
> 
> 
> Well, I'm hoping to steal all the keywords and lay them out in the
> physiome ontology and then put them back in as bioentities (or math
> related) metadata pointing into this. So the long term relationship
> between keywords and this "ontology" metadata is where my thinking
> lies. I like the idea of reflecting this information into keywords,
> e.g. for 'cardiovascular' the bioentity would be some big long uri
> pointing into the instance of the term 'cardiovascular' in the
> ontology, so it would be nice if the keywords were at least
> dynamically generated from the labels of these ontological term
> instances.
> 
> 
> 
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] PMR categories

[Tommy Yu]

David Nickerson wrote:
> I really don't like the idea of giving a model a keyword of "other". 
> Hopefully the repository will be smart enough to automatically add 
> models to the "other" listing if they don't have any of the other 
> predefined key words.
> 

I agree, and I don't think I will put an 'other' category, as giving a value to 
something where an absence of value should be will cause problems in the 
future.  The main listing will of course have a choice to select 'other', where 
models not categorized with the main set of keywords will be shown.

Tommy.

> And then if "other" is taken out of this list of mandatory keywords you 
> can no longer make them mandatory - which I would also prefer. These 
> predefined keywords should simply be given as suggestions for the user 
> to choose from. I think we need to be careful not too present repository 
> users with the impression that only certain types of models are 
> acceptable in the repository - unless we *are* trying to restrict the 
> types of models going in there? One example that wouldn't fit any of the 
> current categories might be finite element basis function definitions 
> for use with fieldML models.
> 
> 
> Andre.
> 
> 
> Peter Hunter wrote:
>> Dear All,
>>
>> The intention of this discussion was to decide on a list of items for a 
>> drop-down list of predefined terms that would be available when choosing 
>> 'key words' for a new model and which would be the list of terms used to 
>> display models on www.cellml.org/models (together with the default 'All 
>> models' item). The idea was that choosing one or more of these key words 
>> terms would be mandatory when defining model metadata but that one could 
>> also enter additional keywords for more advanced searching. It may be 
>> that the additional key words should adhere to terms from an ontology as 
>> Matt suggests and should use the predictive completion facility that 
>> Andre suggests. But I am keen to keep this first list of terms fairly 
>> short. My suggestion is the following list. I've checked through the 
>> repository and less than 10% of the models would end up solely under 
>> 'Other'. I am sure we will need to expand this list as the repository 
>> grows and I suggest we have a policy of keeping the number that end up 
>> solely in the 'Other' category to less than 10% of the total. We may 
>> also later need a policy to refine the classification when too many 
>> models are displayed under one term.
>>
>> Calcium dynamics
>> Cell cycle
>> Cell migration
>> Circadian rhythms
>> Electrophysiology
>> Excitation-contraction coupling
>> Gene regulation
>> Mechanical constitutive laws
>> Metabolism
>> Myofilament mechanics
>> Signal transduction
>> Other (the default key word in the list of predefined terms)
>>
>> Let me know if you can think of other more appropriate terms or 
>> additional ones, then I'll ask Tommy to implement it. I'm happy to then 
>> go through and classify all current models in the repository into these 
>> categories.
>>
>> Cheers,
>> Peter
>>

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] PMR categories

[Tommy Yu]

Matt wrote:
> I'm not sure what the physiome ontology is. Currently the anatomy
> ontology is the one I've been working on and this has no physiological
> processes in it yet.
> 
> I was hoping I had been clear in my previous emails that I want the
> current and future author supplied keywords to help drive the
> ontology, not the other way around.
> 

Authors will still be able to supply their own keywords to models, and if 
enough authors uses it of course it can be added to the main list of terms 
which forms the ontology.

Tommy.

> On 6/8/07, James Lawson <[EMAIL PROTECTED]> wrote:
>> Peter Hunter wrote:
>> It may be that the additional key words
>>> should adhere to terms from an ontology as Matt suggests and should
>> use the
>>> predictive completion facility that Andre suggests.
>> Will we use the Physiome ontology for this? It will require changing the
>> current keywords that are defined in the metadata for many of the models
>> so they fit an ontology.
>>
>> Should we be using ontology terms for the major categories as well? A
>> quick flick through the Physiome ontology suggests that we might have
>> trouble finding terms in it that would fit what we want.
>>
>>
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] PMR categories

[Tommy Yu]

Matt wrote:
> I have concluded that they are now talking about the web site and not
> keywords in general.
> 
> My assumption was that the category field selections are not persisted
> in the model metadata at all.
> 

Actually they are.  Keywords are defined in the CellML metadata specifications 
and are already being used in various files.  Feel free to check the CellML 
files of the old repository and scroll down the to keyword section.  An example 
follows.

>From http://www.cellml.org/examples/models/beeler_reuter_model_1977.html:

  
  

  keyword
  

  ventricular myocyte
  electrophysiological

  

  

I do understand it may be different from the full CellML metadata specification 
as found in 
http://www.cellml.org/specifications/metadata/cellml_metadata_1.0#sec_bqs, but 
all other models pretty much follow this RDF format and so I wound up having to 
follow the above format to pick up the keyword metadata.

> I would have liked some indication that the 'categories' used also end
> up in the model keywords attributed to the model in addition to the
> keywords supplied by the author when creating or uploading the model.
> 

That is already the case, the 'categories' *are* keywords that are chosen by 
Peter as a selectable choice in the filtering drop box for the repository 
listing.

> I would like there to be as many keywords allowed as the
> author/uploader wants (perhaps just a lines field will do for now for
> this). Constraining them to a single extra keyword in addition to a
> selected category makes no sense to me.
> 

In the Edit Keyword interface, any keyword of the model that matches one of the 
'blessed' keywords will be highlighted in the category list.  All other 
keywords will be in the lines field editor.  Feel free to log into the site (I 
assume you have an account) and try out the editing interface.  I do agree it 
is currently slightly clunky, but James has no complaints with it and he has 
already added/verified keyword for half the curated models (I think) of the 
repository.

Again, the category field is a *subset* of keywords to limit the number of 
choices in the filtering menu and not a distinct entity.

Hope this clear things up.

Tommy.

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] PMR categories

[Tommy Yu]

David Nickerson wrote:
>> Actually they are.  Keywords are defined in the CellML metadata 
>> specifications and are already being used in various files.  Feel free to 
>> check the CellML files of the old repository and scroll down the to keyword 
>> section.  An example follows.
>>
>> >From http://www.cellml.org/examples/models/beeler_reuter_model_1977.html:
>>
>>   
>>   
>> 
>>   keyword
>>   
>> 
>>   ventricular myocyte
>>   electrophysiological
>> 
>>   
>> 
>>   
>>
>> I do understand it may be different from the full CellML metadata 
>> specification as found in 
>> http://www.cellml.org/specifications/metadata/cellml_metadata_1.0#sec_bqs, 
>> but all other models pretty much follow this RDF format and so I wound up 
>> having to follow the above format to pick up the keyword metadata.
>> 
>
> does this mean that keywords described using the RDF specified in the 
> CellML Metadata Specification will not be picked up? or is the above 
> allowed in addition to following the specification? And are there any 
> plans to standardise on one or the other of these?
>
>   
I believe as per the metadata specification status, it is only a draft. 
I did not develop the specifications and I did not coded the model, and 
since the current usage is not following the specification I have not 
much of a choice and so I did not follow the draft specification.  I can 
of course make adjustment to the keyword code.  As for standardization 
of the keyword metadata, I am not the best person to answer that.
>>> I would have liked some indication that the 'categories' used also end
>>> up in the model keywords attributed to the model in addition to the
>>> keywords supplied by the author when creating or uploading the model.
>>>
>>>   
>> That is already the case, the 'categories' *are* keywords that are chosen by 
>> Peter as a selectable choice in the filtering drop box for the repository 
>> listing.
>> 
>
> So categories simply end up as keywords in a model's metadata with no 
> other special significance than that they happen to match one of a 
> predefined set used in the model repository interface? And I'm gonna 
> assume that this is not a case sensitive match, right?
>
>   
It may be case sensitive right now, but I will look into it. I currently 
made keywords all lower case on submit, but if it is agreed this is not 
the ideal solution I will no longer enforce the casing and do a 
case-insensitive comparison.
>>> I would like there to be as many keywords allowed as the
>>> author/uploader wants (perhaps just a lines field will do for now for
>>> this). Constraining them to a single extra keyword in addition to a
>>> selected category makes no sense to me.
>>>
>>>   
>> In the Edit Keyword interface, any keyword of the model that matches one of 
>> the 'blessed' keywords will be highlighted in the category list.  All other 
>> keywords will be in the lines field editor.  Feel free to log into the site 
>> (I assume you have an account) and try out the editing interface.  I do 
>> agree it is currently slightly clunky, but James has no complaints with it 
>> and he has already added/verified keyword for half the curated models (I 
>> think) of the repository.
>> 
>
> the interface looks ok, but not sure what you mean about keywords 
> matching the categories being highlighted? I guessing you mean after I 
> click the update keywords button, because there is certainly nothing 
> being highlighted as I type them in...
>
>   
It is done at load time of the page. If for instance we have a model 
with the keywords 'metabolism' and 'cardiac', the keyword 'metabolism' 
will be highlighted, and 'cardiac' will be placed in its own line in the 
following line edit box. No other magic.
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>   

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] PMR categories

[Tommy Yu]

David Nickerson wrote:
>
> I'd suggest that since you are deciding how keywords are extracted,
> edited, and put back into the models that you are the best person to
> answer that. Otherwise there should have been some discussion on this
> mailing list as to how to handle this issue.
>
Okay, I've re-read the metadata specification, specifically the RDF 
schema draft section at the bottom of the document, and the RDF schema 
for Dublin Core (which was related).


  
keyword

  
ventricular myocyte
electrophysiological
  

  


This method of defining a keyword uses the straight dublin core subject 
while using the bqs:subject_type property to label this instance of 
dc:subject property as 'keyword', it is consistent with the standards 
defined, but not specifically to the definition of the CellML metadata.  
Perhaps those keywords were coded in before keywords were defined, and 
nobody raised any issue about the need to convert the old format to the 
new format until today.

If we use the metadata specification it may look like this:

||
|  |
||
||  ventricular myocyte
  electrophysiological
||||
|  |||

||
Since the specification is already written to accomodate the keywords I 
think it is better to keep to it, even though the common usage (as 
defined by the number of files with this RDF to describe keywords used 
by the old and current repositories) does not follow it.  I must admit I 
let this issue slipped through my head as I didn't think too much about 
it.  Thank you for correcting me.


However, my inspection of the metadata specification revealed some 
issues, such as this:

|  
  
subject type

  Defines the topic of a resource.



  
 
  
  
keyword

  Defines the topic of a resource using keywords.



  
|
The specification have||| subject_type prefixed with both the dublin 
core namespace and the bqs|| namespace.  Dublin Core does not define 
subject_type, so that needs to be corrected, perhaps the author meant to 
use &bqsns;subject_type where s/he wrote &dcns;subject_type.  It also 
had double escaped ampersand (||&bqsns;subject_type should probably 
be just ||&bqsns;subject_type) and other mistakes at other places.  I 
also think keyword be limited constrained to certain domains (via rdf 
schema), such as limiting it to within the bqs:reference class so users 
knows specifically where to place it, and machines know where to read it.||

I supposed this topic about formalizing the RDF schema and issues with 
the metadata specification should probably be discussed in a different 
discussion thread.|||
||
||Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] PMR categories

[Tommy Yu]

Ugh, looks like Thunderbird clobbered my last message when I told it to 
converted html to plain text.  This is my reply.

> Okay, I've re-read the metadata specification, specifically the RDF 
> schema draft section at the bottom of the document, and the RDF schema 
> for Dublin Core (which was related).
> 
> 
>   
> keyword
> 
>   
> ventricular myocyte
> electrophysiological
>   
> 
>   
> 
> 
> This method of defining a keyword uses the straight dublin core subject 
> while using the bqs:subject_type property to label this instance of 
> dc:subject property as 'keyword', it is consistent with the standards 
> defined, but not specifically to the definition of the CellML metadata.  
> Perhaps those keywords were coded in before keywords were defined, and 
> nobody raised any issue about the need to convert the old format to the 
> new format until today.
> 
> If we use the metadata specification it may look like this:
> 
> 
>   
> 
>   ventricular myocyte
>   electrophysiological
> 
>   
> 
> 
> Since the specification is already written to accomodate the keywords I 
> think it is better to keep to it, even though the common usage (as 
> defined by the number of files with this RDF to describe keywords used 
> by the old and current repositories) does not follow it.  I must admit I 
> let this issue slipped through my head as I didn't think too much about 
> it.  Thank you for correcting me.
> 
> 
> However, my inspection of the metadata specification revealed some 
> issues, such as this:
> 
>   
>   
> subject type
> 
>   Defines the topic of a resource.
> 
> 
> 
>   
>  
>   
>   
> keyword
> 
>   Defines the topic of a resource using keywords.
> 
> 
> 
>   
> 
> The specification have subject_type prefixed with both the dublin 
> core namespace and the bqs namespace.  Dublin Core does not define 
> subject_type, so that needs to be corrected, perhaps the author meant to 
> use &bqsns;subject_type where s/he wrote &dcns;subject_type.  It also 
> had double escaped ampersand (&bqsns;subject_type should probably 
> be just &bqsns;subject_type) and other mistakes at other places.  I 
> also think keyword be limited constrained to certain domains (via rdf 
> schema), such as limiting it to within the bqs:reference class so users 
> knows specifically where to place it, and machines know where to read it.
> 
> I supposed this topic about formalizing the RDF schema and issues with 
> the metadata specification should probably be discussed in a different 
> discussion thread.
> 
> Tommy.

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] PMR categories

[Tommy Yu]

Matt wrote:
> On 6/11/07, Tommy Yu <[EMAIL PROTECTED]> wrote:
>> Matt wrote:
>>> I have concluded that they are now talking about the web site and not
>>> keywords in general.
>>>
>>> My assumption was that the category field selections are not persisted
>>> in the model metadata at all.
>>>
>> Actually they are.  Keywords are defined in the CellML metadata 
>> specifications and are already being used in various files.  Feel free to 
>> check the CellML files of the old repository and scroll down the to keyword 
>> section.  An example follows.
> 
> You are talking about keywords, I was talking about these new things
> Peter brought up called Categories.
> 

I will say it again.  Categories are not 'new things'.  It is something 
specific to the CellML Repository I was told to implement.  The options in the 
category are keywords themselves.  Items there are not 'new things'.

They are just keywords hand-picked by Peter to show up in the drop box that 
happens to be labeled as categories.  Nothing more.

Before you ask further, I only did what I was told.

> 
>> >From http://www.cellml.org/examples/models/beeler_reuter_model_1977.html:
>>
>>   
>>   
>> 
>>   keyword
>>   
>> 
>>   ventricular myocyte
>>   electrophysiological
>> 
>>   
>> 
>>   
>>
>> I do understand it may be different from the full CellML metadata 
>> specification as found in 
>> http://www.cellml.org/specifications/metadata/cellml_metadata_1.0#sec_bqs, 
>> but all other models pretty much follow this RDF format and so I wound up 
>> having to follow the above format to pick up the keyword metadata.
> 
> It's different, but says the same thing, even though the graph comes
> out different.
> 
> Personally I think we should probably dump bqs; the rdf schema we
> advertise is non-standard and broken.
> 

I very much agree, it was not easy working with and around it, especially given 
the pile of cruft that is already in place that I have to deal with...

> Dublin core is not the easiest thing to follow, but at least it is
> standard and used in the world, so we should at least keep that.
> 

If someone come up with a proper metadata specification based only on industry 
standard with everyone in the community agreeing with use it I would be happy 
as it should make my life easier when dealing with CellML metadata.

Also, I don't want to be dealing with five different graphs that says the same 
thing.  I have enough headaches dealing with constructing multiple versa 
queries to pull relevant data as it is.

>>> I would have liked some indication that the 'categories' used also end
>>> up in the model keywords attributed to the model in addition to the
>>> keywords supplied by the author when creating or uploading the model.
>>>
>> That is already the case, the 'categories' *are* keywords that are chosen by 
>> Peter as a selectable choice in the filtering drop box for the repository 
>> listing.
> 
> You need to make sure the keywords then are ordered collections so
> that you can create some rule for your 'category' interpretation.
> 

Not really.  I don't care what they are ordered.  If it exists it gets 
"highlighted" as per demand.

> I don't like this special attention that certain keywords gets.
> 

They get no further treatment aside from the "special attention" which is to 
limit the listing of keywords.  Peter does not want that list to be filled with 
over 100 keywords.  A condensed listing was desired and I implemented with 
keywords as those keywords used must exactly describe what the models we have 
in the repository (and the old repository) are about.  Feel free to check these 
links out.

http://www.cellml.org/examples/repository/index.html - Under Table of Contents 
- Basically the same list of "categories".
http://www.cellml.org/models/pmr_search - Feel free to see/search by all 
keywords with the 'Keywords' selection box.  It works exactly the same as the 
category filter found on top of the main listing except the short list found on 
the main listing is a predefined list of keywords.

Again, having the "special category listing" that only includes the few chosen 
keywords is intended to be an usability aid for the filtering of the major 
types of models we deal with, which happens to be described via the keyword 
metadata.

If you still think category describes something new (at least in the way it is 
implemented by the CellML repository), I don't know what else to con

[cellml-discussion] Concerning the CellML Model Repository

[Tommy Yu]

Hi,

I have written down some of my thoughts on how the model repository could be 
put together.

http://www.cellml.org/Members/tommy/repository_redesign.html

It is still a pretty rough document.  The usage example section gives a rough 
outline on what I see people might be doing with the repository and how this 
design could address those issues, which I think it will be of interest to 
users.  It is not an exhaustive list, yet.

I must also note the design outlined is quite a drastic departure from what we 
have now (it will be yet another new repository).  However, it is more true to 
the one envisioned before according to 
http://www.cellml.org/wiki/CellMLModelRepositories, except I have an addition 
layer that will assist in pulling content and drawing relationships between 
models.

Feel free to take it apart and/or build on top of it.

Cheers,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Concerning the CellML Model Repository

[Tommy Yu]

Hi Andrew,

A couple notes:

> I don't think it is a bad thing to have a one-way cache of metadata 
> somewhere for technical / performance reasons (perhaps in a relational 
> database), but I think that we should replicate data for each model 
> (perhaps using a deep copy-on-write approach if this is really necessary 
> to save disk space) rather than changing the metadata for existing 
> models without changing the version.
> 
> Making changes to metadata require changes to the model will ensure that 
> no one gets burned by referencing a particular version of a model, only 
> to find that the metadata in that version has changed on them.
> 
> Your current unversioned, globally shared metadata approach probably 
> also has security implications. For example, lets say that Alice submits 

I understood, and I did call for metadata in the RDBMS to be more of a 
snapshot.  Metadata will still be versioned (revision) in the Subversion 
repository.  The publishing of a model to the public could conceivably be done 
by someone other than the model creator.

Also, in the scenario outlined below, you are correct that a paper referenced 
by PubMed would be treated somewhat differently.  If Charlie were to publish a 
"fake" paper to the repository, it would result in a new references anyway:

Alice - Paper title (original)
Alice, Charlie - Paper title (fake)

There is no way to stop users from entering bad data into the system if they 
were given "admin" rights.  Fortunately Charlie wouldn't have that and so he 
wouldn't be able to add a new author to Alice's paper, but able to only create 
a new fake paper that he did not write since he can publish a model.

On the other hand, if he decide to use the original publication name to publish 
his model, then change the reference there, he would still be prevented from 
doing that, but he has the option to create a new fake reference.  Again, no 
way stopping user from publishing bad data if they were given rights.  It is 
possible to limit where Charlie can publish his paper to (i.e. publishes to 
reviewers only), and there would be no visible damage.

> a model which references a publication. Now suppose that Charlie wasn't 
> an author of that paper, but he wants to add his name onto the list of 
> authors. So he submits a completely different, bogus, model which 
> includes metadata for the publication, and includes his name. When Bob 
> downloads Alice's model from the repository, it would then include 
> Charlie's name as one of the authors (assuming that the publication was 
> referenced by PubMed ID or DOI or some sort of publication URI. 
> Particular cases like the one I described might be able to be secured in 
> an ad hoc fashion such as by checking that the authors are the same, but 
> the general attack will still pervade this type of approach unless 
> metadata is associated uniquely with a particular version of a 
> particular model. If the assertions about the same subject cannot be 
> identified between models in the database, then having data flow back 
> from the relational database into the model does not carry any benefit 
> at all).
> 
> However, I do agree that there is a place for some metadata which can be 
> changed without creating a new version (which probably is the type of 
> metadata that you wouldn't include in the CellML file by default). 
> Curation status and permissions would probably fit in this category, 
> because although they may be associated with a particular version, they 
> should not be immutable for a given version.
> 
> 2) I think that there should be a directory for each mathematical model 
> (which may include several CellML model files, documentation, and so 
> on), so that a particular version can be downloaded / checked out in its 
> entirety (with some directory-level manifest describing how to run or 
> view the model). This suggests that collisions between mathematical 
> models should be prevented at this level, not at the file level. Under 
> this scheme, Mary would find that at usage example 3, she couldn't use 
> the same directory name as the one John already submitted.
> 
> 3) I think the 'reference by citation' needs some expansion: I think 
> people referencing models should have the choice to refer to:
>  => a specific version for which no files will change at all.
>  => the latest version which aims to reflect the letter of a publication 
> (updates will only fix mistakes in the model which prevent it from 
> corresponding to the printed paper).
>  => the latest version which aims to reflect the results obtained by the 
> author (updates can fix discrepancies or omissions from the paper that 
> were in the author's original code, if the author didn't use CellML).
>  => the latest derivative of the current model developed by the same 
> author / group, even if it has not yet been peer-reviewed (subject to 
> permissions constraints).
>  => the latest derivative of the current model, but with all imports 

Re: [cellml-discussion] Concerning the CellML Model Repository

[Tommy Yu]

David Nickerson wrote:
> Hi Tommy,
> 
> looks like a good starting point for some discussion. Just to help me 
> think through some of the issues, is there any chance you could add a 
> usage example illustrating how this system would deal with a model made 
> from the combination of a bunch of papers (i.e., a single model where 
> each component defines a new citation). I'm guessing this would be done 
> by adding each of the components as separate models and then importing 
> them into a single model?
> 

It depends on how the model is cited.

If the creator of the model that binds all the separate models together based 
his/her model on a published paper, that citation would be used.  If not, it 
can only reside inside the user's directory as a filename of his choice, that 
imports the other models.

Yes, creator of model would have to import the components.

> Another usage example that might be interesting to look at would be a 
> model author adding a local CellML 1.1 model hierarchy to a remote 
> repository and how all the import href's are handled in this case (i.e., 
> imports throughout the model hierarchy might consist of a mix of 
> relative, http, and file URLs).
> 

The model repository shouldn't be responsible for users importing from file:// 
and other non-existent URIs.  I will create detail use cases for this, but in 
the case of http URIs, I can think of checking for a pre-approved list of 
hostnames that models can be imported from.

> And another usage example might be the searching for models built using 
> a specific set of data. It will hopefully become standard practice to 
> annotate variable values with their source, where the source may be some 
> data from a different article than the model's publication.
> 

That's using the metadata, right?  If the creator of the model does annotate 
components properly (e.g. giving some comment to cmeta:id of some component of 
some file) it will be searchable (provided that the creator publishes that 
model).

Thanks for your inputs,
Tommy.

> 
> Thanks,
> David.
> 
> Tommy Yu wrote:
>> Hi,
>>
>> I have written down some of my thoughts on how the model repository could be 
>> put together.
>>
>> http://www.cellml.org/Members/tommy/repository_redesign.html
>>
>> It is still a pretty rough document.  The usage example section gives a 
>> rough outline on what I see people might be doing with the repository and 
>> how this design could address those issues, which I think it will be of 
>> interest to users.  It is not an exhaustive list, yet.
>>
>> I must also note the design outlined is quite a drastic departure from what 
>> we have now (it will be yet another new repository).  However, it is more 
>> true to the one envisioned before according to 
>> http://www.cellml.org/wiki/CellMLModelRepositories, except I have an 
>> addition layer that will assist in pulling content and drawing relationships 
>> between models.
>>
>> Feel free to take it apart and/or build on top of it.
>>
>> Cheers,
>> Tommy.
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
> 

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Concerning the CellML Model Repository

[Tommy Yu]

eally depends on the structure of the data and
> the queries you want to perform. You should write out a reasonable set
> of these in natural language to get the focus right. Maybe a proof of
> concept using various mechanisms is required.
> 

Will get to that.  I am at the research stage still, but I did have some 
preliminary schemas down.

> The frustration with metadata handling at the moment is a result of
> some difficulties in the metadata specification for the metadata you
> are using the most and also the use of a quite esoteric system:
> 4Suite's Versa RDF query interface. RDQL or SPARQL are better SQL-like
> equivalents and certainly have a wide acceptance.
> 

While Versa itself is not so bad, but the intricacy and gotcha's of 4Suite was 
quite unpleasant to deal with.  I must note I did not decide to use that, I 
merely inherited code that used it so I am sort of stuck.  If I had a choice I 
would be using RDFlib and use SPARQL provided by it.  Yes, it has to do with 
frustration of both 4Suite and the metadata specification.

> Subversion offers a nice philosophy of code management and the guess
> is that this would apply well to the modeling process. It also offers
> the potential for building URIs for versioned material - individual
> files and whole changesets (which is something we are after). The
> default webdav URI scheme may not be what we want, so it is also worth
> looking at others; for example, the trac browser interface to a
> subversion repository form quite nice URIs.
> 

Yes, I am doing research into those also.  The HTTP interface would built on 
top of that also.

It is my desire to use a _real_ code management backend to manage models so I 
don't have to start writing a versioning mechanism into the repository like 
what we have now.

> Workflow and security as defined and implemented by Zope/CMF/Plone is
> a very nice model that should be reflected in our workflow and
> security use-cases. We discussed a few weeks ago that if this
> environment is going to provide the security layer, then there needs
> to be a relationship between this and the subversion repository at
> quite a detailed level.
> 

The workflow and security Zope/CMF/Plone will definitely be used, and will be 
mapped some ways into the model repository interface (abstraction layer, I 
called it).  I will give this more thought when I have the foundations down 
(i.e. interface between subversion/code and the database of metadata, submitted 
models, etc).

Thank you for your thoughts,
Tommy.

> cheers
> Matt
> 
> 
> On 6/21/07, Tommy Yu <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I have written down some of my thoughts on how the model repository could be 
>> put together.
>>
>> http://www.cellml.org/Members/tommy/repository_redesign.html
>>
>> It is still a pretty rough document.  The usage example section gives a 
>> rough outline on what I see people might be doing with the repository and 
>> how this design could address those issues, which I think it will be of 
>> interest to users.  It is not an exhaustive list, yet.
>>
>> I must also note the design outlined is quite a drastic departure from what 
>> we have now (it will be yet another new repository).  However, it is more 
>> true to the one envisioned before according to 
>> http://www.cellml.org/wiki/CellMLModelRepositories, except I have an 
>> addition layer that will assist in pulling content and drawing relationships 
>> between models.
>>
>> Feel free to take it apart and/or build on top of it.
>>
>> Cheers,
>> Tommy.
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Concerning the CellML Model Repository

[Tommy Yu]

Matt wrote:
> Hi Tommy,
> 
> Can you continue to update/fill out your document as well as begin
> associated proposals with information contained in the replies people
> are submitting. The goal of this process is a scoping document with
> associated content.
> 

It will be done when I am done refining all my thoughts about the threads here, 
along with the other thoughts I already have but not written down there.

> More comments below.
> 

Likewise.

> On 6/22/07, Tommy Yu <[EMAIL PROTECTED]> wrote:
>> Matt wrote:
>>> Hi Tommy,
>>>
>>> I found the document seemed to be too far ahead of itself. I also
>>> didn't find any of the pros and cons very compelling because they
>>> don't address specific problems and those problems are not described.
>>>
>>> 1) What are you actually trying to achieve? It would be useful to
>>> describe the parts of the current system that are giving you grief and
>>> look to give you more grief based on the use cases and any axes of
>>> scale.
>>>
>> Starting with what I envisioned.
>>
>> Who is the repository catered for?
>> 1) People who would like to work on models, using it as a place to store 
>> work-in-progress models.
>> 2) Reviewers to review models.
>> 3) Website users to browse models.
>>
>> 1) What do the model builders want?
>> - Their own workspace (home directory)
>> - A place to let reviewers review their models
>> - Also to publish their models
>>
>> First point is not addressed by what we have now.  Second and third point is 
>> quite ad-hoc.  Also, version control is very ad-hoc right now.
> 
> Each of these points need to be filled out, e.g. what does it mean to
> have a workspace for a CellML modeller?, What are the scenarios and
> workflows for reviewers of CellML models?
> 

Workspace is like a home directory.  Or are you comfortable with a flat 
filesystem where each file is owned by different people are all over the place. 
 This is about organization according to what the model builders want.

Models are by default private to the owner, but s/he can expose it via the 
layer that binds subversion and the database together which manages 
permissions.  Other modelers could import their collegues' models (provided 
permissions are given).

Reviewers simply gets access to a model, a URI to a specific revision of a 
model (and associated files, at model builder's options) will be generated 
which s/he could use.  If reviewer has rights s/he can publish the model to the 
public.

>> 2,3) Reviewers and website users
>> - A centralized location to browse models.
>> - They would like to see how models may relate to each other.
>>
> 
> How do models relate to each other? Relations between models come from
> all sorts of data within models, and within any associated metadata
> (so more than just our current cellml metadata specification). It
> would be useful to write out the details of the relationships that are
> important here as these pretty much form the basis of many of the
> queries that will need to be performed.

It will be done.  I can see users wanting to know which component of a model 
was imported by other models, and finding all other dependency of a particular 
model.  More will come.

> 
>> First point is already addressed, but second point is definitely not 
>> possible as the current repository does not support 1.1.
> 
> Why does it not support CellML 1.1? i.e. what is the technology block
> here to extending the current system to support it?
> 

None, aside from the lack of a proper code versioning system in the backend.  
With a few changes to the copy/paste code, CellML 1.1 will then be able to be 
stored into the repository.  I could go ahead and do this, but it will only 
further compound the issues we have now.  Okay, fine, refactor Model.py and 
have new classes inherit from that, but we still lack certain key features, 
such as a proper versioning backend.

Maybe as an experiment I could drop versions/variants and see how feasible it 
is in implementing certain desired features with just that.  However I still 
think we need a proper storage backend as the foundation, get that right 
(decided), before moving forward.

I don't want to build a mansion with a lack of a solid foundation.

>> Issues:
>> - Flat file system.
>> Sure, using ZCatalog it is possible to emulate users' home directories and 
>> the like, but it still does not get away from what we have now.
> 
> I don't understand this. What are you aiming for in a home space and
> why doesn't the current system support it?
> 

See above.  Current system can emulate it, therefore suppor

Re: [cellml-discussion] model upload problems

[Tommy Yu]

David Nickerson wrote:
> Hi,
> 
> I just tried to load the attached model into the model repository to use 
> as an example with the graphing metadata specification but am having 
> some problems.
> 
> Firstly, it didn't pick up some of the model metadata during the upload 
> process. At least there were some empty text boxes presented to me that 
> I would have expected to be filled with the metadata from the model. Not 
> sure if that is an error in the upload process or an error in my model 
> metadata? These boxes are still empty later when I got to the metadata 
> editor.
> 

Hi Andre,

Your metadata is fine, it did get picked up.  However, the namespace is CellML 
1.1 which the XSLT that generates the documentation (from the tmp-documentation 
namespace) do not support.  Ditto for CellML -> MathML XSLT.

I see that it is just one file, so I changed it to 1.0 and repository thinks 
it's okay now.

Kind Regards,
Tommy.

> I managed to get it into the repository as 
> http://www.cellml.org/models/sine-approximations_version01 but it 
> doesn't really seem to work. The overview page just says: "error occurs 
> during transform. See error log" - can I see the error log somewhere or 
> is this just for the site admin to see? The view math tab gives and XML 
> parsing error - a bit strange since I can run simulations of the model 
> fine using my tool based on the CCGS and API and the code generation tab 
> works fine and gives me the expected C code.
> 
> Anyone have any suggestions?
> 
> 
> Thanks,
> Andre.
> 
> 
> 
> 
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Concerning the CellML Model Repository

[Tommy Yu]

Hi,

I thought Andrew's ideas here is worth expanding, and I wrote a page based on 
that.

http://www.cellml.org/Members/tommy/BaseRepository

Cheers,
Tommy.



Andrew Miller wrote:
> Matt wrote:
>>> - Version/Variant
>>> It already clogged up the system.  There is no proper revision control 
>>> mechanism, what we have now is an ad-hoc emulated system.
>>> 
>> I don't think it has clogged the system I just think it has been
>> improperly used both by authors and by the user interface. This is no
>> fault of the authors, there is simply a specification for versioning
>> that is missing. The hope is that subversion applies well to this.
>>   
> I think that the versioning system itself is the root of the problem, 
> because it is simultaneously too complicated and too limited.
> 
> In particular:
> Branching is inherently a hierarchical process with arbitrary depth, in 
> the sense that branches can be made from branches to an arbitrary depth. 
> However, the variant / version system does not really provide the proper 
> tools to deal with this, because it is limited to two levels (variant 
> and version) before its utility in tracking what is a derivative of what 
> is exhausted.
> 
> It is also inadequate because a new model might combine parts of other 
> models, especially if it is a 1.1 model, and these parts need to be 
> tracked individually.
> 
> I think that the solution is to simplify down to a single global version 
> number that is common across the repository or the model (like in 
> Subversion), and then let either the CellML metadata, or perhaps the 
> Subversion copy history, describe the way a model has been derived.
> 
> I see the following workflow as being both simpler and more general...
> 
> John Doe creates a new model directory which has its primary URL at:
> http://www.cellml.org/models/id/0ff280ef-dce6-4a42-a275-c9a7d9699096/
> 
> John now owns this model and is the only one who can change it. John 
> also gets to decide the visibility of different revisions of the model.
> 
> John makes several revisions to the model (each of which bumps the 
> global revision number). There is a URL by which each historic version 
> can be referred to.
> 
> John then publishes the model in a journal, referring to it by the 
> primary URL (or perhaps a short-form if we want to offer authors the 
> option of assigning one). After the paper is accepted by a peer-reviewed 
> journal, John updates the metadata on the model. When he commits these 
> changes, the repository sees this and creates a new alias, e.g. at:
> http://www.cellml.org/models/citation/doe_2007_1/
> 
> John makes some further changes to his model post-publication and 
> commits them. However, by some mechanism (perhaps by the change 
> metadata?) the repository knows that this is a change which occurred 
> post-publication by John.
> 
> Mary notices that there was a discrepancy between the model and John's 
> published paper (assuming that he didn't reference the CellML model in 
> the paper). She creates a new primary URL containing a copy of John's 
> published model, at:
> http://www.cellml.org/models/id/281ab697-4607-4fcf-a433-f3ec382fb445/
> She gets John to check this. When John agrees, she updates the metadata 
> on her model to indicate that her version is a more correct version of 
> John's paper. The repository then updates so that 
> http://www.cellml.org/models/citation/doe_2007_1/ is a reference to 
> John's fixed version.
> 
> John merges in Mary's changes to 
> http://www.cellml.org/models/id/0ff280ef-dce6-4a42-a275-c9a7d9699096/ 
> and continues working on more changes. He starts collaborating with 
> Mary, so he grants her write access to 
> http://www.cellml.org/models/id/0ff280ef-dce6-4a42-a275-c9a7d9699096/.
> 
> Ming wants to create a derivative of John's paper, so he creates a copy 
> of the revision referenced from 
> http://www.cellml.org/models/citation/doe_2007_1/ at 
> http://www.cellml.org/models/id/7a8996e1-8d05-4a29-a7d8-622d047804fc/ 
> and starts working on it (marking up the history in the model metadata).
> 
> As you can see, instead of having a confusing mix of variants and 
> versions (with versions of variants of versions of variants), having a 
> single revision forces us to look at the metadata instead, which then is 
> sufficiently general not to have the problems we have seen.
> 
>>> - It's CellML Code, right?
>>> Why not put code in a real code management system, like Subversion?
>>> 
>> Subversion works well for filesystems of code and text data and to
>> some extent binary data that we don't really need to query the
>> contents of. If this applies well for CellML modelling, then
>> subversion is probably a good match. Subversion will bring its own
>> complexities when we are dealing with applying security to file
>> objects,
> It depends whether or not we actually allow direct access to Subversion 
> by untrusted users.
> A simple approach would be to make everyone go through the f

Re: [cellml-discussion] model upload problems

[Tommy Yu]

David Nickerson wrote:
> Hi Tommy,
> 
> Thanks for picking that up, I didn't even think to check the CellML 
> namespace!
> 

Hi Andre,

I have updated the XSLT used by the model repository to accept both 1.0 and 1.1 
models, but the repository itself still does not distinguish between the two 
different versions of models (i.e. it will still consider a 1.1 model as 1.0 
from the repository's point of view while it really is a 1.1 model, but at 
least none of the uglies you saw earlier will show up).

The changes currently sits in Subversion right now.

Cheers,
Tommy.

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Concerning the CellML Model Repository

[Tommy Yu]

David Nickerson wrote:
> Hi Tommy,
> 
> That looks good - its all starting to make sense to me now.
> 
> I'm just wondering how your system would handle a case where two authors 
> independently encode the same published model. The first author to 
> upload their encoding would get "ownership" of the publication alias (if 
> I have the terminology right). Is there any way for the second author to 
> get a similar alias to their encoding of the model? This is starting to 
> sound like a version/variant theme, but its probably a situation that 
> will crop up quite frequently...

I guess it depends on how those two model creators work.  If John and Mary work 
independently and two different models describing the same item were created, 
each will need have separate project directories.  If John did get the 
publication alias set up first it would obviously point to his model, but now 
Mary comes along and wants to have a separate model up also.  What could happen 
is this:

1) Publication alias is no longer an alias, but a directory holding aliases to 
users' models.
2) New model directory is created.  John and Mary's model directory is copied 
into there.

While outcome is similar, 1) separates publications from models a lot more, may 
reflect this situation when a paper with multiple models with each created by 
different people:

John, Mary and Ming creates on models a, b, c based on Doe's paper.  All three 
gets approved, and repos://publication/doe_2007_1/ is created containing 

repos://publication/doe_2007_1/pathway_a -> repos://!rev/45/home/john/a
repos://publication/doe_2007_1/pathway_b -> repos://!rev/60/home/mary/b
repos://publication/doe_2007_1/pathway_c -> repos://!rev/54/home/ming/c

created by their respective creators.  Each published model is treated 
differently, note their revision numbers.

2) has the benefit of encouraging model creators to work together, groups the 
same models in one place, and may reflect this situation:

A publication that describes multiple models with different people coding up 
each one could have a shared UUID named workspace, owned by the people working 
on it, with each separate models in its own directory.  The publication alias 
could be owned by the whole group that worked on the model.

I just flushed this out of my head, both of these suggestions may have very 
interesting consequences that is not noted here.

This was a very good question.

> 
> This is a slightly different example from your example workflow and 
> could be viewed as John and Mary both having "valid and correct" but 
> different encodings of the doe_2007_1 paper. Actually, I just saw the 
> '_1' on the publication link - is that some kind of version/variant that 
> would be _2 for Mary in my example? I had been assuming the 2007_1 meant 
> January 2007.
> 

It could conceivably mean the first paper John Doe published in 2007, or 
January, as that haven't been decided yet.

Thanks,
Tommy.

> 
> Thanks,
> Andre.
> 
> Tommy Yu wrote:
>> Hi,
>>
>> I thought Andrew's ideas here is worth expanding, and I wrote a page based 
>> on that.
>>
>> http://www.cellml.org/Members/tommy/BaseRepository
>>
>> Cheers,
>> Tommy.
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Concerning the CellML Model Repository

[Tommy Yu]

Matt wrote:
> I don't understand the purpose of this.
> 
> It looks like you are inventing a versioning system to implement from scratch.
> 

That's what it looks like, but if you recall the software choices I have 
written down I have been considering them, and have been going through the 
features they offer that would be of use to us.  I am being agnostic to 
software right here, as someone would like me to stay away from underlying 
pieces at the moment.  I am conveying a generic concept of a repository in the 
context of CellML model development, outlining possible hints to what may be 
best practices.

> I don't see how this system would work with someone working on a
> filesystem and not wanting to use a browser - you'd have to invent
> client software for this.
> 
> Start by reviewing things like:
> 
> subversion
> svk
> darcs
> monotone
> arch
> etc
> 

I did, I already suggested to use Subversion as a possible backend (I also 
reviewed how GIT might be a reasonable choice if we proxy remote repositories), 
possibly a RDBMS to help with the relationship aspect of models, and Plone/Zope 
for the workflow states and presentation front-end via WWW.

> Review them in the context of the use-cases that need to be satisfied.
> 
> Include use-cases such as someone working on a complex model that uses
> imports of models in a local space. Include use-cases of someone
> wanting to follow volatile vs non-volatile versions/branches, etc.
> 

If a model builder develops their models in their local space they could import 
items from within their projects via relative paths (no different than working 
locally on their storage device).  If they rely on other models they could 
import a specific frozen version of a model, or the development version, from 
the repository.  Volatile versions are provided for anyone who need it.

> Include the environments from which you expect this versioning system
> to work (e.g. commands on a filesystem, webdav, etc).
> 

If it's subversion someone could do a svn ci or use their GUI clients to update 
models.  They could also update via WWW.

> What are the kinds of relationships between permissions and roles. I
> know you have some ideas here, but it's not very replete and perhaps
> needs to be put in a table.
> 

They will be put on the table.

> I think aliases in for web URIs are the least of the problems at the moment.
> 
> On 6/26/07, Tommy Yu <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I thought Andrew's ideas here is worth expanding, and I wrote a page based 
>> on that.
>>
>> http://www.cellml.org/Members/tommy/BaseRepository
>>
>> Cheers,
>> Tommy.
>>
>>
>>
>> Andrew Miller wrote:
>>> Matt wrote:
>>>>> - Version/Variant
>>>>> It already clogged up the system.  There is no proper revision control 
>>>>> mechanism, what we have now is an ad-hoc emulated system.
>>>>>
>>>> I don't think it has clogged the system I just think it has been
>>>> improperly used both by authors and by the user interface. This is no
>>>> fault of the authors, there is simply a specification for versioning
>>>> that is missing. The hope is that subversion applies well to this.
>>>>
>>> I think that the versioning system itself is the root of the problem,
>>> because it is simultaneously too complicated and too limited.
>>>
>>> In particular:
>>> Branching is inherently a hierarchical process with arbitrary depth, in
>>> the sense that branches can be made from branches to an arbitrary depth.
>>> However, the variant / version system does not really provide the proper
>>> tools to deal with this, because it is limited to two levels (variant
>>> and version) before its utility in tracking what is a derivative of what
>>> is exhausted.
>>>
>>> It is also inadequate because a new model might combine parts of other
>>> models, especially if it is a 1.1 model, and these parts need to be
>>> tracked individually.
>>>
>>> I think that the solution is to simplify down to a single global version
>>> number that is common across the repository or the model (like in
>>> Subversion), and then let either the CellML metadata, or perhaps the
>>> Subversion copy history, describe the way a model has been derived.
>>>
>>> I see the following workflow as being both simpler and more general...
>>>
>>> John Doe creates a new model directory which has its primary URL at:
>>> http://www.cellml.org/models/id/0ff280ef-dce6-4a42-a275-c9a7d9699096/
>>>

[cellml-discussion] Auckland CellML group meeting minutes (2007-09-26)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting on 2007-09-26 is published at 
this URI:

http://www.cellml.org/meeting_minutes/meeting-minutes-26-september-2007

Cheers,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML group meeting minutes (2007-10-03)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting on 2007-10-03 is published at 
this URI:

http://www.cellml.org/meeting_minutes/meeting-minutes-03-october-2007

Cheers,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML group meeting

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting on 2007-10-17 is published at 
this URI: 

http://www.cellml.org/meeting_minutes/meeting-minutes-17-october-2007

Starting from today, the minutes of the latest weekly meeting of this group 
will be posted on Friday, between the hours of 00:00 and 03:00 UTC at the 
following URI:

http://www.cellml.org/meeting_minutes/latest-minutes

Kind Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (20071121)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting of 2007-11-21 can now be found 
at:

http://www.cellml.org/meeting_minutes/latest

Kind Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (20071128)

[Tommy Yu]

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. 
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (2007-12-12)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting of 2007-12-12 can now be found 
at:

http://www.cellml.org/meeting_minutes/latest

Kind Regards,
Tommy. 
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (2007-12-19)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting of 2007-12-19 can now be found 
at:

http://www.cellml.org/meeting_minutes/latest

Kind Regards,
Tommy. 

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (2008-01-09)

[Tommy Yu]

Greetings,

The minutes to the Auckland CellML group meeting of 2008-01-09 can now be found 
at:

http://www.cellml.org/meeting_minutes/latest

Kind Regards,
Tommy. 

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (2008-01-16)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting of 2008-01-16 can now be found 
at:

http://www.cellml.org/meeting_minutes/latest

Kind Regards,
Tommy. 

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (2008-01-23)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting of 2008-01-23 can now be found 
at:

http://www.cellml.org/meeting_minutes/latest

Kind Regards,
Tommy.

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (2008-01-30)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting of 2008-01-30 can now be found 
at:

http://www.cellml.org/meeting_minutes/latest

Kind Regards,
Tommy. 


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (2008-02-07)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting of 2008-02-07 can now be found 
at:

http://www.cellml.org/meeting_minutes/latest

Kind Regards,
Tommy. 


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (2008-02-13)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting of 2008-02-13 can now be found 
at:

http://www.cellml.org/meeting_minutes/latest

Kind Regards,
Tommy. 


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (2008-04-30)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting of 2008-04-30 can now be found 
at:

http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2008-04-30

Kind Regards,
Tommy. 


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Auckland CellML Group Meeting Minutes (2008-05-07)

[Tommy Yu]

Greetings,

The minutes of the Auckland CellML group meeting of 2008-05-07 can now be found 
at:

http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2008-05-07

Kind Regards,
Tommy. 


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] CellML Metadata Specification - citation tracker item

[Tommy Yu]

Greetings,

CellML Metadata Specification has provisions for logging citations using terms 
and classes under the cellml bqs namespace, which was derived from OMG's 
Bibliographic Query Service Draft Specification.  This was done early this 
decade before there was a RDF schema for creating citations, when there was 
nothing better.  The situation has changed today and there are more widely 
supported choice(s) of RDF schemas to construct citation metadata (such as: 
DCMI-Terms, Bibliographic Ontology, (also OpenURL)), which I think the CellML 
Metadata Specification should be using.  I have created this tracker item that 
lists my concerns relating to this issue.

https://tracker.physiomeproject.org/show_bug.cgi?id=414

Kind Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] PMR2 Prototype Public Demo Server

[Tommy Yu]

Greetings,

The PMR2 prototype has been staged to:

http://67.223.228.57:8282/cellml/

Please register an account there to try it out, and please post any feedback to:

https://tracker.physiomeproject.org/show_bug.cgi?id=248

Kind Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] [Fwd: Re: little b - shared models built from reusable parts]

[Tommy Yu]

Apologies to Hamid, the message somehow got dropped due to non-membership 
status.  This was his message.

 Original Message 
Subject: Re: [cellml-discussion] little b - shared models built from reusable   
parts
Date: Fri, 25 Jul 2008 12:03:24 -0700
From: Hamid Bolouri <[EMAIL PROTECTED]>
To: CellML Discussion List 
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Maybe I am showing my age, but I think using Lisp for modeling makes a
lot of sense. See

http://www.defmacro.org/ramblings/lisp.html


Hamid
-- 
http://www.its.caltech.edu/~hbolouri/


On Fri, Jul 25, 2008 at 5:18 AM, Nicolas Le Novere <[EMAIL PROTECTED]> wrote:
> The SBML community has know little b for a while since they first came to
> us, a long time ago, saying roughly "we're much better than you, and we do
> everything in a simpler way, understandable by users".
>
> I think (and this is a personal opinion, that does NOT reflect the opinion
> of the SBML editors as a whole) this is a worthwhile effort, but
> completely different than SBML and CellML.
>
> 1) In general, the terser a language is, the more fuzzy but the harder to
> interpret it is. If the SBML spec is so long and complicated, it is
> because one of our goal is to ensure that everyone interpret an SBML
> description exactly the same way. That bears a lot of consequences on
> units etc. Terse is good. Unambiguous is better (if you want to exchange
> and integrate)
>
> 2) I am not sure LISP is a good *description* language. And we need to
> separate description of the model structure from description of the
> simulation. SBML and CellML are not programming language.
>
> Again this is a personal feeling. At the end I guess the only criteria is
> the usefullness for the scientific community.
>
>> Hi all,
>>
>> Has anyone encountered this before?
>>
>> http://www.littleb.org/
>>
>> The little b project is an effort to provide an open source
>>  language which allows scientists to build
>> mathematical models  of
>> complex systems. The initial focus is systems biology
>> . The goal is to stimulate
>> widespread sharing and reuse of models.
>>
>> The little b language is designed to allow biologists to build models
>> quickly and easily from shared parts, and to allow theorists to program
>> new ways of describing complex systems. Currently, libraries have been
>> developed for building ODE
>>  models of molecular
>> networks in multi-compartment systems such as cellular epithelia.
>>
>> Little b is based in Common Lisp and contains mechanisms for rule-based
>> reasoning, symbolic mathematics and object-oriented definitions. The
>> syntax is designed to be terse and human-readable to facilitate
>> communication. The environment is both interactive and compilable.
>>
>> Kind regards,
>> James
>>
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
>
>
> --
> Nicolas LE NOVERE,  Computational Neurobiology,
> EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
> Tel: +44(0)1223494521, Fax: +44(0)1223494468, Mob: +44(0)7833147074
> http://www.ebi.ac.uk/~lenov, AIM:nlenovere, MSN:[EMAIL PROTECTED]
>
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] little b - shared models built from reusable parts

[Tommy Yu]

Nicolas Le Novere wrote:
> The SBML community has know little b for a while since they first came to
> us, a long time ago, saying roughly "we're much better than you, and we do
> everything in a simpler way, understandable by users".
> 
> I think (and this is a personal opinion, that does NOT reflect the opinion
> of the SBML editors as a whole) this is a worthwhile effort, but
> completely different than SBML and CellML.
> 
> 1) In general, the terser a language is, the more fuzzy but the harder to
> interpret it is. If the SBML spec is so long and complicated, it is
> because one of our goal is to ensure that everyone interpret an SBML
> description exactly the same way. That bears a lot of consequences on
> units etc. Terse is good. Unambiguous is better (if you want to exchange
> and integrate)
> 

Software code can also be terse and unambiguous, and can be exchanged with 
others to be integrated into one's software.  A software language must also be 
interpreted the exact same way between different interpreters, or users are not 
going to be interested in using the non-standard interpreters (usually, 
anyway).  I can see the same objectives accomplished with little b just as 
well, provided that the model code was written with unambiguity in mind.

> 2) I am not sure LISP is a good *description* language. And we need to
> separate description of the model structure from description of the
> simulation. SBML and CellML are not programming language.
> 

I think this can be done with a programming language.  A modeler could define a 
set of files as the description of the model structure, and build a different 
set of files for the description of the simulation, then the completed models 
can be assembled together.

Naturally, SBML and CellML were never meant to be programming languages from 
the beginning.   XML based languages have other types of advantages over 
lisp-based languages, naming the great number of tools able to interpret XML 
files, interoperability with XML/RDF for a variety of metadata capabilities, 
and many more.  I see it as a case of two different class of langauges with 
different objectives in mind...

> Again this is a personal feeling. At the end I guess the only criteria is
> the usefullness for the scientific community.
> 

... and both types will have their niche where they will be widely used in the 
community.

Just a couple cents from a software programmer.

Tommy.

>> Hi all,
>>
>> Has anyone encountered this before?
>>
>> http://www.littleb.org/
>>
>> The little b project is an effort to provide an open source
>>  language which allows scientists to build
>> mathematical models  of
>> complex systems. The initial focus is systems biology
>> . The goal is to stimulate
>> widespread sharing and reuse of models.
>>
>> The little b language is designed to allow biologists to build models
>> quickly and easily from shared parts, and to allow theorists to program
>> new ways of describing complex systems. Currently, libraries have been
>> developed for building ODE
>>  models of molecular
>> networks in multi-compartment systems such as cellular epithelia.
>>
>> Little b is based in Common Lisp and contains mechanisms for rule-based
>> reasoning, symbolic mathematics and object-oriented definitions. The
>> syntax is designed to be terse and human-readable to facilitate
>> communication. The environment is both interactive and compilable.
>>
>> Kind regards,
>> James
>>
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
> 
> 

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] little b - shared models built from reusable parts

[Tommy Yu]

Michael Hucka wrote:
> My own $0.02, as another software developer and an old Lisp
> hacker myself (and of course, everything I say here is
> purely personal opinion).
> 
>   TY> I think this can be done with a programming language.
> 
> Yup, you can exchange programs as your "model description",
> and people did essentially that for a few decades.  (They
> still do even today, especially when the model is, e.g.,
> MATLAB code.)  There are at least two reasons why people are
> trying to move away from that: 
> 
> 1) The system interpreting the description must implement
>the entire programming language interpreter.  Little b,
>for example, needs Lisp underneath it.  But regardless of
>whether your description requires Lisp or not, it's a
>nontrivial requirement.  It reduces your ability to share
>the model on the one hand, and the size of your willing
>audience on the other.
> 

Yup, see below.

> 2) The essence of what you're trying to model becomes lost.
>It is no longer a description of the domain phenomena
>(here, biological mechanisms), and instead becomes tied
>up with artifacts of the simulation/analysis framework.
> 

Agreed, not being tied to a specific framework grants way more freedom than 
otherwise.  Further points below.

> (I'm sorry if that seems obvious and I'm missing your
> point!)
> 
>   TY> XML based languages have other types of advantages
>   TY> over lisp-based languages, naming the great number of
>   TY> tools able to interpret XML files, interoperability
>   TY> with XML/RDF for a variety of metadata capabilities,
>   TY> and many more.
> 
> I'm not sure if you're saying this, but just to be clear,
> XML is *not* a programming language.  It's merely a
> serialization format.  One could use ASN.1, or Google's
> Protocol Buffers, or any of another of others.
> 

Whoops, I didn't mean to imply XML is a programming language, I meant to say 
using lisp-based languages are limiting because they require a lisp interpreter 
underneath to interpret it, which is what you have said in point 1).

To strengthen point 2) that you've made and to further elaborate/clear up on 
what I said, XML is a fairly good language to use to represent/exchange models 
because it has been extended by many different parties, namely MathML and 
RDF/XML.  MathML allows very raw and explicit representation of the 
mathematical equations represented by the model, there are many different 
software that can render/solve it.  RDF/XML is a versatile description 
framework that has been extended by many different groups to allow 
representation of various types of metadata, and can be very domain specific in 
what it represents.  Again, many different software can be used to interpret 
RDF, and are very platform agnostic.

As for simulation of the representations of the models, one can turn that XML 
representation into any software code of one's choice, as it's not limited by 
any framework.  Definitely much greater flexibility, but of course this 
requires a bit more work.

Thank you for your $0.02!

Cheers,
Tommy.

> MH
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] PMR2 Prototype Public Demo Server

[Tommy Yu]

Greetings,

Just a friendly reminder, the lease for the server space for the PMR2 (Physiome 
Model Repository v2) Prototype will expire in approximately two weeks.  There 
were only a limited number of people who signed up for an account, but it seems 
nobody tried out features that became available with an account.  Please try it 
out, make changes to existing models, and then creating exposures of them.  
Your feedback will be very much appreciated, they will aid us in deciding on 
which course of actions to take for the development of the final repository.  
If you got questions on the usage please feel free to ask me.

Information to log on to the prototype PMR2 is quoted below.

Cheers,
Tommy.

Tommy Yu wrote:
> Greetings,
> 
> The PMR2 prototype has been staged to:
> 
> http://67.223.228.57:8282/cellml/
> 
> Please register an account there to try it out, and please post any feedback 
> to:
> 
> https://tracker.physiomeproject.org/show_bug.cgi?id=248
> 
> Kind Regards,
> Tommy.
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] PMR2 Prototype Public Demo Server

[Tommy Yu]

Bob Gustafson wrote:
> Even though I get your news-emails, and I thought I registered for an
> account, your system doesn't know me..
> 

Don't worry, I did see your account registered.

> I did register and clicked around in the Plone database. The Sache_2008
> folder had some files - interesting graphics too.
> 

Yup, and you are very welcome to test out other features, using the 'Update 
This Commit' link to make test modifications in your personal sandbox.  Select 
'Upload File' to upload the files you may have modified (or even new files), 
save your changes into a commit by 'Commit', and then 'Push' your changes back 
up to the source workspace for the sandbox.  You can also create exposures of 
the changes you've made.  You will have an opportunity to select the 
appropriate files once you created the initial exposure page.

Cheers,
Tommy.

> But, it is getting pretty late here and I need my sleep.
> 
> Bob G
> 
> On Tue, 2008-07-29 at 16:14 +1200, Tommy Yu wrote:
>> Greetings,
>>
>> Just a friendly reminder, the lease for the server space for the PMR2 
>> (Physiome Model Repository v2) Prototype will expire in approximately two 
>> weeks.  There were only a limited number of people who signed up for an 
>> account, but it seems nobody tried out features that became available with 
>> an account.  Please try it out, make changes to existing models, and then 
>> creating exposures of them.  Your feedback will be very much appreciated, 
>> they will aid us in deciding on which course of actions to take for the 
>> development of the final repository.  If you got questions on the usage 
>> please feel free to ask me.
>>
>> Information to log on to the prototype PMR2 is quoted below.
>>
>> Cheers,
>> Tommy.
>>
>> Tommy Yu wrote:
>>> Greetings,
>>>
>>> The PMR2 prototype has been staged to:
>>>
>>> http://67.223.228.57:8282/cellml/
>>>
>>> Please register an account there to try it out, and please post any 
>>> feedback to:
>>>
>>> https://tracker.physiomeproject.org/show_bug.cgi?id=248
>>>
>>> Kind Regards,
>>> Tommy.
>>> ___
>>> cellml-discussion mailing list
>>> cellml-discussion@cellml.org
>>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Summary of PMR2 Prototype Discussions

[Tommy Yu]

Greetings everyone,

Following up on the discussions made regarding the PMR2 prototype exercise, 
found at:
https://tracker.physiomeproject.org/show_bug.cgi?id=248

I have summarized all the major issues and points to be addressed as we develop 
the final PMR2.  The document can be found at:
https://svn.physiomeproject.org/svn/physiome/plone_products/pmr2.hgpmr/trunk/SUMMARY.txt

Cheers,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] PMR2 v0.1rc1

[Tommy Yu]

Greetings,

The first release candidate of the v0.1 release of PMR2 can be accessed at 
http://67.223.234.212:8380/pmr2/.  The tracker item for this release is 
https://tracker.physiomeproject.org/show_bug.cgi?id=1772.

Kind Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Announcement of the new CellML Model Repository (and release of PMR2 v0.1)

[Tommy Yu]

Greetings,

Team CellML is pleased to announce the immediate availability of the new CellML 
Model Repository running on PMR2 v0.1 at http://models.cellml.org/.  All CellML 
models which were hosted within PMR1 (which was at 
http://www.cellml.org/models) have been migrated into PMR2.  In addition to the 
data migration, every URI within PMR1 will remain valid and will redirect to 
their respective URI in PMR2 (i.e. all links in existing publications will not 
be broken).

Also, PMR2, or Physiome Model Repository 2 v0.1 has been released.  This is a 
complete rewrite compared to PMR1, and will now handle CellML 1.1 imports and 
full version control has been implemented using Mercurial.  If you would like 
access to the entire history of any particular model in PMR2, please install a 
Mercurial client (Download link at 
http://www.selenic.com/mercurial/wiki/BinaryPackages).

Please report any bugs or issues you find in PMR2 at the Physiome Tracker 
(https://tracker.physiomeproject.org/), to this mailing list, or directly to 
tommy...@auckland.ac.nz.

Kind Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Announcement of the new CellML Model Repository (and release of PMR2 v0.1)

[Tommy Yu]

Alan Garny wrote:

Hi Tommy,

Well done on getting PMR2 out into the open!



Hi Alan,

Thank you.


A few things:
 - Is there any documentation/tutorial that I could read so that I can learn
more about the differences between PMR1 and PMR2, as well as learn the
basics about PMR2 (e.g. what is an exposure?, what is a workspace?, what is
Mercurial?)?


It will be written soon.


 - Full model listing: by clicking on the full model listing, I can see that
'only' the first 100 models are listed. Is there no way to really get the
full listing? It might also be nice to have anchors that would allow us to


The 100 model listing limit was put into place to decrease loading time.  If 
you would like to see the full listing, you will need to login, then select 
'folder contents', and scroll to the bottom, select 'Show all items'.  You can 
sort by name or other fields that are present.


go straight to the first model where the first author's name starts with an
"A", "B", "C", etc. Also, though I like the list of categories of models in
the homepage, I think it would be nice, in the full model listing, to have
fields on which to sort the list. E.g. one could sort by name (as is
currently the case), year, model type (i.e. the category mentioned on the
front page), type with a given category (e.g. in cardiac electrophysiology,
it could be ventricular, atrial, purkinje fibre, etc.).


Sorting by category will be difficult because most models have multiple 
categories (which are actually keywords associated with the model).


 - Access a model via "Solve using OpenCell": I have PCEnv (not OpenCell,
since it will only be called that as of the next official release) installed
on my system (Windows XP) and clicked on the link, but all that did was to
offer me to save the file (I have tried using both Opera and Firefox). I
have just tried under Linux using Firefox, and same story. Otherwise, the
URL contains "pcenv" while I would have expected "opencell", if anything...


You need to manually get your browser to associate that link with 
PCEnv/OpenCell, as it is sent via a custom mime-type.


 - Generation of procedural code for a particular model: it might be useful
to mention the version of the CellML API that was used to generate the code?
In the past, people have often assumed that PMR1 used the latest version
when I understand it wasn't the case. It might now be the case with PMR2 (I
don't know!), but in any case it would help to know the version used.



Yes, good point.  Currently CellML API 1.6 is used to generate the code.


Anyway, those are just a few quick thoughts... for having had a very quick
look at PMR2... :)



Thank you for your observations.

Regards,
Tommy.


Alan


-Original Message-
From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion-
boun...@cellml.org] On Behalf Of Tommy Yu
Sent: 22 June 2009 02:28
To: CellML Discussion Group
Subject: [cellml-discussion] Announcement of the new CellML Model
Repository (and release of PMR2 v0.1)

Greetings,

Team CellML is pleased to announce the immediate availability of the new
CellML Model Repository running on PMR2 v0.1 at http://models.cellml.org/.
All CellML models which were hosted within PMR1 (which was at
http://www.cellml.org/models) have been migrated into PMR2.  In addition

to

the data migration, every URI within PMR1 will remain valid and will
redirect to their respective URI in PMR2 (i.e. all links in existing
publications will not be broken).

Also, PMR2, or Physiome Model Repository 2 v0.1 has been released.  This

is

a complete rewrite compared to PMR1, and will now handle CellML 1.1

imports

and full version control has been implemented using Mercurial.  If you
would like access to the entire history of any particular model in PMR2,
please install a Mercurial client (Download link at
http://www.selenic.com/mercurial/wiki/BinaryPackages).

Please report any bugs or issues you find in PMR2 at the Physiome Tracker
(https://tracker.physiomeproject.org/), to this mailing list, or directly
to tommy...@auckland.ac.nz.

Kind Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] PMR2 v0.2 has been released

[Tommy Yu]

Greetings,

Team CellML is pleased to announce the release of v0.2 of the Physiome Model 
Repository 2 software.  The CellML model repository (http://models.cellml.org/) 
has been upgraded to this version.

Major changes include:

- Rewriting of the exposure mechanism.  Each file now have views attached to 
them, instead of generating multiple types of files for the presentation of it.
- Smoother workflow representations for curators who deal with creation and 
management of exposures.
- Support for embedded workspaces through the use of Mercurial subrepo.
- Various UI refinements for better representation of models and its exposures. 
 Most noticeable changes are the relocation of exposure information from the 
top of the main content area to the side, and in workspace views, a new column 
will point to exposures if a particular changeset has one made for it.

Please report any bugs or issues you find in PMR2 at the Physiome Tracker (https://tracker.physiomeproject.org/), to this mailing list, or directly to tommy...@auckland.ac.nz. 


Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Upgrading models.cellml.org

[Tommy Yu]

Hi,

On 29 March 2010, 10:00 NZDT (2010-03-28 21:00 UTC), the CellML model 
repository hosted at models.cellml.org will be taken down briefly to expand the 
storage capacity of its host.

Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Upgrading models.cellml.org

[Tommy Yu]

Correction, the downtime should be on 30 March 2010, 10:00 NZDT (2010-03-29 
21:00 UTC).  Its anticipated length is about ten minutes.

Regards,
Tommy.

Tommy Yu wrote:

Hi,

On 29 March 2010, 10:00 NZDT (2010-03-28 21:00 UTC), the CellML model 
repository hosted at models.cellml.org will be taken down briefly to 
expand the storage capacity of its host.


Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Upcoming Maintenance Downtime for CellML websites.

[Tommy Yu]

Greetings,

The UoA ITS group will be performing an OS upgrade on the servers that host the 
CellML websites on Tuesday 27th April 2010, 10:30am to 12:30pm (UTC: 2010-04-26 
22:30 to 2010-04-27 00:30).  Both the CellML website (http://www.cellml.org/) 
and the CellML Model Repository (http://models.cellml.org/) will be 
inaccessible for some time during this scheduled maintenance period.  We 
apologize for any inconveniences that may be caused by this outage, and thank 
you for your kind understanding.

Regards,
Tommy.

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Staging of PMR2 v0.3 rc1

[Tommy Yu]

Greetings,

The first release candidate of PMR2 v0.3 can be accessed at 
http://184.73.44.8:8380/pmr/.  If you have any questions, comments, or have 
encountered issues, please file comments or block tracker item at 
https://tracker.physiomeproject.org/show_bug.cgi?id=2557.

Kind Regards,
Tommy. 
___

cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] CellML Model Repository now running on PMR2 v0.3

[Tommy Yu]

Greetings,

The CellML Model Repository (http://models.cellml.org/) has upgraded to the 
latest release of PMR2, v0.3.  Please file any issues you may find with this 
instance at https://tracker.physiomeproject.org/show_bug.cgi?id=2613.

This instance of the repository will be used for storage of models from other 
Physiome related projects (i.e. FieldML).  Examples used on the testing site 
will be added to this instance soon.

Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] CellML Website/Repository Maintenance

[Tommy Yu]

Dear all,

The machines that host CellML website and its model repository will undergo 
maintenance on 30th May between 09:00 and 11:00 NZST (2011-05-29 21:00-23:00 
UTC), as the original scheduled maintenance on 9th May did not proceed as 
planned.

Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML Website/Repository Maintenance

[Tommy Yu]

Tommy Yu wrote:

Dear all,

The machines that host CellML website and its model repository will 
undergo maintenance on 30th May between 09:00 and 11:00 NZST (2011-05-29 
21:00-23:00 UTC), as the original scheduled maintenance on 9th May did 
not proceed as planned.




Update on the maintenance:

The model repository is up and running, however the main website is still 
undergoing its update procedures.  The access to this website should be 
restored within an hour.

Regards,
Tommy.


Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML Website/Repository Maintenance

[Tommy Yu]

Tommy Yu wrote:

Tommy Yu wrote:

Dear all,

The machines that host CellML website and its model repository will 
undergo maintenance on 30th May between 09:00 and 11:00 NZST 
(2011-05-29 21:00-23:00 UTC), as the original scheduled maintenance on 
9th May did not proceed as planned.




Update on the maintenance:

The model repository is up and running, however the main website is 
still undergoing its update procedures.  The access to this website 
should be restored within an hour.




The maintenance was completed half an hour ago.


Regards,
Tommy.


Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] ABI CellML Meeting Minutes, 8th June 2011

[Tommy Yu]

Greetings,

The minutes of the Auckland Bioengineering Institute CellML meeting of 8th June 
2011 can now be found at:

http://www.cellml.org/community/meeting/minutes/2011/06.08

Kind Regards,
Tommy. 



___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] ABI CellML Meeting Minutes, 8th June 2011

[Tommy Yu]

On 10/06/11 19:48, Randall Britten wrote:

Hi all

My apologies, I forgot to review the minutes on time before our deadline to
make them public.  I will suggest some minor wording changes to those who
attended the meeting, and if they agree, we will modify the posted version,
and send a mail to this list.



Hi All,

The changes have been applied to the minutes.

Regards,
Tommy.


Regards,
Randall


-Original Message-
From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion-
boun...@cellml.org] On Behalf Of Tommy Yu
Sent: Friday, 10 June 2011 7:17 p.m.
To: CellML Discussion Group
Subject: [cellml-discussion] ABI CellML Meeting Minutes, 8th June 2011

Greetings,

The minutes of the Auckland Bioengineering Institute CellML meeting of 8th
June 2011 can now be found at:

http://www.cellml.org/community/meeting/minutes/2011/06.08

Kind Regards,
Tommy.


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Web services and PMR2

[Tommy Yu]

Hi,

In the near future I will be building a module that will provide web service 
support for PMR2.  The protocols I've looked at are SOAP and REST.  SOAP looks 
fairly standardized and seems very simple to add and the SOAPpy client (in 
Python) appears to be straightforward to use, but I can see how people can find 
this to be an overly heavy solution.

REST on the other hand doesn't really have much support natively under 
Zope/Plone, doesn't really have a standard transport mechanism, and the 
standard is basically what the general community and/or implementer decide.  
However, most people use JSON as the transport mechanism for data and I would 
agree that can allow fairly quick way to implement something to get this going.

What I want to know is what the community as a whole wants - do one of the two 
or both?  There is also a tracker item from a while back about this issue 
[https://tracker.physiomeproject.org/show_bug.cgi?id=1909], so please do refer 
to it and comment either on this thread and/or that item.

Regards,
Tommy.


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011

[Tommy Yu]

Greetings,

The minutes of the Auckland Bioengineering Institute CellML meeting of 22nd 
June 2011 can now be found at:

http://www.cellml.org/community/meeting/minutes/2011/06.22

Kind Regards,
Tommy. 
___

cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011

[Tommy Yu]

Alan Garny wrote:

Hi,

Having just read the minutes, I was wondering whether you guys could clarify
the situation with regards to web service support for PMR2? Tommy said that
"REST support is iffy" and that's also what I understood from the email he
sent around earlier this week. However, the minutes read that the "general
upshot is that REST is likely to be the technology of choice"...?! I can't
see the rationale here. So, would it be possible to have some explanations?
Also, in Tommy's email, he mentioned JSON (in addition to SOAP and REST).
So, what about JSON?



Hi Alan,

REST support is iffy is in relation to standards/libraries that provide/support 
within the standard Zope/Plone environment.  What this means is I will have to 
implement anything that isn't there natively.  However, REST really is a 
methodology for transferring of states, and in PMR2's case there isn't really 
that much to add.

As for how these states are transfered, there are many ways to do so, either 
via XML, JSON or other formats.  Since JSON is the preferred encoding method 
for values this is why we tentatively decide to do so.  JSON and REST are two 
complete independent entities and are completely different types of concepts 
that gets used together a lot.

SOAP on the other hand is a design-by-committee standard that ends up being 
excessively verbose for what we are trying to do, which is to provide a 
lightweight method to retrieve values from PMR2.  I did start off doing this in 
SOAP with a library that the Zope community provided.  It was easy to get going 
because SOAP is an established standard, but under the hood it was anything but 
simple.  This is the request body to get the title of an object generated by 
the SOAPpy library:


http://schemas.xmlsoap.org/soap/encoding/";
 xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";









This is the response by the Zope SOAP library I added:

   xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"; 
   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";

   xmlns:ZSI="http://www.zolera.com/schemas/ZSI/";
   xmlns:xsd="http://www.w3.org/2001/XMLSchema";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
 
 
 
   
 Workspaces
   
 


Whereas with JSON it's more of a simple standard HTTP GET to a specific URL 
(which we will have to define) and response body would look something like

{
 "title": "Workspace"
}

An order of magnitude of reduction in bytes.

A response for a list of workspace with its URL looks something like this per 
entry:

{
...
"Per Pixel Lighting": "http://localhost:8380/pmr/workspace/per_pixel_lighting";,
...
}

Rather than this


...

 
   Per Pixel Lighting
 
 
   http://localhost:8380/pmr/workspace/per_pixel_lighting
 

...


For JSON, all you need is to use a standard JSON library, load the string, and 
you have the values you need.  Ditto for SOAP, but the transport body is just 
excessively verbose - added bytes for no added benefits in our case.

To submit changes in the REST protocol I plan to implement for PMR2, you should 
be able to construct a standard POST request to one of our standard forms and 
things will be done.  While some people would argue we should allow users to 
PUT stuff, we don't actually support that with our current web front-end anyway 
because PMR2 generates the content (i.e. exposures and their associated 
pages/views) based on commands user sends via standard http POST forms.

If you want to know more as to why REST is displacing SOAP, search 'REST vs. 
SOAP' in your favorite search engine - evidence for why is too numerous to list 
here.

Okay, I will try anyway:

Popularity between REST and SOAP
http://royal.pingdom.com/2010/10/15/rest-in-peace-soap/

Google deprecated SOAP API two years ago (their encoding is in atom and json):
http://googlecode.blogspot.com/2009/03/introducing-labs-for-google-code.html

BioModels are moving to a REST API, not sure what their encoding will be but I 
heard it will be json.

So yeah, these are the justifications.

Regards,
Tommy.


Cheers, Alan.


-Original Message-
From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion-
boun...@cellml.org] On Behalf Of Tommy Yu
Sent: 24 June 2011 06:49
To: CellML Discussion Group
Subject: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011

Greetings,

The minutes of the Auckland Bioengineering Institute CellML meeting of

22nd

June 2011 can now be found at:

http://www.cellml.org/community/meeting/minutes/2011/06.22

Kind Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinf

Re: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011

[Tommy Yu]

Thanks a lot, Tommy. I am clearly not a web service expert and therefore
assumed that the choice was between SOAP, REST and JSON. From what I now
understand (which may still not be right!), it would seem that the choice is
between SOAP and REST while regarding JSON it would, if anything, be a
choice between XML and JSON. So, in the end, it would seem that it might be
a choice between say SOAP+XML and REST+JSON. If that is the case, then
REST+JSON seems like a better choice for PMR2 indeed. Please feel free to
correct me if I am still missing something...



Hi Alan,

Essentially yes.  SOAP is basically a whole standard that revolves around 
exchanging data between services and its encoding method is basically XML, 
although it is possible to put JSON string inside the output but then that's 
just being silly, so yes, we might just end up going the route of REST+JSON 
over HTTP(S).

This sentiment is also shared by another developer here at the ABI who wants to 
interact with PMR2 via web services.

Regards,
Tommy.

P.S. I am no web service expert either, I just ended up doing a lot of 
reading/thinking/processing/mock-up some code to see where/how this might work.


Alan

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] cellml-discussion Digest, Vol 84, Issue 10

[Tommy Yu]

Maxwell Neal wrote:

Hi all - I was wondering - is there a webservice that would allow me
to programmatically download all the cellml models in the cellml
repository? Many thank,



Hi Maxwell,

Thank you for your interest in the CellML Model Repository.  While we currently 
don't have a formalized web service, we do provide a list of IDs to the 
workspaces (http://models.cellml.org/workspace) which can be found at 
http://models.cellml.org/workspace/list_txt.  Basically you can append the ids 
listed with the path.

To acquire the models, we recommend the usage of a Mercurial client, which can 
be acquired from http://mercurial.selenic.com/.  You can then use some kind of 
shell scripting to loop through that list and clone each workspace onto your 
local machine.

This is an example shell script:

#!/bin/sh

WS_ROOT=https://models.cellml.org/workspace
LIST=list_txt
for WORKSPACE in `wget --no-check-certificate -q -O - $WS_ROOT/$LIST`; do
 if [ -d $WORKSPACE ]; then
   echo $WORKSPACE exists.  Checking updates.
   hg pull -R $WORKSPACE
   hg up -R $WORKSPACE -C
 else
   echo $WORKSPACE does not exist.  Cloning.
   hg clone $WS_ROOT/$WORKSPACE
 fi
done

Note this script will overwrite any local uncommitted changes.

Regards,
Tommy.


M

- Maxwell Neal

Post-doctoral researcher University of Washington mn...@uw.edu (206)
543-8769 -




On Jul 29, 2011, at 5:00 PM, cellml-discussion-requ...@cellml.org
wrote:

Send cellml-discussion mailing list submissions to 
cellml-discussion@cellml.org


To subscribe or unsubscribe via the World Wide Web, visit 
http://lists.cellml.org/mailman/listinfo/cellml-discussion or, via
email, send a message with subject or body 'help' to 
cellml-discussion-requ...@cellml.org


You can reach the person managing the list at 
cellml-discussion-ow...@cellml.org


When replying, please edit your Subject line so it is more specific
 than "Re: Contents of cellml-discussion digest..."


Today's Topics:

1. ABI CellML Meeting Minutes, 27th July, 2011 (Dougal Cowan)


--


Message: 1 Date: Fri, 29 Jul 2011 13:56:13 +1200 From: Dougal Cowan
 Subject: [cellml-discussion] ABI CellML
Meeting Minutes, 27th July, 2011 To: CellML Discussion List
 Message-ID:
<4e32133d.4080...@auckland.ac.nz> Content-Type: text/plain;
charset=ISO-8859-1; format=flowed

I have put the minutes from this week's meeting up at:

http://www.cellml.org/community/meeting/minutes/2011/07.27

Cheers, Dougal



--

___ cellml-discussion
mailing list cellml-discussion@cellml.org 
http://lists.cellml.org/mailman/listinfo/cellml-discussion



End of cellml-discussion Digest, Vol 84, Issue 10 
*


___ cellml-discussion
mailing list cellml-discussion@cellml.org 
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] CellML Model Repository now on PMR2 v0.4

[Tommy Yu]

Greetings,

The CellML Model Repository (http://models.cellml.org/) is now upgraded to the 
latest release of PMR2, v0.4.  Please file any issues you may find with this 
release at https://tracker.physiomeproject.org/show_bug.cgi?id=3071.


Notable features supported now includes:

General:

- Much code refactoring has been done to make PMR2 easier to extend.


In Workspaces:

- Customized renderer for various file types - images and other file types can 
now show up in-line in the standard file page.  This is achieved using the 
plugin system, which also allow other specific file renderers to be added 
directly to the workspace, thus potentially saving the time/effort required to 
create an exposure to generate the same view if more such dynamic views are 
built.
- Ability to browse embedded workspaces from the standard file browsers more 
easily as they are now listed on top of every directory listings if they are 
present.
- Storage backend generalized, allowing the possibility to support other 
version control systems or specialized storage engines.


In Exposures:

- CellML Mathematics view improved - CellML 1.1 models now have all their maths 
rendered as the generation process now uses CellML API instead of XSLT for the 
extraction.  Also, all modern browsers should be able to view the maths even 
without native MathML plugin/viewer as MathJAX[1] is used for the client side 
display.


[1] MathJAX - http://www.mathjax.org/

Regards,
Tommy. 
___

cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Scheduled CellML webservers upgrade on 2011-10-10 21:00-23:00 UTC

[Tommy Yu]

Greetings,

As the ABI ITS team are continuing the improvements of their infrastructure, 
they have scheduled the installation of puppet - a centralize management tool 
for servers.  This will occur between 11th Oct 2011 10am - 12am Auckland 
Daylight Time (or 2011-10-10 21:00-23:00 UTC).  As this is a software upgrade 
that is not directly related to the running of the websites, there should not 
be a visible downtime during this time.

The servers that will be affected are the main CellML website (www.cellml.org) 
and the model repository (models.cellml.org).

Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] cellml-discussion Digest, Vol 87, Issue 10

[Tommy Yu]

I should mention that the staging instance will not persist its data whenever I 
stage a new major feature. Please do not use it to keep your sole copy of any 
models.

Do push it to the main instance, and keep a copy on your system for peace of 
mind.


- Reply message -
From: "Randall Britten" 
Date: Thu, Nov 24, 2011 12:42
Subject: [cellml-discussion] cellml-discussion Digest, Vol 87, Issue 10
To: "CellML Discussion List" 

Hi

Probably the easiest way to get MATLAB code for CellML models that are in the 
CellML model repository if via the generated code link available for each 
exposed cellml model.  However, models.cellml.org uses a buggy version of the 
API, but this has already been fixed by Tommy, and is staged at 
http://50.18.64.32/ (see 
https://tracker.physiomeproject.org/show_bug.cgi?id=3078#c4 ).  This is due to 
be deployed to the live site in the within about a month.

So, if your model is in the repository, you should be able to get valid MATLAB 
code for it, and if not, just create an account for yourself on the staged 
instance, create a workspace, upload your model, and create an exposure (which 
will initially only be visible to you, i.e. you can keep it private if you 
want).

Regards,
Randall


> -Original Message-
> From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion-
> boun...@cellml.org] On Behalf Of Andrew Miller
> Sent: Tuesday, 25 October 2011 9:41 a.m.
> To: cellml-discussion@cellml.org
> Subject: Re: [cellml-discussion] cellml-discussion Digest, Vol 87, Issue 10
> 
> On 25/10/11 09:14, David Nickerson wrote:
> > Hi Maxwell,
> >
> > If you wrap the MathML into a CellML model/component, COR does a
> good
> > job generating Matlab. OpenCell should work as well. Actually, I think
> > OpenCell might be able to generate all the variables for you from the
> > equation, whereas in COR you might also have to create the variables
> > before it will let you export to Matlab.
> 
> To add to what David said, the CellML API includes a general facility
> for translating CellML into imperative languages, and a specific
> description of how to do this for MATLAB, and this was exposed in
> OpenCell.
> 
> There are a few problems with the generated MATLAB that have been
> found
> since the final release of OpenCell (which is no longer maintained in
> Auckland) that have been fixed in the API.
> 
> There is a program that comes with the API (and which exists purely for
> testing the API, rather than as a user friendly program) - if you build
> the CellML API from source code, you can run it as follows:
> 
> cd cellml-api
> ./testCeLEDS urlToModelHere ./CeLEDS/languages/MATLAB.xml
> 
> Hopefully OpenCOR, which is based on the CellML API, and being developed
> in Oxford, will expose this functionality in a user friendly way.
> 
> Best wishes,
> Andrew
> 
> >
> > Cheers,
> > David.
> >
> > On Tue, Oct 25, 2011 at 7:58 AM, Maxwell Neal
> wrote:
> >> Hi all,
> >>
> >> Does anyone know of a good java package for translating MathML into
> MATLAB?
> >> Many thanks,
> >>
> >> M
> >>
> >> -
> >> Maxwell Neal
> >>
> >> Post-doctoral researcher
> >> University of Washington
> >> mn...@uw.edu
> >> (206) 543-8769
> >> -
> >>
> >>
> >>
> >>
> >> On Oct 23, 2011, at 4:00 PM, cellml-discussion-requ...@cellml.org wrote:
> >>
> >>> Send cellml-discussion mailing list submissions to
> >>>cellml-discussion@cellml.org
> >>>
> >>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>http://lists.cellml.org/mailman/listinfo/cellml-discussion
> >>> or, via email, send a message with subject or body 'help' to
> >>>cellml-discussion-requ...@cellml.org
> >>>
> >>> You can reach the person managing the list at
> >>>cellml-discussion-ow...@cellml.org
> >>>
> >>> When replying, please edit your Subject line so it is more specific
> >>> than "Re: Contents of cellml-discussion digest..."
> >>>
> >>>
> >>> Today's Topics:
> >>>
> >>>1. Re: cellml-discussion Digest, Vol 87, Issue 9 (Maxwell Neal)
> >>>
> >>>
> >>> --
> >>>
> >>> Message: 1
> >>> Date: Sat, 22 Oct 2011 19:02:16 -0700
> >>> From: Maxwell Neal
> >>> Subject: Re: [cellml-discussion] cellml-discussion Digest, Vol 87,
> >>>Issue 9
> >>> To: cellml-discussion@cellml.org
> >>> Message-ID:<28198366-57CF-471F-8882-
> 34e73fc05...@u.washington.edu>
> >>> Content-Type: text/plain; charset=us-ascii
> >>>
> >>> Great. Thanks, Lucian and David.
> >>>
> >>> M
> >>>
> >>> -
> >>> Maxwell Neal
> >>>
> >>> Post-doctoral researcher
> >>> University of Washington
> >>> mn...@uw.edu
> >>> (206) 543-8769
> >>> -
> >>>
> >>>
> >>>
> >>>
> >>> On Oct 22, 2011, at 4:00 PM, cellml-discussion-requ...@cellml.org
> wrote:
> >>>
>  Send cellml-discussion mailing list submissions to
>    cellml-discussi

[cellml-discussion] CellML Model Repository upgraded to PMR2 v0.5

[Tommy Yu]

Hi,

The CellML model repository underwent a software upgrade and is now running 
PMR2 v0.5.  If you encountered any issues with this update please file a 
tracker item that blocks the following tracker item:

https://tracker.physiomeproject.org/show_bug.cgi?id=3211

New features that were added for this release includes more CellML specific 
searching (for models.cellml.org) and updated the CellML API to version 1.11.  
Some internal code changes were made also to support some future features.

Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML Model Repository upgraded to PMR2 v0.5

[Tommy Yu]

Hi,

There is a minor correction needed to my previous announcement.  The CellML API 
version I used was a specific snapshot of the CellML API some time after 1.10 
was released and not the 1.11, and that one fixed one of the MATLAB code 
generation issue.

Regards,
Tommy.


Tommy Yu wrote:

Hi,

The CellML model repository underwent a software upgrade and is now 
running PMR2 v0.5.  If you encountered any issues with this update 
please file a tracker item that blocks the following tracker item:


https://tracker.physiomeproject.org/show_bug.cgi?id=3211

New features that were added for this release includes more CellML 
specific searching (for models.cellml.org) and updated the CellML API to 
version 1.11.  Some internal code changes were made also to support some 
future features.

z
Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Upcoming server maintenance on www.cellml.org and models.cellml.org.

[Tommy Yu]

Hi,

There will be a brief outage following a software upgrade for the CellML 
website (www.cellml.org) and the model repository (models.cellml.org).  The 
outage is to be occur on 2012-03-25 between the hours of 18:30-20:00 UTC (or 
Monday morning 7:30am to 9:00am for the people in Auckland).  The length of the 
outage on each of the server is expected to last no longer than a few minutes.

Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Upcoming server maintenance on www.cellml.org and models.cellml.org.

[Tommy Yu]

Hi,

The server maintenance had been delayed to 2012-04-01 between the hours of 
19:30-21:00 UTC (or 2012-04-02 07:00-09:00 NZST).  The same set of services 
will be affected as stated.

Regards,
Tommy.

Tommy Yu wrote:

Hi,

There will be a brief outage following a software upgrade for the CellML 
website (www.cellml.org) and the model repository (models.cellml.org).  
The outage is to be occur on 2012-03-25 between the hours of 18:30-20:00 
UTC (or Monday morning 7:30am to 9:00am for the people in Auckland).  
The length of the outage on each of the server is expected to last no 
longer than a few minutes.


Regards,
Tommy.



___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Server maintenance

[Tommy Yu]

Hi,

There will be a brief outage following a software upgrade for the CellML 
website (www.cellml.org) and the model repository (models.cellml.org).  The 
outage is to be occur on 2012-04-29 between the hours of 18:30-20:00 UTC (or 
Monday morning 7:30am to 9:00am for the people in Auckland).  The length of the 
outage on each of the server is expected to last no longer than a few minutes.

As according to ITS, this one should actually happen as final approval have 
been granted; the maintenance windows previous announced was never used.

Regards,
Tommy. 
___

cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] PMR2 v0.6 staging

[Tommy Yu]

Hi,

PMR2 v0.6 is ready for release, but the final deployment is pending on final 
preparation and testing.  A snapshot of the data residing on 
models.physiomeproject.org (along with models.cellml.org) is taken and is 
staged with the production buildout profile at this location:

http://184.169.251.126/

All available data should have been properly migrated to the new layout (noted 
below).  If you find any issues, please report them at:

https://tracker.physiomeproject.org/show_bug.cgi?id=3417

Major/notable new features for PMR2 v0.6:

- Fork/pull from other workspaces and/or source repositories.  Users can 
specify a URI to fetch content from external repositories, such as other PMR2 
instances or even repositories hosted on Google Code or Bitbucket. If you can 
pull them, PMR2 can pull them (* on the main PMR2 instance, only http/https 
sources are supported due to outbound firewall settings at the host provided by 
UoA ITS).
- Exposure wizard- makes it much easier to create exposures.  This include 
features such as exposure import/export and better exposure rollover handling.
- Curation now file specific instead of exposure-wide, with better editor for 
them and ability for administrator to define curation flags (partial 
implementation only for administration side)
- CellML API updated to 1.11 final and make use of a cgrspy egg that is built 
for this PMR2 release (cgrspy-1.1pmr2), with support for CellML API 1.12 to be 
provided when that is released.
- Some major internal library changes that allow much easier implementation of 
views and their associated tests in PMR2.

Regards,
Tommy.



P.S. Detailed changelogs for packages developed as part of PMR2, which are 
included within docs/HISTORY.(txt|rst) of the listed module.

pmr2.app - the core of PMR2
===

0.6 - Released (2012-10-03)
---

Sixth major release of PMR2 Core, with major focus on user interfaces.

* Fork/Pull from other workspaces

  - This feature allows the forking/pulling of workspaces within PMR2,
and pulling data from external repositories of the same type.

* Exposure wizard

  - This replaces the exposure builder/file type selection with a more
streamlined interface.  This is constructed on top of the original
framework.
  - Migration to updated exposure file types.  This indicates to users
that the views specified have changed, and they are given a button
to activate at their leisure to convert their file over to enable
the usage of the new set of views defined for that file type.

* Exposure export/import, exposure rollover slight overhaul.

  - It is possible to export the exposure structure and import it into
another workspace on the same or different PMR2 instance (provided
that the same structure is supported).  This will lead into the
wizard.
  - Exposure rollover will display the exposure structure using the
wizard instead of recreating the entire structure right away.  This
redirection allows better error handling.
  - Error handling leveraged includes the notification of renamed or
missing files in the target commit for a given exposure, instead of
returning a server error message.

* Curation moved to pmr2.annotation.curation

  - This library now provides better curation facilities, such as
administration defined flags, with user-side selection widget to
assign those defined values to a curation annotation on a file.

* Documentation generation is now tracked by an annotation.

* Default exposure file type is provided, as it is now very difficult
  for end users to assign views manually to an exposure file.

* Internal changes and other bug fixes.

  - All page layout/wrapper from the plone.z3cform classes have been
removed as supporting this system has become quite a task when the
adapter based layout is possible.  If the correct browser class for
a view within PMR2 is correctly defined (which is by inheriting the
browser classes within PMR2), the only changes required will be the
removal of the warppers and then update the zcml to point to the
original unwrapped class.
  - The implementation for the vocabulary `pmr2.vocab.manifest` has
been corrected once more to return the listing of files of the
correct commit as specified by context (either through the object,
form or request).  This is achieved by using this vocab in the
conjunction with pmr2.app.workspace.schema.StorageFileChoice.

pmr2.annotation.curation  - curation module for PMR2 (NEW)
=

0.1 - Released (2012-10-03)
---

* Initial release of the curation annotation extension for PMR2.  Basic
  features provided are:

  - Foundation for the curation flag framework
  - Core curation master flags usable by curators.

cellml.pmr2 - CellML support for PMR2
=

0.5 - Released (2012-10-03)
---

[cellml-discussion] PMR2 v0.6 Released

[Tommy Yu]

Hi,

PMR2 v0.6 is now released and deployed on the production server, and so the 
CellML Model Repository is now up and running on this version.  Two minor 
issues were corrected, with the fixes applied to their respective packages.

Again, notable features for PMR2 v0.6 are:

- Fork/pull from other workspaces and/or source repositories.  Users can 
specify a URI to fetch content from external repositories, such as other PMR2 
instances or even repositories hosted on Google Code or Bitbucket. If you can 
pull them, PMR2 can pull them (* on the main PMR2 instance, only http/https 
sources are supported due to outbound firewall settings at the host provided by 
UoA ITS).
- Exposure wizard eases the process of exposure creation.  This include 
features such as exposure import/export and better exposure rollover handling.
- Curation now file specific instead of exposure-wide, with better editor for 
them and ability for administrator to define curation flags (partial 
implementation only for administration side)
- CellML API updated to 1.12 (latest snapshot as it contained some critical 
changes needed by PMR2) and make use of a cgrspy egg that is built for this 
PMR2 release (cgrspy-1.1pmr2).
- Some major internal library changes that allow much easier implementation of 
views and their associated tests in PMR2.

Regards,
Tommy.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion