- From: Olaf Hartig <olaf.hartig@liu.se>
- Date: Thu, 11 Jan 2024 13:05:34 +0100 (GMT+01:00)
- To: Niklas Lindström <lindstream@gmail.com>
- Cc: RDF-star Working Group <public-rdf-star-wg@w3.org>
Hi Niklas, Is the approach in this email meant to be a replacement or an addition to the approach you described in the previous email just 9 hours ago? In other words, does one have to read that other email as a basis for understanding what you are doing in the current email or can that other email be ignored? Thanks, Olaf Jan 11, 2024 12:19:07 Niklas Lindström <lindstream@gmail.com>: > Further update; TL/DR: Named triples do *not* (AFAICS) have to name > one specific triple. It only "makes sense" to name multiple triples > with the same claim identifier if they are of the same reason. See > below for how that is so. > > (Aside: The below could also answer some, perhaps most, of Andy's > important concerns in [1]. I went from too much in one thread to > perhaps too many threads. I want the subject title to be specific to > the content discussed; but this is hard.) > > Full version: > > With named triples, a graph in the data model is a set of either > asserted and/or named triples. The named triples are not asserted in > and of themselves (conceptually the names denote a *claim*), but > another occurrence of the same abstract triple can also be asserted > (conceptually that is a *fact*). There can only be one such asserted > occurrence per graph (as in RDF 1.1), but many occurrences of the same > triple paired with different names. > > Conceptually, the *meaning* of a graph is the union of its *facts* and *claims*. > > Addition: Thus there may also be *different triples per name*. So the > functional restriction is not necessary. > > So these identically named but structurally different triples: > > <t> | <urn:x:s> <urn:x:p> <urn:x:o> . > <t> | <urn:x:s> <urn:x:p> <urn:x:o2> . > > Can be encoded as (now using rdf:value and a new datatype for the > lexical string representation of a triple): > > <t> rdf:value "<urn:x:s> <urn:x:p> <urn:x:o>"^^rdfx:lexicalTriple . > <t> rdf:value "<urn:x:s> <urn:x:p> <urn:x:o2>"^^rdfx:lexicalTriple . > > To be decided: these can either entail, or must be accompanied with, > the following reification to fulfil the condition of representing a > named triple: > > <t> rdf:subject <urn:x:s> . > <t> rdf:predicate <urn:x:p> . > <t> rdf:object <urn:x:o> . > > <t> rdf:subject <urn:x:s1> . > <t> rdf:predicate <urn:x:p1> . > <t> rdf:object <urn:x:o2> . > > Conceptually, this means that the claim is about all of these triples > at once. The triples are distinct, but the meaning is claimed to be > the same (i.e. the same claim, or the same fact if that is also > asserted about `<t>`). > > (Note that the reification is not "well-formed" (it is > "oversaturated", if you will), and is not in itself enough to pick > apart the original triples themselves named by `<t>`. This sets named > triples, describing claims or facts, apart from *just* reification. It > also makes them somewhat more like named graphs, but with different > characteristics, e.g. not necessarily asserted, inexorably coupled to > one graph (itself named or not), *and* reasonably only naming triples > coupled for *the right reasons*; see below.) > > (This is like a literal as a resource, which can have two lexical > values meaning the same thing.) > > It is also possible to check if a claim is for The Right Reasons. If > all triples are entailed from at least one triple, the others are > necessary truths if the claim is true, contingent upon at least that > one triple. > > (Aside: I think this pretty much reflects what the notion of a *truth > maker* (fact) with truth bearers (triples) is.) > > For instance, given: > > <a> | <elisabeth> ex:marriedTo <richard> . > <b> | <richard> ex:marriedTo <elisabeth> . > <c> | <elisabeth> a ex:Spouse . > <d> | <richard> a ex:Spouse . > > All of `<a>`, `<b>`, `<c>` and `<d>` *may* denote one claim (or actual > fact), for the right reasons, if: > > ex:marriedTo a owl:SymmetricProperty ; > rdfs:domain ex:Spouse . > > They *mustn't* be the same claim of course. But it makes sense to > declare them as owl:sameAs, directly or simply by stating them to be > of type rdfsx:Fact, which as defined using owl:hasKey would be > inferred to be the same under OWL entailment. > > Likewise, a claim can be *nonsense* in the same way. E.g with: > > ex:Batchelor owl:disjointWith ex:Spouse . > > This (as in what `<d>` denotes, *not* the named triples themselves), > would be nonsense: > > <d> | <richard> a ex:Spouse . > <d> | <richard> a ex:Batchelor . > > As would a graph which asserted them be. > > But this would not necessarily be so: > > <e> | <richard> a ex:Batchelor . > > It would be decidedly conflicting with `<d>` though. > > Questions: > * Would an rdfx:Claim only be a *proper* rdfsx:Fact if it is for the > right reasons? > * Could a proper rdfsx:Fact be automatically asserted under some > entailment extension? Probably not, since a graph can contain sense or > nonsense, it is not up to the facts to be decidedly asserted or not... > > (NOTE it might be tempting to infer named triples for all asserted > triples in a graph. But obviously that would result in an infinite, > recursive explosion of named triples, since each inferred triple would > then also entail another named triple.) > > Best regards, > Niklas > > [1]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0053.html> > > > On Thu, Jan 11, 2024 at 3:18 AM Niklas Lindström <lindstream@gmail.com> wrote: >> >> 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 12:05:45 UTC