- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 28 Jan 2013 14:36:35 +0100
- To: "Wilde, Erik" <Erik.Wilde@emc.com>
- Cc: Alexandre Bertails <bertails@w3.org>, Arnaud Le Hors <lehors@us.ibm.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-Id: <A953981A-5091-4E91-8CCE-86E19CEB31FF@bblfish.net>
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/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 28 January 2013 13:37:15 UTC