Re: Links and graphs

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:27 UTC