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

On 31 Mar 2014 16:00, "Richard Cyganiak" <richard@cyganiak.de> wrote:

> This would only be unclear if you assume that there can be multiple
different base URIs for different patterns of relative URIs. That would be
madness. All relative URIs are interpreted relative to the same base.

Of course, I only meant that unless we define a priori that a certain
subtype of lpd:Container will create it's resource in a certain URI space
(as suggested with container1/ creating container1/xxx ) - then the client
can't make much assumptions about the final URI beyond that "" will be your
own document.

> Besides “” and “#fragment”, patterns such as “/“ and “/foo” can also be
very useful.

Agreed, these are all useful and should probably be supported, as it allows
for a "not very clever" lpd container to just serve the posted bytes, which
could then in theory be re-posted to a different lpd container.

"../other" is another matter as it is unpredictable what that is meant to
point to, but it might be out of scope for lpd to require any sanitizing to
detect those.

> > 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.
>
> The problem with that are not the relative URIs, but that the client
makes unfounded guesses about the server’s behaviour.

Exactly, so use of any other relative references (perhaps except for
/-based if we can safely say protocol and hostname won't change) is
unpredictable and should be NOT RECOMMENDED.

> I’d say that encouraging relative URIs makes clients *less likely* to
engage in this kind of fragile guesswork, because it allows them to employ
useful patterns like “#fragment” without having to guess the final URI.

Only if they manage to convince their RDF library to play along. Due to
earlier mentioned insistence on "a graph must have absolute IRIs" many
frameworks enforce this at various levels, forcing developers (who don't
know about the app:// style base URI serialization hacks) to make a priori
decisions about what the IRI will be after POST, which could easily result
in the framework spitting out exactly "../other" and "neighbour/".

So my suggestion was to either do a two stage resource creation, which
gives before-knowledge of the IRI to PUT to (and nicely is imdependent).

Or for traditional POST,  to be on the safe side one could optionally
support the let-the-server-relativize with an explicit Content-Location
header with the base URI of the posted document, where we suggest the
app:// scheme rather than a priori guessing. Thus the developer is taken
down the desired path and might find out how to relativize correctly on his
side anyway.

> Are you proposing this *only* for formats that don't support relative
URIs?

That is where it would make most sense (but that is only nquads, right?),
but as I said it is also the frameworks.

I have for instance been fighting with Jena to get it to serialize with
correct relative IRI refs (ending up with before-mentioned hack), and even
with explicit pleas from TimBL to support relative IRI refs directly in
their Jira bug tracker, it is still not generally supported as the argument
goes that "IRIs in the graph should be absolute anyway".

> Because otherwise, it’ll be even less clear what “/“ or “/foo” or “..”
refer to, as it’s unclear whether they will be resolved against your hack
URI, or the container URI, or the new item URI.

They could in this scheme be either explicitly undefined or explicitly not
allowed. A sanitizing container could fail or just keep them in absolute
form (e.g. app:// 3dc5a45a-38cf-4f7b-abfa-44bb3f6b8d6/other ) as a
fallback, as he does not know what the client meant.