Re: hypermedia controls vs. payload

On 01/14/2013 01:06 PM, Wilde, Erik wrote:
> hello alexandre.
>
> On 2013-01-12 18:43 , "Alexandre Bertails" <bertails@w3.org> wrote:
>> On 01/12/2013 12:23 PM, Wilde, Erik wrote:
>>> i guess this is primarily an indication of the general problem how to
>>> separate LDP metadata (relevant for the data and interaction model) and
>>> LDP content (opaque for the LDP protocol, but may contain anything
>>> including LDP data). in XML, this can easily be done by defining a
>>> schema
>>> and saying which parts matter for the data and interaction model, and
>>> which parts are opaque payload (often then simply using wildcards for
>>> those parts of the schema). i am wondering whether there are established
>>> RDF design pattern to tackle this problem; i cannot really imagine that
>>> we're the first ones having to deal with it.
>> TimBL and I had a discussion a few days ago about that.
>> Let's say that you're dereferencing the fragment-less URL X, and that
>> you get back a header like this:
>> [[
>> Link: <target>; rel=Y
>> ]]
>> Then we could say that this is like having the triple
>> [[
>> <> <http://w3.org/TO/BE/DETERMINED/Y> <target>
>> ]]
>> This would be enough for us for linking WebACL-s resources (rel=acl)
>>from <> at the protocol level, without messing with the actual
>> data. LDP could have its own set of reserved URLs for its protocol.
>> Note that you can't have meta informations for hash-URIs this way. But
>> this is actually ok -- and even a good thing -- as you want to state
>> things about the resource document itself, not its content.
>
> it seems to me that this suggest to, as a general rule, extract hypermedia
> controls from the resource representation, and place them in link headers
> only. i can see how this could be very useful in some cases, such as:
>
> - including hyperlinks that are mostly perceived to be a result of the
> server applying some policy/logic, instead of being part of the "resource
> itself". this is not a very strict definition, but the ACL scenario sounds
> a bit like it.

Yes, that's exactly the spirit of WebACL.

>
> - representing links in cases where the resource representation is not
> capable of carrying links, such as multimedia resources, where the
> representation is "just content", and there isn't a way how hypermedia
> controls can be embedded.

Andrei and I spent some time recently playing with these
concepts. That was basically our only way to link data to an image,
for example.

>
> my concerns about this as a general strategy are the following:
>
> - in many scenarios you need links that do not link the resource as a
> whole, but instead fragments of it. if you look at a container, it
> contains a sequence of (some) metadata about entries, and then links that
> matter for the protocol, where clients are supposed to follow those links
> to get to the URIs for the resources. more generally speaking, many
> hypermedia formats need and have controls that are not at the resource
> level but at the sub-resource level.

I believe that LDP is mainly about LDPC-s and LDPR-s.

When the LDPR is itself an RDF resource, then it's easy: you can point
to some content in it, or search for it from its LDPC.

If the LDPR is not an RDF resource, then you need another way to point
to additional content, that's the idea behind
[[
Link: <...>; rel=meta
]]

In practice, you can say that a client would have to follow this Link
to find additional content. And there is nothing preventing one from
speaking about sub-resources there. For example, you could have X
being a media resource, and having metadata referring to
media-fragments.

Then you have some LDP extensions, like having a standardized ACL
system. Unlike meta, this is not application specific but server
specific. And because you want to re-use LDP, you would make that an
LDPR as well (the LDPC is unspecified though).

So far, acl and meta are only about the resource document, so there is
no need to be able to speak about sub-resources here. Do you see a
use-case where it would be mandatory?

>
> - depending on the complexity of your hypermedia format, the number of
> links in resource representations can be considerable. always placing all
> of them in HTTP headers as the only option to me seems like an option that
> quickly may run into limitations of what HTTP should do, and what HTTP
> implementations are able to do.

Right. This should be delimited and documented. So far, I've found
interest only in rel=meta and rel=acl.

>
> so my guess is that for some "add-ons" that feel mostly orthogonal to what
> we're doing (such as the ACL example), using HTTP headers may be a good
> option and one that allows us to decouple the LDP protocol from orthogonal
> issues. however, for the things that are at the center of the protocol. i
> am not so sure that this approach would work very well.

What are the LDP metadata that would be "at the center of the
protocol"?

Alexandre.

>
> thanks and cheers,
>
> dret.
>
>

Received on Monday, 14 January 2013 19:06:14 UTC