- From: Sandro Hawke <sandro@w3.org>
- Date: Mon, 31 Mar 2014 18:07:49 -0400
- To: Reto Gmür <reto@apache.org>, "public-ldp@w3.org" <public-ldp@w3.org>
- Message-ID: <5339E735.70103@w3.org>
On 03/31/2014 04:55 PM, Reto Gmür wrote:
> (somehow the thread moved to the other lists where I cannot post, so
> forwarding to here)
>
Sorry, the mailing list situation is a little complex.
public-ldp is for general discussion among everyone
public-ldp-comments is for sending in an official comment; you sent your
comments to public-ldp, which doesn't make them count as comments, so we
forwarded them to public-ldp-comments for the official record
public-ldp-wg is just for people who've chosen to join the WG
>
> On Mon, Mar 31, 2014 at 4:12 PM, Kingsley Idehen
> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>
> On 3/31/14 8:53 AM, henry.story@bblfish.net
> <mailto:henry.story@bblfish.net> wrote:
>>
>> On 31 Mar 2014, at 13:49, Kingsley Idehen <kidehen@openlinksw.com
>> <mailto:kidehen@openlinksw.com>> wrote:
>>
>>> On 3/31/14 5:51 AM, Reto Gmür wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Mar 28, 2014 at 2:42 PM, Kingsley Idehen
>>>> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>>>>
>>>> On 3/28/14 7:02 AM, Reto Gmür wrote:
>>>>> On Fri, Mar 28, 2014 at 12:04 AM, Kingsley Idehen
>>>>> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>>
>>>>> wrote:
>>>>>
>>>>> On 3/27/14 4:42 PM, Reto Gmür wrote:
>>>>>>
>>>>>>>
>>>>>>
>>>>>> If you consider RFC5995 ( Using POST to Add
>>>>>> Members to WebDAV )
>>>>>> http://tools.ietf.org/html/rfc5995
>>>>>> you need only consider that it does not say
>>>>>> anything about relative URIs to understand
>>>>>> that because it says nothing it does exactly what
>>>>>> we are proposing. If you were to use
>>>>>> a RFC5995 compliant server to POST some Turtle
>>>>>> with relative URIs in it, then you'd
>>>>>> get exactly the LDP intended result. A turtle
>>>>>> document that was posted with a <> URI would refer
>>>>>> to the document created.
>>>>>>
>>>>>> Granted. The same happens if you send an email with
>>>>>> text/turtle content-type. Still, a bit far fetched to
>>>>>> see this use as the intended design or even as to
>>>>>> see an established design pattern in that, imho.
>>>>>
>>>>> This is an established design pattern, that's poorly
>>>>> understood. Relative URIs are really a major route to
>>>>> taking a lot of confusion and tedium out of Linked
>>>>> Data exploitation.
>>>>>
>>>>>
>>>>> I doubt about the this being established (given that it
>>>>> violates RFC3986). But maybe you're right and relative
>>>>> URIs would be elegant and powerful. But then they should
>>>>> be in the RDF data model rather than having LDP breaking
>>>>> the abstraction. (I'm a bit afraid relative URIs in RDF
>>>>> might also add more confusion by people expecting the URIs
>>>>> so be relative to the position of the resource in the graph).
>>>>>
>>>>> What is need to create the body of a POST request using
>>>>> RDF toolkits with the current design:
>>>>>
>>>>> var i = new
>>>>> NamedResource("http://some.temporary.uri/that/must/not/be/used/elsewere/in/representation")
>>>>> graph.addTriple(i, RDFS.descrition, "This is the resource
>>>>> that will be created")
>>>>> ..add more triples
>>>>> var turtleToPost =
>>>>> graph.serializeAsTurtleWithBaseUri("http://some.temporary.uri/that/must/not/be/used/elsewere/in/representation")
>>>>>
>>>>>
>>>>> In my opinion, using this throwaway URI and hoping it
>>>>> doesn't escape from the context of our code is a dirty hack.
>>>>>
>>>>> If the RDF would support relative URIs things would be
>>>>> straight forward:
>>>>>
>>>>> var i = new NamedResource("") //Currently illegal and
>>>>> not supported by most toolkits!!!
>>>>> graph.addTriple(i, RDFS.descrition, "This is the resource
>>>>> that will be created")
>>>>> ..add more triples
>>>>> var turtleToPost = graph.serializeAsTurtle()
>>>>>
>>>>> Of course if RDF would support relative URIs we could use
>>>>> any serialization and also the problem I initially
>>>>> illustrated would be gone.
>>>>>
>>>>> The current question is not about using relative URIs or
>>>>> not but if the spec should be defined in terms of RDF or
>>>>> in terms of some particular serializations. The latter
>>>>> prevents RDF tools from being used, at least from being
>>>>> used in a straight forward way.
>>>>>
>>>>> Cheers,
>>>>> Reto
>>>>
>>>> To be clearer, an actual RDF graph isn't comprised or
>>>> relative URIs. Those URIs have to be absolute. Put
>>>> differently, the final product of an RDF document
>>>> processing pipeline has to be a graph comprised of absolute
>>>> URIs.
>>>>
>>>>
>>>> The problem is that with RDF tools you cannot create (unless
>>>> you use a throwaway URI hack as described above) what needs to
>>>> be posted against an LDP server.
>>>>
>>>>
>>>> There is still a subtle conflation of notation for
>>>> describing an RDF graph and the actual serialization that
>>>> manifests when said has been processed by a processor. For
>>>> instance, a Turtle doc with relative URIs is basically an
>>>> RDF description that a processor will transform into a
>>>> final RDF document that's comprised of a graph with
>>>> absolute URIs.
>>>>
>>>>
>>>> That's why I think that relying on turtle documents with
>>>> undefined based-URI conflicts with the turtle spec that says:
>>>> "A Turtle document defines an RDF graph
>>>> <http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-graph> composed
>>>> of set of RDF triple
>>>> <http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-triple>s"
>>>>
>>>> Cheers,
>>>> Reto
>>>
>>> As you can see, clearly, the habitual conflation of things in
>>> the world of RDF has struck again.
>>>
>>> The abstract syntax of RDF and notations for creating RDF
>>> document content are being conflated yet again. Basing any RDF
>>> based spec on a notation (rather than abstract model) simply
>>> repeats errors from the past.
>>>
>>> RDF specs should understand RDF and never undermine its abstract
>>> syntax. Likewise, Web based specs should understand HTTP URIs
>>> and their powers of denotation and de-reference.
>>>
>>> Turtle specificity, is causing problems here, clearly.
>>
>> The abstract syntax 1.1 says:
>> [[ 1.8 RDF Documents and Syntaxes
>> A concrete RDF syntax
>> <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-concrete-rdf-syntax> may
>> offer many different ways to encode the same RDF graph
>> <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-graph> or
>> RDF dataset
>> <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-dataset>,
>> for example through the use ofnamespace prefixes
>> <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-namespace-prefix>,
>> relative IRIs, blank node identifiers
>> <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-blank-node-identifier>,
>> and different ordering of statements. While these aspects can
>> have great effect on the convenience of working with the RDF
>> document
>> <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-rdf-document>,
>> they are not significant for its meaning.
>> ]]
>>
>> And then later:
>>
>> [[
>> *Relative IRIs:* Some concrete RDF syntaxes
>> <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-concrete-rdf-syntax> permit
>> relative IRIs as a convenient shorthand that allows authoring of
>> documents independently from their final publishing location.
>> Relative IRIs must be resolved against
>> <http://tools.ietf.org/html/rfc3986#section-5.2> a base IRI to
>> make them absolute. Therefore, the RDF graph serialized in such
>> syntaxes is well-defined only if a base IRI can be established
>> <http://tools.ietf.org/html/rfc3986#section-5.1> [RFC3986
>> <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#bib-RFC3986>].
>> ]]
>>
>> The abstract syntax clearly makes place for relative URIs. The
>> whole point of what the LDPC spec is doing in defining a POST to
>> an LDPC is to define a method for establishing the base URI
>> without requiring the client to know it.
>>
>> If some syntaxes that do not support relative URIS have problems
>> - and LDP does not and is not required to say something about
>> those syntaxes - this just shows that even though the meaning of
>> the documents is defined in the end in terms of absolute URIs,
>> there is a pragmatic loss for documents that do not support
>> relative URIs. LDP is about the pragmatics ( protocol ) of
>> publishing documents, and so the loss does not show up in the
>> meaning side of things.
>>
>> Henry
> Henry,
>
> I understand the excerpts above, if you look closer you'll notice
> we have "abstract syntax" and "concrete syntax" which is utterly
> confusing. What we have in reality are:
>
> 1. A language -- RDF
> 2. Notations -- Turtle, RDF/XML, RDFa, HTML+Microdata, TriG, TriX
> etc..
>
> An abstract RDF graph isn't comprised of entity relations where
> participants are denoted using relative IRIs, they are always
> absolute IRIs. Basically, if you base a spec on notations you
> basically skew the entity relations semantics expressed and
> represented by abstract RDF statements (triples) .
>
> The fact that RDF (the language -- signs, syntax, and semantics)
> is loosely coupled with notations (so called concrete syntaxes)
> doesn't imply that one builds an RDF specification atop specific
> notations, and then expect no confusion as a consequences of
> subtleties across RDF's many associated notations.
>
> The spec has to address the problem that's arising here by
> enabling implementers understand the fact that Turtle (as a
> notation) can be used to *declare* an RDF graph (which is where
> relative HTTP URIs come into play, for instance) as well has being
> an RDF graph serialization format (where the serialized RDF graph
> is never comprised of relative URIs). A Turtle processor
> understands these fundamental rules.
>
>
> The spec could be clearer and say that for the POST turtle is not used
> to serialize a graph but that here it serializes a graph template[1]
> (which is, IIUC what refer to as graph declaration).
I'm starting to agree that it makes sense to coin a term for these
things. "graph declaration" I find misleading, and "graph template" to
me is a generic thing, covering also what you find in N3 or SPARQL.
I'm thinking "relative graph" or "iri-relative graph" or
"unspecified-base graph" or "relocatable graph". In any case, it's
like an RDF graph in all regards except that the IRIs may be relative.
It's a very easy concept, but, yes, it's not in the current RDF specs.
> But such increased clarity wouldn't change anything to the fact that
> the spec is built on specific notations, abusing their relative IRI
> feature to build such RDF templates.
>
Some would say "using" instead of "abusing", but yes, ... (ab)using in a
manner that might be unexpected to some.
We've had relative URIs in RDF since the beginning. But their
formalization has always been a bit awkward because of the
abstract-vs-concrete syntaxes, I think.
>
> If we can be a little clearer, the confusion can be addressed.
>
>
> To me the problem is not confusion, but the inability to use every
> serialization
N-Triples and N-Quads were never meant for this kind of use.
> (e.g. serializations that allow signing of the sent graph)
How could you possibly do that, ever, with any POST protocol design?
The client doesn't know some of the URLs in the graph, as it will be
posted, so how can it sign it?
If you need the client to sign the graph (as a real RDF graph, not a
relative graph) then you have to use PUT instead of POST.
> and RDF tools in a straight forward manner. This problem arise from
> the spec being (for these part) designed for the notation rather than
> for RDF.
There's nothing in the spec that's designed for Turtle. We're well
aware of other RDF syntaxes, including RDF/XML and JSON-LD. The fact
that you can't access all LDP features from N-Triples and N-Quads does
not seem to me to be a serious problem.
>
> The spec could promote the use of relative URIs consistently against
> the URI of the HTTP request whenever the serialization supports this.
> But the actual normative part should be based on RDF. I think this
> would better satisfy both the RDF as well as the REST[2] goal of the
> charter.
>
Did I miss a reply from you to my point about posting things other than
RDF? Do you have a solution for handling this in HTML, SVG, etc?
-- Sandro
>
> Cheers,
> Reto
>
> 1. https://twitter.com/AndySeaborne/statuses/450574666936360961
> 2.
> http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
> says "A REST API should spend almost all of its descriptive effort in
> defining the media type(s) used for representing resources and driving
> application state, or in defining extended relation names and/or
> hypertext-enabled mark-up for existing standard media types." however
> LDP is spending effort in specifying how an already defined media type
> should be interpreted.
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web:http://www.openlinksw.com
> Personal Weblog:http://www.openlinksw.com/blog/~kidehen <http://www.openlinksw.com/blog/%7Ekidehen>
> Twitter Profile:https://twitter.com/kidehen
> Google+ Profile:https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
>
>
>
>
>
>
Received on Monday, 31 March 2014 22:07:59 UTC