VocabularyNegotiation

From W3C Wiki


HTTP Extension For Vocabulary Negotiation

An HTTP extension to allow content negotiation for resources which can be dereferenced to RDF Graphs.

Intro

The HTTP specification define mechanisms for Content Negotiation. Content Negotiation allows a client to get the most suitable representation of a resource which resource is most suitable depends both on the capabilities of the client device and software as well as the abilities and preferences of the user.

Content Negotiation makes an HTTP-URI possibly identify something more abstract than a file, for example the URI [1] identifies the logo of the Swiss Refugee Council, dereferencing the resource con lead to differnt images differing by the language of the contained text. The URI [2] refers to the french version of the logo, for this resource content negotiation can be used to get the most suitable image format.

File based webservers typically allow Content Negotiation by allowing to map an HTTP URL (or the path section of it) to map to a set of different files. Especially content negotiation for natural language prefernces is often used at a more fine grained level, for example if you dereference this Wiki-Page with different language preferences this will change the language of some elements of the navigation while other parts don't change as they are not translated.

If a resource can be dereferenced to an RDF Graph the current possibilities of the server to optimize the response content for the client are limited:

  • It can deliver different serialization of the graph depending on the Accept-Header
  • It may omit triples with a literal object which doesn't match the Accept-Language Header

This page bases on proposals and discussions on the semantic web mailing lists in the threads starting at [3] and [4] which aims to allow an HTTP to optimize the response graph such as by:

  • Omitting triples with predicate the client doesn't understand
  • Provide infered triples it the client does not understand the base triples (such as by providing a subproperty)

Use Cases

Some examples of cases in which vocabulary negotiation could be used

FOAF / Relation / Postal address

http://example.com/me is a personal profile document describing a person using the foaf vocabulary defined at http://xmlns.com/foaf/0.1/, the postal address vocabulary with URI http://wymiwyg.org/ontologies/foaf/postaddress# and teh relationship vocabulary defined at http://vocab.org/relationship/.

  1. The client is only interested in name and postal address and would like to skip the social relations stuff
  2. The client knows only FOAF
  3. The client knows the Relationship vocabulary and the inferable foaf:knows statements are not needed

Solution Approach

An additional Accept-Vocabulary header is defined, similarly to theAccept and the Accept-Language this haeder associates vocabularies and optionally the wildchar to a q-value indicating the preference of the vocabulary.

If the server honours the request it answers a graph containing only triples matching the vocabularies specified in the request. Typically this is a subgraph of the graph that would be returned for a request without Accept-Vocabulary header, as for a request without vocabulary-preferences all possibles triples are returned. TODO: Check if this behaviour should be madatory to allow caching, similarly to the cahcing of partial content responses, or if the server should be allowed to make assumptions about the best vocabularies for a request which doesn't specifies vocabulary-preferences. TODO: response code for partial-triples response.

Questions

Why not just use SPARQL? =

You general arguments applies much more for the gap from HTTP 1.0 to 1.1. HTTP has something which works for documents and for natural language which doesn't works fro graph. Of course you may say "Invent a Graph-Transfer-Protocol for this" but I think its good to see the semantic web as an extension to the current web and not as something which can be tunnelled over it.

SPARQL is a very versatile query language, vocabulary negotiation is not about a generic quering sytem but about getting the represention most suitable to the client, it is a way to have a way to dereference resource best represented by graphs as easy as dereferencing resource represented by a set of documents. Support for vocabulary needs a minimimum of computational power while SPARQL requires the server to handle operations of non-polynomial complexity.

Shouldn't filtering be at another protocol layer than the trasnportanional one?

Does it works only for ontologies defining dieffernt set ofterms for an identical set of concepts?

Why should a webserver look into the document?