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

On 3/31/14 3:46 PM, Pierre-Antoine Champin wrote:
> On Mon, Mar 31, 2014 at 9:02 PM, Kingsley Idehen 
> <kidehen@openlinksw.com <mailto: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 <mailto: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. 
>
>
> +1
>
>     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".

That's what you get via a Turtle document (for instance) where RDF 
statements are comprised of entities denoted using relative HTTP URIs. 
It's a really useful and powerful feature that could ultimately help 
end-users and developers alike fully appreciate how RDF enables Linked 
Open Data creation and publication etc..
>
>     Maybe "a declarative RDF graph" could work better, it keeps the
>     coupling loose and defensible (in my eyes).
>
>
> -0.9
> I don't really get the meaning of "declarative" here, nor what makes a 
> (non-relative) RDF graph less "declarative" than a relative one.

When you have relative HTTP URIs in a Turtle Document you are declaring 
to a Turtle processor how to serialize an RDF graph. In this 
intermediate state (represented by this kind of Turtle document), the 
RDF statements have a declarative aspect, in regards to denotation of 
entity relationship participants.

>     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 :)

Which is why we need examples [1] to compliment these issues. RDF 
toolkits aren't immune to many of the challenges that arise from 
confusion about RDF, Linked Data, and AWWW.

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

Anything that helps spec readers and implementers is a good thing :-)

[1] http://bit.ly/1fWnvCP -- Simple Linked Data Deployment Tutorial 
based on Turtle using Relative HTTP URIs (this Tutorial is 100% Linked 
Data, 100% portable across HTTP accessible document locations, and 
doesn't use any @prefixes ).


Kingsley
>
>  best
>
>
>
>
>
>
>


-- 

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