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

RE: Semantic content negotiation (was Re: expectations of vocabulary)

From: Xiaoshu Wang <wangxiao@musc.edu>
Date: Wed, 26 Jul 2006 10:56:08 -0400
To: "'Henry Story'" <henry.story@bblfish.net>
Cc: "''Reto Bachmann-Gmür' '" <reto@gmuer.ch>, <public-semweb-lifesci@w3.org>, "'Semantic Web'" <semantic-web@w3.org>
Message-ID: <002901c6b0c3$a0bd4e30$4a741780@bioxiao>

-- Henry, 

> Good questions. My fault in not being careful with the 
> example. I intended them to be under different namespaces. So 
> the examples should be
> 
> <> a :CategoryList;
>     :category [ :scheme <http://eg.com/cats/>;
>                 :term "dog" ];
>     :category [ :scheme <http://eg.com/cats/>;
>                 :term "house" ].
> 
> but I receive this
> 
> <> a mcdo:CategoryList;
>     mcdo:category [ mcdo:scheme <http://eg.com/cats/>;
>                 mcdo:term "dog" ];
>     mcdo:category [ mcdo:scheme <http://eg.com/cats/>;
>                 mcdo:term "house" ].
> 
> > Or they are supposed to be under different namespace? So, 
> the server 
> > that you have in mind is much more an "ontology warehouse" 
> than plain 
> > ontology?
> > I am still not clear what you intends to do?
> 
> Given the above correction I should mention again that the 
> problem I was looking to solve is a little different from the 
> one Reto would like to solve - though his problem does build on mine.
> 
> I was just looking to see if there was a way to specify the 
> content of rdf documents, because otherwise the flexibility 
> of rdf could also be its doom. If there were no way to expect 
> that I would receive the first document rather than the 
> second, since they both make the same statements about the 
> world, then there would be no way to tell if I could ever 
> seriously follow rdf links over the web.
> 
> But given that it is not impossible, if schemerama2 [1] type 
> proposals can be formalised, then it looks like one can 
> specify documents, not just by their format, but also by 
> their content.  This can then solve the problem I put forward 
> above: since a document that contained the sentence "<> a 
> mcdo:CategoryList ." but not the sentence "<> a :CategoryList 
> ." would just simply be lying, even though
> 
> mcdo:CategoryList owl:sameAs :CategoryList .

Now at least we are clear about the problem.  Hence, what you wanted is not
a "partial" content but instead of a description in what kind of "dialect".
Then, I don't see any fundmental problem. However, now the problem is
practicality.  Your example only gives one "dialect" of a particular nature.
For instance, if I want to describe me, I would have considered dialects
regarding color, heights, weight, etc.  Think about how you are going to put
all these kind of request in the header.

Second, if I intend to describe a resource that I own. I will choose the set
of vocabulary that I think is most appropriate.  Rarely will I consider
describe it in two similar vocabularies.  And honestly, I think, that we
SHOULD not use multiple categories.

Then if you dereference my resource URI and get back an assertion:

<> a mcdo:CategoryList;

Then you further dereference the mcdo:CategoryList to see if there is

mcdo:CategoryList owl:sameAs :CategoryList .

Whether mcdo assert this or not is up to the mcdo designer.  It is not my
concern.  The key to semantic web is sharing ontology.  The reason that I
think we SHOULD not describe one resource in multiple similar vocabularies
is: by this we can forcefully select the "good" ontology because what is
shared the most has the best chance to survive.  If two competing ontologies
both survive, then their mapping will be known, more likely pre-known by the
software agent, or be put in their respective ontologies. But in any case,
it is up to ontology designer to think how to design their ontology that can
be maximumly shared and reused but not the concern of an ontology's user and
therefore definitely not the concern of transportation.

Cheers,

Xiaoshu 
Received on Wednesday, 26 July 2006 15:12:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:44 GMT