Representing Named Triples as Just Triples

This is an update to the Named Triples as Claims variant. (Using
terminology added to [1], and following [2].)

(I've yet to fully compare it to the Occurrence Set variant Andy just
posted [3]. They seem to have a lot of the same goals, vary in what is
added to the abstract syntax and data model, possibly vary on
many-to-one or many-to-many for occurrence-to-triple, and on opacity.)

Named triples can be represented as just triples, through a predicate
for the lexical triple representation.

This named triple:

    <t> | <urn:x:s> <urn:x:p> "l"^^<urn:x:d> .

Can be encoded as:

    <t> rdfx:lexicalTriple "<urn:x:s> <urn:x:p> "l"^^<urn:x:d>" .

This would *only* be for use in N-triples, to keep named triples as
just triples "over the wire". Other syntaxes supporting RDF-star would
parse directly into named triples.

(For RDF 1.2 Basic though, this does "expose" raw N-Triples also in
other syntaxes.)

These lexical forms could be dropped upon parsing as named triples.
They might still be entailed; just as the transparent meaning of named
triples in the graph needs to be entailed, as a regular reification,
for this design to work in `owl:sameAs`-dependent use cases [2].

Per the functional requirement, a different value of
`rdfx:lexicalTriple`for the same subject is not allowed to produce the
same name for a different triple. That would be the same restriction
as for the direct syntax of named triples. But it might not be
necessary to halt on it. The raw `rdfx:lexicalTriple` triple could be
kept as is, along with an issued warning. (A parser option could
control this behaviour, for use in linters, etc.)

Blank nodes have been seen as problematic in unstarring, since while a
parser can use the blank node remapping function, the mapping would
not survive roundtripping through RDF 1.1 (nor RDF 1.2 Basic) parsers.
But skolemization can be used to manifest the mapping, by also
associating the bnode with the genid lexical form:

So, given:

    <t> | <s> <p> _:b .

that would become:

    <t> rdfx:lexicalTriple "<urn:x:s> <urn:x:p>
<.../.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6>"^^rdfx:lexicalTriple
.

    _:b rdfx:genid ".../.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6" .

(That needs not be functional, but inverse-functional.)

The RDF data model with named triples would be (a variant of RDFn [4]):

    graph             ::= (triple|namedTriple)*
    triple            ::= subject predicate object
    subject           ::= IRI | BlankNode
    predicate         ::= IRI
    object            ::= term
    term              ::= IRI | BlankNode | Literal
    namedTriple       ::= identifier triple
    identifier        ::= IRI | BlankNode

(The difference from RDF 1.1 is the addition of namedTriple, and
allowing that in graph.)

Conceptually, graphs can contain both asserted triples and claims
thereof (as named triples). In the example above, `<t>` denotes the
*claim* of that named triple.

To query for these, SPARQL-star syntax may be required. But a regular
reification can be entailed from a named triple, which is also needed
to support transparency in this design.

Alternatively, an actual reification could be required alongside the
lexicalTriple form above in N-triples, and RDF-star could be sugar for
reification with this additional data model and conceptual
interpretation. That would *extend* reification to also support
quotation. It would result in more triples in the raw data of course,
but it would not require reifications to be, or stay, "well-formed".
(They can have multiple subjects, predicates or objects, and distinct
occurrences are still preserved, through the named triple in the
abstract syntax, and through the lexical form in N-triples.)

A claim can be stated as a rdfsx:Fact, meaning that it denotes the
fact, i.e. the actual asserted triple in the graph. Using OWL, it is
then restricted to that denotation (through owl:hasKey on the
reification parts, there can only be one).

Best regards,
Niklas

[1]: <https://github.com/w3c/rdf-star-wg/wiki/Triple%E2%80%90Edge-subgroup-proposals>
[2]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0047.html>
[3]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0050.html>
[4]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/att-0008/RDFn_Abstract_Syntax_and_Concepts.pdf>

Received on Thursday, 11 January 2024 02:18:49 UTC