Re: [rest-discuss] Re: The relation of Linked Data/Semantic Web to REST
Barry Norton
Bob, there's already quite a few of the semantics crowd working explicitly in this area.
Reto Krummenacher, who I worked with in Innsbruck, and I had a tutorial on 'Linked Open Services' at ISWC last year. There's work at Karlsruhe (where I moved) on 'Linked Data Services', looking closely into the interlinkage of service results as well as 'query planning' over RDF-based retrieval operations. Also there's work (from my former colleagues) at the OU who originally coined the term 'Linked Services' - they're particularly concerned with exposing service descriptions as Linked Data (indeed you'll see their iServe tool as one of the bubbles in the latest Linking Open Data Cloud).
As you observe, most of the best practice around Linked Data is simply about retrieval. Even with updates in SPARQL 1.1, and its bindings (and some other read/write approaches to Linked Data) there's very often a naive notion of pushing complete RDF descriptions of resources / named graphs, and little accomodation of computation and side effects resulting from interactions, which one expects with services. In Linked Open Services we try to bring more of REST together with Linked Data and have many (RDF-exchanging) services that create new addressable REST resources, i.e. that can be, say, DELETEd but also POSTed to individually.
I'd say two important questions with RDF-based communications are: (as you said) how to use RDF in the equivalent/supplementary role as HATEOS (to make the future state and interactions 'machine processable' in an RDF/inference-driven way); (additionally) how to describe messages expected in a Linked Data compatible way.
To the latter question the Linked Open Services and Linked Data Services work proved almost exactly coincident in both picking SPARQL graph patterns. Very much like the static data argument for flexibility (extensible graph constraints versus fixed - difficult to compatibly extend, difficult to reuse without planning - schemas), we find that this is a very intuitive way to describe what the service would like you to submit, and what you can expect to receive back (in RDF form).
I've CCed the Google Group we'd all started together, but not yet advertised, hoping that some of the other guys will jump in here.
Barry
On 31/01/2011 13:14, Danny wrote:
Hi Bob,
Glad you've brough this up, and I reckon you've pretty well scoped the domain.
Generally I'd say that Linked Data/Semantic Web technologies do fit well with the REST model. The separation between resources and their representations allow resources that correspond to non-document things (concepts, real-world objects etc) to have HTTP-friendly representations. (having said that, http-range-14 is a bit of a rathole, but the TAG's resolution with 303s etc seems Good Enough).
So this part I suggest could be called "transparent", there aren't really any interop obstacles on the horizon from the perspectives of REST, HTTP or Semantic Web/Linked Data.
But your following comments do raise some very interesting issues.
> [...] Hypermedia Driven Application State of the REST principles. This principle can again be powered for better machine processing by using the common knowledge representation languages of the Semantic Web as basis.
Ok, agreed. By generalizing from documents to /anything/, the resources and their relationships (via their representations), are potentially a lot more open to direct machine processing.
> However, I'm a bit unclear how the links drive my application state. Although, I guess that the application state would change when navigating to a resource by dereferencing a link (HTTP URI).
> This is explained in the introduction section of Principled Design of the Modern Web Architecture[13]:
>
> The name "Representational State Transfer" is intended to evoke an image of how a well-designed Web application behaves: a network of Web pages forms a virtual state machine allowing a user to progress through the application by selecting a link or submitting a short data-entry form, with each action resulting in a transition to the next state of the application by transferring a representation of that state to the user.
Right, that's my understanding too.
With most current applications the state that's needed is fairly trivial. The primary Web application, the browser, only usually deals with a handful of resources at a time. Even with things like proxies, aggregators, spider-based agents etc, the interactions are individually very simple, it's just there are a lot more of them going on concurrently.
On the other hand I suspect SW/LD applications are likely to be a lot more demanding in terms of complexity of state. A representation of a resource (plus HTTP headers) can contain a lot more resource-related machine-usable information than an opaque blob or even a HTML document with hrefs.
The water around Web applications has been muddied somewhat by systems that rely on server-side state and coupling to the client: "I can't do that without cookies", and RPC still pops up here and there, however disguised.
(Aside: I'd be interested in pointers to material that walks the reader from this mindset to something more RESTful).
But with SW/LD apps we kind-of have a chance to start from year zero and do things *right*. The links you provided and the Linked Data Patterns book [1] are good steps in this direction (as hopefully so so too the Linked Data book [2]).
> Stateless Interaction is not really covered by the Linked Data principles as defined by timbl[9], or? Although, when realizing "state as a resource" (cf. [15]), I can use again the common knowledge representation languages of the Semantic Web as basis for describing states and using HTTP URIs to make these resources also accessible.
Yes - although the "transparency" here is not so obvious.
> Would you agree with (parts of) my interpretation?
Generally, yes.
> Finally, are the principles of Linked Data really only intended to be read-only. I though read and write would better fit to the principles of REST, or?
A very good point. Read, write and the other operations covered by HTTP methods should ideally be a core part of LD/SW systems from the get-go (otherwise things will be a bit boring!).
It has taken the Web quite a while to get more read/write despite the capability being there from the start. CMSs and blogging tools, things like Twitter and Facebook do help extend the media from broadcast to peer (few publishers/many consumers -> many publishers/many consumers). Even within these useful systems there are various Web anti-patterns, most notably the closed data silo as opposed to linked open data (LOD, [3]).
(heh, speaking of which I might well repost this mail on my blog, or at least tweet it...)
Hopefully, thanks to the explosion in publication of RDFa - 3.6% of webpages now contain RDFa [4] - we will soon be seeing a lot more diverse use made of the technologies from folks that aren't coming straight from the traditional (incomprehensible ;) SW/LD communities.
There may well also be some more useful infrastructure subsystem bits (akin to those described by Fielding in his thesis) enabled by RESTful HTTP + semweb tech. For example, an RDF store (server- or client-side) is essentially a cache of a little chunk of the Web of Data. A SPARQL endpoint offers an efficient mode of access to that cache. Going one step further, a generic intelligent linked data proxy could be composed this way.
The current generation of mainstream RDF/SW/LD applications seem to be mostly limited either catalog-like systems (e.g. the drug DBs and the BBC) or the augmentation of search (e.g. Yahoo! SearchMonkey and Google Rich Snippets). Useful those these may be, they aren't exactly inspiring.
Going off-topic a little, I reckon the parts needed for a really useful, compelling and *interesting* Web of data include:
* improved linkage between data sets, to facilitate easier discovery
* refactoring of traditional data-based activities to use (just-in-time) linked data
* new user interface paradigms to work with linked data
* a lot more imagination!
I reckon there's easily enough momentum to make progress down this track inevitable - the question is what do we need to do to lubricate the wheels and move a bit faster.
Cheers,
Danny.
[1] http://patterns.dataincubator.org/book/
[2] http://tomheath.com/blog/2011/01/the-linked-data-book-draft-table-of-contents/
[3] http://esw.w3.org/SweoIG/TaskForces/CommunityProjects/LinkingOpenData
[4] http://tripletalk.wordpress.com/2011/01/25/rdfa-deployment-across-the-web/
__._,_.___![Yahoo! Groups]()
.![]()
__,_._,___