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: Xiaoshu Wang <wangxiao@musc.edu>
Date: Mon, 18 Sep 2006 00:55:52 -0400
To: <drew.mcdermott@yale.edu>, <public-semweb-lifesci@w3.org>
Cc: "'Dan Brickley'" <danbri@danbri.org>
Message-ID: <000501c6dade$b7bb0600$25241780@bioxiao>


> > 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.

No, it doesn't sound shocking to me at all.  This is exactly what I have
comprehended.  I think each URI has two levels of semantics.  The first
level is extensional.  For instance, http://xmlns.com/foaf/0.1/Person
represents a Person, whatever it is meant.  The second level is intensional,
where, as you said, we "constrain them" by associating them with other
resources.  To increase ontology's sharing and reuse, the first thing to do
is to remove the hard dependency between ontologies (the same we learnt in
software engineering).  I have named the similar process to ontology as
ontology normalization.  

For instance, we can use one namespace say,
http://example.com/foaf_vocabulary, to group all existing foaf URI with only
AnnotationProperty but no any other constraints.  And use another namespace,
say http://example.com/foaf_ontology_v1, to put all these constraints. 

By this normalization, which I named extensional normalization, we can
freely used the URI without any other potential implications.  Then, in an
instance document, we can say

_:xiaoshu_wang a http://example.com/foaf_vocabulary/Person .
http://example.com/foaf_vocabulary/Persoon rdfs:isDefinedBy
http://example.com/foaf_ontology_v1 .

With such normalization, the meaning of the URI is stable.  For instance, if
foaf evolve to v2, which contains some incompatible statement with v1, a new
namespace http://example.com/foaf_ontology_v2 can be created.  And it won't
break the existing application that depends on the v1. 

There is another normalization, which I named intensional normalization, I
will skip the details here.  There are some brief description about it at
http://www.charlestoncore.org/ont/2005/08/o3.html, I also have a manuscript,
if you are interested I will send you a draft copy. 

If Dan does not object, I don't mind playing around with FOAF, trying to
modulize it a bit and then normalize it and see how everyone think about it?


Received on Monday, 18 September 2006 04:56:04 UTC

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