[Open-bio-l] RE: [BioSQL-l] Ontology names

[hz5@njit.edu]

Question:

GENE ONTOLOGYTM CONSORTIUM(http://www.geneontology.org/) has a whole system set 
up in 3 category: cellular components, biological process, and molecular 
function. Is the ontology term/name talked here same concept as those?

Haibo


Quoting Hilmar Lapp <hlapp@gnf.org>:

> Your points are well taken, and I agree with most of them. But given our
> domain of expertise here and our schedule, I just don't feel we should
> take a lead here, where we is referring to our local group, not the
> audience of the mailing list.
> 
> OTOH we're kind of taking a lead already because we need to get it
> working somehow in a reasonable way ... So, yes, the category does mix
> different things together; I just took it from ChrisM's proposal, and
> the simple self-referencing FK does work for us for the time being (it
> shouldn't be hard to change it though). I also agree that Ontologies
> should reference a namespace with authority, which a simple term
> doesn't. Or could the category be regarded as the namespace?
> 
> As for the schema aspect of these ontologies, yes that's not at all
> dealt with right now. It's not exactly in the focal point of our use
> case here though, although I feel that ontology maps will hit us rather
> sooner than later (e.g., which tags denote a dbxref: db_xref, dbxref,
> DR, ...)
> 
> Sorry if this was confusing, I'm in a rush... bottom line is I'm glad if
> other people with more or less different use cases than ours weigh in
> with their requirements and proposals, and I'm happy to (help) make them
> all work together if there is a reasonable way.
> 
> 	-hilmar
> 
> > -----Original Message-----
> > From: Thomas Down [mailto:td2@sanger.ac.uk]
> > Sent: Monday, September 30, 2002 2:46 AM
> > To: Hilmar Lapp
> > Cc: Biosql; David Block; OBDA
> > Subject: Re: [BioSQL-l] Ontology names
> > 
> > 
> > On Fri, Sep 27, 2002 at 11:52:56AM -0700, Hilmar Lapp wrote:
> > >
> > > Ontology names will likely (but are not required to) have NULL in 
> > > category_id.
> > > 
> > > Is everyone OK with this so far?
> > > 
> > > In order to get things out by a Bio* package other than the 
> > one that 
> > > put it in, we need to agree on ontology names in the first place 
> > > (but also on terms).
> > > 
> > > I am right now using the following ontology names:
> > > 
> > > - 'Annotation Tags': the keys (tags, qualifier names) for simple 
> > > annotation values (qualifier values)
> > > - 'SeqFeature Keys': the keys of seqfeatures ($feat->primary_tag()
> 
> > > slot in bioperl; e.g., the genbank feature key, or 
> > swissprot feature 
> > > key, like 'CDS', 'mRNA', ...)
> > > - 'SeqFeature Sources': the source names of seqfeatures 
> > > ($feat->source_tag() slot in bioperl; like 'swissprot', 'genscan',
> 
> > > etc).
> > > 
> > > There is already a pre-defined number of terms for location 
> > > properties (min_start, etc), but without an ontology. I'd like to 
> > > put them into an ontology and suggest the name 'Location Tags' for
> 
> > > it.
> > 
> > Sorry to reply a bit late to this thread -- I've been having
> > a few problems with e-mails to and from these mailing lists
> > (probably DNS-related, and seem to be sorted out now).
> > 
> > Anyway, to me this all feels like it's trying to mix together
> > several different concepts.  Many (though by no means all)
> > ontology_terms are really defining properties of objects.
> > The keys used in seqfeature_qualifier_value are a very good
> > example of this.  Similarly the location qualifiers.
> > 
> > Looking specifically at properties, they can be defined by:
> > 
> >   - Their domain -- the class (or classes) of object to which
> >     they apply.
> > 
> >   - Their range -- the set of values which are allowed.
> > 
> >   - Their cardinality -- e.g, 0..1, exactly 1, 0..infinity
> > 
> > The domain might just be `seqfeature' or `seqfeature_location'.
> > But the interesting cases come when you set more restrictive
> > domains (say, "A feature of type SNP must have one or more
> > variants").  A more mundane application might be to define
> > the required set of qualifiers for a given feature type in
> > an EMBL feature table./
> > 
> > We're now taking ontology_terms somewhat beyond being a simple
> > controlled vocabulary, and into schema-land.  I don't know what
> > people's feelings are on this.  My understanding is that the
> > original plan with ontology_term was to leave it totally opaque,
> > then join on some extra tables which included relationship/schema
> > information.
> > 
> > As I understand it (please correct me if I've got the wrong
> > end of this), the `category' concept seems to be trying to
> > mix up aspects of property domains (for ontology_terms which
> > define names of properties) and propery ranges (for terms which
> > are used as values -- e.g. seqfeature_key).  Is this actually
> > a sensible thing to do?
> > 
> > 
> > Hilmar: I know you're on a tight schedule with this.  If adding
> > a category field solves your problem, today, then go for it.
> > However, it might be better to put this on a separate table,
> > for ease of untangling stuff in the future (it also avoids having
> > an FK to self, although you still get a circular reference, of
> > course).
> > 
> >      Thomas.
> > 
> > 
> > PS. The way I've discussed properties here is very DAML-esque.
> >     At some point in the past, I remember a dicussion about doing
> >     DAML definitions for the open-bio datamodels.  Did this
> >     ever get off the ground?
> > 
> _______________________________________________
> Open-Bio-l mailing list
> Open-Bio-l@open-bio.org
> http://open-bio.org/mailman/listinfo/open-bio-l
> 



=========================================================
Haibo Zhang, PhD student
Computational Biology, NJIT & Rutgers University
Center for Applied Genomics, PHRI
http://afs13.njit.edu/~hz5