Skip to content

Latest commit

 

History

History
476 lines (362 loc) · 16.5 KB

querying.md

File metadata and controls

476 lines (362 loc) · 16.5 KB

Querying

[UNDER CONSTRUCTION]

Querying Nested Graphs

Querying as Usual

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

Querying for Statements in a Graph and its Nested Graphs

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

Querying for Principal Statements Only

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 Along Nesting Paths

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.

Querying Included Literals

[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"

Example

@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.

Result Formats

how to retrieve the graph containing a result term together with the term

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]

how to retrieve the semantics governing a result term together with the term

The same argument can be made about matches from included graph terms that are governed by non-standard semantics. More on this below.

[TODO]

Extensions to SPARQL

FROM NAMED|ALL|DEFAULT

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.

FROM INCLUDED nng:Literal|nng:Quote|nng:Report|nng:Record

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 anINCLUDED 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.