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

Hi Richard,


On Thu, Mar 27, 2014 at 2:38 PM, Richard Cyganiak <richard@cyganiak.de>wrote:

> Hi Reto,
>
> On 27 Mar 2014, at 13:05, Reto Gmür <reto@wymiwyg.com> wrote:
> > Of course if you want the prefixes to remain the same RDF isn't the
> right level of abstraction to work on.
>
> Well, then what *is* the right level of abstraction?
>
> Users who convert an RDF/XML file to Turtle usually expect that prefix
> mappings and relative IRIs are retained. Not all tools do this, and this is
> a common source of confusion and complaints.
>
> So the syntax level is not right (information should be carried across
> syntaxes), and neither is the RDF graph level (the information is not part
> of the RDF graph model).
>
> My view is that this missing level should be standardised. And if it were
> standardised, then that extended model would be a reasonable candidate for
> the payload of LDP messages.
>
> Whether the required definitions happen in the RDF specs, in the LDP spec,
> or somewhere else, doesn't really matter for this argument.
>

Luckily LDP doesn't mandate the usage of specific namespace prefixed in the
serialization. But it would be consistent with your argument.

>
> >> I think Henry makes a good case that the use of relative IRIs is the
> Right Thing here. It's practical, it has precedent with the way HTML works,
> it's webby, and it's supported by the relevant RFCs.
> >
> > Ok, let's look into this:
> > - "practical": it requires hack on the client (throwaway URI to
> serialize against) and prevents framework to be effectively used on the
> server side. As for expressiveness it allows less flexibility (creating
> multiple resources in one post) as Antoine's proposal
>
> It works just fine, without hacks, if client and server use RDF libraries
> that support relative IRIs.
>

But not when using tools which act on the RDF data model level.

What LDP does is like if I ask people calling me to use SIP with H.264 as
codec omitting the domain of the target. Something you can do with the
right (hacker) library but certainly not with a normal phone.


> > - "it has precedent": I don't know of any protocol which requires the
> sender to send URIs that are relative to something that isn't defined yet.
> So I don't know where the precedent is.
>
> There are protocols (WebDAV, APP) where messages with relative IRIs can be
> POSTed and it works just as expected.
>

Neither in WebDAV nor in APP I see where the client is required to send
post IRIs relative to a yet undefined base (i.e. that the client couldn't
also send as absolute URI). In Antoine's proposal you can use relative URIs
but you don't have to.


>
> > - "supported by the relevant RFCs": The RFC says the sender is
> responsible that the base URI can be established, this seems quite
> different from "the receiver defines a base URI" to me.And I haven't got an
> answer to
> http://lists.w3.org/Archives/Public/public-ldp/2014Mar/0033.html yet.
>
> If the protocol implemented by the server asserts that the server will
> choose an appropriate base IRI, then a client has met its responsibility by
> using that protocol.
>

It that is enough to satisfy the requirement I don't see how the earlier
requirement "the base URI is defined by the context of the application"
without also satisfying the requirement that the client is responsible. I
think your interpretation of the requirement makes it pointless.


> >> Given all this, it appears to me that using relative IRIs to good
> effect in LDP is a step in the right direction.
> >
> > Well the goal of LDP is not to establish faits accomplis to push the RDF
> specification to adopt new features but in my understanding to apply the
> existing standards where possible. As for this use case there are
> alternatives that do not go beyond the current standard and they do not
> provide any disadvantage (except if you need the dirt) I don't think we
> should go beyond the existing standard.
>
> As you have seen in this thread, one can argue in either direction by
> pointing to existing standards.
>
> It comes down to a question whether you prefer to do the Right Thing
> vis-a-vis RDF Concepts or vis-a-vis RFCs 2616 and 3986.
>

You are arguing that it doesn't violate RFC3986 where I disagree, I didn't
read any argument that any of the two RFCs you mention would suggest that
the base URI should not be the resource against which the request is sent
(as with Antoine's proposal) but that the base should be the resource the
server has yet to create.

Cheers,
Reto