RE: [Obo-phenotype] Some proposed modifications to PATO

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

What about using the 'Q' to address either quality or quantity?
Anne

Anne E. Kwitek, Ph.D.
Assoc Professor of Physiology
Human and Molecular Genetics Center
Medical College of Wisconsin
8701 Watertown Plank Road
Milwaukee, WI 53226
P: (414) 456-4346
F: (414) 456-6516

-----Original Message-----
From: obo...@li...
[mailto:obo...@li...] On Behalf Of Monte
Westerfield
Sent: Sunday, December 18, 2005 5:39 PM
To: chris mungall
Cc: obo...@li...
Subject: Re: [Obo-phenotype] Some proposed modifications to PATO

I think the ASAP changes look reasonable.

I just attended the NIH meeting with Mark Musen and Suzi.  During my =20
talk, where I presented sample annotations with EA (instead of EAV), =20
a few hackles were raised because the A of EA are "not really =20
attributes".  Does anyone have thoughts on this?  Do we need to =20
rethink the use of Qualities or some other word?

-Monte

On Dec 15, 2005, at 4:13 PM, chris mungall wrote:

> Some proposed changes to PATO
>
> Following on from the CSHL meeting, I have some suggestions for
> changes to PATO. I'm happy to pitch in and make changes myself.
>
> I have ordered these by proposed implementation time. "ASAP" can be
> done right away providing everyone consents; these should hopefully be
> uncontroversial. Phase 2 will wait until after George and I have
> discussed them (probably at the beginning of January), and phase 3
> some time after that.
>
> We should of course discuss any of these on this list, but traffic may
> be a bit slow at this time of year.
>
> Change JavaStyleNames to obo style names
> ----------------------------------------
>
> (I have a script to do this)
>
>  - spaces between words
>  - leading lower case on all words, including first
>
> For example, "electrolyte composition" rather than
> "ElectolyteComposition".
>
> Everyone at the cshl meeting was *unanimously* in favour of this!
>
> WHEN: ASAP. Should not affect annotation.
>
> Remove redundant "attribute" prefix and "value" suffix from names
> -----------------------------------------------------------------
>
> (my script also does this)
>
> For example "electrolyte composition" rather than
> "attributeElectrolyteComposition"
>
> this will result in duplicates, see below
>
> WHEN: ASAP. Should not affect annotation.
>
> Remove pointless duplicates
> ---------------------------
>
> there are terms that are duplicated, once as "attribute" and once as
> "value". These must be merged.
>
> For example:
>
>  PATO:0000310 "ColorValue" and PATO:0000014 "attributeColor" would be
>  merged to create a single attribute:
>
>  PATO:0000014 "color"
>
> WHEN: ASAP. Should not affect annotation.
>
> Top-level division
> ------------------
>
> First, get rid of PATO:0000000 "pato". This is not a term desribing an
> attribute. We are suggesting that all these fake roots are removed
> from all OBO ontologies.
>
> Second, I propose a top level split between "quality" and =20
> "quantifier".
>
> Most of what we are calling attributes are qualities (and are thus
> things that inhere in entities). The quantifiers such as "absent" and
> "supernumery" are useful from an annotation standpoint but problematic
> from the point of view of creating definitions and an is_a hierarchy.
> Introducing this division at the top level is a good compromise.
>
> Thus we would have:
>
>  PATO:0000001  "attribute"
>     PATO:0000914 "quality"
>     PATO:new001  "quantifier"
>
> For the more formally inclined among us, the actual ontology starts at
> "quality". "quantifier" is a small terminology of count operations.
>
> WHEN: phase 2. Should not affect annotation.
>
> Removal of non-qualities
> ------------------------
>
> These terms and everything below must be removed:
>
> - substance    (use ChEBI instead)
> - function     (use GO instead)
> - activity
>
> Some other terms are problematic and I would argue should be removed
>
> - count (children moved to quantatitive)
> - qualitative
> - deviation (from_normal)
>
> WHEN: phase 2. May affect annotation?
>
> Commencement of definitions
> ---------------------------
>
> PATO is lacking definitions
>
> New definitions are woth adding ASAP, but it may be better to focus
> energies on the above issues first (so we don't waste time defining
> terms that will be removed).
>
> My proposal would be to start at the top of the
> hierarchy and work down breadth-first; at the same time working with
> annotators to add definitions for terms as they are used in new
> annotations.
>
> Definitions should as far as possible be specified in terms of
> instances instantiated by the quality classes. The definitions =20
> should reflect
> the is_a hierarchy, which each definition refining its is_a
> parent. [more on what this actually means later - see the talk i =20
> presented at cshl for now]
>
> Providing definitions may be done in concert with hierarchy
> changes, see below
>
> WHEN: phase 2, ongoing. All annotations that used a term before being
> defined should be checked. New annotations should have definitions for
> all terms used. This may slow annotation a little at first.
>
> Univocity of values
> -------------------
>
> (this wasn't mentioned explicitly at the meeting, but this was an =20
> error of omission on my part)
>
> The terms in the "value" part of PATO should only mean one
> thing. Right now a mix-and-match approach can be used, with some
> values applicable to different attributes with the meaning changing =20
> subtly based on the context.
>
> For example, "irregular" means different things when applied to shape
> and frequency. I propose two separate value terms here.
>
> If values can be made univocal, then EAV becomes redundant and can be
> represented as just entity plus value without any loss of information.
>
> Univocity is worth pursuing in its own right, regardless of whether we
> switch EAV to EA.
>
> WHEN: phase 3. May affect annotation - conversion to new univocal =20
> terms
> should be automatable
>
> Mark monadic vs relational attributes
> -------------------------------------
>
> For relational attributes such as "sensitivity", indicate in the obo
> file that these are relational (the default is monadic).
>
> We can then remove the various cross-products (eg
> "soil composition sensitivity"), although it may be desirable to
> retain these with appropriate logical definitions.
>
> WHEN: phase 3. May affect annotation?
>
> Hierarchical reorganisation
> ---------------------------
>
> I would like to propose a hierarchical reorganisation of PATO to make
> it more ontologically sound, faster to search, and to ensure that the
> is_a hierarchy is reflected in the definitions. We also have to =20
> prepared for
> an influx of new qualities as people start to annotate, so a =20
> rational is_a tree
> is a must
>
> Details to follow...
>
> One idea would be to group qualities by the level of granularity of
> the entities in which they inhere . Another is to cleanly separate
> process qualities from qualities that inhere in 3D objects.
>
> WHEN: phase 3, ongoing. Should not in general affect annotations, but
> will affect the annotation process, as annotators will expect a tree
> structure that is both intuitive to navigate and stable. We don't =20
> want to have unnecessary churn
> in the tree for this reason.
>
> --
> Chris
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =20
> SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Obo-phenotype mailing list
> Obo...@li...
> https://lists.sourceforge.net/lists/listinfo/obo-phenotype

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
_______________________________________________
Obo-phenotype mailing list
Obo...@li...
https://lists.sourceforge.net/lists/listinfo/obo-phenotype