Chronological Thread 

< Chronological >      < Thread >

---

Hi Randall,

Some initial feedback follows, broken into the sections in your document.
I'm not sure how to comment on github and I don't think we should be
submitting issues under the CellML organisation at this early stage of
drafting of the object model.

Cheers,
Andre.


Introduction

Restricting this high level conceptual design to just one use-case seems a
bit too limited. Makes more sense to me if you consider a range of
potential use-cases tool developers might need - those described in the
roadmap are just designed to limit the scope of the implementation, not the
object model design.

Overview of object model

Consistency in the interfaces would probably be useful - its not clear, for
example, why a unit has a definingModel whereas a component has a model?
perhaps just my lack of UML skills. Also, in CellML it should be a units
class not unit. And the cardinality of the Maths class should be [*] rather
than [1].

It might be useful to have a common base class for all the objects in which
to define attributes common to all objects - such as the ID property.

Model class

A method like getXML seems the wrong approach to me. It would make mode
sense to have some kind of IO configuration class and then providing a more
generic serialisation/deserialisation set of methods. Obviously
implementation would focus on XML serialisation to begin with, but you'd
imagine JSON or RDF based methods being required in the near future.

Having a addImport method on the model class also seems the wrong approach
to me. In CellML you are either importing a component or a units
definition, so to me it has always made more sense to simply create those
imported components or units directly. Possibly having a collection of them
if you need to import a bunch of components and/or units from a single
instance of an imported model?

Details for variable object model

I can't recall why real and boolean variables are needed in CellML 1.2. A
link to the tracker item discussing this would be most appreciated.
Similarly for a definition of what is meant by codomain in this context.
Also, the use of the variable of integration is a bit too specific to
ODE-type models, might be more useful to talk about independent/dependent
variables?

It would be good to make use of the same term regarding a
collection/list/set. I don't have any particular preference for which is
used but collection seems to be the dominant term in this document. Also,
there are a few ")" missing in this section.

I'm not understanding what you mean by "normalised at this conceptual
level" - some more explanation or clarification would be useful.

Encapsulation

This seems reasonable to me at this stage.

Units of measure

As above, the main class should be "Units" rather than "Unit" (i.e., in
CellML we define units for use in variable definitions and numerical
constants in the math, and a units definition consists of a collection of
units references.


Imports

Imported units appear to be missing completely from this document?

Its not clear why you are not using names from the CellML data model?
remoteName seems imply a lot more meaning that is intended (it is in fact
very rare, and against best practice, to import components from an actual
remote model). I'd simply go with componentRef or something like that, as
per the CellML standard. Similarly, href or xlinkHref rather than URL, as I
don't think there is any restriction that the href locator must be a URL.

Todo

I'd be very wary about adding any documentation to the Papyrus model unless
you have a clear way to get it into future revisions of this document or
the actual C++ code. The Papyrus model is just an intermediary format that
you are using to produce the diagrams and eventually the C++ code that are
what we will actually be discussing and using.



On Wed, Aug 27, 2014 at 4:45 PM, Randall Britten
<r.britten AT auckland.ac.nz>
wrote:

> Hi all
>
> The libCellML project aims to provide a library for working with CellML,
> focussed on CellML 1.2, but with limited support for older formats (i.e.
> CellML 1.0 and 1.1). Please see
> http://libcellml-fork-01-for-previewing.readthedocs.org/en/latest/projectIntro.html
> (temporary
> location) for a bit more info.
>
> We decided that 2 days would be spent to create a UML (or "UML-esque")
> representation of thoughts on the object model for libCellML, as a starting
> point for community discussion.
>
> I have presented this work at
> http://libcellml-fork-01-for-previewing.readthedocs.org/en/latest/objectModel.html
> or
>
> https://github.com/codecurve/libcellml/blob/uml01/docs/source/objectModel.rst
>
> Please provide your feedback by commenting on GitHub, or creating GitHub
> issues (https://github.com/cellml/libcellml/issues), or e-mailing this
> list, or e-mailing me, whichever is your preference. Note that I will only
> be collating and responding to feedback after 3 September, due to the
> project planning. We would like as much feedback from the community as
> possible during this project.
>
> Regards,
>
> Randall Britten
>
> ______________________________________________
>
> Bioengineering Software Development Specialist
>
> Auckland Bioengineering Institute
>
> University of Auckland
>
> Auckland, New Zealand
>
> www.abi.auckland.ac.nz
>
>


--

[image: David Nickerson on about.me]

David Nickerson
about.me/david.nickerson
<http://about.me/david.nickerson>

---

• [[cellml-dev] ] Introducing the libCellML project, Randall Britten, 08/27/2014
  • Re: [[cellml-dev] ] Introducing the libCellML project, David Nickerson, 08/27/2014

---

Archive powered by MHonArc 2.6.18.