Tommy Yu wrote:
David Nickerson wrote:
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
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
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
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.
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
Dear All,
Poul and I have looked at the discussion on this thread and to best
encompass the various suggestions we've decided to ask Tommy to do the
following:
1. Include both a category field with predefined terms (Tommy has this
in now) and an additional general 'key word' field. A model
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
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.
And then if other is taken out of this list of mandatory keywords you
can
I think that list is a good start for a top level set of terms. I
agree with Andre that other should not be a selectable term. I would
probably offer a primary keyword which forces a selection from the
current list of terms ('none of these') being one of the items, and
then a dynamic set of free
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
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,
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
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
Actually, I'd venture to say that the majority of them aren't models of
human biological systems. A lot of them are animal models or based on
experiments done in non-human cell lines (for example Xenopus oocytes
(frog) are commonplace for cell cycle experiments,) and there are also a
number of
A separate phylogeny attribute is probably also needed.
It is not clear whether all the models are meant to pertain to human
physiology. One example certainly does not: # Baylor, Hollingworth,
Chandler, 2002, 'Comparison of Simulated and Measured Calcium Sparks
in Intact Skeletal Muscle
So for example someone's trying to build a large model but the only
components (or data to build components) available are from non-matching
species? So the LFID (I looked it up but it went over my head) provides
a way we can do that which is more precise and flexible than simply
referring to NCBI
Some of those are subsets of others. You might want to generalise a
bit more and then fit some of the useful specifics into that. I would
be interested to see what you come up with.
cheers
Matt
On 6/6/07, James Lawson [EMAIL PROTECTED] wrote:
Hi folks,
Tommy is currently working on a sorting
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? And if so, I'm gonna further assume that there are
no issues
Hi
I agree with David, 'Multiscale' looks out of place because it is a
description of what kind of model it is, rather than what aspect of
biology/physiology is being modelled.
Edmund
David Nickerson wrote:
Would I be correct in assuming that these terms will be key words added
to the
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
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
On 6/6/07, David Nickerson [EMAIL PROTECTED] 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?
I would
And what are the consequences for a model not fitting into any of these
categories?
It has to fit somewhere, I don't think the list is easily determined
from the top down like this. I would prefer that keywords were added
for each model and then we look at the accumulation of terms post
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
I think you need to re-read my last email.
Ontologies are blessed lists at the most simple interpretation.
I don't care too much about different terms for the same thing at the
moment, the impetous should be to retrieve all the current keywords,
then 'bless the list and update the keywords and
One thing I have found useful in other taxonomy/keyword type web
interfaces (e.g., see drupal) is that when entering such keywords the
interface dynamically completes the terms and/or presents alternatives
based on what the user enters. I'd imagine such an interface would work
well at pulling
26 matches
Mail list logo
