Re: Multiple Named Graph

So to start from the beginnging again.
I checked the mentions of "named graph" in the spec.

In the definitions section:
[[
Linked Data Platform RDF Source (LDP-RS)
An LDPR whose state is fully represented in RDF, corresponding to an RDF named graph. See also the term RDF Source from [rdf11-concepts].
]]

Section 5.1:
[[ 
Alternatively, servers may provide the net worth resource and supporting containers in a single response representations. When doing this, a preference would be for RDF formats that support multiple named graphs, one named graph for the net worth resource and then two others for asset and liability containers. This allows for the membership triples to be represented with the named graph for the net worth resource, while the containment triples would be represented within the liability and asset containers [rdf11-concepts]. Generally, the membership triples belong to the representation of an LDP-RSand the containment triples belong to the representation of the LDPC.
]]

5.2.3.4 LDP servers that successfully create a resource from a RDF representation in the request entity body must honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server must fail the request.

5.2.4.2 LDP servers that allow LDPR creation via PUT should not re-use URIs. For RDF representations (LDP-RSs),the created resource can be thought of as an RDF named graph [rdf11-concepts].

That's all I found on a quick search.


On 20 Mar 2014, at 14:56, Reto Gmür <reto@apache.org> 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".

Ok, so that's in the non normative section 5.1 above.

> 
> I am irritated by this recommendation. First the specification mandates the possibility to serialize as turtle which does not currently support multiple named graphs.

yes, but it does not limit other serialisations.

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

It depends on what kind of server you are writing. If you are writing a server where any client can post anything - in  order to support Tabulator like clients, or others - then the
server will want to seperate domain logic it understands from logic it does not. No server will be able to understand all the triples POSTed, so the named graphs are a good
way to allow the server to be careful to seperate what it as a server understands ( essentially LDPCs interactions ), from the domain space.

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

The Container and its ldp:contains relations represent information the server must act on. If a client somehow
POSTs content with ldp:contains relations and you don't seperate that in your container, you could end up with a client messing up your
LDPC datastructure. The grouping of triples into graphs is important as it allows the server to distinguish what it "believes" from what the clients that created
statements stated.

Btw. I don't see what you loose in expressive power. You can always take a number of graphs, merge the information in each, and reason over it. 

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

Section 5.1 *suggests* this behaviour. It does not mandate it. There are good reason for the suggestion as explained above. 

The rest of the spec is very careful in how it phrases things. 5.2.3.4 and 5.2.4.2 say "resource can be thought of as an RDF named grap"
This does not mean that you can not in fact put everything into one big graph, if you later have some logic to work out what parts of your
big graph appear where, you'd have built named graphs on top of 1 graphs - in which case your resource can be "though of as an RDF named graph".
(This is often how one maps RDBMSs to RDF - RDBMSs don't have a notion of named graphs, so one has to make that concept explicit. )

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

LDP is a protocol for interaction between a client and a server. For the client, unless you only have one URL for your graph, it will appear 
to the client that you have more than one named graph. If you have one URL only for your graph, all you need to do is interact with it using
PATCH to add or remove triples. If you use POST and create new LDPRS, and for the client this will appear as one new named graph appearing.

My feeling is that you are thinking of the protocol too much from the server side. But protocols are means of communications between client and servers.

Henry



> 
> Cheers,
> Reto  
> 

Social Web Architect
http://bblfish.net/