- From: Sandro Hawke <sandro@w3.org>
- Date: Mon, 31 Mar 2014 12:56:30 -0400
- To: Reto Gmür <reto@wymiwyg.com>, "henry.story@bblfish.net" <henry.story@bblfish.net>
- CC: Soiland-Reyes Stian <soiland-reyes@cs.manchester.ac.uk>, "Kingsley (Uyi) Idehen" <kidehen@openlinksw.com>, "public-ldp@w3.org" <public-ldp@w3.org>
- Message-ID: <53399E3E.9020506@w3.org>
On 03/31/2014 11:59 AM, Reto Gmür wrote:
> On Mon, Mar 31, 2014 at 1:46 PM, henry.story@bblfish.net
> <mailto:henry.story@bblfish.net> <henry.story@bblfish.net
> <mailto:henry.story@bblfish.net>> wrote:
>
>
> On 31 Mar 2014, at 12:53, Stian Soiland-Reyes
> <soiland-reyes@cs.manchester.ac.uk
> <mailto:soiland-reyes@cs.manchester.ac.uk>> wrote:
>
> > One would also have to be very careful about creating the relative
> > URIs, because effectively only safe relative reference to use is ""
> > and "#anchors". It is unclear if a relative reference like
> "../other"
> > should be interpreted with the base URI according to the URI you
> POST
> > to (e.g. http://example.com/coll1 *) ) or the final resource that is
> > created (unknown: http://example.com/col1/item5,
> > http://example.com/col1/items/5, http://example.com/col1/items/5 or
> > even http://other.example.com/5 )
>
> The answer to this is not to develop a protocol to get agreement
> over to-be-created URIs in advance, which would be a horrible slow
> and an unecessary hack, but instead to refine the meaning of
> containers
> so that creating a resource in an LDPC is predictable, and so that
> all the types of relative URIs can work.
>
>
> You cannot have URIs relative to the container and relative to the to
> be created resource at the same time.
Fortunately, there's no need to have something relative to the
container, since one can just use the absolute URI for something like that.
> So with the current spec they unfortunately are relative to the
> resource to be created. The questions shows how unintuitive this
> approach is, as with GET and PUT requests the relative URIs are always
> relative to the request URI.
In all three cases (GET, PUT, POST) they are relative to the resource
being transmitted. To me, that seems completely intuitive.
Don't forget that POST as a way to put new content on the Web works for
more than just RDF content. It also works for HTML, CSS, Javascript,
SVG, PNG, JPEG, PDF, etc, etc, etc. Nearly all of those formats
include links. In some formats, like HTML and SVG, they often contain
relative links to other parts of the document. That works perfectly with
the current design, without the server having to touch a single byte.
The blank node design and your null-relative proposal (and every other
design I've thought of) would require the server to know how to safely
edit these file formats to rewrite the links.
-- Sandro
> In Pierre-Antoine's proposal they are relative to the request URI too
> making usage consistent with the other HTTP methods.
>
> Cheers,
> Reto
>
>
> I proposed this as ISSUE-50, and initially called this an
> ldp:iContainer
> for an intuitive container.
>
> https://www.w3.org/2012/ldp/track/issues/50
>
> This would also solve the problem as to how PUT should work.
> Currently it is not at all clear where one can create a resource
> with PUT. With ldp:iContainers it would be simple: if a resource
> has a path such as http://ldpc.example/ then any PUT to a resource
> whose URL fits the regex http://ldpc.example/[^/]* would be created in
> the above LDPC. Indeed this could be extended to simply allow that any
> successful put on a URL creates all the LDPCs ( always ending in a
> '/')
> that form the path of the given created resource, each one
> ldp:containing
> the other.
>
>
> > *) If the base URI is the resource you post to, then you have no way
> > in the posted document to refer to the not-yet-existing resource
> >
> >
> > Therefore any hint of using relative URI references would have to be
> > very specific about only using "" and "#anchors", and would easily
> > become quite fragile if clients do the 'wrong hack' and try to
> > preemptively guess the final URI in advance and relativize
> > accordingly.
> >
> > In many ways it might be better to specifically recommend the
> details
> > of the hack - say require the use of a fresh app:// base URI [
> > http://www.w3.org/TR/app-uri/ ] that is also declared in the
> header:
> >
> >
> > POST http://example.com/coll1
> > Content-Location : app://3dc5a45a-38cf-4f7b-abfa-44bb3f6b8d66/
> > Content-Type: text/nquads ## Now supported
> >
> > <app://3dc5a45a-38cf-4f7b-abfa-44bb3f6b8d66/>
> > <http://www.w3.org/2000/01/rdf-schema#type>
> > <http://example.com/Example> .
>
> Given that relative URLs are meant exactly for this purpose, work
> in WebDAV with
> all other formats, all this trying to dance around a non existent
> problem here
> is completely ridiculous. The answer is instead to work with the
> architecture of the
> web and to follow through on the consequences, such as defining an
> iContainer.
>
> Henry
>
> >
> >
> > Note, HTTP 1.1 says:
> >
> > The meaning of the Content-Location header in PUT or POST requests
> > is undefined; servers are free to ignore it in those cases.
> >
> >
> >
> >
> >
> > On 31 March 2014 12:51, Reto Gmür <reto@wymiwyg.com
> <mailto:reto@wymiwyg.com>> 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 composed of set of RDF triples"
> >>
> >> Cheers,
> >> Reto
> >>
> >>
> >>>
> >>>
> >>> If I import data into Virtuoso (for instance) from a Turtle
> doc comprised
> >>> of relative URIs, the RDF graph that manifests in the DBMS
> isn't comprised
> >>> of relative URIs. It can't be.
> >>>
> >>>
> >>> [1] http://bit.ly/1fWnvCP -- Linked Data Deployment Tutorial
> based on
> >>> Relative URIs using Turtle.
> >>>
> >>> --
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Stian Soiland-Reyes, myGrid team
> > School of Computer Science
> > The University of Manchester
> > http://soiland-reyes.com/stian/work/
> http://orcid.org/0000-0001-9842-9718
> >
>
> Social Web Architect
> http://bblfish.net/
>
>
Received on Monday, 31 March 2014 16:56:42 UTC