Re: Links and graphs

On 10/12/2012 22:13, Erik Wilde wrote:
 >> This all leads me to to see plenty of upside and no downside in liberal
 >> use of link relations to guide interactions.
 >
 > 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.

> hello graham.
>
> i am afraid i can do little here other than pointing to mike and say "just what
> he said".

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.

I'll try and make this concrete in my response to your next points:

>> 1. It is overloading the notion of media type to have it be the sole
>> determinant of interaction;
>
> media types determine the conversation you're engaging in on the web. i really
> don't know anything else, so like mike said, if you think we should put it
> somewhere else, i'd be curious to know where that would be.
>
>> 2. The distinction between "why a client might use a resource" and "how
>> a client might interact with a resource" is not (as you also indicate)
>> entirely clear cut, making it unsuitable as a dogmatic basis for
>> choosing format over link relation for driving an interaction
>
> "not clear cut" and "unsuitable as a basis" are very different things. again,
> the interesting here are media types. a link relation is something you find in
> the context of one conversation, and if you choose to follow it, you're doing it
> because you want to accomplish some goal. if accessing the link results in you
> now using a different media type, then you've just switched conversational
> contexts, and for starting a conversation in that new context it shouldn't
> matter how you got there. so distinguishing link relations and subsequent
> interactions with the link target is a very useful thing, because it allows us
> to evolve conversations and add new pieces into the conversations, without
> having to change anything about the existing machinery.

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.

So we have here: one goal, two possible mechanisms.  The appropriate mechanism 
may depend on the client 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").

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.

>> 3. Link relations appear in content as well as in link headers (and
>> other protocol-level structures)
>
> that's correct. it's up to media type to choose how to manage that, so that
> clients can engage in meaningful conversations. HTML never uses link headers.
> HTTP services serving blobs may critically depend on using link headers. a
> future hyperRDF will have the freedom to choose how it expects clients to engage
> in conversations. for now, since RDF has no links, it doesn't really matter.

Sure - I raised this because link relations can also appear outside specific 
media types (e.g. as Link: headers).  I think this is probably a red herring as 
far as this discussion is concerned.

>> 4. Client implementation is much easier if they can use Link headers (or
>> equivalent) to choose between available resources, where such choice may
>> depend on the client's interaction capabilities.
>
> that very much depends on you scenario. it can be pretty much impractical for
> pretty much every hypermedia document format i know of, and it can be really
> nice to avoid the madness that is adobe's strategy of placing metadata in 37
> different places in a PDF.

I think I'm with you on this.  I'm not sure what I said that suggests this kind 
of deployment, but it's not what I'm aiming for.  Hopefully the comments above 
make clearer what I'm contemplating.

>> This all leads me to to see plenty of upside and no downside in liberal
>> use of link relations to guide interactions.
>
> 100% agreed, but i don't think we ever disagreed on that one.
>
>> I also think we lack a common or self-describing way for link relations
>> to guide interactions.
>
> - common way: RFC 5988
> - self-describing way: without knowing the media type, you don't know its rules.

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.

Cheers,

#g
--

Received on Sunday, 16 December 2012 13:14:16 UTC