On 25/08/2024 15:56, Bob DuCharme wrote:
(Sorry about using the older Fuseki that I just happened to have on my
hard disk before; I think the problem may have been that I was using the
wrong version of the data with it.)
This query gets 6 rows of results from Fuseki 5.1.0, 10 from GraphDB
10.7.1,
To get 10 there must be duplicates with different ?g in GraphDB (or
DISTINCT is mishandled). There are two ways to get the same s/p/o
triples. There are only 6 triples! 2 default graph and 2 x 2 named graph.
and 12 from Blazegraph. (In Blazegraph, the "one" and "two"
triples show up once with no value for ?g and once with bd:nullGraph as
the ?g value.)
SELECT DISTINCT ?g ?s ?p ?o {
{ ?s ?p ?o }
UNION
{ GRAPH ?g {?s ?p ?o }}
}
What about without the ?g
SELECT DISTINCT ?s ?p ?o {
{ ?s ?p ?o }
UNION
{ GRAPH ?g {?s ?p ?o }}
}
In your first message we have "SELECT * WHERE {?s ?p ?o}"
so three result columns. Without the ?g is the nearest equivalent.
Or CONSTRUCT { ?s ?p ?o } WHERE {
{ ?s ?p ?o }
UNION
{ GRAPH ?g {?s ?p ?o }}
}
because a graph is a set of triples.
Andy
This next query gets 6 rows with all three triplestores with no value
for ?g with the "one" and "two" triples in Fuseki and GraphDB and
bd:nullGraph as the ?g value in BlazeGraph:
SELECT ?g ?s ?p ?o
WHERE
{
{ ?s ?p ?o
MINUS { GRAPH ?g {?s ?p ?o} }
}
UNION
{ GRAPH ?g { ?s ?p ?o } }
}
It's less efficient than the first, but any "give me absolutely all the
triples" query is asking a lot of the processor anyway. I tend to use
them for pedagogical demos with small datasets, e.g after a named graph-
related update query to show the effect of that query.
Thanks,
Bob
On 8/24/24 3:27 PM, Andy Seaborne wrote:
On 24/08/2024 18:33, Bob DuCharme wrote:
Thanks Andy! I understand a bit, but have some followup questions.
For one thing, I couldn't figure out which part of https://
jena.apache.org/ about_jena/security-advisories.html was relevant to
this.
"Jena (tested with Fuseki 4.6.1)" -- always good to keep up-to-date.
Hint, hint.
Is it oversimplifying if I said:
- many triplestores treat the default graph to be the union of all
named groups with the triples in any unnamed graphs
- Jena does not do this by default but can be configured to
and that other triplestores do not support the full range that the
specs allow especially update.
This query shows the six triples from the original example in Fuseki
but shows ten rows of results in GraphDB (and, I will assume in the
other triplestores I tried before sending my original email):
SELECT DISTINCT ?s ?p ?o {
{ ?s ?p ?o }
UNION
{ GRAPH ?g {?s ?p ?o }
}
That query is "all triples" in default and named graphs.
Given there are only 6 "?s ?p ?o" anywhere in your example data I
don't see how "DISTINCT ?s ?p ?o" can be 10.
If it's 10, then there must be duplicates after DISTINCT.
GraphDB finds triples via two routes - default graph and named graph -
hence 10 in quads ?g/?s/?p/?o
Please try in other stores.
This is more verbose but got consistent results with the two
triplestores. Any comments or suggestions?
SELECT ?g ?s ?p ?o
WHERE
{
{ ?s ?p ?o
MINUS { GRAPH ?g {?s ?p ?o} }
}
UNION
{ GRAPH ?g { ?s ?p ?o } }
}
More expensive. BTW it has ?g in the projection. Do you get rows with
?g undefined?
Thanks,
Bob
On 8/24/24 10:40 AM, Andy Seaborne wrote:
On 24/08/2024 15:20, Bob DuCharme wrote:
Imagine running the short INSERT query at https://
www.learningsparql.com/2ndeditionexamples/ex338.ru on an empty
dataset. It inserts six triples: two in the default graph and two
each into two named graphs, for a total of six triples.
Next, we run the query SELECT * WHERE {?s ?p ?o}. In some
triplestores this returns a row for each of the six triples in the
dataset, but Jena (tested with Fuseki 4.6.1)
Don't forget:
https://jena.apache.org/about_jena/security-advisories.html
> only returns rows for the two triples in the > default graph.
It depends on the setup.
The default graph is a separate graph unless the setup configures it
to be viewed as the union of all named graphs.
In your example, you'll get 4 triples.
e.g. for TDB2:
:dataset_tdb2 rdf:type tdb2:DatasetTDB2 ;
tdb2:location "DB2" ;
## Optional - with union default
## for query and update WHERE matching.
tdb2:unionDefaultGraph true ;
.
Note - there still is a storage-level default graph.
unionDefaultGraph is a view.
I can't find anything in the Recommendation about what should
happen here.
The specs don't say much about how the dataset to be queried come
into being without any FROM's.
This is intentional because treating the default graph as the union
of named graphs has been a pattern since before the SPARQL 1.0.
In some systems, the default is really a named graph
It looks like https://www.w3.org/TR/sparql11-query/
#namedAndDefaultGraph would have been the place to clarify this. Is
the issue of proper behavior in this case just up to the
implementer, like what DESCRIBE is supposed to return? Or is it
something that the sparql12 group should clarify and document? (Or
maybe they have and I missed it...)
https://github.com/w3c/sparql-dev/blob/main/SEP/SEP-0004/sep-0004.md
https://github.com/w3c/sparql-dev/issues/43
There should be three names for the three cases:
DEFAULT
UNION (of named graphs)
ALL - a set view of all triples:
SELECT DISTINCT ?s ?p ?o {
{ ?s ?p ?o }
UNION
{ GRAPH ?g {?s ?p ?o }
}
Andy
Thanks,
Bob
