Re: Representing Named Triples as Just Triples

Hi Olaf,

It is (alas) an addition (I should have said that instead of the
ambiguous "further update"). So you may have to read both to get the
full picture.

(I do hope the gist of this last one captures enough of the concept.
The previous email was mostly about *encoding* in just triples
(avoiding quads/quins), with the functional restriction on the
name,triple pair in place. This last is about *removing* that
functional restriction, and the conceptual consequences of doing so.)

Thank you,
Niklas


On Thu, Jan 11, 2024 at 1:05 PM Olaf Hartig <olaf.hartig@liu.se> wrote:
>
> 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:40:36 UTC