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

Hi Richard,


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

> Reto,
>
> On 26 Mar 2014, at 09:29, Reto Gmür <reto@apache.org> wrote:
> >> It is clear that the usage of relative URIs is correct here and in the
> spirit of the web.
> >
> > Clearly not. If the RDF Data Model would support relative URIs then it
> would be an acceptable solution (Antoine's still being more elegant, imho).
> But as RDF has no relative URIs this is just an unnecessary hack.
>
> You are absolutely right that the RDF Data Model doesn't support relative
> IRIs.
>
> But why is this? Is it by design? I think the reason is historic: the use
> cases didn't seem sufficiently compelling at that time.
>
> Back then, RDF/XML was the only syntax intended for deployment, so the
> line between what's syntax and what's model could be drawn more or less
> anywhere. The WG tried to keep the model as simple as possible, and perhaps
> ended up making it too simple.
>

Things should be as simple as possible, here I don't see a compelling
reason to make it more complex.


>
> Today, we have an entire zoo of syntaxes, and many of them share certain
> features that are not in the model, especially support for relative IRIs
> and prefix mappings. The fact that these features are not in the data model
> leads to multiple problems, including subtle interoperability failures,
> poor support in library APIs, varying behaviour across implementations, and
> poor user understanding.


I don't see these interoperability issues. Of course if you want the
prefixes to remain the same RDF isn't the right level of abstraction to
work on. This is the same when copying files from one disk to another, the
data will not end up in the same sector. If I can't live with this I have
to use a lower level copy tool. I work with graphs for which I have good
tools to deal with, I don't care and don't want to care about how this
graphs are serialized. So far I haven't missed the feature of being able to
name nodes with relative URIs very badly. But having it in the model would
not be a big problem like forcing me to care about serialization. I don't
care about serialization more than about the disk sectors that are
populated by my files


> Real instances of these problems have been brought up by you and
> Pierre-Antoine in this discussion. If the features were normatively defined
> in the model, then interoperability and support would likely be better and
> more consistent.
>
> Perhaps the latest RDF WG could have done something to improve this
> situation, but it didn't, for complex reasons. As a member of that WG and
> one of the editors of the relevant document, I will accept some of the
> blame for this.
>
> 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 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.
- "it's webby": hard to argue about that, you mean "with just a right
amount of dirty" as Saul Goodman used to say?
- "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.


>
> 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.

Cheers,
Reto