Re: Current agreement upon named graphs

I agree with David and Richard's responses, but just wanted to add...

On Fri, Nov 9, 2012 at 7:38 AM, Olivier Rossel <olivier.rossel@gmail.com>wrote:

> I have been out of the semantic web for some time, and I would like to know
> the current agreement upon named graphs.
>
> Here are my questions:
>  - can a triple belong to several named graphs?
>

Triples don't "belong to" a graph per se, but in general it's fine for the
same triple to appear in more than one graph. The exception to this is for
those triples that contain a blank node. In that case it may be possible to
have equivalent triples in different graphs, but not the same triple. What
I mean is that the blank nodes will be different, though it may be possible
to merge them if they were to be brought into the same context.

Hopefully that's OK with you, but if I'm too opaque, then an example would
be:

graph1:
  _:b1 ex:id ex:123456 .

graph2:
  _:b1 ex:id ex:123456 .

In this example, the _:b1 in graph1 is not the same as the _:b1 in graph2.
If they are brought into the same context (say, the contents of graph2 are
inserted into graph1) then we would see:
  _:b1 ex:id ex:123456 .
  _:b2 ex:id ex:123456 .

As you can see, the blank node label changed, indicating that it's not the
same blank node. Now, if we know that ex:id is a inverse-functional
property, then this indicates that the blank nodes must be the same, which
would allow the nodes to be merged, but this is at a higher semantic level
than plain RDF.

 - can the argument of the SPARQL "GRAPH" keyword  be *a list* of named
> graph?
> if yes, is this list considered to be the union of all those named graphs?
>

In SPARQL 1.0 we had to use a list of named graphs, which is the technique
that David referred to. However, that can interfere if you need named
graphs for any other reason. Another alternative with SPARQL 1.0 is to not
specify any dataset (no FROM or FROM NAMED clauses) and to bind a graph
variable with a basic graph pattern in the WHERE clause. Unfortunately,
that only works if there is information in the store that describes the
graphs that you want.

I like Richard's response about using VALUES in SPARQL 1.1. This is much
more flexible. It does have an issue whereby any FROM NAMED clauses can
interfere with the use of GRAPH, but if FROM NAMED is avoided then this
works perfectly. Any other part of the query that wanted to use a FROM
NAMED can specify its own GRAPH sections.


>  - is there a plan to investigate algebra of named graphs, such as :
> (namedGraph1 && !namedGraph2) || namedGraph3?
>
>
None that I know of. As David said, this can usually be done using SPARQL.
|| is just a union, && is the default join operation, and ! is a NOT EXISTS.

Regards,
Paul