[cellml-discussion] PMR2 v0.6 staging
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] Server maintenance
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
Re: [cellml-discussion] Upcoming server maintenance on www.cellml.org and models.cellml.org.
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] Upcoming server maintenance on www.cellml.org and models.cellml.org.
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] CellML Model Repository upgraded to PMR2 v0.5
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] Scheduled CellML webservers upgrade on 2011-10-10 21:00-23:00 UTC
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] ABI CellML Meeting Minutes, 22nd June 2011
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:
?xml version=1.0 encoding=UTF-8?
SOAP-ENV:Envelope
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
SOAP-ENV:Body
get_title SOAP-ENC:root=1
/get_title
/SOAP-ENV:Body
/SOAP-ENV:Envelope
This is the response by the Zope SOAP library I added:
SOAP-ENV:Envelope
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;
SOAP-ENV:Header
/SOAP-ENV:Header
SOAP-ENV:Body
get_titleResponse
SOAP-ENC:arrayType=xsd:anyType[1] xsi:type=SOAP-ENC:Array
element id=ob2d7f20 xsi:type=xsd:stringWorkspaces/element
/get_titleResponse
/SOAP-ENV:Body
/SOAP-ENV:Envelope
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
SOAP-ENV:Envelope ...
...
Eoceb8bec
Eoced4c60 id=oced4c60 xsi:type=xsd:string
Per Pixel Lighting
/Eoced4c60
Eocedc260 id=ocedc260 xsi:type=xsd:string
http://localhost:8380/pmr/workspace/per_pixel_lighting
/Eocedc260
/Eoceb8bec
...
/SOAP-ENV:Envelope
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
Re: [cellml-discussion] CellML Website/Repository Maintenance
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] CellML Website/Repository Maintenance
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
[cellml-discussion] CellML Model Repository now running on PMR2 v0.3
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] Staging of PMR2 v0.3 rc1
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] PMR2 v0.2 has been released
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] Summary of PMR2 Prototype Discussions
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
Re: [cellml-discussion] PMR2 Prototype Public Demo Server
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
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] [Fwd: Re: little b - shared models built from reusable parts]
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 cellml-discussion@cellml.org 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 http://www.opensource.org/ language which allows scientists to build mathematical models http://en.wikipedia.org/wiki/Mathematical_model of complex systems. The initial focus is systems biology http://en.wikipedia.org/wiki/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 http://en.wikipedia.org/wiki/Differential_equation 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
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 http://www.opensource.org/ language which allows scientists to build mathematical models http://en.wikipedia.org/wiki/Mathematical_model of complex systems. The initial focus is systems biology http://en.wikipedia.org/wiki/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 http://en.wikipedia.org/wiki/Differential_equation 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
[cellml-discussion] Auckland CellML Group Meeting Minutes (2008-05-07)
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] Auckland CellML Group Meeting Minutes (2008-04-30)
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-02-13)
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-02-07)
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-01-09)
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 (20071121)
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
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 (2007-10-03)
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 minutes (2007-09-26)
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
Re: [cellml-discussion] Concerning the CellML Model Repository
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] model upload problems
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
[cellml-discussion] Concerning the CellML Model Repository
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
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 external to the model updated to the latest versions (even if
Re: [cellml-discussion] Concerning the CellML Model Repository
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] PMR categories
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). bqs:reference rdf:parseType=Resource dc:subject rdf:parseType=Resource bqs:subject_typekeyword/bqs:subject_type rdf:value rdf:Bag rdf:liventricular myocyte/rdf:li rdf:lielectrophysiological/rdf:li /rdf:Bag /rdf:value /dc:subject /bqs:reference 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: |bqs:reference rdf:parseType=Resource| | ||bqs:keyword| |||rdf:Seq| || rdf:liventricular myocyte/rdf:li rdf:lielectrophysiological/rdf:li |||||/rdf:Seq||| | ||/bqs:keyword| |||/bqs:reference| || 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-- rdf:Property rdf:about=amp;bqsns;subject_type rdfs:labelsubject type/rdfs:label rdfs:comment Defines the topic of a resource. /rdfs:comment rdfs:subPropertyOf rdf:resource=dcns;subject / rdfs:isDefinedBy rdf:resource=bqsns; / /rdf:Property !--Subject Type:Keyword-- rdf:Property rdf:about=bqsns;keyword rdfs:labelkeyword/rdfs:label rdfs:comment Defines the topic of a resource using keywords. /rdfs:comment rdfs:type rdf:resource=dcns;subject_type / rdfs:isDefinedBy rdf:resource=bqsns; / /rdf:Property | 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 (||amp;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
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). bqs:reference rdf:parseType=Resource dc:subject rdf:parseType=Resource bqs:subject_typekeyword/bqs:subject_type rdf:value rdf:Bag rdf:liventricular myocyte/rdf:li rdf:lielectrophysiological/rdf:li /rdf:Bag /rdf:value /dc:subject /bqs:reference 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: bqs:reference rdf:parseType=Resource bqs:keyword rdf:Seq rdf:liventricular myocyte/rdf:li rdf:lielectrophysiological/rdf:li /rdf:Seq /bqs:keyword /bqs:reference 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-- rdf:Property rdf:about=amp;bqsns;subject_type rdfs:labelsubject type/rdfs:label rdfs:comment Defines the topic of a resource. /rdfs:comment rdfs:subPropertyOf rdf:resource=dcns;subject / rdfs:isDefinedBy rdf:resource=bqsns; / /rdf:Property !--Subject Type:Keyword-- rdf:Property rdf:about=bqsns;keyword rdfs:labelkeyword/rdfs:label rdfs:comment Defines the topic of a resource using keywords. /rdfs:comment rdfs:type rdf:resource=dcns;subject_type / rdfs:isDefinedBy rdf:resource=bqsns; / /rdf:Property 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 (amp;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
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(s) -- bqs:reference rdf:parseType=Resource dc:subject rdf:parseType=Resource bqs:subject_typekeyword/bqs:subject_type rdf:value rdf:Bag rdf:liventricular myocyte/rdf:li rdf:lielectrophysiological/rdf:li /rdf:Bag /rdf:value /dc:subject /bqs:reference 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 convince you that it isn't. 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
Re: [cellml-discussion] PMR categories
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(s) -- bqs:reference rdf:parseType=Resource dc:subject rdf:parseType=Resource bqs:subject_typekeyword/bqs:subject_type rdf:value rdf:Bag rdf:liventricular myocyte/rdf:li rdf:lielectrophysiological/rdf:li /rdf:Bag /rdf:value /dc:subject /bqs:reference 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
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
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
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] initial feedback on new repository metadata tools
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 proper library that abstracts operations away to classes for
Re: [cellml-discussion] broken tabs on the repository pages
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
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] model variants(?): e.g. where multiple cell types are described by the same model in different files
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
[cellml-discussion] Adding an information page for each model category
-> [cellml-discussion] Adding an information page for each model category cellml-discussion -- Thread -- -- Date -- <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "000000"; //--> [cellml-discussion] Adding an information page for each model category Tommy Yu Reply via email to
