Re: Semantic Predication: 4 - more worked out examples

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.

Let me emphasise this: YES!
This shows that the important bit to look at, in order to understand which meaning an embedded triple has, is the predication.
In the dct:created case, the meanings are more precisely: (1) a property stating the created date of the creating event induced by the embedded triple; (2) a property stating the created date of the triple denoted by the embedded triple itself.
—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