TODO define nng:asserts as a new subtype of includes,
with the semantics of nng:transcludes,
but for graph literals
TODO define nng:Literal as an underspecified inclusion,
an inclusion without semantics
TODO the section on Literals is not correct
a section on Nested is missing
TODO the plan to have literals of datatype rdf:ttl be searchable
doesn't work. so we need another way to refer to the
abstract (and unasserted) type.
maybe the rdf-star syntax - << :s :p :o >> - without a name prefix?
how often would the two be confused?
[]<<:s :p :o>> :said :alice ; # token _:b1
:on :monday .
[]<<:s :p :o>> :said :bob ; # token _:b2
:on :tuesday .
vs
<<:s :p :o>> :said :alice ; # type
:on :monday .
<<:s :p :o>> :said :bob ; # same type
:on :tuesday .
maybe it would be better to introduce a
specific name for the abstract type
e.g. its hash value, or just a keyword
and express that syntactically as
[#]<<:s :p :o>>
or
[TYPE]<<:s :p :o>>
RDF literals can be used to introduce RDF with non-standard semantics into the data. Many such semantics are possible, like un-assertedness, referential opacity, closed world assumption, unique name assumption, combinations thereof, etc. This section concentrates on different kinds of citation. The section on Configurable Semantics discusses other options.
NNG provides maybe a bit too much different ways to specify the semantics of an inclusion.
To introduce a graph with specific semantics it is included from a graph literal, e.g.:
:Alice :said [ nng:includes ":s :p :o. :a :b :c"^^nng:ttl
nng:semantics nng:Quote ] The semantics of the inclusion specify which operations may be performed on the included graph. A quoted inclusion for example is not amenable to entailments and is not asserted either.
To prevent problems with monotonicity, specific inclusion properties for each semantics can be specified, e.g.
:Alice :said [ nng:quotes ":s :p :o. :a :b :c"^^nng:ttl ]This provides an extra guarantee that no entailments are derived from the included graph before a semantics configuration has been retrieved that might forbid such an operation.
To provide even more comfort, specific semantic modifiers like eg. nng:Quote can be defined and prepended to a graph literal (also omitting the datatype declaration), creating a nested graph with the specified semantics:
:Alice :said [nng:Quote]":s :p :o. :a :b :c"To provide yet more comfort, special notations are provided to specify a select set of citation semantics, e.g.:
:Alice :said [] << :s :p :o. :a :b :c . >> # chevrons signify nng:QuoteThe next section will present all pre-configured semantics with their keywords and notations.
The RDF*/star Community Group was quite determined that an annotation device should also provide means to document unasserted assertions and that references to the annotated triples should be referentially opaque. Not all of this made sense to us and some of it we found indeed rather dangerous in the context of annotation, but the needs so expressed nonetheless make sense. We therefore strived to provide a sound mechanism to express the most common forms of citation in a succinct and well-structured way.
Special keywords and notations are introduced to support the most common use cases:
- reporting assertions without asserting them,
- providing records of assertions with lexical accuracy and
- quoting statements with lexical accuracy, but without asserting them. This boils down to two aspects - an assertion may be asserted or not, and it may be interpreted or not - and four categories:
| referentially | referentially
| transparent | opaque
-----------------|---------------------|----------------------
asserted token | (NESTED) RDF | RECORD
| [] { :s :p :o . } | [] {" :s :p :o . "}
-----------------|---------------------|----------------------
unasserted type | REPORT | QUOTE
| [] "{ :s :p :o . }" | [] << :s :p :o . >>
NESTED asserted token, referentially transparent
(a graph, nested or not, no literal involved, i.e. standard RDF)
REPORT unasserted type, referentially transparent
(reported speech, akin to RDF standard reification as used "in the wild")
RECORD asserted token, referentially opaque
(interpreted, but without co-denotation)
QUOTE unasserted type, referentially opaque
(like verbatim quoted speech, and not endorsed)
LITERAL last not least the bare graph literal
":s :p :o."^^nng:ttl
since it is not included, it is also not named by a blank node
and the datatype declaration can't be omitted
really just a datatyped string, but on demand accessible by a SPARQL engine
These configurations should cover most use cases that are not targeting specific semantic arrangements like Unique Name Assumption, Closed World Assumption, etc. Of course, there's always a way to advance even deeper into the rabbit hole...
# VOCABULARY
nng:Record a rdfs:Class ;
rdfs:comment "Interpreted, but without co-denotation - asserted token, referentially opaque" .
nng:records a rdfs:Property ;
rdfs:subPropertyOf nng:includes ;
rdfs:domain nng:Record ;
rdfs:range nng:GraphLiteral ;
rdfs:comment "Includes a graph literal with record semantics: asserted and referentially opaque" .
nng:Report a rdfs:Class ;
rdfs:comment "Reported speech, akin to the use of RDF standard reification in the wild - unasserted type, referentially transparent." .
nng:reports a rdfs:Property ;
rdfs:subPropertyOf nng:includes ;
rdfs:domain nng:Report ;
rdfs:range nng:GraphLiteral ;
rdfs:comment "Includes a graph literal with report semantics: un-asserted and referentially transparent" .
nng:Quote a rdfs:Class ;
rdfs:comment "Like verbatim quoted speech, but not endorsed - unasserted type, referentially opaque" .
nng:quotes a rdfs:Property ;
rdfs:subPropertyOf nng:includes ;
rdfs:domain nng:Quote ;
rdfs:range nng:GraphLiteral ;
rdfs:comment "Includes a graph literal with quotation semantics: un-asserted and referentially opaque" .A few examples may illustrate the use cases for these semantic configurations. All these configurations have one thing in common: they are queryable in SPARQL. However, a query will have to explicitly include them so that unasserted quotes can't pop up in unassuming result sets.
Unasserted assertions are a niche but recurring use case that so far isn't properly supported in RDF. Many participants of the RDF-star CG strongly argued in its favour. The intent is to document assertions that for some reason one doesn't want to endorse, e.g. because they are outdated, represent a contested viewpoint, don't pass a given reliability threshold, etc.
The RDF standard reification vocabulary is often used to implement unasserted assertions, but the specified semantics don't support this interpretation and its syntactic verbosity is considered a nuisance. A semantically sound and at the same time easy to use and understand mechanism would be a useful addition to RDF's expressive capabilities.
However, the semantics of existing approaches in this area, like RDF standard reification and RDF-star, differ in subtle but important aspects. NNG supports two kinds of unasserted assertions: reports with standard RDF referentially transparent semantics, and quotes with referentially opaque semantics.
Reports resemble indirect speech in natural language. The aim is not to reproduce a statement in verbatim equivalence, but only to document the meaning of it. Like quotes reports are not actually asserted, but in any other respect they perform like regular RDF. We might for example neither want to endorse the following statement nor might we want to claim that this were Bob's words verbatim:
:Bob :said [] "{ :Moon :madeOf :Cheese . }" .This reports but doesn't assert Bob's claim. The IRIs refer to things in the realm of interpretation, they are not a form of quotation. Bob may have a used an IRI from Wikipedia to refer to the moon and the report would still be correct. This semantics is very similar to that of RDF standard reification.
Quotes are used to document statements with lexical precision, but again without endorsing them. One may imagine a written statement issued to a court, or documenting a conversation where the precise account of the actual wording used is important. This may be useful for use cases like versioning, explainable AI, verifiable credentials, etc. The example somehow unrealistically assumes that Bob speaks in triples, but note the emphasis on :LOVE that the quote preserves:
:Bob :proclaimed [] << :i :LOVE :pineapples . >> .Likewise, quotation semantics suppresses any transformations that are common in RDF processes to improve interoperability, e.g. replacing external vocabulary with inhouse terms that refer to the same meaning, entailing super- or subproperty relations or even just some syntactic normalizations.
TODO the following is not quite correct
The bare literal, besides its function as a building block for the inclusion mechanism, may find uses on its own, e.g. to keep graphs around that have not been properly defined yet
:UC rdf:value " :x :y :z ."^^nng:ttl ;
:status :UnConfirmed .Graph literals can be used to document state, e.g. when implementing versioning, explainable AI or verifiable credentials.
# VOCABULARY
nng:statedAs a rdf:Property ;
rdfs:range nng:GraphLiteral ;
rdfs:comment "The object describes the original syntactic form of a graph" .The following example shows how this can be used to document some normalization:
[]{ :s :p :o } nng:statedAs ":S :p :O"^^nng:ttl .
In the following example the literal is accompanied by a hash value to improve security:
[]{ :s :p :o } nng:statedAs [
rdf:value ":S :p :O"^^nng:ttl ;
nng:hash "4958b2dad87fef40b4b4c25ab9ae72b2"^^MD5
]
Note that while the graph literal is accompanying an assertion of the same type, itself it is unasserted.
Records do introduce statements into the universe of interpretation, but they don't allow the interpretation to diverge from the lexical form. They are meant to be interpreted "literally". So like quotes they provide verbatim correctness, but they also are indeed asserted, not merely documented.
:Denis :called [] {":Proposal :literally :Madness . "}.For completeness lets establish that standard nested named graphs have standard RDF semantics. So in the following nested named graph
[] { :Alice :buys :Car . }the statement :Alice :buys :Car is interpreted exactly as if stated in a regular RDF graph.
And the following code includes a graph literal as nested graph:
:Doug :knows [ nng:includes ":Earth a :Sphere"^^nng:ttl ;
nng:semantics nng:NestedGraph ]A vocabulary is provided to define the precise semantics of REPORT, RECORD, QUOTE
and some other configurations like e.g. closed world and unique name assumption. We envision extensions of this mechanism towards e.g. lists and other shapes with more predictable properties than the open world semantics of RDF can provide, and also for close-to-the-metal applications like versioning, verifiable credentials, etc.
Such semantics will not have the benefit of built-in syntactic sugar nor the pre-defined semantics indicators, but they can still be encoded quite concisely, using the square bracket syntactic sugar together with namespaced identifiers, e.g.
:Bob :claims [nng:APP] { :s :p :o. :a :b :c . }if an unabbreviated form
:Bob :claims [ nng:includes ":s :p :o. :a :b :c"^^nng:ttl
nng:semantics nng:App ] is considered too verbose.