W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > September 2006

RE: A question on the vocabulary for 'persons' - ACL level of granularity?

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Sun, 17 Sep 2006 13:13:58 -0400
Message-ID: <17677.33366.711382.681244@drew-mcdermotts-computer.local>
To: public-semweb-lifesci@w3.org

> [Xiaoshu Wang]
> Well, how can a computer knows my intension about the parts that I don't
> "use/disagree"?  But, I think, if I disagree one portion of the ontology, I
> certainly would not use the other part of the ontology at all since if I
> make one contradicting statement, it will invalidate the entire model.

Just to be clear: I agree with you that one shouldn't import an
ontology that you disagree with part of.  (That is, an ontology
containing parts that may contradict assertions you make now or

> Hence, even if I don't disagree but just no use certain part of an ontology.
> How do I know if those who want to use my ontology but disagree the imported
> other part.  For example, if I develop a ex:Patient and make it a
> rdfs:subClassOf the foaf:Person.  Personally, I don't care the
> foaf:geekcodes.  But what if other, for example, Chris Mungall like my
> ex:Patient but not the foaf:geekcodes, it will force him to not use
> ex:Patient but develop another cm:Patient, where he might make a statement
> saying that "there is no such thing as foaf:geekcodes".  Now the world
> becomes messy because a simple mappying from ex:Patient to cm:Patient with
> owl:equivalentClass won't be able to remove the contradiction.  Then, what
> if someone disagree the online account part of foaf, or Organization, or
> even Agent?  

I don't see how you can possibly avoid this problem.  If you craft an
ontology that consists of various imported ontologies plus your own
stuff, then of course someone else may not be able to use it.  If you
think the presence of "geekcodes" makes this more likely, and the
risks of imprting FOAF are too great, okay.  But the same issues are
going to come up with other ontologies.

> Do you mean just use the URI without importing it? 

I mean, just do what they do in the XML world.  Declare the namespace
and use it.

> If so, I am not sure how
> it will work?  One of the neat features of the web is its loosely coupled
> nature.  But you need to follow your nose to know more about the resource.
> Without "importing", i.e., to fetch the resource description from the
> namespace, what is the use of it?  For instance, if given a dublin core URI
> http://purl.org/dc/elements/1.1/creator, without following the URI, I won't
> even know how I should label it.

Granted, you have to know what the vocabulary items are in order to use
them.  The purpose of using them without importing anything is to
declare that your intent is to use that symbol with its intendend
meaning rather than invent your own and clutter up people's heads with
a synonym.

I can anticipate your reaction: Without the ontology, how does the
symbol get the intended meaning, or any meaning?  Answer: Ontologies
don't actually give symbols meanings, so their absence doesn't take
meaning away.  I know this may sound shocking, and I feel like a
parent revealing the truth about Santa Claus, but all the axioms in
ontologies can do is _constrain_ the meanings of symbols.  It's a well
known theorem of formal semantics that it can never constrain them
fully (or enough).  So in practice the axioms must always be
supplemented by informal documentation or even unspoken assumptions
about the way a symbol is supposed to work.  (Even this doesn't get us
all the way, unless we adopt some mystical tenets about the human
mind.)  Whenever there's confusion about a symbol, or a needed
inference arises that the current ontology doesn't license, we add
axioms and constrain the meaning further.

So, if you want to use an ontology's namespace, and maybe copy a few
axioms from it, without importing it, I think you should just go

   Drew McDermott
   Yale Computer Science Department
Received on Sunday, 17 September 2006 17:14:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:28 UTC