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

On 1/28/13 8:36 AM, Henry Story wrote:
> On 28 Jan 2013, at 11:43, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:
>
>> 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).
> I don't know where you read that in the RFC 5988. I see:
>
> section 4.1 http://tools.ietf.org/html/rfc5988#section-4.1
> [[
>     Well-defined relation types can be registered as tokens for
>     convenience and/or to promote reuse by other applications.  This
>     specification establishes an IANA registry of such relation types;
>     see Section 6.2.
> ]]
>
> So you register relations for convenience, but that does not mean
> you cannot use others.
>
> section 4.2 http://tools.ietf.org/html/rfc5988#section-4.2
> [[
>     Applications that don't wish to register a relation type can use an
>     extension relation type, which is a URI [RFC3986] that uniquely
>     identifies the relation type.  Although the URI can point to a
>     resource that contains a definition of the semantics of the relation
>     type, clients SHOULD NOT automatically access that resource to avoid
>     overburdening its server.
> ]]
>
> That is just to avoid stupid implementations dereferencing the URI every
> time automatically. It also says that it "can point to a resource that
> contains a definition of the semantics of the relation"
>
>
>>> 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.
> I was not claiming that the link has a different meaning. It should not.
> It should mean the same thing as when it is in the body.
>
> But there is quite clearly a difference. And it is the difference between
> saying something and saying something about something, and also who says
> what.
>
> Header data is metadata about data. The semantics have not been formalised
> clearly, ( ie they have not been made explicit ) but one can make a
> few major points:
>
> 1. that the Content-Length gives the length of the binary representation
>     of the content, something the content cannot do for itself ( in RDF
>     for example, since a graph could be serialised in numerous ways and so
>     have different content-lengths ).
> 2. the GET, PUT, POST, etc are descriptions of what type of action the
>     event of sending the request is doing. This is agent to agent
>     communication. It is not making a statement about the content at all,
>     but specifying the action
> 3. E-tags are strings the server takes care of, not the content.
> etc, etc...
>
> So if we want to model it we need to distinguish the content and the
> metdata. This is what Atom does with its entry is doing. Semantically
> one needs to use the notion of a graph, which in N3 one could represent
> something like this
>
> [] a http:POST;
>     by <http://bblfish.net/people/henry/card#me>;
>     http:contentSemantics { <> ldp:Container; ... }
>
> This is just a sketch: but you can see that there is a difference between
> the event of POSTing, who does that posting, and the content of the posted
> object.
>
> Clearly there is work to do if one wishes to "GRDDL" HTTP  correctly.
> For example clearly the link header would not be describing the event
> of posting, but the  content. So a good GRDDL would need to work on
> what the subject of a link header was.  Perhaps
>
> [] a http:POST;
>     toCreate _:x;
>     by <http://bblfish.net/people/henry/card#me>;
>     http:content "...".
>
> _:x a ldp:Container .
>
>
>
>> as a pragmatic illustration: if you want to expose metadata about an HTML
>> page, you now have at least four options of doing so:
>>
>> 1- embed in the page and use microformats.
>> 2- embed in the page and use microdata.
>> 3- embed in the page and use RDFa.
>> 4- put into link headers and do not embed.
> Logically those boil down to 2: content in the body, and content
> outside. 1,2,3 are just different syntactical representations of the
> same thing. and 4.
>
>> 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.
> This pragmatic limitiation is what gives the content meaning. Because
> no client knows more than how things work on the web, the meaning of
> those fields is implicit in the behavior of agents that consume it.
>
>
>> 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?
> This is what things like knowledge engineering do. They come to a field
> and they make explicit what the implicit behavior is, in order to then
> build more robust systems. This is also what philsophical analyses do for
> concepts. It is in fact what science does when it goes about improving
> its own vocabulary.
>
> In fact that is the process that HTML5 uses to improve HTML: they look
> at how things are used and then they make additions that don't break
> what is important.
>
>> 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.
> I agree there is no difference of meaning of the relation. But it is
> important to think about what is being said.
>
>> 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>]."
> yes, it is semantically equivalent. But now there remains the
> pragmatic side. Who is saying what, what are they doing when they
> are saying something,  etc...
>
> Not it may very well be that there are relations such that
>
> { { <> ?rel ?x } = ?g } <=> { ?g ?rel ?x }
>
>
>
>> cheers,
>>
>> dret.
>>
> Social Web Architect
> http://bblfish.net/
>

+1

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen