[UNDER CONSTRUCTION]
Querying for BGPs dependent on the properties of containing graphs doesn't differ from established practice, like e.g. querying for what Alice said, and in which graph:
SELECT ?g ?s ?p ?o
WHERE {
:Alice :said ?g .
{ GRAPH ?g { ?s ?p ?o }}
}
Result:
_:termgraph-15,http://example.org/a,http://example.org/b,http://example.org/c
_:termgraph-15,http://example.org/s,http://example.org/p,http://example.org/o
Repeating the example from the start page:
prefix : <http://ex.org/>
prefix nng: <http://nng.io/>
:G1 {
:G2 {
:Alice :buys :Car .
:G2 nng:domain [ :age 20 ];
nng:relation [ :payment :Cash ];
nng:range nng:Interpretation ,
[ :color :black ].
} :source :Denis ;
:purpose :JoyRiding .
:G3 {
[] {
:Alice :buys :Car .
THIS nng:domain [ :age 28 ] .
} :source :Eve .
} :todo :AddDetail .
}
In the background, a query to retrieve all nesting relations
prefix : <http://ex.org/>
prefix nng: <http://nested-named-graph.org/>
SELECT ?s ?p ?o
WHERE {graph nng:embeddings { ?s ?p ?o } }
returns
urn:dydra:default,http://nested-named-graph.org/transcludes,http://ex.org/G1
http://ex.org/G1,http://nested-named-graph.org/transcludes,http://ex.org/G3
http://ex.org/G1,http://nested-named-graph.org/transcludes,http://ex.org/G2
http://ex.org/G3,http://nested-named-graph.org/transcludes,_:b29
A query to learn what :G1 itself contains
prefix : <http://ex.org/>
prefix nng: <http://nested-named-graph.org/>
SELECT ?s ?p ?o
WHERE { graph :G1 { ?s ?p ?o } }
returns
http://ex.org/G3,http://ex.org/todo,http://ex.org/AddDetail
http://ex.org/G2,http://ex.org/purpose,http://ex.org/JoyRiding
http://ex.org/G2,http://ex.org/source,http://ex.org/Denis
A query for all nested content
prefix : <http://ex.org/>
prefix nng: <http://nested-named-graph.org/>
SELECT ?s ?p ?o
FROM INCLUDED nng:NestedGraph
WHERE { graph :G1 { ?s ?p ?o } }
returns
_:b29,http://nng.io/domain,_:o-30
http://ex.org/Alice,http://ex.org/buys,http://ex.org/Car
_:o-30,http://ex.org/age,28
_:b29,http://ex.org/source,http://ex.org/Eve
http://ex.org/Alice,http://ex.org/buys,http://ex.org/Car
_:o-25,http://ex.org/age,20
_:o-26,http://ex.org/payment,http://ex.org/Cash
_:o-27,http://ex.org/color,http://ex.org/black
http://ex.org/G2,http://nng.io/domain,_:o-25
http://ex.org/G2,http://nng.io/relation,_:o-26
http://ex.org/G2,http://nng.io/range,_:o-27
http://ex.org/G2,http://nng.io/range,http://nng.io/Interpretation
http://ex.org/G3,http://ex.org/todo,http://ex.org/AddDetail
http://ex.org/G2,http://ex.org/purpose,http://ex.org/JoyRiding
http://ex.org/G2,http://ex.org/source,http://ex.org/Denis
The result above contains a lot of annotating statements. To get a quick overview of the central information we'd like to retrieve only the core facts, those that themselves are annotated with further detail. That would in the above example be two instances of :Alice :buys :Car .
[TODO]
Querying for an annotation on a nesting graph or any graph it is nested in is discussed in an example walk through and the accompanying shell script.
[Under Construction]
We have to differentiate between
- regular RDF data
- data in graph literals and
- data included from graph literals with special semantics
A query MUST NOT return results in RDF literals or included with un-asserted semantics from RDF literals if not explicitly asked for (to prevent accidental confusion of asserted and un-asserted data).
This is guaranteed by the need to use specific keywords in a FROM
clause to include literals in the context graph of a query.
A query MUST return RDF literals included with asserted semantics and it MUST annotate the returned data with those semantics (because asserted data has to be visible, but its specific semantics have to be visible too).
[TODO]
this is not yet guaranteed, as it requires some modification to the query execution engine. Those modifications however will be beneficial to all queries on nested graphs, not just such including graphs with special semantics.
Explicitly asking for literal data with un-asserted semantics can be performed in two ways: either use a FROM
modifier to the query or explicitly ask for the content of a literal.
Any query asking specifically for data from a literal will get those results without having to select the literal type in a FROM
clause.
A query using the FROM
modifier will include results from all literals of that type:
- LITERAL will include all ":s :p :o"^^nng:ttl and ":s"^^nng:TermLiteral literals, included or not
- INCLUDED will include all included literals, asserted and un-asserted, but not their LITERAL source
- REPORT will include all unasserted transparent types
Annotating the returned data with semantics is performed in a similar way as when authoring. However, asserted terms are not put in quotes:
- a term in a result set is encoded as a term literal, e.g. [QUOTE]:Superman, [REPORT]":Superman"
- a graph in a CONSTRUCT result is encoded as a graph term, e.g. [QUOTE]{:s :p :o}, [REPORT]":s :p :o"
@base <http://dydra.com/> .
prefix : <http://example.org/>
prefix nng: <http://nested-named-graph.org/>
prefix iana: <https://www.iana.org/assignments/media-types/application/>
prefix owl: <http://www.w3.org/2002/07/owl#>
:Bob :says ':Moon :madeOf :Cheese'^^iana:trig .
:Alice :said ':s :p :o. :a :b :c'^^iana:trig .
[ :Y nng:Quote]':ThisGraph a :Quote'^^iana:trig .
[nng:Quote]{:LoisLane :loves :Superman} .
:LoisLane :loves :Skiing .
[nng:Report]{:LoisLane :loves :ClarkKent} .
[nng:Report]{:Kid :loves :Superman }.
:Kid :loves ':Superman' .
:Carol :claims {":Denis :goes :Swimming"} .
:Y {:Some :dubious :Thing} .
:ClarkKent owl:sameAs :Superman .
:ClarkKent :loves :LoisLane .
Be aware of but let yourself not get irritated by the fact that the syntax in this example is not always reflecting exactly the description given in other parts of the documentation.
Prefixes in the following queries are always:
prefix : <http://example.org/>
prefix nng: <http://nested-named-graph.org/>
A naive request for mentions of Superman only retrieves mentions in the default graph:
SELECT ?s ?p
WHERE { ?s ?p :Superman }
Result:
http://example.org/ClarkKent,http://www.w3.org/2002/07/owl#sameAs
Including also mentions in quoted statements requires to add a respective FROM INCLUDED
instruction:
SELECT ?s ?p
FROM INCLUDED nng:Quote
WHERE { ?s ?p :Superman }
Result:
http://example.org/LoisLane,http://example.org/loves
http://example.org/ClarkKent,http://www.w3.org/2002/07/owl#sameAs
Asking for what or whom Lois Lane loves follows the same principle. A naive query returns only skiing:
SELECT ?o
WHERE { :LoisLane :loves ?o }
Result:
http://example.org/Skiing
Asking also for quoted statements return also Superman.
SELECT ?o
FROM INCLUDED nng:Quote
WHERE { :LoisLane :loves ?o }
Result:
http://example.org/Superman
http://example.org/Skiing
Here the same for reported statements (please ignore that the semantics in this example don't make much sense):
SELECT ?o
FROM INCLUDED nng:Report
WHERE { :LoisLane :loves ?o }
Result:
http://example.org/ClarkKent
http://example.org/Skiing
And both:
SELECT ?o
FROM INCLUDED nng:Quote
FROM INCLUDED nng:Report
WHERE { :LoisLane :loves ?o }
Result:
http://example.org/ClarkKent
http://example.org/Superman
http://example.org/Skiing
Making assertions about the moon visible requires to include literal graphs (from a previous version of NNG). A naive query will not find them:
SELECT ?o
WHERE { :Moon ?p ?o}
Result:
# no results
An explicit request does:
SELECT ?o
FROM INCLUDED nng:GraphLiteral
WHERE { :Moon ?p ?o}
Result:
http://example.org/Cheese
TODO
Queries should always return RECORDS, because they are asserted - but in a different way, indicating that they are opaque, but REPORTS and QUOTES only when specifically asked for via FROM INCLUDED, because they are unasserted. In general query results with non-standard semantics should be rendered differently.
Since annotations on graphs may provide important detail about the statements they contain it is important that for each BGP match the containing graph can be easily retrieved. A result format should be provided that returns with each match the name of the garph from which it originates.
[TODO]
The same argument can be made about matches from included graph terms that are governed by non-standard semantics. More on this below.
[TODO]
SPARQL leaves it unspecified if the context graph is the default graph or the union of all named graphs. This needs a solution, probably as a Dataset Vocabulary.
We introduce graph literals as a queryable datatype to implement non-default semantics. However, we need to control how matches against these graph literals get included in query results. By default they are not included. They can however be matched against by
- either calling them visible for transclusion in a FROM clause, introduced by an
INCLUDED
keyword and followed by the IRI referring to the respective semantics, e.g.FROM INCLUDED nng:Literal|nng:Quote|nng:Report|nng:Record
- or by targeting them as a class in a FROM or FROM NAMED clause,
- or by matching them explicitly in a query, by specifying a class or an individual name in a GRAPH clause.
Some examples are given above.