<http://keet.wordpress.com/2007/12/09/nontologies-and-the-thorny-issue-of-definitions/>http://keet.wordpress.com/2007/12/09/nontologies-and-the-thorny-issue-of-definitions/
on the OBO Foundry paper in Nature Biotechnology
http://www.nature.com/nbt/journal/v25/n11/pdf/nbt1346.pdf
>If you have looked at the abstract, slides, or
>the video, you may have noticed the absence of
>the efforts on terminology of ontologies etc in
>the bio-ontologies community. This was discussed
>off-line before and after the seminar, which is
>in no small part due to that there are no good
>definitions around there either. Of course, we
>have <http://ontology.buffalo.edu/smith/>Barry
>Smith et al’s recent KR-MED article [2] who
>makes a step in that direction, but their
>description of an ontology–“an ontology is a
>representational artifact, comprising a taxonomy
>as proper part, whose representational units are
>intended to designate some combination of
>universals, defined classes, and certain
>relations between them”–is not a formal
>definition that would make a computer scientist
>happy (which may not have been the aim of the
>authors anyway). Moreover, and what troubles me
>most, is the recently published OBO Foundry
>paper in Nature Biotechnology [3]. I am aware I
>might make some steps on thin ice for what I’m
>going to write, but it really is meant as an
>honest questionok, a few questions.
As I hope is now clear from the mentioned KR-MED
article and from a large number of posts
elsewhere, I have long been advocating the view
that an ontology for scientific research purposes
should be a controlled vocabulary with a logical
structure to support formal reasoning and which
rests on an attempt to represent biological
reality and is thus subject to update in light of
advances in scientific knowledge.
As Marijke, of course, understands perfectly
well, this view underlies the Nature
Biotechnology paper as it underlies the work of the OBO Foundry.
>There is not only no definition in the Nature
>Biotech article of what an ontology is (possibly
>due to the intended readership), but it starts
>by putting ontology in sneer quotes in the
>abstract. We have that “controlled vocabularies or ‘ontologies’… ”
These are not 'sneer' quotes; they are 'look at
this special word, dear reader' quotes.
>as if controlled vocabularies and
>ontology-in-sneer-quotes are synonyms (are
>they?), then there is the MGED Ontology as an
>“annotation resource”, which is a functional
>definition of sorts, but also that each OBO
>“Foundry ontology forms a graph-theoretic
>structure, with terms connected by edges
>representing relations”. The latter is a useful
>point if it weren’t for the confusion it causes
>because it is mentioned directly after dealing
>with OWL ontologies, which have a model-theoretic semantics.
We were assuming that the ontologies expressed in
OWL can be conceived as graph-theoretic
structures (built out of triples, etc.).
> Now, we can have a logical theory T with
> model-theoretic semantics where the non-empty
> underlying set and interpretation (=structure)
> of the vocabulary (=set of function, relation,
> and constant symbols) happen to be a particular
> graph (model M). Definition-wise, we’d be
> making a lot of progress with that. But can an
> OBO Foundry ontology only be a particular
> graph? Why and what kind of graph, what are the
> properties of the graphs? Only DAGs? (Are you sure about that?)
Who is the 'you' who is being addressed here?
>An OBO Foundry ontology can have only binary
>relations, or could/should that change if an
>n-ary (where n>2) is added to the Relation Ontology?
This is an interesting point. For the moment, we
are experimening with the idea that OBO Foundry
ontologies should be expressible in both OBO
format and in OWL DL format. If this is so, then
we are presumably restricted to two-place
relations by OWL. I can well imagine that this
restriction might be removed in the future,however.
>Also, there’s the issue of instance-level versus
>type-level, but we might set that aside for the
>moment because the OBO Foundry clearly focuses
>on type-level knowledge representation and we
>can store a type-level ontology in a database so
>that the universals in logical theory T are,
>mathematically, instances (in a model M) and
>pretend they are types in the GUI so as to
>meet the point on having a graph as structure if
>we have a [TBox-] OWL ontology.
Er, Yes. I think.
>Or you
again, who is 'you'?
>want to stick to obo format and DAGs instead of
>starting/migrating/continuing with OWL? Or have
>both DAGs and OWL-formalised bio-ontologies and
>have a definition of an ontology or, more
>precisely, OBO Foundry ontology, alike “a DAG or
>OWL-formalised logical theory”? If the latter,
>is there a policy for new proposals for
>inclusion of ontologies being represented
>preferably in obo format or for OWL-formalised bio-ontologies?
Given the OBO-OWL converters which now exist, we
are reaching the point where this question is moot, I think. But see above.
See on this another blog post:
>http://cszamudio.spaces.live.com/blog/cns!9BCF6F9D6772B8F5!1715.entry
with response by Chris Mungall:
>Hi Carlos
>
>I saw your blog posting:
>
>It seems that one must register for a microsoft account before
>submitting comments on your blog which seemed too much of an energy
>barrier so I thought I would just comment in the appropriate forum.
>
>Thanks for your positive comments on the OBO Foundry. I just wanted
>to highlight a few points:
>
>>I do however question the reliance on the OBO language itself.
>>There is no way, that I have found, to enforce consistency on the
>>underlying ontology semantics. Recent publications have attested to
>>this lack of a formal logic specification for OBO
>
>In actual fact there is a definition of the OBO language in terms of
>OWL semantics (in fact there are several mappings from obof to owl,
>but they all differ in terms of representation of logically-invisible
>terminological aspects).
>
>http://www.bioontology.org/wiki/index.php/OboInOwl:Main_Page
>
>There are still certain issues to be worked out specifically w.r.t
>the treatment of time
>
>You can download any obo ontology in owl from here:
>http://www.berkeleybop.org/ontologies
>
>>As some of the rich OBO ontologies have grown quite large (e.g.,
>>ChEBI), performing QC on the ontology is an amazingly difficult
>>problem.
>
>I agree - but I don't think OWL is the magic bullet here
>
>>I have discovered significant challenges in providing visualization
>>for some of the larger ontologies in a consistent way. This is why
>>many have argued that a migration to the OWL language would be of
>>significant benefit to the project. Robust open-source tools such
>>as Protege and Jena exist to construct ontologies. Commercial
>>tools such as TopBraid's Composer provides an excellent commercial
>>platform for development.
>
>This seems to be something of a non-sequitor. Can you state more
>specifically how migration to OWL helps with visualisation per se?
>How would Jena be of help here? I don't think visualisation at the
>level of RDF triples would be particularly helpful.
>
>I haven't looked at TopBraid - but I'm afraid that use of a
>commercial tool is a non-started for all the ontology developers I know
>
>Cheers
>Chris
>
BS
> >An OBO Foundry ontology can have only binary
> >relations, or could/should that change if an
> >n-ary (where n>2) is added to the Relation Ontology?
>
> This is an interesting point. For the moment, we
> are experimening with the idea that OBO Foundry
> ontologies should be expressible in both OBO
> format and in OWL DL format. If this is so, then
> we are presumably restricted to two-place
> relations by OWL. I can well imagine that this
> restriction might be removed in the future,however.
You are correct that owl properties are binary, and I think it's highly
unlikely that this restriction will ever be lifted, given that OWL is
intended to have well-defined logical behavior. However, you must be aware
that it is trivial to represent multi-place relations using binary relations
only - given the isomorphism between graphs and hyper-graphs - by introducing
a class where the instances are relational tuples, and each of the different
slots in the tuple is captured by an owl property. This same trick is
frequently used in literature discussing ontological roles, and participation
of entities in processes. It is only if you insist upon a 1:1 mapping between
owl properties and BFO relations that you run into trouble with n-ary
relations (where n > 2, or n varies with each instantiation of the relation).
As a concrete example, consider BFO:instantiates, which is a 3-place relation.
We can represent this in OWL as:
owl:Class Instantiation
owl:Property instantiationOf (Instantiation -> Universal)
owl:Property instantiationBy(Instantiation -> Particular)
owl:Property instantiationAt(Instantiation -> Time)
And, as an example,
instanceOf(person Universal)
instanceOf(matthew Particular)
instanceOf(tonight Time)
instanceOf(i Instantiation)
instantiationOf(i person)
instantiationBy(i matthew)
instantiationAt(i tonight)
This is almost directly analogus to the way this is handled in the Isabell
theories of BFO, and while more verbose than the existing mappings between
BFO and OWL, it has at least some virtues: for example that it makes explicit
that universals are not OWL classes, allows relationships between universals
to be stated explicitly and inferred over, lets us axiomise instantiation
fully, lets us drop in any model of time that is appropriate to the
situation, gives hooks for dl-safe rules to inject 'differentiae' and other
constraints into the OWL, let us apply SKOS between the universal instances
to partition our terminological/linguistic layer from our logical one and so
on.
> BS
Matthew
As you describe it below, this sounds very much like the OWL-based
"magic bullet" we (us OWL-based BFO users) have been in need of.
As I endeavor to absorb your very dense advertisement below, please
allow me to wear my ignorance on my sleeve.
1) Is
instanceOf (person Universal)
equivalent to
<Universal rdf:about="#person">
2) Won't it confuse people to tell them instances of the owl:Class
"Universal" such as "cell" are not types (explicitly not part of the
T-Box).
3) Perhaps this is off the point you were trying to make - or -
perhaps this WAS the point you were trying to make, but its sounds
like what you are proposing is a means to subvert the OWL plumbing
(i.e., formal semantics) to get it to work in the realist realm BFO
is cast in that requires we ignore the expected use of the set
theoretic underpinnings of OWL (e.g., that "cell" represents the set
of all instances of the universal "cell" AND instances of all its
descendant classes)
4) Can you help to flesh out an example? For instance, let us assume
we would want to represent the relation between a receptor and its
high-affinity ligands - and a receptor and the nucleotide sequence
antecedents of its peptide subunits as follows:
macromolecule is a type of object, and peptide, transcript, and gene
are all types of macromolecule (this is VERY controversial, I know -
gene should be an generically dependent continuant of some sort, but
let's leave that for now)
macromolecular complex is a type of object aggregate
chromosome is a type of macromolecular complex
multimeric macromolecular complex is a type of macromolecular complex
made up of fully specified parts in a defined stochiometric ratio
gene X is_located_at (map_position bearer_of
(chromosomal_location_quality_111.222 toward (chromosome 2 located_in
(mouse))))
gene Y is_located_at (map_position bearer_of
(chromosomal_location_quality_222.333 toward (chromosome 7 located_in
(mouse))))
gene Z is_located_at (map_position bearer_of
(chromosomal_location_quality_222.333 toward (chromosome 14
located_in (mouse))))
transcript I transcribed_from gene X
transcript II transcribed_from gene Y
transcript III transcribed_from gene Z
peptide A translated_from transcript I
peptide B translated_from transcript II
peptide C translated_from transcript III
multimeric macromolecular complex a1 has_part peptide A
multimeric macromolecular complex a1 has_part peptide B
multimeric macromolecular complex a2 has_part peptide A
multimeric macromolecular complex a2 has_part peptide C
multimeric macromolecular complex a1 is_bearer_of (bind a ligand
disposition toward (molecule 1))
multimeric macromolecular complex a2 is_bearer_of (bind a ligand
disposition toward (molecule 1))
a) how would you represent this set of Universals in OWL using your
proposed method?
b) can you then use Pellet to infer ==> the set of multimeric
macromolecular complexes that bind molecule 1 and have a peptide
subunit derived from mouse chromosome 7
5) Can you use both Protege v3.4.x and Protege 4 to build out a BFO-
based representation according to the method you outline below?
Many thanks for any additional info you can provide on how to
experiment with the method you describe.
Cheers,
Bill
As you describe it below, this sounds very much like the OWL-based
"magic bullet" we (us OWL-based BFO users) have been in need of.
On Sunday 16 December 2007, Bill Bug wrote:
> Hi Matttew,
>
> As you describe it below, this sounds very much like the OWL-based
> "magic bullet" we (us OWL-based BFO users) have been in need of.
Hum, this seems to have got a bit out of hand - it was intended just as an example of a 3-place relation familiar to BFO folks and how it can be encoded in OWL. I only meant to point out that the 1:1 mapping between BFO primitives and OWL primitives is an arbitrary modelling choice, not an insurmountable fact of life.
As Alan points out, you pay for your choices one way or the other:
On Sunday 16 December 2007, Alan Ruttenberg wrote:
> Well, it's not exactly a magic bullet. It may be worth experimenting
> with but note that when one does this one loses the special aspects
> of classes in OWL, such as the ability to compute their subsumption
> relationship naturally, and to the extent that one wants to reproduce
> them, new relations need to be defined and care taken to ensure that
> appropriate inferences follow. For example, consider restrictions -
> they need to be reformulated to work with this instance based view.
>
> -Alan
Anyway, at the risk of getting into a mud-slinging match over representations rather than meanings, I'll try to answer your questions.
> As I endeavor to absorb your very dense advertisement below, please
> allow me to wear my ignorance on my sleeve.
>
> 1) Is
> instanceOf (person Universal)
> equivalent to
> <Universal rdf:about="#person">
I think so - I was aiming for the owl instanceOf semantics, but they boil down to the same thing in this case as far as I can tell.
> 2) Won't it confuse people to tell them instances of the owl:Class
> "Universal" such as "cell" are not types (explicitly not part of the
> T-Box).
It may well do - this would be one of the primary draw-backs of this kind of encoding, and the cost may be excessive, particularly if we show people the representation directly. However, BFO currently says that universals 'exist', and that relations hold between them seperately from relations that hold between individuals (including but not limited to is_a), and if you want to say this in OWL in any meaningul way, you must make these entities into individuals.
You make the trade - represent it in the syntax that people expect, or represent it in the syntax that makes what we want to say about universals available to the reasoner. There are already plugins for protege4 that allow you to view concepts organised other than by subsumption - I expect that it would not be hard to knock up one that renders universal individuals by is_a. At this level, it's largely a UI/tools issue.
> 3) Perhaps this is off the point you were trying to make - or -
> perhaps this WAS the point you were trying to make
I was just trying to say that you don't need to encode ontological relationships directly as owl properties.
> , but its sounds
> like what you are proposing is a means to subvert the OWL plumbing
> (i.e., formal semantics) to get it to work in the realist realm BFO
> is cast in that requires we ignore the expected use of the set
> theoretic underpinnings of OWL (e.g., that "cell" represents the set
> of all instances of the universal "cell" AND instances of all its
> descendant classes)
Well, given the long discussions we've had on this list about what the semantics of BFO are meant to be and what the semantics of owl classes are, to be honest I'm not sure it's such a large subverting. You can't use OWL and throw away the set-theoretic underpinnings and then also be supprised if bad things happen, or gasp in shock when people get snagged by the gap between the operational semantics of OWL and the ontological semantics of BFO. OWL classes and BFO universals have very different properties.
In the BFO world, universals 'exist' independently of but by virtue of their particulars. This sudgests a cardinality restriction:
Unviersal < inverse(instantiationOf) at_least 1
Many of the other properties of instantiation can probably also be recovered e.g. those dealing with the is_a hierachy vs subsumption. Assuming is_a to be transitive and reflexive, introducing instantiates that links a particular directly to a universal, and with the caveat that i've not run this through a reasoner, you could say something like:
instantiates < inverse(instantiationBy) o instantiationOf o is_a
This will recover all of the universals that a particular instantiates, given a 'most specific universal' assertion. A similar trick could be used to ensure that if there is an instantiation for a time period, that there is an instantiation for all contained time periods.
Similarly, we can distinguish between the Universal instance person, and the restriction of all particulars that instantiate person (the BFO extention of person) with something like:
# introduce an 'extentional' class over the particulars that
# instantiate the universal 'person'
Persons = Particular
and inverse(instantiationAs) some (instantiationOf { person } )
> 4) Can you help to flesh out an example? For instance, let us assume
> we would want to represent the relation between a receptor and its
> high-affinity ligands - and a receptor and the nucleotide sequence
> antecedents of its peptide subunits as follows:
As I said above, I was only intending to illustrate the point that you don't have to map 1:1 between your language of choice and OWL. However, I'll have a stab at part of your example.
Something like:
domain(is_a Universal)
range(is_a Universal)
macromolecule is_a object
peptide is_a macromolecule
transcript is_a macromolecule
gene is_a macromolecule #as you say, this is a dumb thing to claim
macromolecular complex is_a object aggregate
chromosome is_a macromolecular complex
Easy so far.
multimeric macromolecular complex is_a macromolecular complex
The defined parts - no idea - I have never read a BFO axiomatisation of parts, with stochiometry or otherwise. I don't belive that OWL can deal with sochiometry either, without encoding peno arithmetic up in some custom way.
Ignoring the counting issue, you can go two ways. Firstly, you could define some universal-universal properties describing the 'idealised' parts and their stochiometry. Secondly, you could place a restriction on the Instantiation class that means that when the universal is_a multimeric macromolecular complex, the particular has qualified cardinality constraints on the has_part relation. Thirdly, you could create a restricted sub-class of Particular that encodes the restriction:
# named class for all instantiations of a universal, because
# we have specific things to say about it
Multimeric_Macromolecular_Complex <
instantiation some { multimeric_macromolecular_complex }
and has_part exactly 2 (instantiation some { peptide A })
and has_part exaclty 2 (instantiation some { peptide B })
What you do here is probably a matter of style rather than of logic - personally, I'd use universal-level properties and dl-safe rules, as this keeps the knowledge close to where you intended to state it.
I can't face typing the rest of your example out in full. I'm not a compiler, but you should get the gist by now.
> b) can you then use Pellet to infer ==> the set of multimeric
> macromolecular complexes that bind molecule 1 and have a peptide
> subunit derived from mouse chromosome 7
Yes, but don't ask me to draw out the tableau :) Notice, you are asking here for the set of particulars, so it is a restriction on the right-hand-side of the instantiatedBy relation - a sub-class of Particular. Notice how we were able to go directly from your form of words to the logical construct, without inventing some 'pseudo-universal' or 'pseudo-predicate' to fill the gap.
> 5) Can you use both Protege v3.4.x and Protege 4 to build out a BFO-
> based representation according to the method you outline below?
I very much doubt you can do much interesting with protege 3.4 and this kind of representation. It requires the expressivity of owl 1.1 to say many of the interesting things (e.g. role chains to get instantiation that respects is_a), and this is supported only in protege 4. It would need some custom UI to make it palatable to users, which is easier to do in protege 4 in our experience.
To bridge the gap between assertions between universals and native owl restrictions, you would need either tedious manual intervention, or dl-safe rules. However, the up-side is that when you state 'human has_part exactly 2 arm' on universals, you can write your dl-safe rule to do sane things on Instantiation, to possibly classify one-armed men as human, but not as cannoical human.
>
> Many thanks for any additional info you can provide on how to
> experiment with the method you describe.
I can see I'm now going to have to embark on a furous session of coaxing genies back into bottles.
>
> Cheers,
> Bill
Matthew
The idea is good; the terminology ('universals are individuals') is
confusing; 'universals are first-rate entities' would be better
The OBO community has been toying with this idea for some time. It is
sketched in all its philosophical glory in:
http://ontology.buffalo.edu/bfo/Against_Fantology.pdf
Also sounds right to me.
>Many of the other properties of instantiation can probably also be
>recovered e.g. those dealing with the is_a hierachy vs subsumption.
>Assuming is_a to be transitive and reflexive, introducing
>instantiates that links a particular directly to a universal, and
>with the caveat that i've not run this through a reasoner, you could
>say something like:
>
>instantiates < inverse(instantiationBy) o instantiationOf o is_a
>
>This will recover all of the universals that a particular
>instantiates, given a 'most specific universal' assertion. A similar
>trick could be used to ensure that if there is an instantiation for
>a time period, that there is an instantiation for all contained time periods.
>
>Similarly, we can distinguish between the Universal instance person,
>and the restriction of all particulars that instantiate person (the
>BFO extention of person) with something like:
>
># introduce an 'extentional' class over the particulars that
>
># instantiate the universal 'person'
Also corresponds to the way I have been thinking about this.
>Persons = Particular
'='?
BS
you are free to join the corresponding googlegroup
> is that really the right mailing list? not some other obo or
> obofoundry mailing list, or an obo-owl one? and some of it appeard
> on the RO-list as well. That is also why I wrote a blog post originally.
One day, I hope, we will have greater clarity in what is and is not
the right mailing list for any given topic.
>Anyway, reading the responses, some of the comments/confusion comes
>from (mis)use of terminology and that what I want to get at is a
>definition of what OBO Foundry intends and that logicians
>understand; but this may be futile.
>Briefly, two points on that:
>
>1. I don't know why you insist on only permitting bare-bones graphs
>as ontologies. one can do so much more than just graphs. and triples
>are so RDF-like. the layer cake is there for a reason - to abstract
>away from XML and RDF and be at the KR-level with OWL. Of course,
>one may say so for backward compatibility with the original OBO
>format, which is a consensus or political decision. Then there is
>the issue that if you stay with simple graphs, you don't need the
>whole OWL machinery (and the slower performance that comes with it)
>but you can be better served with DL-languages like EL or DL-Lite
>and their respective better-performance reasoners. Thus, the "you"
>used means "OBO Foundry member(s)", whoever feels s/he can give the
>answer to clarify the policy/preference, if any, for one or the other.
My own personal view is that every ontology should have bare-bones
graphs, including a backbone is_a hierarchy; ontology is an empirical
science, and we are advancing quite rapidly; I do not rule out any of
the nice things you describe.
>2. (minor) when the article start with things like "graph-theoretic
>structure" and the desire for formal/logic-based, then in that
>context of logics, "structure" is the non-empty underlying set and
>interpretation (of a logical formula/theory) and thus,
>mathematically, with a "graph-theoretic structure" you deal with
>instances and to have ontologies of instances only. I'm sure that is
>not your intention.*
It is not our intention. Ontologies are representations of types.
Their terms are used to annotate data about instances derived, e.g.
from laboratory experimentation. How to get OWL (or indeed OBO) to
get this right formally is a problem we are trying to puzzle out.
>But there's room to play in the software realm. The bit before the
>"Er, yes. i think" response just says that you can play with
>transforming instances to types back and/or forward (from the
>computer science perspective and in software implementations!).
The problem is that there is no simple back and forth, unless one
simple identifies OWL classes (e.g.) with sets of instances, and my
OWL friends tell me that this identification is not correct.
>For instance, when you store the GO terms/universals in the current
>GO database, these "universals" are mathematically instances with
>tuples in the database, idem with the FMA that is stored in a
>database (it makes a lot of things easier to implement and reason
>with, although you might find this twisting around unappealing).
Terms represent universals. When we store terms in a database, the
database represents universals. Terms are strings. Universals are
something else. Certainly it is tempting to run the two together.
>If you have your GO/FMA stored in an OWL-DL file, then the GO
>terms/universals are really treated at the type level as "DL
>concepts" in the TBox. Given that types and instances get, e.g.,
>different colours in the GUI, a software developer equally can write
>a piece of code to fetch the instances from the database and
>colour-code then as types/universals in the graphical display so
>that the user can be fooled into thinking they are really
>(representations of) types. But all this does not matter much, and
>maybe it's better ontology content creators don't know about such
>details. It does when trying to define what an ontology is though.
Yes. I think.
Merry Christmas
BS
>p.s. on the "... 'look at this special word, dear reader' quotes
>...": that's what I always have thought they meant, until it was
>pointed out to me that these things are sneer quotes...
They were not, in this case, intended as sneer quotes.
This is one very specific use-case for knowledge representation though. The
tagging of data with well-understood terms is just one of a very wide range
of applications that well-structured ontologies can target. Any methodology
tuned to this use-case is likely to fail to produce ontologies suitable for
different situations, especially if the intent is to off-load much of the
intermediate reasoning about the instance-level data to machines.
Matthew
> BS
best regards,
marijke
C. Maria Keet
KRDB Research Centre
Faculty of Computer Science
Free University of Bozen-Bolzano
Piazza Domenicani 3
39100 Bozen-Bolzano
Italy
tel: +39 04710 16128
fax: +39 04710 16009
email: ke...@inf.unibz.it <mailto:ke...@inf.unibz.it>
web: http://www.inf.unibz.it/krdb/
home: http://www.meteck.org <http://www.meteck.org/>
The world's most successful ontology, thus far, is the Gene Ontology,
which was built around this specific use-case, but which has now
proved useful for many other purposes. I do not, by any means, want
to rule out other uses for ontologies; but do not want to kill the
GOose that is still laying these GOlden eggs.
BS
annotation != tagging
> Matthew
>
>> BS
>
> >
>