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

Xiaoshu Wang wrote:
> [...]
>
> In the second case, I have a document in Chinese but sprinkled with some
> paragraphs in Engish.  If you ask me to return only those paragraphs in
> English, you are asking too much, don't you think?
>   
I implemented exactly this in KnoBot [1]: When requesting a page with
multiple articles where not all articles are available in the same set
of languages a polyglot user with multiple languages in the
Accept-Language header may get a page with the navigation and some
articles in his prefered language and other articles in an language with
a lower q-value [2].
> [...]
>
> Again, they are two independent documents representing the same resource.
> They are not two parts residing in one document, with part-1 being in atom
> and part-2 in RSS.  
>   
So I think that for many resources there are many independent but
non-contradicting graphs representing the resource, HTTP does not yet
have a method to allow content negotiation when a Resource can be
represented by a set of graphs.
>> How can I do something 
>> similar for RDF oriented clients with different levels of 
>> understanding of AtomOWL, AtomRDF, RSS 1.0 and/or RSS 1.1? 
>> Delivering several triples with identical (or near identical) 
>> meaning for every assertion an saying "sort it out when it 
>> gets to your home" doesn't seem ideal to me.
>>     
>
> I have answered this question before.  But let me repeat it again.  Your are
> only thinking in very limited use case with the returned RDF triples
> described in vocabularies from only one namespace.  But RDF is not limited
> to that.  An RDF document can be constructed in vocabularies from any number
> of namespaces. 
I perfectly agree with that and I was talking about response-graphs with
typically use multiple ontologies.
>  How can you possibly put all sorts of combinations in an
> HTTP header?
>   
It is probably true that the average number of vocabularies understood
by a client is higher than the average number of natural language
understood by a human user. I think a useful degree of  vocabulary
negotiation could be done by defining an extra HTTP-Header and that this
would suit well with the existing content-negotiation mechanism. The
exact definition of such a header is yet to be done, does the value name
an ontology? a collection of ontologies or properties? An URI-Prefix?
Keeping the requests small is certainly a goal when defining such a header.
> Such kind of reasoning is faulty: if I can do it in XML, why cann't I do it
> in RDF?  Or vice versa.  By the same logic, everything doable in XML can
> also be done in RDF and vice versa, why do we bother to start RDF anyway?
> The inherent differences between XML and RDF are huge, though appears
> subtle.   
>   
A too narrow notion of the range of HTTP URIs as files or set of files
doesn't make it a good basis  for RESTful semantic web applications. The
HTTP namespace names things like ontologies for which the existing
content negotiation mechanisms are extremely limited.
> Besides, do you ever write an article putting all possible synonyms in it?
> I am not sure about you, but I never did.  It is the same for RDF.  No one
> would write the same description in all available vocabularies.  If it were
> me, I will choose the best sets that I think benefit me.  Whether you
> understand my description or not is not my concern.  Of course, if I
> eventually found out that I am using sets of obsolete vocabularies that hurt
> my resource being understood by others, it will force me to change my
> description in more popular terms. 
While the convergence of languages is generally a good thing and does
happen, synonyms do and will always exist, as well as transitions from
one domain-predominant ontology to another. During the transition phase
a non-lazy and well educated server should try to give the response the
client can best deal with.

But synonyms are only one case, say I choose to use more specific
subproperties of foaf:knows to describe social relations: while I'm
confident that the trendy ontology I'm using will soon be wide spread,
my server uses inferences to add inferred statements with foaf:knows. In
this case either the statements with foaf:knows or the one using the
subproperty of it will not be of any use to the client, vocabulary
negotiation could avoid this.

Cheers,
Reto

1. http://wymiwyg.org/knobot
2. The feature is used for example on the page <http://wwww.osar.ch/>
showing articles mostly in German and French but also some english
content (for a mixed-content page use Accept-Language: en,fr;q=0.8,de;q=0.5