On 26 Jul 2006, at 15:41, Xiaoshu Wang wrote:
The server has the following 7 base triples:
<> a :CategoryList;
:category [ :scheme <http://eg.com/cats/>;
:term "dog" ];
:category [ :scheme <http://eg.com/cats/>;
:term "house" ].
doing OWL-Inference it can infere the following additional 7 triples:
<> a :McDonaldCategoryList;
:McCategory [ :McScheme <http://eg.com/cats/>;
:McTerm "dog" ];
:McCategory [ :McScheme <http://eg.com/cats/>;
:McTerm "house" ].
To allow clients knowing any of the two ontologies to
understand the response the server would deliver all 14
triples. If the requests would have an Accept-Vocabulary
header the client could in this case avoid getting too many
redundant triples. Of course the simple
Accept-Vocabulary-Header doesn't solve the problem of
distributing inference in the general case, whether or not
inferred triples are valuable to the client or a simple
redundancy depends on the client capabilities and of the
cpu/bandwith ratio, additional headers could give the server
some hints.
I am still not sure if I understand you. What is the relationship
between
:CategoryList and :McDonaldCategoryList? Are they under the same
namespace?
If so, how are they related to each other? And why would someone
build two
set of vocabularies to describe the same thing?
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 .
As such if I find a link on the web saying that some resource is
a :CategoryList, I would be in my right to expect certain types of
vocabularies to be used there.
Back to Reto
------------
It is easy to see how it becomes very attractive to think the way
Reto does, since we are defining document types, no longer by looking
at the format, but by looking at the content of the documents. And so
as soon as one does this, one could wonder whether one could not have
semantic content negotiation.
I do find your points concerning this being a problem since it ends
up forcing the web infrastructure to open the packets, to be forceful.
Henry
[1] http://isegserv.itd.rl.ac.uk/schemarama/how.html
Xiaoshu
