Re: [External] : Re: Semantic Predication: 1 - basic distinctions

I like the fact that Thomas' scheme seems to go beyond the capability of named triples in RDFn by allowing easy references to the individual components -- subject, predicate, and object -- of a named triple. In a sense this is equivalent to a dot notation -- <nameOfTriple>.subject, <nameOfTriple>.predicate, <nameOfTriple>.object -- but his syntax is probably more compliant to the IRI syntax.

Thanks,
Souri.


________________________________
From: Thomas Lörtsch <tl@rat.io>
Sent: Wednesday, February 15, 2023 11:13 AM
To: Franconi Enrico <franconi@inf.unibz.it>
Cc: RDF-star WG <public-rdf-star-wg@w3.org>
Subject: [External] : Re: Semantic Predication: 1 - basic distinctions

Hi Franco,



I believe that your distinction between "semantic" and "modal/epidemic" predications (*) is too brittle to be workable in practice.
For example you consider ":accordingTo" an example for modal/epistemic predication. However, :accordingTo to me sounds very much like :source, :src, :said ... - all those properties that we make up regularily to illustrate provenance use cases. And provenance is so often used to illustrate examples because in our intuition it is far from modifying the meaning of a statement, let alone make it the subject of a modality or believe system. Granted, that intuition is not well-founded, as the source of a statement can make all the difference e.g. in court - but that just confirms my point: the use case determines if a source is just administrative detail or a central piece of information. In any case, on itself it just conveys a description of the source. Descriptions is all there is in RDF. You can define certain properties like ":believes" or ":accordingTo" to have special meanings and employ a semantic extension to interpret them accordingly and drive entailments outside of RDF/S, OWL etc. Only then are you entering the realm of modalities.
In general I think such attempts at classification most of the time are intuitive only to their creators ;-)



The other distinction you make, between "syntactic" and "semantic" predications, is IMO justified. I would name it differently though - I prefer FACT and ARTEFACT - and I don’t agree that that syntactic/artefact predications should refer to the referentially opaque version. An example: Carol said that Alice likes Bob and Dan added that fact to the triple store. So:

   << << :Alice :likes :Bob >> :src :Carol >> :src :Dan .

I see no justification for referential opacity. It can be employed, but there is no need and since the repurcussions are subtle but wideranging IMO it shouldn’t - not in this general and passing way.

Also I’m not proposing a solution here (but below) on how to disambiguate the two different kinds of reference, I just want to illustrate the problem. But note that this problem has strong parallels with the identity problem of the Semantic Web: is an IRI meant to refer to a webpage or to what the webpage is about.



In the last example on semantic predicatins in eMail nr. 2 you use properties ":spouse-1" and ":spouse-2", defined as subproperties of ":spouse". Note that here you are employing the Singleton Property approach and wouldn't need quoted triples at all. But, because quoted triples reference the type, practically all your examples could face the same need to account for a multiplicity of annotations. Ergo Singleton Properties might be the better approach after all.



Also, I don’t agree with your take on reification: reification introduces a meta-level, the reification is not the same as what it reifies. Check yourself if when you think you’re reifying a statement, you’re rather creating an instance or subclass of said statement. That is not reification. I’m specifically referring to eMail 4, Example 4.



I’ve got a different proposal for the identification problem:

    :Alice 1@:likes :Bob .
    :1#predicate :source :Carol
    :1#triple :source Dan

Annotations on the predicate annotate the fact in the realm of interpretation. Annotations on the triple annotate the artefact, the syntactic representation. This use of fragment identifiers IMHO is in line with web architecture.

I’ve got two more:

    :Alice 1@:likes :Bob .
    :1#subject :age 17
    :1#predicate :source :Carol
    :1#object :coolnessFactor :Rocksinger
    :1#triple :source Dan

Note the nicely memorable set of s/p/o/t fragment identifiers and the very interesting increase in expressivity. Carol says that Alice at age 17 liked :Bob because he was the singer of a rockband, and Dan added the fact to the triple store. You’d need two few more blank nodes - for Alice and Bob - to model this in regular RDF, and you’d need to know about those blank nodes when querying.



Best,
Thomas



> On 14. Feb 2023, at 17:24, Franconi Enrico <franconi@inf.unibz.it> wrote:
>
> As I said, I’m interested to make sure that in RDF-star there will be a sound characterisation of the class of use cases which I call “semantic predication”. It is clear that they behave homogeneously but differently from the other two classes of use cases which I call “syntactic predication” and “modal/epistemic predication”. For this reason and for simplicity, in order to avoid confusion, at this stage I will use three different notations to identify embedded triples in the three different predication classes; I will argue elsewhere why I believe that this is better than adopting other ways to distinguish the three classes.
>
> Let me, again, summarise the difference between these three classes, via three different examples:
>
> Semantic predication example:
>
> <<< :john :teaches :cs101 >>> rdf:type :teaching ;
>                               dct:Location dbr:Stanford_University ;
>                               dct:PeriodOfTime :1st-term-2022 .
>
> A semantic embedded triple denotes a resource that is meaningful in the domain of interest. In the above example, <<< :john :teaches :cs101 >>> denotes an instance of :teaching.
>
> Syntactic predication example:
>
> << :john :teaches :cs101 >> :recorded "2021-07-07"^^xsd:date .
>
> A syntactic embedded triple denotes a resource representing the triple itself as a syntactic object. In the above example, << :john :teaches :cs101 >> should denote an instance of something like unstar:triple and not an instance of :teaching.
>
> Modal/epistemic predication example:
>
> <<<< :john :teaches :cs101 >>>> :accordingTo :employee22 .
>
> A modal/epistemic embedded triple does not denote any meaningful resource in the domain of interest, but it represents a statement which should be true in the context of the predication. For this reason, it would be wrong to let a modal/epistemic embedded triple denote a resource. As a matter of fact, a modal/epistemic embedded triple should denote a set of RDF interpretations, namely all the RDF interpretations in which the modal/epistemic embedded triple is true. This leads to a semantics for RDF-star modal/epistemic embedded triples in the style of modal logics, which clearly can not be adjusted easily as an extension of the RDF 1.1 semantics. However, in the spirit of RDF as a language capable of meta modelling, the modal/epistemic embedded triple  <<<< :john :teaches :cs101 >>>> could still denote a resource, and it would be an instance of something like unstar:statement.
>
> Final comment:
> So, the above examples show that a way to understand which class an occurrence of an embedded triple belongs to, is to ask yourself: does the occurrence of the embedded triple denote an instance of some event/state meaningful in your domain, or it denotes just the occurrence of the triple itself, or it denotes a statement which is meant to be true in the context of the predication?
>
>
>