Re: ISSUE-36: Summary of ways of making containers

hello henry.

On 2013-01-27 13:09 , "Henry Story" <henry.story@bblfish.net> wrote:
>RFC5988 on WebLinking  may help
>http://tools.ietf.org/html/rfc5988#section-5.5
>It states that the rel value can be an IRI.

yes, but the rules of RFC 5988 say that you use a IRI when you're using
non-registered link-relations, and you register those which should become
well-known ones and then their identifier is a string, and not a IRI. so
you cannot pick the value space here, it depends on the relation you want
to expose (private vs. public/registered).

>So what is the difference when <> a ldp:Container appears in the header,
>and when it appears in the body? There are two cases:
>
>1. If the header is sent by the server, then one expects the
>header data to be statements by the server. Since the server
>is responsible for what is or is not a ldp:Container that would
>make it a reasonable place to put that. ( It would also be a useful
>place for the server state who is making the statement
>in the content )
>
>2. I am not so clear what is happening when the client puts
>the content in the header like that, rather than in the body.
>The client is making a statement about the content, but when
>is that different from when the client is making the statement
>in the content? Clearly it could have a pragmatic role here
>of saving the server from having to look through all the
>content, to decide what to do. But it would be nice to have
>some guiding logical principles for what the difference
>of meaning is.

there really is no provision in HTTP or RFC 5988 to say that a link in a
header means anything different (has a different authority) than a link in
the content. since the server composes the response, the questions how
links are serialized are exclusively a function of how the protocol
defines them. in some cases (for example for binary documents) content may
not have the extensible data model to include links, but that's just a
special case.

as a pragmatic illustration: if you want to expose metadata about an HTML
page, you now have at least four options of doing so:

- embed in the page and use microformats.
- embed in the page and use microdata.
- embed in the page and use RDFa.
- put into link headers and do not embed.

since the web is a mess, there's no rule how you *have* to do it, and
perfect clients should expect any of those ways. they all mean exactly the
same, they are just different "protocols" for metadata encoding. clients
could even provide nice libraries that would join all of these four
methods and expose a unified view to a client-side processor, so that it
would be easier to consume. however, then you have to deal with the
question what to do when you have conflicting metadata in these protocols,
how do you resolve this? hand the conflicting data to the processor?
perform some form of clean-up based on a hierarchy? this is all up to the
client to decide since there is no spec saying anything about this...

back to the topic: while it's tempting to think of embedded links as
semantically different than header-based ones, there really is no
difference. it's just a question of how the link information is
communicated through the uniform interface, which provides different ways
for how this can be done.

http://tools.ietf.org/html/rfc5988#section-5: "The Link entity-header
field provides a means for serialising one or more links in HTTP headers.
It is semantically equivalent to the <LINK> element in HTML, as well as
the atom:link feed-level element in Atom [RFC4287
<http://tools.ietf.org/html/rfc4287>]."

cheers,

dret.

Received on Monday, 28 January 2013 10:44:14 UTC