Re: Semantic Predication: 4 - more worked out examples

On 16 Feb 2023, at 16:17, Olaf Hartig <olaf.hartig@liu.se> wrote:

You are right that Timothée's trick with :transparentType does not work as intended, for exactly the reason that you mention.
Also, your fix to the TEP version of your example is correct now. Notice, however, that introducing the :created2 property is not actually needed. Instead, the :created property can be used directly. (in contrast, :created1 is needed, exactly as you have it).

Agree.

Notice also that the relationship type 'created' is perhaps a bit special in the sense that it may have both a referentially opaque interpretation and a referentially transparent one (so, in a way, it has two meanings, and these can be separated by using two different IRIs). While there are certainly more examples of such types of relationships, I would think that for most types of relationships only one of the two interpretations makes sense.

Yes.

One question that your recent emails don't answer explicitly is: Are you proposing that we should have two kinds of embedded triples (one kind with a "semantic predication" interpretation and another one with a "syntactic predication" interpretation) and, then, have some syntactic way of distinguishing them? Or are you proposing that we should have only  the "semantic predication" interpretation (i.e., replacing the current "syntactic predication" interpretation)?

The current RDF-star definition of <<…>> looks good to me to represent "syntactic predications” .
As a first step, I’m proposing to classify the use cases in these three categories, and to characterise the behaviour for each of these categories - since they behave differently. And we have to be very clear in describing “best practises”.
As far as the representation and formal semantics is concerned, I vastly prefer a compositional approach, which is what RDF, RDFS, OWL, SPARQL have, namely the meaning of a syntactic constituent depends only on the components of the constituent itself. This support good practises while developing knowledge bases.
As a consequence, I strongly prefer to have three distinct representations, e.g., as <<…>>, <<<…>>>, and <<<<…>>>> for syntactic, semantic, and modal cases respectively.

cheers
—e.

Feb 15, 2023 15:54:52 Franconi Enrico <franconi@inf.unibz.it>:
Ooops, you are right. Just a typo among so many examples…
Let me rephrase.

EXAMPLE 2 (Is TEP a good solution?):

this example shows why it is better to have a syntactic way to characterise semantic embedded triples as opposed to use the TEP facility.

<<< :catalog-entry-1 dct:creator :alice >>> rdf:type :cataloging ;
                                            dct:created "2022-07-01"^^xsd:date .

<< :catalog-entry-1 dct:creator :mary >> rdf:type unstar:triple ;
                                         dct:created "2022-08-04"^^xsd:date .

vs the non-compositional solution with TEP:

<< :catalog-entry-1 dct:creator :alice >> rdf:type :cataloging ;
                                          :created1 "2022-07-01"^^xsd:date .

<< :catalog-entry-1 dct:creator :mary >> rdf:type unstar:triple ;
                                         :created2 "2022-08-04"^^xsd:date .

:created1 rdfs:subPropertyOf dct:created .
:created2 rdfs:subPropertyOf dct:created .
:created1 rdf:type rdf-star:TransparencyEnablingProperty .
:catalog-entry-1 dct:creator :alice .

(still not nice)

I believe that your solution below does not work, since the transparency stated for the embedded triple by :transparentType (cool trick!) does not apply when the same embedded triple is the subject of dct:created property, according to the compositional semantics of RDF. This is clear when you remove the semicolon to get a N-Triples syntax.
I still believe that the transparency of an embedded triple depends by its occurrence, not by its context; in this way, the semantics remains purely compositional and directly understandable.
cheers
—e.

On 15 Feb 2023, at 12:50, Timothée Haudebourg <timothee.haudebourg@spruceid.com> wrote:

Hi,

about your Example 2, I think the rdf-star:TransparencyEnablingProperty is supposed to be the type of the property applied on the quoted triple, not the type of the property inside the quoted triple. So the solution with TEP would be:

<< :catalog-entry-1 :creator :alice >> :transparentType :cataloging ;
                                       dct:created "2022-07-01"^^xsd:date .

<< :catalog-entry-1 :creator :mary >> rdf:type unstar:triple ;
                                      dct:created "2022-08-04"^^xsd:date .

:transparentType rdfs:subPropertyOf rdf:type .
:transparentType rdf:type rdf-star:TransparencyEnablingProperty .
:catalog-entry-1 :creator :alice .

Maybe we could provide a standard rdf:transparentType if this use case is so common? In which case the example would become:

<< :catalog-entry-1 :creator :alice >> rdf:transparentType :cataloging ;
                                       dct:created "2022-07-01"^^xsd:date .

<< :catalog-entry-1 :creator :mary >> rdf:type unstar:triple ;
                                      dct:created "2022-08-04"^^xsd:date .

:catalog-entry-1 :creator :alice .

It doesn't look so bad to me anymore.

Best,

--
Timothée