Re: [cellml-discussion] UnitsML
Hi Jonathan, Presumably you are referring to the Units Ontology and not ontologies in general? The Units Ontology appears to be mainly a controlled vocabulary with no formal definition of relationships between units (and IMHO, in need of some work, as e.g. microgram per kilogram per day is not dimensionless). An ontology can be used to define classes and properties to allow for units conversion and to provide a mechanism for user defined units; I've created such an ontology as proof-of-concept; next is Python code to map RDF descriptions into CellML Canonical Unit Representations. I agree 100% to only having a single way of specifying and defining units. How about standard URIs backed by ReSTful web services that return both RDF descriptions (from an ontology) and UnitsML (and for that matter, [CellML, SBML, ...]) descriptions? Behind the scenes there would a single master definition with mappings to different representations. On the metadata side I envisage a reasoning system to resolve owl:sameAs and similar equivalences. A web service could also be used as a source of definitions for units checking and conversion libraries. Best regards, Dave On 28/09/11 10:41 PM, Jonathan Cooper wrote: Hi Bernard, I have thought about this a little. The biggest problem with using an ontology is that there doesn't seem to be any possibility of a mechanism for allowing user-defined units. The units ontology at present also doesn't appear to contain enough information to perform units conversions. It would certainly be beneficial to have a single units language across all COMBINE standards. Given that the SBML world has considered CellML's units to be too complicated, I'm not sure what they'd think of UnitsML! But producing our own version of such a standard does seem rather foolish. I wonder if there's scope for a 'lite' version of UnitsML that could be incorporated? From the very brief look I had, UnitsML does seem pretty comprehensive. I wasn't too enamoured of their approach to defining conversions though - you ought in most cases to be able to deduce appropriate conversions from the units definition, so it may be that they're lacking detail there. Best wishes, Jonathan On 28/09/11 10:34, Bernard de Bono wrote: Hi, Is, alternatively, the use of an ontology for units also a consideration? Terms from such an ontology could be applied to the annotation of semantic metadata associated both with (i) model variables, as well as (ii) related datasets. Thoughts most welcome. All the best, Bernard On 28 September 2011 09:49, Steve McKeever steve.mckee...@cs.ox.ac.uk mailto:steve.mckee...@cs.ox.ac.uk wrote: Hi, Only had a quick read through but it looks good, perhaps a bit too comprehensive for CellML and FieldML. Hard to tell if it will become *the* standard for units though. Steve On 27 Sep 2011, at 01:04, David Brooks wrote: Hi, I've come across the Units Markup Language (UnitsML, http://unitsml.nist.gov/), which is a project of the National Institute of Standards and Technology for encoding scientific units of measure in XML. It is currently being standardised by OASIS (the Working Draft is at http://www.oasis-open.org/committees/download.php/42538/UnitsML-Guide-v1.0-wd01.pdf). Should UnitsML be embedded in a future version of CellML? In FieldML? To become the preferred way to specify units in the various MLs?? Regards, Dave ___ cellml-discussion mailing list cellml-discussion@cellml.org mailto:cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org mailto: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] UnitsML
Hi, I've come across the Units Markup Language (UnitsML, http://unitsml.nist.gov/), which is a project of the National Institute of Standards and Technology for encoding scientific units of measure in XML. It is currently being standardised by OASIS (the Working Draft is at http://www.oasis-open.org/committees/download.php/42538/UnitsML-Guide-v1.0-wd01.pdf). Should UnitsML be embedded in a future version of CellML? In FieldML? To become the preferred way to specify units in the various MLs?? Regards, Dave ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] ABI CellML Meeting Minutes, 21st April 2010
DSL = Domain Specific Language. An internal DSL is one used directly in your source code, as opposed to reading and parsing sources from an external file. See http://www.scala-lang.org/node/1403 for an example (esp. for BASIC fans...). A DSL for menu building that could be used to say describe the CellML web site might look something like: Menu(Home) / index, Menu(About CellML) / about submenus ( Menu(Contact us) / about / contact, Menu(Featured articles) / about / featured, Menu(CellML scope) / about / scope, Menu(Current development) / about / current-development, Menu(Funding sources) / about / funding, Menu(CellML publications) / about / publications ), Menu(Getting started) / getting-started submenus ( ... ), Regards, Dave - What are internal DSLs? ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Announcement of OpenCell 0.7rc1
Yeah, great! All part of having a professional and world class system! Thanks, Dave On 29/01/10 8:02 AM, Dougal Cowan wrote: On 28/01/2010 12:00, David Brooks wrote: A small thing, but what about improving the resolution of the icon used for OpenCell? Compare OpenCell's icon with that of other applications in the attached screen image. I am attaching a set of PNGs: these are just higher resolution renders of the icon I made for the complete model structure tree view. For the time being, you can just replace the icon with one of these in order to make things (just a bit) less unsightly. Hopefully we can replace the rather prehistoric looking app icon at some point! Dougal ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Announcement of OpenCell 0.7rc1
And ditto for the OS/X version -- it needs to be a .dmg Thanks, Dave On 28/01/10 8:10 AM, Michael Cooling wrote: ...similar minor issue with the Windows version, had to add '.exe' to the file (and it was called something like 'installer-binary'). Quoting Alan Garny alan.ga...@dpag.ox.ac.uk: I believe there is something wrong with the filename of the Linux version of OpenCell 0.7RC1, but only for the one available from http://www.cellml.org/tools/downloads/opencell/releases/0.7rc1, since the one from http://sourceforge.net/projects/cellml-opencell/files/ is fine. Indeed, the filename is x86-linux-bzip2-compressed-binary-tarball, which confuses Ubuntu's archive manager. To add .tar.bz2 to the filename 'fixes' things though. Alan -Original Message- From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion- boun...@cellml.org] On Behalf Of Justin Marsh Sent: 27 January 2010 09:20 To: CellML Discussion List Subject: [cellml-discussion] Announcement of OpenCell 0.7rc1 Hi all, The first release candidate for OpenCell version 0.7 has been released. More information, and the released files themselves, are available at http://www.cellml.org/tools/downloads/opencell/releases/0.7rc1 or alternatively, from SouceForge at https://sourceforge.net/projects/cellml-opencell/files/ A release candidate will become a release one week from announcement on this list if there are no problems identified with it. Please report any bugs you find at https://tracker.physiomeproject.org/, or to this list, or directly to j.ma...@auckland.ac.nz Best regards, Justin Marsh. ___ 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 This message was sent using IMP, the Internet Messaging Program. ___ 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] Announcement of OpenCell 0.7rc1
A small thing, but what about improving the resolution of the icon used for OpenCell? Compare OpenCell's icon with that of other applications in the attached screen image. Ta. On 28/01/10 11:43 AM, David Brooks wrote: And ditto for the OS/X version -- it needs to be a .dmg attachment: Opencell-Finder.png___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML leadership structures
On 23/1/09 11:38 AM, James Lawson wrote: Hi all, We're bouncing around some ideas about how we might structure the decision making process within the CellML community. Ideally, we want to make it as transparent as possible and have some kind of executive group that reports directly to the community via a fair, democratic process. I've drafted a document that outlines some of the ideas we've talked about in the Auckland CellML meetings. There are a few holes in it that we need to patch up - namely, how the actual voting system might work. Please let me know what you think. Kind regards, James So far as a voting system goes, what about the one used by the Apache Software Foundation? See http://www.apache.org/foundation/how-it-works.html *Decision Making* Projects are normally auto governing and driven by the people who volunteer for the job. This is sometimes referred to as do-ocracy -- power of those who do. This functions well for most cases. When coordination is required, decisions are taken with a lazy consensus approach: a few positive votes with no negative vote is enough to get going. Voting is done with numbers: * +1 -- a positive vote * 0 -- abstain, have no opinion * -1 -- a negative vote The rules require that a negative vote includes an alternative proposal or a detailed explanation of the reasons for the negative vote. The community then tries to gather consensus on an alternative proposal that resolves the issue. In the great majority of cases, the concerns leading to the negative vote can be addressed. This process is called consensus gathering and we consider it a very important indication of a healthy community. Regards, Dave ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Auto-generate HDF5 from CellML?
On 13/11/08 2:38 AM, Jon Olav Vik wrote: David Nickerson [EMAIL PROTECTED] writes: As a side note, I am envisioning that in the long term such simulation data would ideally be stored using FieldML (http://www.fieldml.org) which underneath is likely to provide several options for the high performance persistent storage (with HDF5 being one of the options that crops up quite frequently). Unfortunately, I'm unsure what sort of time frame a fieldML based solution might become available... To me, HDF5 looks like a fairly round wheel, which I'd be happy to use while FieldML decides whether to invent its own. One feature that would often be useful is parallel writing, for instance for trivially parallel simulation of multiple parameter scenarios, writing results for one scenario without blocking output from the others. HDF5 has this (http:// www.hdfgroup.org/HDF5/PHDF5/) but e.g. the Python interface (www.pytables.org) does not yet support it. Although PyTables provides an easy to use and efficient interface between Python and HDF5 files, it also imposes it's own metadata model on HDF5 files. If a general HDF5 solution, able to be used with PyTables, were to be designed to hold CellML simulation results then the HDF5 structure would have to allow for PyTable specific groups. Another approach would be to specify a generic HDF5 framework for CellML simulations and to implement this layer in C/C++, and then, if using Python, access it via a possible PyCellML wrapper (which could also provide access to the CellML API). Regards, Dave Brooks ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Representing the next version of the CellML Specification
Hi Andrew, My vote is for DocBook - I used it a few years ago for a software manual without too many issues, and the tools have matured since then. Keep away from anything DSSSL based (including the DSSSL flavour of DocBook), otherwise we will create a dependency on needing a Lisp expert to sort out the stylesheets. Another option would be to have our own simple XML markup language along with XSLT that produces DocBook (I know nothing about CWML - is it XML based? Can it be transformed into DocBook?) Regards, Dave On 7/11/2007 2:16 p.m., Andrew Miller wrote: Hi, One issue which came up at today's meeting for people at Auckland involved with CellML is how we will represent the next version of the CellML specification. Having a 'source' format of the specification will make it easier for us to propose specific changes to the document and so will hopefully allow us to make progress towards the next version of CellML. There are a few different options out there which might be worth exploring. Any feedback from the wider CellML community on the issue of how we represent the 'source' of the specification which gets exchanged would be very helpful, and after the close of discussions we will be able to start preparing draft versions with proposed changes much more easily. I have identified a few possible choices, and have included my views on what potential benefits or pitfalls of different approaches will be: 1) Use HTML as is currently stored in the Plone Software Centre. Pros: * The source format can be directly visualised in the user's browser, which reduces the complexity of the required development environment. * WYSIWYG type editing possible (although the cleanness and consistency of such editors' output may be an issue). * We already have the document in this format which we could use as a starting point. Cons: * No automatic ability to generate section references by number based on a reference by name in the source. * Sophistication of automatic numbering limited to single uninterrupted numbered lists with possible manual restarts if there is intervening text. * Diffs between different HTML versions are hard to read. * Even if CSS is used, there will inevitably be some mixing of style and content, which makes it harder to make sweeping changes to the layout, and makes it harder to create good quality PDF / RTF / plain text outputs. 2) Use reStructured text. Pros: * The unrendered reStructured format is quite readable, which means that it is easy to learn by example, and also that diffs are more readable. * Easy to set reasonable and consistent style guidelines for writing the specification in the reST source. * Reasonable tool support, including in Trac and in ZWiki. * Could convert to several types of output. Cons: * No section references by number based on reference by name in the source. * No automatic numbering aside from numbered lists (e.g. no counters). * No easy way relate specific elements to specific style instructions if we need to do this. 3) Use Warren's CWML language Pros: * We already have the document in this format which we could use as a starting point. * Reasonably clean markup in terms of header, section, and so on. * Supports section references by name, which come out as references by number. * Can generate multiple output types. * Embedded MathML equations can be used. Cons: * Non-standard. * Warren's tools are out of date and need to be updated to be useful for the current CellML site - potentially a large time investment. * Need to manually create contents sections and the like as it is at the moment. 4) Modify the W3C DSSSL based tools (see http://www.w3.org/XML/1998/06/xmlspec-report-v21) used for their specifications. Pros: * Allows for section references and generation of full specification structure. * Supports a lot of specification type metadata and concepts, and will therefore delimit everything in specification very thoroughly. * Used by the W3C for a large number of specifications, so reasonably well field tested. Cons: * Potentially hard to read diffs if they change lots of sections and therefore include parts of the markup. * We will need to make some changes to make it non-W3C specific. 5) Use DocBook Pros: * DocBook widely implemented - lots of tools, several output formats. * Lots of semantic markup elements for a lot of different types of data. * Automated section numbering and content page references. * Content page generation * With the MathML extension module, embedded MathML can be used - I'm not sure how well this works in practice Cons: * Potentially hard to read diffs
Re: [cellml-discussion] 'CAVEman' the future of medicine
Their home page is at http://www.visualgenomics.ca/index.php?option=com_frontpageItemid=1 Dave On 30/05/2007 11:53 a.m., James Lawson wrote: Hey folks, Thought you might be interested in this. I really don't know how far they've actually got but they're certainly making some pretty impressive claims. http://www.cosmosmagazine.com/node/1351 'Caveman' the future of medicine OTTAWA: The world's first virtual computer model of a human body has been created, translating a litany of complex medical and genomic data into 4D images to test drugs and surgical techniques. The virtual man has his skin and skeleton removed to display every vein, artery and organ, and consists of more than 3,000 body parts projected from the walls and floor. -James ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
