Re: Links and graphs

On 12/17/12 9:32 AM, Graham Klyne wrote:
> 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?
>

+1

Kingsley
> #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.
>>
>
>
>


-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen