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

--Reto, 

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

Reto, I never said you cannot.  But it won't be a standard practice.  It is
a special application logic that does not apply to general cases. Agree?
Besides, your article is a collection of article, that logic can applies.
If I have a sentence.  "Hello, [Xiaoshu]", with [Xiaoshu] in Chinese,
returning only "Hello" according to Accept-Language:en. would be outrageous
wrong. 

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

Again, take the following example, dereference a URI would return an RDF of
the following,

<> n1:x1 n2:x2 .
n2:x2 n3:x3 n4:x4 .
n4:x4 n5:x5 ...
...

If each ontology/namespace has at least an alternative ontology/namespace,
think about how you are going to make the header to handle n^2
possibilities.

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

You can design a hammer not limited to be just a hammer. You can "extend" it
to make it a saw, and a drill, and a screwdriver, and a stop watch, and a
radio.  The end result of it is this super tool won't help to do one thing
good.  The HTTP is limited because it is designed to be so.  That is not a
valid argument.  Once again, take my example usecase as an example, and
propose a solution and see (1) if it is practical and (2) how won't it
overlap with SPAQL?  

If you have a limited usecase, like the Atom/RSS cases, go ahead and specify
your own convention.  But I don't think it is worthy consideration for more
general cases. 

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

If you invent a new property say - new:knowsWell.  And you have a statement
from

http://eg.com/foo

_:x http://bar.com/newfoaf#knowsWell _:y .

The agent takes this statement should further dereference the
http://bar.com/newfoaf#knowsWell and probably returns back a statement like,

http://bar.com/newfoaf#knowsWell rdfs:subPropertyOf foaf:knows .

It is not at http://eg.com/foo where the inference is done.

Please, let's stop this subject.  I think I have expressed enough of my
concern.  If you think you find a general solution to the general use case I
gave above.  Make you proposal.

Cheers,

Xiaoshu

Received on Thursday, 27 July 2006 19:22:57 UTC