- From: Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
- Date: Mon, 17 Dec 2012 14:32:30 +0000
- To: Erik Wilde <dret@berkeley.edu>, mike amundsen <mamund@yahoo.com>
- CC: LDP <public-ldp@w3.org>, W3C provenance WG <public-prov-wg@w3.org>
Eric, Mike, Thank you again for your patient explanations. I think I'm coming to better understand what you are describing. I still have some reservations about the client side complexity, but for the moment I'm going to assume they are misguided and try to move the discussion forwards. Specifically, I'd like to explore the role of media types in more detail. (By way of preparation, I've just re-read Roy Fielding's description of REST - http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) The basic pattern for a REST interaction I'll aim to follow is: 1. use available information, possibly including link relations, to select a target resource ("why?") 2. retrieve a representation of the target resource and combine that with knowledge of how to process it based on its media type (aka content type - sorry, I tend to use the terms interchangeably), to access some further desired information. ("how?") The specific application I'm considering is how to access provenance about a resource using a service that (in general) has provenance information about many resources. (The simple case of directly accessing the provenance as a resource in its own right is covered separately - the service covers the case when the resource server does not have direct knowledge of a corresponding provenance resource.) Two mechanisms for accessing provenance for a specified resource are considered: SPARQL query and a simple interface in which a URI template [http://tools.ietf.org/html/rfc6570] is provided via a service description. It seems to me that RDF (in its various syntaxes) is a natural way to provide a service description. A client application needs to understand about RDF in general, and about specific RDF vocabularies that are used to describe services. A service provider can introduce new mechanisms by introducing new descriptions (using new vocabulary terms) into the RDF returned, without breaking existing clients. I think this approach is entirely consistent with Roy Fielding's description of REST, in which a representation is "a sequence of bytes, plus representation metadata". The metadata may include, but is not limited to, a media type description. Thus, in our RDF service description for accessing provenance, we might describe either or both of: (1) a REST service description, e.g. per http://www.w3.org/TR/prov-aq/#provenance-service-description, which introduces a resource with RDF type 'prov:ProvenanceService' (this is a fairly old PWD which is undergoing revision - part of my reason for this discussion is to figure out what should go here). One point of ongoing debate is whether the RDF type should cover all of the access mechanisms (REST and SPARQL). (2) a SPARQL endpoint description per http://www.w3.org/TR/sparql11-service-description/, being an RDF resource of type 'sd:Service'. But this does not use media type to discriminate between the options. Depending only on the client's knowledge of how to process the media types seems to me to be a narrow view compared with "examining and choosing from among the alternative state transitions in the current set of representations" [Fielding]. I'm concerned that this dependency leads to an overloading of media types, which "specify the native representation (canonical form) of such data" [http://tools.ietf.org/html/rfc2045] to also cover data semantics. For formats where the semantics is tied to a specific format, this seems not to be a problem, but does not sit so well with RDF which uses common syntax to convey arbitrary semantics. One thing we lose by not using a media type to distinguish between the access options is the ability to use content negotiation for selection. I think this is somewhat offset by a server easily being able to supply multiple RDF descriptions in a single response, so the process can proceed without any additional round-trips. (This doesn't preclude the use of media types and content negotiation for non-RDF service descriptions, so I think the essential flexibility and evolvability of the REST style is not compromised. In future, maybe we have a way to negotiate on RDF types?) In summary, I think there can be alternatives to using media types for guiding the "how?" of interactions, without compromising the essential evolvability properties of REST. But maybe you can point out where the problems lie in the approaches I sketch here? #g -- On 16/12/2012 17:56, Erik Wilde wrote: > hello graham. > > On 2012-12-16 3:27 , Graham Klyne wrote: >> On 10/12/2012 22:13, Erik Wilde wrote: >> > 100% agreed, but i don't think we ever disagreed on that one. >> Good - that suggests I've not properly understood what you were >> suggesting. We're hopefully less divergent in our views that the >> discussion so far may suggest. > > or maybe not ;-) link relations are all about the "why", and not about the > "how". the "how" should be strictly runtime, and thus cannot by part of the link > relation, but must be done through the uniform interface. media types and maybe > OPTIONS, basically. > >> I just responded to Mike. I have a sense that part of our disconnect >> may be that I'm considering pure application-to-application >> interactions, with no direct human involvement, and no HTML. > > not at all. i think all of us do pretty much no human-facing services; it's all > about machine-to-machine. > >> Consider the scenario where there are two ways to access provenance of a >> resource: one of them is via a REST service, and the other is by a >> SPARQL endpoint. > > hopefully, they both have their interactions exposed in a self-describing way, > the REST service definitely through a media type, and the other one also through > something more self-describing than just announcing general RDF capabilities. > >> What I propose is to use the link relation type to distinguish between >> these endpoints: one pointing to a SPARQL endpoint, the other pointing >> to a REST service description (ala Atom "Service document" or @mnot's >> "API Home page"). > > possible, but not what i would recommend. what you should do is link to both in > a uniform way, and then distinguish at runtime, based on the uniform interface. > >> The alternative seems to be to have some kind of service description >> that presents one or either of these as alternatives, but this seems >> more complicated to describe, and when I try to think about it, more >> complex to implement. > > not really, because that's the basic switching fabric of the web. unless your > client doesn't work like the web and therefore you have to teach it, but that's > a worthwhile thing to do. > >> Agreed. I was thinking about follow-your-nose type mechanisms that >> might allow an application to decide whether or not to use a link >> relation whose URI it's never seen before. But that's probably way >> beyond the scope of what I really wanted to find common ground on right >> now. > > the basic question is that of openness: if you hardcode media types into link > relations, then you have to mint a new link relation for each new media type > that appears. let's say in three years application/über-PROV appears, the media > type specifying provenance in a way that blows everything else out of the water. > in your scenario, everybody embedding links about PROV in their resource will > need to learn about application/über-PROV and start embedding the > application/über-PROV link relation in their resources. in a web-like design, > resource providers can happily still serve links to the PROV provider they > always linked to, but now when clients follow those links they can discover (at > run-time!), that the PROV service now (also) supports application/über-PROV, and > everything can happily evolve without the need to change anything in old services. > > cheers, > > dret. >
Received on Monday, 17 December 2012 14:33:26 UTC