- From: Niklas Lindström <lindstream@gmail.com>
- Date: Thu, 11 Jan 2024 03:18:16 +0100
- To: RDF-star Working Group <public-rdf-star-wg@w3.org>
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