CellML Discussion List

Text archives Help


[cellml-discussion] Suggestions regarding search and browse utility for CellML Repository


Chronological Thread 
  • From: j.lawson at auckland.ac.nz (James Lawson)
  • Subject: [cellml-discussion] Suggestions regarding search and browse utility for CellML Repository
  • Date: Thu, 01 May 2008 14:04:32 +1200

Hi Abhishek,

Good to hear from you, you make some very good points. I apologise if
someone has already raised these points, I've just come back after being
away for a couple of weeks and I'm going through my many unanswered emails.

So at the moment, one of the things I am thinking a lot about is
ontological annotation of CellML models. I've just been to visit Neil
Wipat's lab at the University of Newcastle, and I talked quite a lot
with him and members of his group about ontologies and how they might be
of use to the CellML community. So one of the things that the new CellML
repository will handle much better than the current one is the manner in
which a user can view models and their interrelationships, whether these
are based directly on CellML relationships such as import based
modularity or whether they are based on relationships inferred from
ontological tags.

I'll definitely have a look at MeSH - what we're planning to do (I
believe) is let the CellML-Bio Ontology import as much as possible from
other ontologies, and let Sarala's ontological framework stand as our
contribution. Where we conclude that there is no ontology that covers
what we are trying to do in a satisfactory manner, we'll create our own.
I can see this happening in the area of synthetic biology, which is only
just starting to be represented by formats like CellML and SBML. So a
tree-like browsing structure as constructed from MeSH tags or similar
could be one of a number of different ways of viewing the models. You
could also do searching by terms, or construct trees according to terms.
For example, you could have 'species' as the top level and 'organ' as a
lower level, and 'cell type' as the bottom. So then you'd get a tree
sorted first by species, then by organ type, say heart, pancreas, liver,
etc. and then by cell type, so within the heart: myocardium, epicardium,
etc. etc.

The possibilities for how we display fully tagged models are huge, so we
do need to form some kind of system of constraints - or at least provide
a set of default viewing architectures based on what workflows we
anticipate for users.

When we decompose models into modular elements, this kind of tagging is
going to be absolutely crucial for model reusability and for the process
of figuring out what module you want and where to get it.

As far as the technology for web services and programmatic access to the
repository database, that isn't something we've thought about much until
now, but on our travels Mike and I have realised that this is really
quite important. In fact, it was often one of the first questions I was
asked when I was discussing the CellML repository. A lot of people are
seeing the repository not simply as a database containing individual
models, but as an dataset in and of itself. We need to work on this -
I'm told Mike mentioned it at the Auckland CellML meeting last week.

Hope you found this of some interest,
James

Abhishek Tiwari wrote:
> As growing no of models in CellML repository I feel that CellML
> Repository can be made more user friendly by implementing one or more
> suggestions mentioned below-
> 1. A Tree like browsing mechanism in which end child node of tree will
> have model. For that we need to have classification system for the
> models based on Physiological system or better say using MeSH (Medical
> Subject Headings,something like
> http://www.nlm.nih.gov/cgi/mesh/2008/MB_cgi). Models can be in multiple
> classes and basically model metadata can have details for the
> classification purpose like keywords. Domain ontologies can be used to
> give better description for tree like representation.
> 2. For a given model at the end of overview similar models (basic or
> improved models or more complex models) can be reported (Similar to
> model variants).
> 3. Web services to search and download CellMl models for non ABI tools (
> using CellMl API or Web API for CellMl).
>
> I don't know if efforts to handle above is under development or already
> exists so I thought to write you all.
>
> abhishek
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: j_lawson.vcf
Type: text/x-vcard
Size: 278 bytes
Desc: not available
Url :
http://www.cellml.org/pipermail/cellml-discussion/attachments/20080501/2fd313fe/attachment.vcf





Archive powered by MHonArc 2.6.18.

Top of page