<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Might I make a suggestion? When the topic of a thread diverges
significantly from the original subject line, let's send it to the list
with a new subject line that reflects the nature of the new thread. I
don't know if I'm the only person who does this, but I do go to the
list archives to try to find old posts that I remember and to which I
would like to refer. However, that gets really hard when there are a
lot of posts and the subject lines don't correspond to the topic of the
posts. This is a good example of a series of posts to which I'm likely
to want to refer in the future but I have a feeling I wouldn't find
them under this subject line.<br>
<br>
Thanks,<br>
Steve<br>
<br>
Shawn Bowers wrote:
<blockquote
cite="mid:AANLkTikznHS3539G+RhHifAxeE4ReHUtbQddQhZReikm@mail.gmail.com"
type="cite">
<pre wrap="">Hi Hilmar,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Both OBOE and EQ do introduce classes that prescribe how to structure new
classes and type
individuals
</pre>
</blockquote>
<pre wrap="">That's actually not quite true. The EQ model itself doesn't prescribe any
new classes or the types that individuals must be of; instead it simply says
that a phenotype instance can be expressed as some instance of a quality Q
that inheres_in some instance of an entity E, and thus a class of phenotypes
(or observations of an organism's characteristics) is the intersection of
all instances of Q (a subclass restriction), and all things that inhere_in E
(a property restriction).
</pre>
</blockquote>
<pre wrap=""><!---->
There are two ways to type things in OWL, classes and properties (I
should have said properties in addition to classes above, since OBOE
also introduces properties). So, in this way, the "inheres_in"
property is how EQ prescribes type information on "instances". It also
sounds like it prescribes E's and Q's (since this really defines what
inheres_in is), and so at least implicitly these are types also
"introduced" by EQ.
</pre>
<blockquote type="cite">
<pre wrap="">While typically we will draw Q and E from certain ontologies (such as PATO
for qualities), you can designate any class (term) in those places, and the
class expression by itself will not support inferences about the nature of Q
or E or their instances (the ontologies that Q and E are drawn from do
that). The class expression itself is often anonymous, but there are
(so-called "pre-composed") ontologies that identify and label them.
</pre>
</blockquote>
<pre wrap=""><!---->
But, one would imagine that designating a class within an inheres_in
statement (even if anonymous) means it is either an E or a Q (at least
implicitly, i.e., it may not be inferable from EQ that this is the
case, but that seems like a detail). Of course, PATO as a realization
of EQ uses a Quality class.
</pre>
<blockquote type="cite">
<pre wrap="">That being said, while EQ in principle allows you to do real crazy things if
you want to (which perhaps is what Joel means by schema-last?), if you want
to be able to do discovery and reasoning with a set of EQ class expressions
from different sources, they will need to follow some shared conventions,
such as not simply making up quality and entity terms as needed, but drawing
them from PATO and shared entity ontologies.
</pre>
</blockquote>
<pre wrap=""><!---->
Right.
</pre>
<blockquote type="cite">
<pre wrap="">Conversely, OBOE does prescribe the nature of the things that it relates to
each other in the model, the cardinality of those relationships, and what it
means for an instance it is has such a relationship. For example, if I
assert o oboe:ofEntity e, the semantics of oboe:ofEntity prescribe that o is
an instance of oboe:Observation, e is an instance of oboe:Entity, and if I
also assert o oboe:ofEntity e1, it prescribes that e and e1 are identical,
i.e., the same instance.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, this is true.
BTW. I'm a bit confused though -- is EQ an OWL ontology? Or is it
purely an abstract model that prescribes a convention for defining
qualities, with concrete quality and entity ontologies being drawn
from other places (like PATO)? Where is the inheres_in property
defined?
</pre>
<blockquote type="cite">
<pre wrap="">I think these differences are a result of how they were motivated, and it is
interesting to me that Joel would pick these as examples for illustrating
"schema-lastishness". OBOE was motivated by having a unified data model for
observational data, in the interest of better data exchange and integration.
I think all its class and property constraints are a reflection of that -
there is a desire not to "allow anything".
</pre>
</blockquote>
<pre wrap=""><!---->
I agree with this.
As an example, one of the driving use cases for OBOE is annotating
relational data sets in which the attributes within a given data set
is tagged with observation/measurement types and from these
annotations OBOE instance data (i.e., sets of triples) are
automatically generated.
</pre>
<blockquote type="cite">
<pre wrap="">Conversely, EQ wouldn't make for
a good model in which to exchange arbitrary observational data - there would
be no guarantees for what you get. However, it is very powerful for
reasoning over the semantics of the observations (see the Washington et al
2009 paper), which is what it was conceived for.
</pre>
</blockquote>
<pre wrap=""><!---->
Right ... and I think ideally EQ models could be used within OBOE for
assigning qualities to specific observations. This would allow for
both the reasoning abilities of OBOE (e.g., context, units, etc.) plus
those for qualities via EQ.
Shawn
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, Feb 17, 2011 at 11:28 AM, joel sachs <a class="moz-txt-link-rfc2396E" href="mailto:jsachs@csee.umbc.edu"><jsachs@csee.umbc.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Do you (or does anyone else on the list) know the status of OBD? From the
NCBO FAQ:
</pre>
</blockquote>
<pre wrap="">Funny you should ask. We're in the final stages of writing up a manuscript
about it. I can share a preprint with you next week. OBD is what is
underpinning the Phenoscape Knowledgebase (<a class="moz-txt-link-freetext" href="http://kb.phenoscape.org">http://kb.phenoscape.org</a>).
The URL is <a class="moz-txt-link-freetext" href="http://www.berkeleybop.org/obd/">http://www.berkeleybop.org/obd/</a>. It is still pretty outdated, but
will be updated very soon.
</pre>
<blockquote type="cite">
<pre wrap="">Is it still the plan to integrate OBD into BioPortal?
</pre>
</blockquote>
<pre wrap="">I don't think so. And there are lots of resources working on that (at least
in the biomedical domain), so it'd be hard for them to pick what to follow.
</pre>
<blockquote type="cite">
<pre wrap="">So in the OBOE case, the characteristics (color, perimeter texture, basic
shape) are given a priori, while in the EQ case they would (presumably) be
abstracted during subsequent ontology development.
</pre>
</blockquote>
<pre wrap="">Yes. They are implied by the subclass structure of PATO (and thus subject to
change).
</pre>
<blockquote type="cite">
<pre wrap="">it might be worth experimenting with tag-driven ontology evolution, as in
[1], where tags are associated to concepts in an ontology. [...] So the
domain expert/knowledge engineer
partnership is preserved, but with the domain expert role being replaced
by collective wisdom from the community.
</pre>
</blockquote>
<pre wrap="">Are you aware of the "Fast, Cheap, and Out of Control" paper from Mark
Wilkinson's group:
Good et al. 2006. Fast, Cheap and Out of Control: A Zero Curation Model for
Ontology Development. Pacific Symposium on Biocomputing 11: 128-139.
<a class="moz-txt-link-freetext" href="http://psb.stanford.edu/psb-online/proceedings/psb06/good.pdf">http://psb.stanford.edu/psb-online/proceedings/psb06/good.pdf</a>
-hilmar
--
===========================================================
: Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org :
===========================================================
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
tdwg-content mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a>
<a class="moz-txt-link-freetext" href="http://lists.tdwg.org/mailman/listinfo/tdwg-content">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a>
.
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences
postal mail address:
VU Station B 351634
Nashville, TN 37235-1634, U.S.A.
delivery address:
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235
office: 2128 Stevenson Center
phone: (615) 343-4582, fax: (615) 343-6707
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
</pre>
</body>
</html>