Content negotiation
An important notion of Linked Data is that a URI identifies a resource, but a resource can have different representations of the same content
- A HTML page describing the resource
- RDF data describing the resource
- XML, CSV, etc data
- etc
Content negotiation is the process by which the server provides the appropriate representation for each client, according to the MIME type of the Accept header provided by the client (text/html for a web browser, application/rdf+xml for an RDF agent, etc.).
The content negotiation process at Open Data Euskadi is designed in the same way as in DBpedia. Given a URI, the content negotiation process redirects the client with HTTP 303 codes to the appropriate URLs containing representations (page or data URLs).
In the case of Open Data Euskadi there is an additional consideration since some resources can hava an associated web page (ie a formal human oriented web page describing the resource) while other resources do NOT have a web page (they're only data) so if the client requests HTML content for the resource URI (http://id.euskadi.eus/{resource}):
- If the {resource} has an asocciated formal web, the client is redirected to that web page (ie: www.euskadi.eus/{resource}) when requesting http://id.euskadi.eus/{resource} with mime=html
- If the {resource} does NOT have an associated formal web, when the client requests html content for http://id.euskadi.eus/{resource}, the client is redirected to http://doc.euskadi.eus/{resource} where Epimorhic's ELDA is used to return an HTML representation for the resource's data
Internally, when the client requests html data for a {resource}, the [URI handler] (the open-data euskadi's module in charge of content negotiation) issues a [triple-store] query to guess if that {resource} has a main-entity-of-page property that points to the formal web page; if this is the case, a 303 redir to that page is returned, if not, a 303 redir to http://doc.euskadi.eus/{resource} is returned
If the client requests a not-html content type (ie RDF, Turtle, etc),, the [URI handler] redirects the client to http://data.euskadi.eus/{resource}
So the URI api is consistent:
- {resources} are iidentified by URIs like: http://id.euskadi.eus/{resource}
- Requesting a {resource} url (http://id.euskadi.eus/{resource}) with content type = html, results with a 303 redirect response to http://doc.euskadi.eus/{resource}
- While requesting a {resource} uri (http://id.euskadi.eus/{resource}) iwith content type other than html, results with a 303 redirect response to http://data.euskadi.eus/{resource}
Obviously if one knows beforehand that the html representation of the resource is required, the client can call directly http://doc.euskadi.eus/{resource}; in the same way, if the data is required, the client can call http://data.euskadi.eus/{resource} with the appropiate content-type
The following is an schema of the [URI handler] (the opendata euskadi's module in charge of content negotiation)
^
| +--------------------------+
+ | http://idsite/{resource} |
Resource +-------------+------------+
URIs |
+ Is main entity |
| +---+ of page? +-----+MIME=HTML+-----+-----+MIME=RDF+--------+
| | |
| +------------+-------------+ |
| | | |
| | | |
| | | |
+---------------------------------------------------+[***** CLIENT REDIR ****]+----------------------------------+
| | | |
| | |
| +----------v--------------+ +---------v---------------+ +------------v-------------+
| |http://docsite/{resource}| |http://website/{resource}| |http://datasite/{resource}|
+ +----------+--------------+ +---------+---------------+ +------------+-------------+
| | |
Representation | | |
URLs | | |
+ +------v-------+ +---------v--------+ +--------v--------+
| | | | | | |
| | ELDA | | Web | | Triple+Store |
| | | | | | |
v +--------------+ +------------------+ +-----------------+
The list of supported MIME types can be found at the RDF4J REST API documentation.