W3C home > Mailing lists > Public > public-ldp@w3.org > March 2014

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

From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
Date: Mon, 31 Mar 2014 21:46:53 +0200
Message-ID: <CA+OuRR9ZLOAFpkqyAqjw4oPjabrW8DAtr3eK3Td5m4q1xuNUcQ@mail.gmail.com>
To: Kingsley Idehen <kidehen@openlinksw.com>
Cc: "public-ldp@w3.org" <public-ldp@w3.org>
On Mon, Mar 31, 2014 at 9:02 PM, Kingsley Idehen <kidehen@openlinksw.com>wrote:

> On 3/31/14 2:23 PM, Richard Cyganiak wrote:
>> Kingsley,
>> On 31 Mar 2014, at 18:54, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>> Simple solution: make it clear that LDP is based on Turtle Notation.
>>> There are pros and cons to this approach (naturally), but being clear
>>> ultimately reduces confusion. Inferring that LDP is based on RDF, in this
>>> context, without the suggested clarification re., notation specificity, is
>>> just another case of RDF conflation (abstract and concrete syntaxes) and
>>> inevitable confusion.
>> Would it be insane to say that LDP (or at least its POST semantics for
>> containers) is based on something else, let's call it a "relative RDF
>> graph", which has the following properties:
>> - It is similar to an RDF graph
>> - But it may contain relative URIs
>> - It can be resolved against a base URI to yield a "normal" RDF graph
>> - It's what we get when we parse a Turtle file that contains relative
>> URIs without resolving them
>> - Relative RDF graphs cannot be stored in RDF stores, cannot be merged,
>> cannot be reasoned over, etc.
>> - To do any of those things, it needs to be resolved against a base first.
>> Best,
>> Richard
> Not insane at all, you've captured all the fundamental characteristics of
> what LDP is based on, at this point in time.


> My only concern would be the first point where you state "..similar to an
> RDF graph" which kind of dissociates LDP and RDF .

How about "an intermediate abstraction layer between the RDF abstract
syntax and (most of) its concrete syntaxes".

> Maybe "a declarative RDF graph" could work better, it keeps the coupling
> loose and defensible (in my eyes).

I don't really get the meaning of "declarative" here, nor what makes a
(non-relative) RDF graph less "declarative" than a relative one.

> Anyway, the crux of the matter is covered above, we just needs integration
> into the spec, using clear (as possible) language and good examples.

That would be a major improvement, IMHO, but would still let many
developers helpless, as this new notion is not explicitly covered by RDF
toolkits and library -- and why would it, as it has just been coined :)

How about a WG note providing examples in major RDF libraries of the best
way to generate and serialize a relative Graph?


> --
> 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
Received on Monday, 31 March 2014 19:47:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:16:37 UTC