Re: Semantic Predication: 4 - more worked out examples

Hi Enrico,

On Thu, 2023-02-16 at 16:06 +0000, Franconi Enrico wrote:
> > > 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.

I agree!

In this case, however, doesn't the fact that there are two meanings
justify the need for two separate IRIs, where each of them captures one
of these meanings?

Then, shouldn't the "<<< ... >>>" versus "<< ... >>" version of your
Example 2 also use two different IRIs rather than overloading
'dct:created' with both meanings?

Olaf


> —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,
> > > > >

Received on Thursday, 16 February 2023 16:53:58 UTC