- From: James Anderson <anderson.james.1955@gmail.com>
- Date: Tue, 24 Oct 2023 00:16:19 +0200
- To: RDF-star WG <public-rdf-star-wg@w3.org>
good morning;
> On 23. Oct 2023, at 18:06, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote:
>
> Dear Thomas, all,
>
> ...
>
> To the rest of the discussion and the added complexity: apart from all the theoretical aspects we discuss here (and where I agree that graphs are more complex than triples), please also note that we would have to decide howto deal with quoted graph terms in practice. In SPARQL queries, it is relatively easy to search for a triple term having dbr:Linköping as subject, like:
>
> Select ?p ?o ?date
> {
> << dbr:Linköping ?p ?o>> ex:statedAt ?date
> }
>
> But to make a similar query for graphs, we either need to know the exact structure of the graph (that is: how many triples does it contain?) or we need to come up with extra Filter functions for SPARQL.
> If we have
>
> { dbr:Linköping a ex:City; ex:locatedIn dbr:Sweden} ex:statedAt „23.10.2023“^^xsd:date.
>
> A query
>
> Select ?p ?o ?date
> {
> {dbr:Linköping ?p ?o. ?s1 ?p1 ?o1} ex:statedAt ?date
> }
>
> Would fire, but
>
> Select ?p ?o ?date
> {
> {dbr:Linköping ?p ?o. ?s1 ?p1 ?o1. ?s2 ?p2 ?o3} ex:statedAt ?date
> }
>
> would not. I am sure we can solve this problem together, but this adds complexity since we need to have a discussion on how we would like to solve it.
how would matching nested graphs add any more complexity to sparql query formulation than named graphs already may?
queries which target nested graphs of single statements should require no more complex expressions than those for a triple term.
queries which target graphs with more statements would be as restrictive as the pattern specifies.
in the examples, above, patterns which were more restrictive might not match.
this would be an intended goal.
this particular example, however, would cross-join the two wild card statement patterns.
root@de17 /opt/spocq # dydra-import -X PUT -i application/n-quads james/test /dev/stdin <<EOF
> <http://example.org/Linköping> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.org/City> <http://example.org/graph> .
> <http://example.org/Linköping> <http://example.org/locatedIn> <http://example.org/Sweden> <http://example.org/graph> .
> EOF
4c70b81f-7e32-0f45-aeec-e7ed27355b7d
root@de17 /opt/spocq # fg
bin-seg/spocq-listener
(test-sparql "
select ?g ?p ?o
#from <urn:dydra:all>
where {
{graph ?g { <http://example.org/Linköping>?p ?o. ?s1 ?p1 ?o1. ?s2 ?p2 ?o3 } }
}
" :repository-id "james/test" :response-content-type mime:text/csv)
g,p,o
http://example.org/graph,http://www.w3.org/1999/02/22-rdf-syntax-ns#type,http://example.org/City
http://example.org/graph,http://example.org/locatedIn,http://example.org/Sweden
http://example.org/graph,http://www.w3.org/1999/02/22-rdf-syntax-ns#type,http://example.org/City
http://example.org/graph,http://example.org/locatedIn,http://example.org/Sweden
http://example.org/graph,http://www.w3.org/1999/02/22-rdf-syntax-ns#type,http://example.org/City
http://example.org/graph,http://example.org/locatedIn,http://example.org/Sweden
http://example.org/graph,http://www.w3.org/1999/02/22-rdf-syntax-ns#type,http://example.org/City
http://example.org/graph,http://example.org/locatedIn,http://example.org/Sweden
NIL
NIL
#<QUERY [B1963734-71EF-11EE-ADD5-F02F7494A8ED/NIL, select@FINALIZED, james/test@HEAD] {101AB7326B}>
T
*
---
james anderson | james@dydra.com | https://dydra.com
Received on Monday, 23 October 2023 22:16:38 UTC