Re: Linked Media: Extending Linked Data for Updates and arbitrary Media Formats using the REST Principles

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          sebastian.schaffert@salzburgresearch.at
> | 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
>
>

Received on Thursday, 5 May 2011 08:34:46 UTC