CellML Discussion List

Text archives Help


[cellml-discussion] [team-cellml] corrections for the minutes


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] [team-cellml] corrections for the minutes
  • Date: Mon, 05 Mar 2007 19:28:27 +1300

David Nickerson wrote:
> Andrew Miller wrote:
>
>> David Nickerson wrote:
>>
>>> Just to note that the page for the website has been ready for a while
>>> now, it is only the programme which is not finalised and can't be until
>>> we know who can make it....and we are running out of time to promote the
>>> event...
>>>
>>>
>> Thanks for the correction.
>>
>> I have put an errata note after the relevant part of the minutes
>> explaining this.
>>
>
> Thanks Andrew. I have just adjusted your errata a bit to reflect what I
> meant. The web page for the workshop is ready to be made public its just
> waiting on an appropriate location to be made available on cellml.org.
> The programme is still a work in progress and it is hoped that once
> invitations have been sent and replies received we'll get that finalised
> pretty quick and make it available.
>
>
>>> Finally, just wondering if we could get an update (to the
>>> cellml-dissussion list?) on the work Tommy is doing with metadata and
>>> the repository and how it ties in to the CellML API?
>>>
>>>
>> The CellML API doesn't have a metadata API, but I hope that Tommy's work
>> can at least give us a structure for the API (unfortunately Tommy's work
>> is in Python, to match with Zope, which isn't a very good match for the
>> rest of the CellML API). Other than that, there is no relationship,
>> because Tommy's work uses Python RDF APIs.
>>
>
> What I was really after is whether Tommy is taking this chance in
> re-writing the metadata handling in the model repository to actually
> integrate the CellML API into the model repository product (PMR). ie,
> using the API to fetch the RDF from a model and then ensuring any
> changes in the metadata via the web interface are reflected in the
> actual CellML model.
I think that the metadata is just extracted using hand-written Python,
and then put back into the model at the end. This could be done using
the API, but it wouldn't gain a whole lot from it, until either the
repository either starts working with CellML models more than it does
now (it doesn't really touch any CellML at all), or the CellML API
provides a better metadata interface.
> Although is there any interface(s) in the API for
> changing the RDF contained in a model?
Yes:

interface RDFXMLDOMRepresentation : RDFRepresentation
{
/**
* A complete RDF/XML document (including a single top-level RDF:rdf
* element) as a DOM document. The document fetched is a copy of the RDF
* in the model (that is, it is not live). However, fetching the
attribute
* again will update to the latest data. Assigning this attribute to
* a new document (or a changed version of the previous document) will
* replace all the RDF in the model with the contents of the new
document.
*/
attribute dom::Document data;
};
#pragma terminal-interface

/**
* The RDF representation for type="http://www.cellml.org/RDFXML/string";
*/
interface RDFXMLStringRepresentation : RDFRepresentation
{
/**
* A complete RDF/XML document (including a single top-level RDF:rdf
* element) as a serialised string. The document fetched is a copy
of the RDF
* in the model (that is, it is not live). However, fetching the
attribute
* again will update to the latest data. Assigning this attribute to
* a new document (or a changed version of the previous document) will
* replace all the RDF in the model with the contents of the new
document.
*/
attribute wstring serialisedData;
};

> I would imagine that at the least
> this would result in a clearer definition of the repository requirements
> for the high level metadata interface Matt proposed a while ago - things
> like get/set publication(s), authors, modification history, etc...
>
Yes, that is what I meant by the statement you are replying to.
> From what you are describing this is almost what Tommy is working on,
> but doing it in Python code independent of the CellML API. The Python
> code may then be taken and incorporated into the API to provide the same
> functionality in a more generally usable package...have I got that right?
>
I'm not sure we can take the Python code itself (it would be messy to
put Python into the C++ API implementation), but at least the interfaces
can be reviewed and used, when Tommy is finished developing them.

Best regards,
Andrew





Archive powered by MHonArc 2.6.18.

Top of page