Open Biomedical Ontologies

Hilmar

Thanks.  Yes I know about the TGN and yes the licensing issues are  
the blocker.
However, we are in touch with them and hope to have a meeting with  
them next
year to discuss the possibilities for collaboration.

We will get a page up - probably after our meeting in Banbury in two  
weeks,

Thanks for your interest,

Michael

On 2 Nov 2007, at 10:52, Hilmar Lapp wrote:

> Michael,
>
> pretty cool - is there a web-site somewhere for it, and/or a mailing
> list? The OBO website doesn't seem to turn up anything.
>
> As an aside, you may have seen the TGN (http://www.getty.edu/research/
> conducting_research/vocabularies/tgn/index.html). It seems really
> comprehensive and has geocoordinates too. Unfortunately, it doesn't
> seem to be an open resource; use of the raw data requires a license
> and a fee. Do you think there's any way to reach an agreement with
> the Getty that would let NCBO take advantage of this tremendous
> resource in some way?
>
> 	-hilmar
>
> On Oct 24, 2007, at 12:58 PM, Michael Ashburner wrote:
>
>> I agree it is a terrible mess. Not the new gaz.obo project.  This
>> is an attempt to build an artefact in OBO
>> format for geographical locations. The current version has about
>> 20,000 locations. We have a parse of about
>> 45,000 from Genbank but it will take some time to check them and
>> get them in to this file.
>>
>> http://obo.cvs.sourceforge.net/obo/obo/ontology/environmental/
>> gaz.obo?view=log
>>
>>
>> Michael Ashburner
>>
>>
>> The file is available from the OBO CVS site
>
> -- 
> ===========================================================
> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
> ===========================================================
>
>
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Obo-discuss mailing list
> Obo-discuss@...
> https://lists.sourceforge.net/lists/listinfo/obo-discuss

Hi Michael,

that's interesting to know. One thing I really like in gaz.obo is the  
containment hierarchy (located_in).

However, as you're probably aware this is often less trivial that it  
might seem. For example, while most of Chapel Hill, NC, is in Orange  
County, parts of it are actually in Durham County and Chatham County.  
In gaz, there are accordingly three located_in relationships, but  
obviously none of Chapel Hill is located in more than one county.  
Does that mean the semantics of located_in are defined accordingly,  
such as, if A located_in B, there is some part of A that is located  
within B?

Also, for applications such as assessing biodiversity on a per- 
boundary (such as per county) basis, I guess it is important exactly  
which of the containment links applies, e.g., based on  
geocoordinates. Is that something that you envision gaz to support?

	-hilmar

On Nov 2, 2007, at 12:31 PM, Michael Ashburner wrote:

> Hilmar
>
> Thanks.  Yes I know about the TGN and yes the licensing issues are
> the blocker.
> However, we are in touch with them and hope to have a meeting with
> them next
> year to discuss the possibilities for collaboration.
>
> We will get a page up - probably after our meeting in Banbury in two
> weeks,
>
> Thanks for your interest,
>
> Michael
>
> On 2 Nov 2007, at 10:52, Hilmar Lapp wrote:
>
>> Michael,
>>
>> pretty cool - is there a web-site somewhere for it, and/or a mailing
>> list? The OBO website doesn't seem to turn up anything.
>>
>> As an aside, you may have seen the TGN (http://www.getty.edu/ 
>> research/
>> conducting_research/vocabularies/tgn/index.html). It seems really
>> comprehensive and has geocoordinates too. Unfortunately, it doesn't
>> seem to be an open resource; use of the raw data requires a license
>> and a fee. Do you think there's any way to reach an agreement with
>> the Getty that would let NCBO take advantage of this tremendous
>> resource in some way?
>>
>> 	-hilmar
>>
>> On Oct 24, 2007, at 12:58 PM, Michael Ashburner wrote:
>>
>>> I agree it is a terrible mess. Not the new gaz.obo project.  This
>>> is an attempt to build an artefact in OBO
>>> format for geographical locations. The current version has about
>>> 20,000 locations. We have a parse of about
>>> 45,000 from Genbank but it will take some time to check them and
>>> get them in to this file.
>>>
>>> http://obo.cvs.sourceforge.net/obo/obo/ontology/environmental/
>>> gaz.obo?view=log
>>>
>>>
>>> Michael Ashburner
>>>
>>>
>>> The file is available from the OBO CVS site
>>
>> -- 
>> ===========================================================
>> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
>> ===========================================================
>>
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------- 
>> -
>> ---
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Obo-discuss mailing list
>> Obo-discuss@...
>> https://lists.sourceforge.net/lists/listinfo/obo-discuss
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Obo-discuss mailing list
> Obo-discuss@...
> https://lists.sourceforge.net/lists/listinfo/obo-discuss

-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================

The solution here is to add a new relation, spatially_overlaps_with.
If we use located_in for the case described, then we lose the 
transitivity of located_in (which would be a very significant loss 
for reasoning purposes)
We can then add axioms, e.g.

x located_in y ==> x spatially_overlaps_with y

x spatially_overlaps_with y ==> y spatially_overlaps x

x located_in y & y located_in x ==> x = y

BS

At 12:56 PM 11/3/2007, Hilmar Lapp wrote:
>Hi Michael,
>
>that's interesting to know. One thing I really like in gaz.obo is the
>containment hierarchy (located_in).
>
>However, as you're probably aware this is often less trivial that it
>might seem. For example, while most of Chapel Hill, NC, is in Orange
>County, parts of it are actually in Durham County and Chatham County.
>In gaz, there are accordingly three located_in relationships, but
>obviously none of Chapel Hill is located in more than one county.
>Does that mean the semantics of located_in are defined accordingly,
>such as, if A located_in B, there is some part of A that is located
>within B?
>
>Also, for applications such as assessing biodiversity on a per-
>boundary (such as per county) basis, I guess it is important exactly
>which of the containment links applies, e.g., based on
>geocoordinates. Is that something that you envision gaz to support?
>
>         -hilmar
>
>On Nov 2, 2007, at 12:31 PM, Michael Ashburner wrote:
>
> > Hilmar
> >
> > Thanks.  Yes I know about the TGN and yes the licensing issues are
> > the blocker.
> > However, we are in touch with them and hope to have a meeting with
> > them next
> > year to discuss the possibilities for collaboration.
> >
> > We will get a page up - probably after our meeting in Banbury in two
> > weeks,
> >
> > Thanks for your interest,
> >
> > Michael
> >
> > On 2 Nov 2007, at 10:52, Hilmar Lapp wrote:
> >
> >> Michael,
> >>
> >> pretty cool - is there a web-site somewhere for it, and/or a mailing
> >> list? The OBO website doesn't seem to turn up anything.
> >>
> >> As an aside, you may have seen the TGN (http://www.getty.edu/
> >> research/
> >> conducting_research/vocabularies/tgn/index.html). It seems really
> >> comprehensive and has geocoordinates too. Unfortunately, it doesn't
> >> seem to be an open resource; use of the raw data requires a license
> >> and a fee. Do you think there's any way to reach an agreement with
> >> the Getty that would let NCBO take advantage of this tremendous
> >> resource in some way?
> >>
> >>      -hilmar
> >>
> >> On Oct 24, 2007, at 12:58 PM, Michael Ashburner wrote:
> >>
> >>> I agree it is a terrible mess. Not the new gaz.obo project.  This
> >>> is an attempt to build an artefact in OBO
> >>> format for geographical locations. The current version has about
> >>> 20,000 locations. We have a parse of about
> >>> 45,000 from Genbank but it will take some time to check them and
> >>> get them in to this file.
> >>>
> >>> http://obo.cvs.sourceforge.net/obo/obo/ontology/environmental/
> >>> gaz.obo?view=log
> >>>
> >>>
> >>> Michael Ashburner
> >>>
> >>>
> >>> The file is available from the OBO CVS site
> >>
> >> --
> >> ===========================================================
> >> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
> >> ===========================================================
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> ---
> >> This SF.net email is sponsored by: Splunk Inc.
> >> Still grepping through log files to find problems?  Stop.
> >> Now Search log events and configuration files using AJAX and a
> >> browser.
> >> Download your FREE copy of Splunk now >> http://get.splunk.com/
> >> _______________________________________________
> >> Obo-discuss mailing list
> >> Obo-discuss@...
> >> https://lists.sourceforge.net/lists/listinfo/obo-discuss
> >
> >
> > ----------------------------------------------------------------------
> > ---
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a
> > browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Obo-discuss mailing list
> > Obo-discuss@...
> > https://lists.sourceforge.net/lists/listinfo/obo-discuss
>
>--
>===========================================================
>: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
>===========================================================
>
>
>
>
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>Obo-discuss mailing list
>Obo-discuss@...
>https://lists.sourceforge.net/lists/listinfo/obo-discuss

I suggest we should follow Maureen Donnelly in this matter. She writes:

Location relations are more general than are mereological (part-of) =20
relations. Unlike mereological relations, location relations depend =20
only on two individuals=92 locations. Thus, for example, a bolus of =20
food may be located in my stomach cavity although it is never part of =20=

my stomach cavity. Similarly, a ship may be located in a harbor =20
without being part of the harbor. Also, parts of the ecoregion called =20=

=91Humid Temperate Domain=92  are located in the United States but are =20=

not parts of this socio-economic unit.
In MI, location relations are defined in terms of a function, r, =20
which maps every individual to the unique spatial region it occupies =20
throughout the given time-frame. A spatial region is an immaterial =20
individual which may be one, two, or three dimensional. For most =20
applications, we assume that all spatial regions are fixed relative =20
to the earth. Thus, for example, my stomach cavity, though =20
immaterial, is not considered a spatial region. (But see (Donnelly =20
2005) for an alternative approach.)
The following relations are defined in terms of the region function.

(D4) Loc-In(x, y) =3D: Pr(x)r(y) (x is located in y)
(D5) PCoin(x, y) =3D: Or(x)r(y) (x partially coincides with y)
(D6) NCoin(x, y) =3D: ~PCoin(x, y) (x and y are non-coincident)

For example, an airplane getting ready for take-off from LaGuardia =20
Airport is located in the airport but is not part of (and does not =20
share parts with) LaGuardia Airport. A storm system on the Gulf of =20
Mexico may partially coincide with Florida, but does not share parts =20
with Florida. These two examples show that non-coincidence is a =20
stronger relation than discreteness =96 the airplane is always discrete =20=

from LaGuardia Airport, but the airplane and the airport are non-=20
coincident only after the airplane leaves the airport.

Axioms for the region function and location relations are as follows.
(L1) [2] r(r(x)) =3D r(x)  (x=92s spatial region is its own spatial =
region)

(L2) Pxy -> Loc-In(x, y) (if x is part of y, then x is located in y)

It follows from the axioms and definitions above that Loc-In is =20
transitive, PCoin and NCoin are symmetric, Loc-In and PCoin are =20
reflexive, and NCoin is irreflexive. We can also derive the following =20=

theorems.

(LT1) Oxy -> PCoin(x, y) (if x and y overlap, then x and y partially =20
coincide)
(LT3) Loc-In(x, y) & Pyz -> Loc-In(x, z) (if x is located in y and y =20
is part of z, then x is located in z)
(LT4) Pxy & Loc-In(y, z) ->  Loc-In(x, z) (if x is part of y and y is =20=

located in z, then x is located in z)
For example, since i) my heart is located in my middle mediastinal =20
space and ii) my middle mediastinal space is part of my thoracic =20
cavity, it follows that: iii) my heart is located in my thoracic =20
cavity (LT4). Similarly, if i) your car is located in Queens, then =20
since ii) Queens is part of New York City, it follows that: iii) your =20=

car is located in New York City.


this is from: M. Donnelly and T. Bittner. Spatial relations between =20
classes of individuals. In D. Mark and T. Cohn, editors, Spatial =20
Information Theory. Cognitive and Computational Foundations of =20
Geographic Information Science. International Conference (COSIT =20
2005), number 3693 in Lecture Notes in Computer Science, pages 182 =96 =20=

199. Springer Verlag, 2005.

Tom

On Nov 5, 2007, at 12:45 PM, Smith, Barry wrote:

> The solution here is to add a new relation, spatially_overlaps_with.
> If we use located_in for the case described, then we lose the =20
> transitivity of located_in (which would be a very significant loss =20
> for reasoning purposes)
> We can then add axioms, e.g.
>
> x located_in y =3D=3D> x spatially_overlaps_with y
>
> x spatially_overlaps_with y =3D=3D> y spatially_overlaps x
>
> x located_in y & y located_in x =3D=3D> x =3D y
>
> BS
>
> At 12:56 PM 11/3/2007, Hilmar Lapp wrote:
>> Hi Michael,
>>
>> that's interesting to know. One thing I really like in gaz.obo is the
>> containment hierarchy (located_in).
>>
>> However, as you're probably aware this is often less trivial that it
>> might seem. For example, while most of Chapel Hill, NC, is in Orange
>> County, parts of it are actually in Durham County and Chatham County.
>> In gaz, there are accordingly three located_in relationships, but
>> obviously none of Chapel Hill is located in more than one county.
>> Does that mean the semantics of located_in are defined accordingly,
>> such as, if A located_in B, there is some part of A that is located
>> within B?
>>
>> Also, for applications such as assessing biodiversity on a per-
>> boundary (such as per county) basis, I guess it is important exactly
>> which of the containment links applies, e.g., based on
>> geocoordinates. Is that something that you envision gaz to support?
>>
>>         -hilmar
>>
>> On Nov 2, 2007, at 12:31 PM, Michael Ashburner wrote:
>>
>> > Hilmar
>> >
>> > Thanks.  Yes I know about the TGN and yes the licensing issues are
>> > the blocker.
>> > However, we are in touch with them and hope to have a meeting with
>> > them next
>> > year to discuss the possibilities for collaboration.
>> >
>> > We will get a page up - probably after our meeting in Banbury in =20=

>> two
>> > weeks,
>> >
>> > Thanks for your interest,
>> >
>> > Michael
>> >
>> > On 2 Nov 2007, at 10:52, Hilmar Lapp wrote:
>> >
>> >> Michael,
>> >>
>> >> pretty cool - is there a web-site somewhere for it, and/or a =20
>> mailing
>> >> list? The OBO website doesn't seem to turn up anything.
>> >>
>> >> As an aside, you may have seen the TGN (http://www.getty.edu/
>> >> research/
>> >> conducting_research/vocabularies/tgn/index.html). It seems really
>> >> comprehensive and has geocoordinates too. Unfortunately, it =20
>> doesn't
>> >> seem to be an open resource; use of the raw data requires a =20
>> license
>> >> and a fee. Do you think there's any way to reach an agreement with
>> >> the Getty that would let NCBO take advantage of this tremendous
>> >> resource in some way?
>> >>
>> >>      -hilmar
>> >>
>> >> On Oct 24, 2007, at 12:58 PM, Michael Ashburner wrote:
>> >>
>> >>> I agree it is a terrible mess. Not the new gaz.obo project.  This
>> >>> is an attempt to build an artefact in OBO
>> >>> format for geographical locations. The current version has about
>> >>> 20,000 locations. We have a parse of about
>> >>> 45,000 from Genbank but it will take some time to check them and
>> >>> get them in to this file.
>> >>>
>> >>> http://obo.cvs.sourceforge.net/obo/obo/ontology/environmental/
>> >>> gaz.obo?view=3Dlog
>> >>>
>> >>>
>> >>> Michael Ashburner
>> >>>
>> >>>
>> >>> The file is available from the OBO CVS site
>> >>
>> >> --
>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> =20
>> ---------------------------------------------------------------------
>> >> -
>> >> ---
>> >> This SF.net email is sponsored by: Splunk Inc.
>> >> Still grepping through log files to find problems?  Stop.
>> >> Now Search log events and configuration files using AJAX and a
>> >> browser.
>> >> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> >> _______________________________________________
>> >> Obo-discuss mailing list
>> >> Obo-discuss@...
>> >> https://lists.sourceforge.net/lists/listinfo/obo-discuss
>> >
>> >
>> > =20
>> ---------------------------------------------------------------------=20=

>> -
>> > ---
>> > This SF.net email is sponsored by: Splunk Inc.
>> > Still grepping through log files to find problems?  Stop.
>> > Now Search log events and configuration files using AJAX and a
>> > browser.
>> > Download your FREE copy of Splunk now >> http://get.splunk.com/
>> > _______________________________________________
>> > Obo-discuss mailing list
>> > Obo-discuss@...
>> > https://lists.sourceforge.net/lists/listinfo/obo-discuss
>>
>> --
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------=20=

>> ----
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a =20
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Obo-discuss mailing list
>> Obo-discuss@...
>> https://lists.sourceforge.net/lists/listinfo/obo-discuss
>
>
>
>

Thomas Bittner
Department of Philosophy
Department of Geography
New York State Center of Excellence in Bioinformatics and Life Sciences
National Center for Geographic Information and Analysis
University at Buffalo
135 Park Hall
Buffalo, NY 14260
bittner3@...
http://www.buffalo.edu/~bittner3

Yes you are right. Tom corrected this already earlier in the thread.
BS

At 03:40 PM 11/6/2007, gary.h.merrill@... wrote:
>Barry:
>
>       x located_in y & y located_in x ==> x = y
>
>Do you really want this principal?  Seems a bit strong to me.  I think
>there certainly are counterexamples in the area (no pun intended) of
>geographic/political entities, and I would suspect in other domains as
>well.  It does seem reasonable in a lot of cases, but I'm not sure that
>it's fully defensible as a general principle.  However, I suppose it is
>*one* sense of 'located_in'.  It may depend on how closely (or not)
>'located_in' is intended to mimic (or be) a part/whole relation.
>
>------------------------------
>Gary H. Merrill, Head
>Semantic Technologies Group
>Statistical and Quantitative Sciences
>GlaxoSmithKline Research and Development
>Research Triangle Park, NC
>919.483.8456
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>Obo-discuss mailing list
>Obo-discuss@...
>https://lists.sourceforge.net/lists/listinfo/obo-discuss

Hi Bill

I think the principle here is merely that instances of the type  
denoted by the term must actually exist. Hopefully this shouldn't be  
controversial.

In terms of practical consequences, the deprecated PATO term "absent"  
falls on the wrong side of this guideline. There are no instances of  
wings that have the quality of being absent (and therefore no  
instances of "absent"). However, there are real instances of thoraxes  
that lack wings; the PATO term for lacking a part is encouraged here.

I don't think the guideline has any other practical consequences for  
many OBO ontologies as they exist now, as they are solidly grounded  
in reality.

On Nov 1, 2007, at 4:15 PM, Bill Bug wrote:

> Hi All,
>
> I've been reviewing the proposed additions to the OBO Foundry
> principles:
> 	
> 	http://obofoundry.org/wiki/index.php/OBO_Foundry_Principles
>
> I am heartily in favor of all - except the last:
>
> 	4. All terms should refer to types (or defined classes) which have
> instances.
>
> I recognize the inferencing capabilities such a requirement would
> enable, but I think in the current state of things, this is very
> problematic.
>
> It's not I believe it would never be appropriate to have a principle
> addressing some of the issues this sentence makes reference to, it's
> just in its current form I find it a bit counter to some of the other
> proposed principles or is at least ill-defined.
>
> Instances: the understanding of what an instance is seems to vary
> quite a bit across the community of people using OWL & OBO, beyond
> the pure semantics (e.g., in OWL, an instance is a terminal class
> extensive from which no new extension will be derived - i.e.,
> instances cannot descendants in the semantic graph).
>
> Also - should use of BFO become a principle (which I believe it
> should), or any other foundation that constrains its representation
> to a "realist" perspective, then instances as defined in this
> perspective probably do not belong in a shared, re-usable ontology.
>
> Any thoughts?
>
> Cheers,
> Bill
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Obo-discuss mailing list
> Obo-discuss@...
> https://lists.sourceforge.net/lists/listinfo/obo-discuss
>

>>>>> "CM" == Chris Mungall <cjm@...> writes:

  CM> I think the principle here is merely that instances of the type denoted
  CM> by the term must actually exist. Hopefully this shouldn't be
  CM> controversial.

  CM> In terms of practical consequences, the deprecated PATO term "absent"
  CM> falls on the wrong side of this guideline. There are no instances of
  CM> wings that have the quality of being absent (and therefore no instances
  CM> of "absent"). However, there are real instances of thoraxes that lack
  CM> wings; the PATO term for lacking a part is encouraged here.

  CM> I don't think the guideline has any other practical consequences for
  CM> many OBO ontologies as they exist now, as they are solidly grounded in
  CM> reality.


The problem with the principle as stated is that it raises issues of "do
things exist". If you are trying to avoid terms like "absent" then it may be
possible to restate the rule more precisely than this. 

OBO ontologies which arguable do not appear to describe "reality" would
include:

the evidence ontology
the relationship ontology

and anything that explicates canonicals which, by definition, don't
exist other than as a social agreement.

Other problemantic concepts would be numbers, patterns and so on. 

All of these things are useful; it would be a pity if discussions on the
nature of their reality precluded their inclusion in the OBO foundary. 

Phil

At 06:15 PM 11/1/2007, you wrote:
>Hi All,
>
>I've been reviewing the proposed additions to the OBO Foundry
>principles:
>
>         http://obofoundry.org/wiki/index.php/OBO_Foundry_Principles
>
>I am heartily in favor of all - except the last:
>
>         4. All terms should refer to types (or defined classes) which have
>instances.
>
>I recognize the inferencing capabilities such a requirement would
>enable, but I think in the current state of things, this is very
>problematic.
>
>It's not I believe it would never be appropriate to have a principle
>addressing some of the issues this sentence makes reference to, it's
>just in its current form I find it a bit counter to some of the other
>proposed principles or is at least ill-defined.
>
>Instances: the understanding of what an instance is seems to vary
>quite a bit across the community of people using OWL & OBO, beyond
>the pure semantics (e.g., in OWL, an instance is a terminal class
>extensive from which no new extension will be derived - i.e.,
>instances cannot descendants in the semantic graph).
>
>Also - should use of BFO become a principle (which I believe it
>should), or any other foundation that constrains its representation
>to a "realist" perspective, then instances as defined in this
>perspective probably do not belong in a shared, re-usable ontology.

Instances, in BFO idiolect, are particular items (this particular 
dog, this particular process of cell division) existing at some 
specific time and place, and instantiating some general (type, universal ...).

I agree wholeheartedly with Bill that instances do not belong in an 
ontology; ontologies are representations of what is general (roughly, 
of what is captured in textbook science), not of what is particular.

I am not sure that we are ready to make it a principle that every 
type in an ontology should have (or have had) instances. I do know, 
however, find this principle very useful, e.g. in understanding why 
it is an error to conceive of a special type 'absent lower limb' as a 
subtype of 'lower limb'.
BS


>Any thoughts?
>
>Cheers,
>Bill
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>Obo-discuss mailing list
>Obo-discuss@...
>https://lists.sourceforge.net/lists/listinfo/obo-discuss

My take on #4 is that it refers to comprehensiveness: stick to things 
that "are" as opposed to things that might be.  One should not include 
terms for that which has not been seen or described before.  For 
example, one should not have a term for a flying car in an "Automobile 
Ontology" just because one might be invented in the future ("Chitty 
Chitty Bang Bang" not withstanding).

Darren A. Natale
Protein Information Resource
Georgetown University Medical Center


Chris Mungall wrote:
> Hi Bill
> 
> I think the principle here is merely that instances of the type  
> denoted by the term must actually exist. Hopefully this shouldn't be  
> controversial.
> 
> In terms of practical consequences, the deprecated PATO term "absent"  
> falls on the wrong side of this guideline. There are no instances of  
> wings that have the quality of being absent (and therefore no  
> instances of "absent"). However, there are real instances of thoraxes  
> that lack wings; the PATO term for lacking a part is encouraged here.
> 
> I don't think the guideline has any other practical consequences for  
> many OBO ontologies as they exist now, as they are solidly grounded  
> in reality.
> 
> On Nov 1, 2007, at 4:15 PM, Bill Bug wrote:
> 
>> Hi All,
>>
>> I've been reviewing the proposed additions to the OBO Foundry
>> principles:
>> 	
>> 	http://obofoundry.org/wiki/index.php/OBO_Foundry_Principles
>>
>> I am heartily in favor of all - except the last:
>>
>> 	4. All terms should refer to types (or defined classes) which have
>> instances.
>>
>> I recognize the inferencing capabilities such a requirement would
>> enable, but I think in the current state of things, this is very
>> problematic.
>>
>> It's not I believe it would never be appropriate to have a principle
>> addressing some of the issues this sentence makes reference to, it's
>> just in its current form I find it a bit counter to some of the other
>> proposed principles or is at least ill-defined.
>>
>> Instances: the understanding of what an instance is seems to vary
>> quite a bit across the community of people using OWL & OBO, beyond
>> the pure semantics (e.g., in OWL, an instance is a terminal class
>> extensive from which no new extension will be derived - i.e.,
>> instances cannot descendants in the semantic graph).
>>
>> Also - should use of BFO become a principle (which I believe it
>> should), or any other foundation that constrains its representation
>> to a "realist" perspective, then instances as defined in this
>> perspective probably do not belong in a shared, re-usable ontology.
>>
>> Any thoughts?
>>
>> Cheers,
>> Bill
>>
>>
>> ---------------------------------------------------------------------- 
>> ---
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a  
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Obo-discuss mailing list
>> Obo-discuss@...
>> https://lists.sourceforge.net/lists/listinfo/obo-discuss
>>
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Obo-discuss mailing list
> Obo-discuss@...
> https://lists.sourceforge.net/lists/listinfo/obo-discuss

At 10:55 AM 11/5/2007, Darren Natale wrote:
>My take on #4 is that it refers to comprehensiveness: stick to things
>that "are" as opposed to things that might be.  One should not include
>terms for that which has not been seen or described before.  For
>example, one should not have a term for a flying car in an "Automobile
>Ontology" just because one might be invented in the future ("Chitty
>Chitty Bang Bang" not withstanding).

It also refers to the rejection of the notion of 'abstract classes' 
from object oriented programming. The idea there (to the extent that 
I understand it), is that very general terms like 'object' don't have 
instances, but more specific terms like 'mammal' do. Since, for us, 
trivially, every instance of mammal is also an instance of object, 
such an approach is not available to us.
This is not a trivial matter -- the constraint of having-an-instance 
allows us to track every ontology term back down to whatever it is in 
reality which, when it is observed, gives us evidence for the truth 
of the statements involving that ontology term.

BS

>Darren A. Natale
>Protein Information Resource
>Georgetown University Medical Center
>
>
>Chris Mungall wrote:
> > Hi Bill
> >
> > I think the principle here is merely that instances of the type
> > denoted by the term must actually exist. Hopefully this shouldn't be
> > controversial.
> >
> > In terms of practical consequences, the deprecated PATO term "absent"
> > falls on the wrong side of this guideline. There are no instances of
> > wings that have the quality of being absent (and therefore no
> > instances of "absent"). However, there are real instances of thoraxes
> > that lack wings; the PATO term for lacking a part is encouraged here.
> >
> > I don't think the guideline has any other practical consequences for
> > many OBO ontologies as they exist now, as they are solidly grounded
> > in reality.
> >
> > On Nov 1, 2007, at 4:15 PM, Bill Bug wrote:
> >
> >> Hi All,
> >>
> >> I've been reviewing the proposed additions to the OBO Foundry
> >> principles:
> >>
> >>      http://obofoundry.org/wiki/index.php/OBO_Foundry_Principles
> >>
> >> I am heartily in favor of all - except the last:
> >>
> >>      4. All terms should refer to types (or defined classes) which have
> >> instances.
> >>
> >> I recognize the inferencing capabilities such a requirement would
> >> enable, but I think in the current state of things, this is very
> >> problematic.
> >>
> >> It's not I believe it would never be appropriate to have a principle
> >> addressing some of the issues this sentence makes reference to, it's
> >> just in its current form I find it a bit counter to some of the other
> >> proposed principles or is at least ill-defined.
> >>
> >> Instances: the understanding of what an instance is seems to vary
> >> quite a bit across the community of people using OWL & OBO, beyond
> >> the pure semantics (e.g., in OWL, an instance is a terminal class
> >> extensive from which no new extension will be derived - i.e.,
> >> instances cannot descendants in the semantic graph).
> >>
> >> Also - should use of BFO become a principle (which I believe it
> >> should), or any other foundation that constrains its representation
> >> to a "realist" perspective, then instances as defined in this
> >> perspective probably do not belong in a shared, re-usable ontology.
> >>
> >> Any thoughts?
> >>
> >> Cheers,
> >> Bill
> >>
> >>
> >> ----------------------------------------------------------------------
> >> ---
> >> This SF.net email is sponsored by: Splunk Inc.
> >> Still grepping through log files to find problems?  Stop.
> >> Now Search log events and configuration files using AJAX and a
> >> browser.
> >> Download your FREE copy of Splunk now >> http://get.splunk.com/
> >> _______________________________________________
> >> Obo-discuss mailing list
> >> Obo-discuss@...
> >> https://lists.sourceforge.net/lists/listinfo/obo-discuss
> >>
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Obo-discuss mailing list
> > Obo-discuss@...
> > https://lists.sourceforge.net/lists/listinfo/obo-discuss
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>Obo-discuss mailing list
>Obo-discuss@...
>https://lists.sourceforge.net/lists/listinfo/obo-discuss

>>>>> "Barry" == Smith, Barry <phismith@...> writes:

  Barry> It also refers to the rejection of the notion of 'abstract classes'
  >> From object oriented programming. The idea there (to the extent that
  Barry> I understand it), is that very general terms like 'object' don't have
  Barry> instances, but more specific terms like 'mammal' do. Since, for us,
  Barry> trivially, every instance of mammal is also an instance of object,
  Barry> such an approach is not available to us.  

Barry

Just for information, the OO analogy doesn't work. Instances of an Object
Orientated Mammal are, trivially, also instance of an OO Object as well. It
works exactly the same. 

The idea of abstract classes are that they are not meant to be DIRECTLY
instantiated. You have pretty much the same notion in the OWL encoding of BFO:
which states that

bfo:entity 
     subclass
        union-of (bfo:continuant bfo:occurrent)


So you can't be a bfo:entity without being a bfo:continuant or
bfo:occurrent. There are instances of bfo:entity however. The analogy is not
direct; the purpose of subclassing in ontological representations and OO is
different.


  Barry> This is not a trivial matter -- the constraint of having-an-instance
  Barry> allows us to track every ontology term back down to whatever it is in
  Barry> reality which, when it is observed, gives us evidence for the truth
  Barry> of the statements involving that ontology term.

I don't think that this works. If we have a term X, and we find some instance
of X that does not obey the definition, perhaps it's just not an X at all. You
are also making the assumption that just because