Re: Practical issues arising from the "null relative URIs"-hack - iContainers

On Mon, Mar 31, 2014 at 1:46 PM, henry.story@bblfish.net <
henry.story@bblfish.net> wrote:

>
> On 31 Mar 2014, at 12:53, Stian Soiland-Reyes <
> 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. 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 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> wrote:
> >>
> >>
> >>
> >> On Fri, Mar 28, 2014 at 2:42 PM, Kingsley Idehen <
> 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>
> >>> 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
> >>> 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/
>
>