Re: Links and graphs

hello graham.

On 2012-12-16 3:07 , Graham Klyne wrote:
> Well, I'm proposing that the link relation may also be.
> (I'm referring here to application interactions, not browser.)

could, but just as the stepping stone. as the one making a link, you 
don't control the link target. so yes, you can link to it, but no, you 
shouldn't hardcode assumptions on how to interact with it on the source 
side of the link, because then you make things unnecessarily brittle. 
link to the target because of the "why" (why would a client follow this 
link: because it has some objective), and leave all of the how up to the 
target of the link. allow independent evolution. avoid coupling.

> I think so.  I was reacting against the (maybe incorrectly perceived on
> my part) idea that content type was the only basis for indicating the
> kind of interaction mechanism to follow.

nope, it really should be. if you link to an image, for example, then 
the HTML page doesn't mind if the server for the link switches some 
outdated GIF version against a new JPEG2000 version. the image link says 
"follow this if you want to GET an image", the media type determines (at 
runtime!) what the client actually GETs.

> Specifically, I'm thinking about choosing between a SPARQL endpoint and
> a REST service:  it seems to me that a link relation would be useful for
> making this distinction.  Eric's response seemed to me to indicate
> otherwise (but maybe I misunderstood).

nope, that would be bad design. have a link relation representing the 
why ("follow this if you want provenance information", in your case), 
and leave discovering the how up to runtime interactions with the link 
target. much more open, much more decoupled.

> In the scenarios I envisage and am working with, using the link relation
> results in simpler client logic and code paths.

maybe it's easier if your client has harcoded assumptions on how 
everything works? what about other clients that look at the same 
resources and also want to find provenance information, but the 
provenance resolution protocol is a different one? can they use your 
service at all?

> It's difficult for me to say, but I'm thinking of client application
> interactions not directly involving a (human) user.  HTML is primarily
> about providing a presentation to a user, and the text surrounding a
> link can provide context for helping a user in deciding whether or not
> to follow a link.  That's not readily available to applications;  but I
> perceive that link relations can serve a similar purpose.

but again, the human-readable text in HTML does not tell you, at least 
in principle, "what" to GET, but "why" you might want to follow that 
link. "click here to see a map of the area": whether this is a JPEG of a 
GIF or some fancy GIS interface is not something that should decide the 
interactions, and ideally the provider of the service should be able to 
change implementations, without breaking the linking page.

cheers,

dret.

Received on Sunday, 16 December 2012 17:44:10 UTC