Re: Multiple Named Graph

On Mon, Mar 24, 2014 at 2:45 PM, Sandro Hawke <sandro@w3.org> wrote:

>  On 03/20/2014 04:56 PM, Reto Gmür wrote:
>
>     Hello,
>
> I've notice that the latest published version suggest using RDF formats
> that support multiple named graphs. For the net-worth example it suggests
> using "one named graph for the net worth resource and then two others for
> asset and liability containers".
>
>  I am irritated by this recommendation. First the specification mandates
> the possibility to serialize as turtle which does not currently support
> multiple named graphs.
>
>  But more importantly I don't see the reason of this splitting of the
> information into many graphs and it seems to significantly restrict the
> possibilities to implement LDP Servers.
>
>  The suggested three graph do not seem to represent three different
> information sources with thus potentially contradictory statements. So in
> this situation there is typically no quotation-use case with provenance
> that must be preserved. Grouping into different graphs what can be safely
> expressed in one graph seems to deny the expressive power of RDF and
> suggesting that the grouping of triples into different graphs has a
> significance beyond provenance.
>
>  With the previous published version it was possible to have an LDP
> compliant server backed by a single graph. This would be my choice of
> implementation if the data has a single provenance and the access
> restrictions are the same for all the triples. This change in the new
> version seems however to mandate implementation to be based on different
> graphs for the different resources.
>
>  In my opinion this is a significant loss of flexibility. I would like for
> simple implementations based on one graph to be possible. It can also be
> useful for an implementation to be based on multiple graphs representing
> different provenances or confidentiality but containing descriptions of
> larger and possibly overlapping sets of resources. With the latter approach
> the resource description accessed through LDP would contain more or less
> triples depending on my access rights and the sources I've decided to trust.
>
>
> I'm a little confused.    I see a few different options.   Can you say
> which of these you like (+1), don't mind (0), or think are harmful (-1)...?
>
> 1.  The state of every LDP-RS is really an RDF Dataset, so in addition to
> the triples you get in Turtle, if you ask for TriG, you might get a bunch
> of other data in Named Graphs
>
-0.9
This would require a change of the definition of LDP-RS which I think would
unnecessarily add complexity. While the current definition is confusing by
referring to the term named graph, the description of RDF Source in
rdf11-cocepts seems more helpful: "A snapshot of the state can be expressed
as an RDF graph". If it cannot be fully expressed as an RDF graph then it's
not an LDP-RS.


>
> 2.  Some LDP-RS's are like that, but not all
>
-0.9

>
> 3.  None are like that.  Every LDP-RS (including every Container) has a
> state represented by exactly one RDF Graph.   Of course, you could
> represent the state of an LDP Server (which has lots of LDPR-RS's) in a
> dataset, where each LDR-RS URL was the name of a named graph containing
> that corresponding graph.
>

+0.9
For what this specification shall care about, i.e. the exposed resources
and transferred states. How the graph describing an LDP-RS looks like may
of course depend on your authorization level and on which side of the GFW
you are located. The server may internally have multiple graphs and
assemble the response graph from one or several of them but this is shall
not be a concern if this specification as clients should not need to care
bout this (like browsers don't need to know anything about database driven
webapps).


>
> 4.  Actually the entire state of some LDP Servers, with all of its
> LDP-RS's, is really just stored as one graph.   The information about how
> it is divided into LDP-RS's can be derived deterministically from the graph.
>
+1


> 5.  Like 4, but this is the case of all LDP Servers.   The division of
> triples into particular LDP-RS's must never involve state that isn't
> naturally present in the one backing graph.
>
-1


Thanks for these good questions. Statement 4 is the one which I saw
threatened by the wording of section 5.1.

Cheers,
Reto

>
> Having thought about this for 20 minutes now, my tentative answers would
> be 0, +1, -1, +1, -1.
>
>       -- Sandro
>
>