hypermedia controls vs. payload

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.

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

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.

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

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.

thanks and cheers,

dret.

Received on Monday, 14 January 2013 18:07:28 UTC