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
