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

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/