Re: Links and graphs

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 Sunday, 16 December 2012 17:57:16 UTC