Re: Occurrences as Named Triples

> On 6. Jan 2024, at 20:03, Niklas Lindström <lindstream@gmail.com> wrote:
> 
> Given recent discussions (in emails and during the last Semantic TF
> meeting), I've adjusted my position, and come to some tentative
> conclusions.
> 
> 1. We haven't fully clarified what we (need to) mean by occurrence. I
> think most(?) expected it to be "an occurrence of one specific
> triple".

Define "specific"… 

> 2. The notion of truth-makers [1] is a valuable input, at least from a
> philosophical point of view. It also appears too advanced, or
> ambitious, and while it appeals to my "intuitions" about what we're
> talking about, I think we need something simpler for triples. It does
> however, to me, further affirm that occurrences and not "types" are
> key.

I skimmed the first paragraphs of [1] and they don’t help me at all. In what respect do you think is that notion helpful? How does this concept of truthmakers relate to triples, occurrences, names, etc? Or do you find it helpful w.r.t. asserted vs unasserted statements? And if yes, how?

> 3. The RDFn proposal is in a clearer state now [2]. It has always [3]
> been about *naming triples*, and from my point of view, its current
> design, with a functional requirement on the name to the triple,
> solves the problem of mapping the name to the triple.

To me it’s pretty unclear what that functional requirement expresses. It could be one name per type, ergo no occurrences whatsoever, but back to the CG proposal. It could be many different names but bound to the syntactic form of the triple, ergo occurrences but with referential opacity. It could be many different names, but about the meaning of the triple, ergo a semantics similar to RDF standard reification. See 1. above… 

> 4. This is different from triple terms in the abstract syntax, and
> avoids special properties. The named, unasserted triple is a new
> concept,

It is a concept that maybe we should think more about. It is not immediatly clear why we should provide machinery to talk about occurrences of not asserting something. Wouldn’t a reference to the type suffice? Well, no, it wouldn’t as it would run into the same cul de sac as triple terms (as types). Okay… 

> so it does add to RDF concepts and abstract syntax, but
> differently (I think it is simpler). Whether N-triples can now contain
> "quads" and N-quads become quins, or if we keep more of the "shape" of
> triple terms, as in the triple occurrence consolidation, needs to be
> further thought through. (It does feel more like a typographical
> concern than a conceptual one though. The concepts and abstract syntax
> would now have named triples added, and that's it.)
> 
> 5. RDF-star syntax can remain largely as is, with the recent addition
> of triple occurrence names (implicit or explicit).
> 
> 6. These are named triples (unasserted but described in a graph), and
> not named graphs. There is a likeness in that just as you cannot use
> the same name for two different graphs in a dataset, you cannot use
> the same name for two different triples in a graph. (But in different
> graphs, presumably.) The naming will presumably be fully semantically
> defined though, and named triples are unequivocally unasserted, which
> should further clarify the distinctions.

I see two ways in which this can break:
1) the name being used multiple times, refering to different triples
2) multiple triples of the same name but different syntactic form all referring to the same meaning
Both were discussed Friday and captured in Enrico's simple example:

[17:20] <enrico> :liz :spouse :richard .
[17:21] <enrico> << :wed-1 | :liz :spouse :richard >>  :starts 1964 ;  :ends 1974 .
[17:22] <enrico> << :wed-2 | :liz :spouse :richard >>  :starts 1975 ;  :ends 1976 .
[17:22] <enrico> << :wed-1 | :richard :spouse :liz >> .
[17:23] <enrico> << :wed-1 | :liz a :wife >> .
[17:25] <enrico> << :wed-1 | :richard :spouse :liz >> ; :starts 1964 .

The first case (see 17:23) is discouraged by web architecture principles. However semantic web semantics generally do not forbid anything (open world etc). It is possible to have an RDF standard reification quad with more than one subject/predicate/object (obviously it’s not a quad anymore). TriG merges the contents of multiple graphs that all have the same name [4]. So the constraint would have to be part of the model and would have to be enforced not just when merging graphs but when authoring them, right?

The second case (see the second instance of 17:22) brings back the discussion about referential opacity. What are we concerned with: syntactic form or meaning. That’s again the questions I had above. A meaning can be expressed in many syntactic forms. That might not be a problem at the basic RDF layer, but it will become one at the upper layers of RDFS, OWL, etc.

My hunch is that avoiding all these problems by making graphs possible would be a much more elegant solution than introducing hard reqirements on uniqueness and referential opacity. There is much more potential to break the fundamental workings of RDF with such constraints than in the pretty niche and construed problems that Peter presented w.r.t. graphs.

> 7. Named triples are reasonably *just* better reification. (Both
> unstarring and "starring" would be very simple.)
> 
> Example (with only implicit names):
> 
>    <book> :datePublished "2023" {| ex:impliedBy <#bp23> |} ;
>      :publisher <X> {| ex:impliedBy <#bp23> |} .

I bet you’d already like to have graphs instead of tedious repetition of triple annotations ;-)

>    <#bp23> a :PublicationEvent ;
>        :location <London> .
> 
>    << <book> :datePublished "2023" >>
>      ex:source <bookedition#titlepage> ;
>      ex:comment "The edition statement says New York."@en .

B.t.w. we didn’t discuss nesting on Friday. Since I recently became aware that one would not be able to annotate the above in one nesting triple, I’m pretty much against nesting in RDF-star. It’s just a too restricted version of nesting, not even well supported in SPARQl, as to be worth the effort. 

> In N-Triples with named triples (here, the name comes *first* for
> unasserted triples, followed by a `|`):
> 
>    <book> <sdo/datePublished> "2023" .
>    _:b1 | <book> <sdo/datePublished> "2023" .

How is this still an (N-) triple?

>    _:b1 <ex#impliedBy> <#bp23> .
>    <book> <sdo/publisher> <X> .
>    _:b2 | <book> <sdo/publisher> <X> .
>    _:b2 <ex#impliedBy> <#bp23> .
> 
>    <#bp23> <rdf#type> <sdo/PublicationEvent> .
>    <#bp23> <sdo/location> <London> .
> 
>    _:b3 | <book> <sdo/datePublished> "2023" .
>    _:b3 <ex#source> <bookedition#titlepage> .
>    _:b3 <ex#comment> "The edition statement says New York."@en .
> 
> (Note: Whatever form, we need to allow it in Turtle too, in order to
> keep N-Triples as a strict subset thereof. Another naming operator
> like `:=` might be clearer.)
> 
> In the same RDF source, this MUST be an error (_:b1 is only allowed to
> name one triple):
> 
>    _:b1 | <book> <sdo/datePublished> "2023" .
>    _:b1 | <book> <sdo/publisher> <X> .
> 
> (Should this stop processing, or warn and ignore "renames"? I propose
> full stop upon interpretation.)
> 
> Suggestion: Call the unasserted, named triples *claims*. Calling them
> edges (or arcs) could be confusing, since they are, from an RDF point
> of view, "hypothetical", and not partaking in "forming" the graph, as
> asserted triples are. The rdf:type could be rdf:Claim (rdfs:subClassOf
> rdf:Statement?). Optionally, rdfs:Fact could be defined as a *user
> hint* that this claim is also asserted (possibly added by the
> annotation syntax), or that any so typed claim in the graph is
> informally "accepted". It would not have any formal semantic meaning.

I fear I have to offer one more level of confusing detail: one might want to differentiate both unasserted claims and facts. E.g. Lois Lane believes for a fact that Clark Kent and Superman are different persons. Having both unasserted claims and facts at our disposal might help model this more accurately with *asserting* it as a fact. I’m not sure if this is helpful, but it kept me thinking.

> Regarding opacity: Since claims do not "partake in the graph", they
> are obviously not reasoned over

I don’t think that’s a valid conclusion. If the claim is that the ex:Moon is made of ex:cheese it is probably not concerned with the syntactic representation of the identifiers it uses to refer to Moon and cheese. An entailment that the claim is also represented by yps:Moon and zet:cheese is valid and valuable as long as the claim itself is considered noteworthy.

> (further setting sets of claims apart
> from named graphs, I think).

No, that’s an orthogonal issue. You’d just like it to be that way ;-)

> If they would be opaque (in that an OWL
> regime would not take their terms into account), we've foreseen
> problems in some use cases (e.g. not being able to find annotations on
> statements with the same meaning; and more tricky things in the formal
> semantics). If they are transparent, I assume that this:
> 
>    <X> owl:sameAs <Y> .
>    _:b1 | <book> <sdo/publisher> <X> .
>    _:b1 <ex#impliedBy> <#bp23> .
> 
> might (under some regime) entail:
> 
>    _:b4 | <book> <sdo/publisher> <Y> .
>    _:b4 owl:sameAs _:b1 .  # ?
>    _:b4 <ex#impliedBy> <#bp23> .
> 
> If so, it appears that the two names denote the same resource; but it
> is different from the occurrence "itself"? Needs more thought. Note
> that each named triple occurrence must

Only problems with that...

> still have a unique name. So
> this would NOT be entailed (and it would be an error):
> 
>    _:b1 | <book> <sdo/publisher> <Y> .
> 
> I believe that, while depending upon implementation particulars, you
> can still query over the inferred graph using SPARQL with entailment
> "off", and pick out the "raw data facts". I'm not sure if that's
> enough of a "keeping the cake and eating it" for precise data
> provenance though.


Best,
Thomas


> Thoughts?
> 
> Best regards,
> Niklas
> 
> [1]: <https://plato.stanford.edu/entries/truthmakers/>
> [2]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/att-0008/RDFn_Abstract_Syntax_and_Concepts.pdf>
> [3]: <https://blogs.oracle.com/oraclespatial/post/rdfn-extending-rdf-to-support-named-triples>

[4] https://www.w3.org/TR/trig/#sec-differences

Received on Sunday, 7 January 2024 12:45:39 UTC