Sebastian,
Good stuff and timely, indeed. Can you please tell me, how this
relates to TimBL's notes [1] [2] (if it does)?
I'm especially interested in the following:
+ How exactly is SPARQL utilised in your proposal? See also [3] and
[4] for related work.
+ How is authentication and authorisation handled (like WebID [5]
and WAC [6])?
Cheers,
Michael
[1] http://www.w3.org/DesignIssues/ReadWriteLinkedData.html
[2] http://www.w3.org/DesignIssues/CloudStorage.html
[3] http://www.w3.org/TR/sparql11-http-rdf-update/
[4] http://portal.acm.org/citation.cfm?id=1645412
[5] http://www.w3.org/2005/Incubator/webid/spec/
[6] http://www.w3.org/wiki/WebAccessControl
--
Dr. Michael Hausenblas, Research Fellow
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html
On 5 May 2011, at 09:12, Sebastian Schaffert wrote:
Dear all,
in the context of our work in Salzburg NewMediaLab and the KiWi EU
project before, we had an idea that I would like to get feedback
from the Linked Data Community. We are also writing on an article
about it (probably for ISWC), but I think it makes sense to discuss
the idea in advance. Maybe there is also a bit of related work that
we are not yet aware of.
Salzburg NewMediaLab is a close-to-industry research project in the
media/broadcasting and the enterprise knowledge management domain.
Goal of the current phase is to connect enterprise archives
(multimedia but also other) with Linked (Open) Data sources to
provide added value. In this context, it is not only relevant to
publish and consume Linked Data, we also had the requirements to be
able to easily update Linked Data and also to manage content and
metadata in a uniform way. We therefore call our extension "Linked
Media", and I am going to briefly describe it in a rather informal
way.
Background
----------
The idea is a kind of combination of concepts from Linked Data,
Media Management and Enterprise Knowledge Management (from KiWi). Up
till now, the Linked Data world is read-only and primarily concerned
with the structured data associated with a resource (regardless of
whether this data is represented in RDF or visualised in HTML).
However, in order to build more interactive mashups, it would make
sense to also allow updates to the data in Linked Data servers. And
in enterprise settings, it makes sense to have a unified means to
manage both structured data and human-readable content for a
resource. For example, a resource might represent a video on the
internet, and depending on how I access the video I want to get
either the video itself or the structured metadata about the video
(e.g. a list of RDF links to DBPedia for all persons depicted in the
video).
Our Linked Media idea tries to address both issues:
- it extends the Linked Data principles with RESTful principles for
addition, modification, and deletion of resources
- it extends the Linked Data principles by means to manage content
and meta-data alike using MIME to URL mapping
Linked Media Idea
-----------------
1. extending the Linked Data principles for updates using REST
Linked Data is currently "read-only" and depending on Accept headers
in the HTTP request, it redirects a request to the appropriate
representation (RDF or HTML). For supporting updates in Linked Data,
a consequent extension of Linked Data is to apply REST and otherwise
use the same or analgous principles. This means that GET is used to
retrieve a resource, POST is used to create a resource, PUT is used
to update a resource, and DELETE is used to remove a resource. In
case of GET, the Accept header determines what to retrieve and
redirects to the appropriate URL; in case of PUT, the Content-Type
header determines what to update and also redirects to the
appropriate URL. This extension is therefore fully backwards
compatible to Linked Data, i.e. each Linked Media server is a Linked
Data server.
2. extending the Linked Data principles for arbitrary content using
MIME mapping and "rel" Content Type
Linked Data currently distinguishes between an RDF representation
and a human readable representation in the GET request. The GET
request then redirects either to the URL of the RDF representation
or to the URL of the human readable (HTML) representation. We
extended this principle so that it can handle arbitrary formats
based on the MIME type in Accept/Content-Type headers and so that it
can still distinguish between content and metadata based on the
"rel" extension for Accept/Content-Type headers.
The basic idea is to rewrite resource URLs of the form http://localhost/resource/1234
depending on the MIME type as follows:
- if the Accept/Content-Type header is of the form "Accept: type/
subtype; rel=content", then the redirect URL is http://localhost/content/type/subtype/1234
; when this URL is requested, the Linked Media Server will deliver
the CONTENT of the resource in the content type passed, or it will
return "415 Unsupported Media Format" in case the content is not
available in this MIME type
- if the Accept/Content-Type header is of the form "Accept: type/
subtype; rel=meta", them the redirect URL is http://localhost/meta/type/subtype/1234
; when the URL is requested, the Linked Media Server will delivered
METADATA associated with the resource and tries to seralise it in
the content type passed (or again returns 415); in this way,
different RDF serialisations can be supported, e.g. RDF/JSON
The differentiation between content and metadata using "rel" is
necessary for a "kind-of" reification, because we need to be able to
distinguish between an RDF/XML document stored in the server (i.e.
content) and the metadata associated with it (i.e. metadata). The
same holds for human-readable content: "Accept: text/html;
rel=content" will return the HTML content, while "Accept: text/html;
rel=meta" will return an HTML visualisation of the metadata (e.g. as
a table).
This extension is also fully backwards-compatible to Linked Data,
because the default behaviour (if no "rel" is given) is "rel=meta".
So in case a Linked Data client accesses the Linked Media server, it
will behave as expected.
Implementation / Principles
---------------------------
What we implemented in our Linked Media Server is therefore the
following extensions (to simplify the presentation, I am always
using a concrete resource URI, but it can be more or less arbitrary):
- GET http://localhost/resource/1234
in case the resource does not exist, returns a "404 Not Found",
otherwise, a "303 See Other" as follows:
1. header: "Accept: type/subtype; rel=content" will redirect to http://localhost/content/type/subtype/1234
; requesting the URL will return the content in the format requested
by the MIME type if available; the HTTP response will then contain a
"Link:" header linking to all metadata representations of the URL in
all metadata serialisation formats supported; in case the resource
is not available in the format requested, returns "415 Unsupported
Media Type"
2. header: "Accept: type/subtype; rel=meta" will redirect to http://localhost/meta/type/subtype/1234
; requesting the URL will return the RDF metadata about the resource
in the format requested by the MIME type; the HTTP response will
then contain a "Link:" header linking to all content representations
of the URL in all content formats available; in case the resource
metadata is not available in the format requested, returns "415
Unsupported Media Type"
- POST http://localhost/resource/1234
will create the resource with the URI given and return "201
Created"; the response will contain a "Location:" header pointing to
the URL
- POST http://localhost/resource
will create a resource with a random URI and return "201 Created";
the response will contain a "Location:" header pointing to the
generated URL
- PUT http://localhost/resource/1234
in case the resource does not exist, returns a "404 Not Found",
otherwise a "303 See Other" analoguous to GET, but instead of the
"Accept" header, the "Content-Type" header is used:
1. header: "Content-Type: type/subtype; rel=content" will redirect
to the content location as in GET; a subsequent PUT to the
redirected URL will upload the content in the given MIME type and
stored on the server; returns a "200 Ok" in case of successful
upload or different error codes in case of errors
2. header: "Content-Type: type/subtype; rel=meta" will redirect to
the metadata location as in GET; a subsequent PUT to the redirected
URL will upload the metadata in the given MIME type, which will then
be parsed by the server and stored in the triple store; returns a
"200 Ok" in case of successful upload or a "415 Unsupported Media
Type" in case the parser does not exist, or also other error codes
- DELETE http://localhost/resource/1234
in case the resource does not exist, returns a "404 Not Found",
otherwise removes the resource and returns a "200 Ok"; removing the
resource removes all content and all metadata (currently all triples
where the resource is subject, object or predicate) from the triple
store
This all is implemented in our Liked Media Server (aka KiWi 2.0)
where we will have a first pre-release end of the week. We are also
preparing a screencast of a demo of the implementation, which in
addition to these Linked Media functionalities also offers a
Semantic Search that allows a uniform way of fulltext querying and
SPARQL querying.
What do you think of this idea? Would this be a reasonable extension
to Linked Data? In any case it fulfills the requirements that we
have in our industry projects, so we will follow it further. As I
said, we are also planning a more detailed and elaborated submission
to the ISWC In-Use Track and also to the ISWC Demo Track, so there
will hopefully be a chance to also discuss it there ...
Greetings,
Sebastian
--
| Dr. Sebastian Schaffert [email protected]
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662
2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
