Re: Multiple Named Graph

On 3/20/14 9:56 AM, 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.
>
> Cheers,
> Reto
>
Reto,

First off, your point is 100% valid, and spot on!

The problem I see right now is general understanding of this very 
important point by those who have approved this regression.

There is nothing about describing "net worth" that implicitly requires 
relations to represented as quads when that can be achieved using RDF 
triples.

"Graph" and "Named Graph" in SPARQL parlance, doesn't match colloquial 
use of "Graph" in RDF quarters, net effect, this kind of irritating 
confusion becomes the norm and propagates everywhere :-(

Personally, I minimize loose use of terms such as "Named Graph" or 
"Graph" since without qualification they are just another RDF confusion 
vector. Basically, in the context of durable RDF statement construction, 
both of the aforementioned terms refer to an RDF document denoted by an 
IRI. Of course, a SPARQLer will pop up and say: well, what about the 
system graph etc.., and the answer is simple: this has nothing to do 
with SPARQL, since a query language is a DBMS or Store feature which is 
only relevant when making RDF statements using such a system (even then 
a Named Graph is still a document denoted by an IRI generated by the 
DBMS or Store).

To conclude, If I can describe a network on a piece of paper using 
natural language or even RDF triple based statements. I should be able 
to do the same thing in an digital RDF document, without any need to 
express my statements as quads.

FWIW -- here are no RDF semantics representing relations as quads, they 
only exist for representing relations as triples. That is to say, TriG 
and NQuad != RDF, they are simply notations (concrete syntaxes in RDF 
spec parlance) for constructing documents comprised of collections of 
RDF statements (triples) partitioned by an identifier that processors of 
said notations treat as an external or internal document identifier.


-- 

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