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

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

Received on Wednesday, 26 July 2006 14:20:46 UTC