Re: Multiple Named Graph

Hi,

On Tue, Mar 25, 2014 at 10:07 AM, Reto Gmür <reto@apache.org> wrote:
>
>  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.
>

IMHO, LDP follows the same approach as mentioned in the webapp analogy.
Though out the LDP spec, I think what we are talking about is the external
view or how the client sees the data. What the server does internally is up
to the server and is not a concern of the LDP spec. In some of the
scenarios that we implement, we don't even have a triple store in the
backend and we dynamically generate RDF using some API invocations to an
application or converting relational data.

I think section 5.1 describes named graphs to handle a special case of
composing multiple resources in one HTTP response or embedding member data
in a container representation i.e, "*Servers may provide the net worth
resource and supporting containers in a single response representations*".
Here we are returning a composite resource which contain more than one
logical resource for some reason, may be performance by avoiding the client
make multiple round trips. So this is not about internal data or how they
are stored in a triple store but how the client can differentiate the
triples that are returned in the composite resource into multiple logical
resources. It allows the server to say that it included triples from other
LDD-RSs in the same response. The client can clearly see this is if the
returned representation is in a format that can show quads.

BR,
Nandana