Re: Occurrences as Named Triples

> On 11. Jan 2024, at 12:02, Andy Seaborne <andy@apache.org> wrote:
> 
> 
> 
> On 11/01/2024 10:38, Thomas Lörtsch wrote:
>>> On 11. Jan 2024, at 11:17, Andy Seaborne <andy@apache.org> wrote:
>>> 
>>> On 06/01/2024 19:03, Niklas Lindström wrote:
>>> -- What is the name token?
>>> 
>>> No URIs for names or there are now RDF graphs can't be merged yet each graph on its own is valid.
>>> 
>>> The names can't be blank nodes because the edge set names have a special property of "no inference" which would apply to the set of triples.
>> I’m not sure I understand you properly but you seem to say that names for occurrences can’t be regular URIs or blank nodes and need to be defined as a separate set because the triple term they refer to is referentially opaque.
> 
> In this proposal (edge set), that seems to be a consequence of the design. The edge set has an additional mandatory condition. Inferences relating to the name of the occurrence need to obey that condition. That connects the edge set to RDF semantics.
> 
> (Maybe I read it wrong.)
> 
>> I was hoping that we could go the following way: even if the triple trem is opaque, the reference - eg the rdfx:occurrenceOf relation - refers to its referentially transparent interpretation. Or we could have different variants of the occurrenceOf property that refer to either the referentially opaque or the referentially transparent interpretation.
>> If we don’t provide a link to the referentially transparent interpretation then we are back to one of the CG report’s basic problems: that what it annotates is nowhere to be found in the data.
> 
> [Aside: Could you write this as triples? The emails are for the wider audience as well. Thanks.]

I just did it a little in [0]. Here is a fuller account. Note that I use the triple term syntax in the RDF-star CG report sense, that is 

    << :s :p :o >> 

*doesn’t* expand to 

    << [] |: s :p :o >> 

i.e. it does not represent an occurrence but the type (if it should indeed be referentially  opaque or rather transparent will be discusssed below).

For the annotation syntax however I assume such an implicitly defined identifier when I don’t explicitly provide one.



The beauty of the annotation syntax 

   :s :p :o {| :a :b |}

is not its precise syntactic form, but that it fixes all the subtle differences that otherwise we have to define, disambiguate, make users aware of and bridge with duct tape.



What are those subtle differences:


1) asserted vs unasserted

Clearly ':s :p :o ' above is asserted. However, expanded to N-triples syntax

    :X rdfx:occurrenceOf << :s :p :o >> .
    :s :p :o 

we can only assume that

    :s :p :o 

was meant to be asserted by the creator of 

    :X rdfx:occurrenceOf << :s :p :o >> .

The two are independent of each other. It might very well be that the annotation was meant to refer to an unasserted triple and only at a later time the triple itself was added.


2) referentially transparent vs opaque

The triple

    :s :p :o .

is referentially transparent and the annotation syntax 

   :s :p :o {| :a :b |}

clearly refers to it as such. The triple term however, if defined as referentially oapque (as discussed now on the mailing list), refers to something else, something much more constrained (it's a reference to an exact quote, not just an account of a meaning). Defined that way the :X in 

    :X rdfx:occurrenceOf << :s :p :o >> .

will never refer to the (referentially transparent) RDF triple

    :s :p :o .

but to an asserted, but referentially opaque version of << :s :p :o >> - something that doesn’t yet exist in RDF (and that for that reason we specifically define in Nested Named Graphs).


3) fact vs claim

This is a variation of 1) above. To disambiguate annotations that refer to an assertion from those that refer to unasserted assertions we might introduce new properties, e.g. rdfx:assertionOf and rdfx:claimOf (rdfx:factOf would be nicer than rdfx:assertionOf, but it doesn’t treat the english language well). In consequence we could have the following graph 

    :s :p :o .
    :X rdfx:assertionOf << :s :p :o >> ;
        :a :b .
    :Y rdfx:claimOf << :s :p :o >> ;
        :c :d .

where neither :X nor :Y refer to the asserted triple (note that ':X rdfx:assertionOf << :s :p :o >>' *doesn’t* entail ':s :p :o').

We could expand on this and tackle the problem outlined in 2) by explicitly defining that rdfx:assertionOf and rdfx:claimOf refer to referentially transparent instances (analoguously to RDF standard reification). We could then go on and define other properties that refer to referentially opaque instances of the triple term, e.g. rdfx:opaqueAssertionOf and rdfx:opaqueClaimOf [1].

We would then have an exact and complete solution, but it would be confusing to use (not because the proposal is confused but because the terrain is confusing) and I’m not sure it will ever be followed correctly. On the other hand we wouldn’t need to propagate those subtle differentiations: we would clearly express what the annotation syntax maps to (see below) and would give a few examples for the other properties. After all, unasserted assertions and quotes are niche use cases and although we consider them important enough to cover them, we don’t need to confuse users that only want to understand how the general case, well covered by the annotation syntax, is mapped to N-Triples.


The beauty of the annotation syntax is that it gives a clear intuitive interpretation of all these subtle differentiations: the annotation annotates an asserted and referentially transparent occurrence. Following the above sketch it would be mapped to N-Triples as follows:

    :s :p :o {| :X | :a :b |}

    ==> 

    :s :p :o .
    :X rdfx:assertionOf << :s :p :o >> ;
        :a :b .

and 

    :s :p :o {| :a :b |}

    ==> 

    :s :p :o .
    [] rdfx:assertionOf << :s :p :o >> ;
        :a :b .


Everything else - like e.g. annotations on an opaquely asserted assertion without actually asserting it, to give the most extreme example - is there for the well-educated power user, but should be kept out of reach of casual users that just want to annotate a triple. 

Before Christmas it was consensus in the SemTF that triple terms are transparent. Why did this change? Because I started to discuss graphs as a means to account for different triples with the same meaning? Of course IMO the Nested Named Graph proposal would provide a better solution to the problems outlined above, but the above would at least not cause new problems. 

Best,
Thomas


[0] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0057.html
[1] Maybe it would be more useful to differentiate between referentially transparent and referentially opaque triple terms, but I’ll leave that for further discussion.

>> An annotation on a referentially opaque triple (no matter if term or occurrence) is never the same as an annotation on a referentially transparent triple (no matter if term or occurrence) of the same type. The disconnect is doubled: there is no direct link (there is in the annotation syntax but that’s just syntax, and there would be if we annotated graphs) and the two syntaxes do not even share the same semantics.
>> Thomas
>>>    Andy
>>> 
>

Received on Thursday, 11 January 2024 12:42:03 UTC