Re: Interaction and REST focus

On Nov 8, 2012, at 02:56 PM, Kjetil Kjernsmo wrote:

> Hi all!
> 
> First, I should congratulate you with such an excellent first public working draft of the Linked Data Platform! However, in doing so, you violated the first principle of FPWDs of my former boss chaals: He said that FPWDs should be really bad, to bring out all the fury of the people just sitting idly by and thus get all the arguments to the surface before putting too much effort into it. And while I appreciate your work, I shall have to come out in all my fury, which is too bad, since you already wrote a very comprehensive and thorough spec. ;-) 
> 
> I think we, as a community, have become somewhat too narrow-minded and constrained to HTTP due to the Linked Data principles. That is not to say that HTTP isn't the most suitable protocol and that HTTP URIs aren't the best URIs, they are, but it steals focus from what we should be thinking about first. 

+1


> I think the charter has a clear mandate for a non-HTTP focus, even though it also has a clear misunderstanding of HTTP in REST. This misunderstand is so common that Roy Fielding has commented on it in a blog post:
> <http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven>
> 
> "A REST API should not be dependent on any single communication protocol," which is broken in the very first requirement:
> 
>    "4.1.1 LDPR servers must at least be HTTP/1.1 conformant servers".

Sadly, +1.


> So, the problem here is that people generally agree that REST is important, but they aren't sure why. Now, let me shamelessly plug my paper from the ESWC LAPIS2012 workshop: "The necessity of hypermedia RDF and an approach to achieve it", with paper and slides (you may prefer the latter) respectively at 
> <http://folk.uio.no/kjekje/2012/hypermedia-rdf.pdf>
> <http://folk.uio.no/kjekje/2012/lapis2012.xhtml>
> 
> In there, I hint at a different focus: See, the thing isn't just that we need to use HTTP verbs to read or write stuff, that's the trivial part. What we need to think about is what kind of interactions made possible by the protocol. Now, with this spec, if I have some resource, I still have to look up your out-of-band specification to figure out how I can edit it, though with HTTP, I can figure out that I can edit by looking at the Allow header by taking the extra effort of doing a HEAD first.
> 
> In my talk, I said that REST implies that "don't make developers look up the spec", let me reformulate that a bit: "Systems that require developers to frequently look up specifications will over time loose to systems that do not", or something like that. REST is there because it is far easier to just "View Source" and then you have what you need to do the Right Thing[tm]. Moreover, by having what you need right there, up front, in the message, you can automate things that you cannot automate if you need a human looking up the spec. That's partly why RDF is self-describing, right?
> 
> So, that's what we need to focus on: The message, not the protocol!

+1


> In my paper, I propose not only ways to express what write operations are allowed, but also some links to read-only resources. However, it is much more to be explored there. In the original Linked Data Design Issue, timbl introduces the concept of a "Browsable Graph":
> <http://www.w3.org/DesignIssues/LinkedData> 
> where part of the definition is "Returning all statements where the node is a subject or object; and Describing all blank nodes attached to the node by one arc. " (go check it if the context isn't clear)
> Note the object part, because I think we have a potential for a lot of confusion and incompatibilities there, since the current spec says: 
> 
>    "4.4.5 A LDPR client must preserve all triples retrieved
>    using HTTP GET that it doesn’t change whether it understands
>    the predicates or not, when its intent is to perform an update
>    using HTTP PUT. "

I think that the client actually needn't preserve *anything* it's 
not going to PUT back, whether changed or not -- because Open World 
states that anything unstated is unknown -- so anything the client 
doesn't know (and doesn't PUT) but the server does know (and returned 
in the GET) should then be preserved (or not) by the *server* and its 
own logic/programming.


> So, following timbl's advice, we would PUT back triples that has the Request-URI as object, not subject. OMG, the horror! ;-) 
> 
> It gets worse though, because in near future, the server might have much more data than is reasonable to communicate in a single message, and paging might be the wrong solution, since it doesn't say anything about what is relevant by any measure... 
> 
> I think that timbl's "browsable graphs" will also be obsolete in many cases.
> 
> You can't just return an RDF molecule, or a concise bounded graph, or an spo = Request-URI ?p ?o. Many of the reasons are already listed in the next section "Limitations on browseable data" in the Design Issue. Instead, Linked Data Information Architects (who is the first to have such a title? :-) ) would have to think carefully about the interactions they would enable by the data. And then, we're not just talking about replacing a resource or merging more triples into it. Perhaps there are a whole lot of sensor readings for example for a certain resource, they may want to provide some digest and link to more readings, carefully thinking about what that digest should be, just like you're not putting all your relevant links in a hypertext document, that's up to the author. In some cases, the first thing an agent might want to do is to put sensor data that pertains to a certain resource, and lots of it. Making this interaction efficient will be the chief concern of the Linked Data Information Architect. Without this, Linked Data servers will be just like the web pages of 1996 that contained mostly links to other pages, but very little new information of value... 
> 
> However, this WG cannot foresee these developments, and it is a 1.0 spec after all. What I expect of 1.0 is a basic set of interactions and some constraints on what triples can be expected to be returned and what MUST be accepted and what SHOULD be accepted and what MUST NOT. 

+1


> To understand this last point, lets go back to the SPARQL Graph Store. I helped conceive that spec back in the day, thinking we would one day understand what REST could do for us. Then, we got distracted by HTTP, indirect identification and all that kind of stuff, and it ended up in something non-RESTful. The main difference, as I see it, is this:
> 
> With the Graph Store spec, the Request-URI is just a name for a bunch of triples. It could be just about any bunch of triples, the Request-URI is not even likely to be subject or object of any of the triples, but I guess it could be.
> 
> On the Linked Data Platform, this is not the case, at the very least you'd expect that the Request-URI has to be the subject of some of the triples in the result, and the platform may legitimately reject or ignore triples sent to it that doesn't have the Request-URI as the subject, or some other criteria. This makes the Linked Data Platform much more complex than just a Graph Store, but other than that, in particular considering the interactions you can do with it, it is the same beast.
> 
> The interactions you are allowed to do, must be immediately clear when you have a representation of a resource, that's the most efficient way to do things, and to do that, it must be part of the message somehow.

+1

Regards,

Ted


> I believe this is where most of the effort should be spent, because it is not going to be easy. Once that's done, adding HTTP is going to be easy. It would be particularly nice if that could be done in-band too, i.e. in terms of a vocabulary. In my talk, I proposed doing stuff like this on every resource that can be POSTed to:
> 
>    <> hm:canBe hm:mergedInto .
> 
> Then, the object of that can be defined in a vocabulary like:
> 
>    hm:mergedInto
>       rdfs:comment
>          "Perform an RDF merge of payload into resource"@en ;
>       hm:httpMethod
>          "POST" .
> 
> Finally, I have only suggested a vocabulary, but this you could turn into an ontology. With HTTP verbs, all you're going to get is a literal. :-)
> 
> BTW, I'm landing in Boston for ISWC on Friday, and I'm all for a f2f chat and hack session on Saturday if anybody wants to meet up. My simple linked data platform is the Perl module RDF::LinkedData, which is on CPAN, and also in Debian and Ubuntu as librdf-linkeddata-perl. I have some unreleased code on github for the read-write support ideas, at least many of the tests are there.
> 
> Cheers,
> 
> Kjetil
> -- 
> Kjetil Kjernsmo
> PhD Research Fellow, University of Oslo, Norway
> Semantic Web / SPARQL Query Federation
> kjetil@kjernsmo.net           http://www.kjetil.kjernsmo.net/
> 

--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
         10 Burlington Mall Road, Suite 265, Burlington MA 01803
     Weblog   -- http://www.openlinksw.com/blogs/
     LinkedIn -- http://www.linkedin.com/company/openlink-software/
     Twitter  -- http://twitter.com/OpenLink
     Google+  -- http://plus.google.com/100570109519069333827/
     Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers