Re: Semantic Predication: 4 - more worked out examples

Hi Enrico,

That's helpful! Some more responses inline below ...

On Fri, 2023-02-17 at 07:26 +0000, Franconi Enrico wrote:
> > On 16 Feb 2023, at 19:23, Olaf Hartig <olaf.hartig@liu.se> wrote:
> > 
> > Or, perhaps, we are misunderstanding one another. Let me try to ask
> > my question again: In the "<<< ... >>>" versus "<<
> > ... >>" version of your Example 2, the data looks as follows (for
> > clarity, I have removed the Turtle shorthand notion
> > with the semicolon and, instead, use a NTriples-like notation with
> > one triple per line).
> > 
> > <<< :catalog-entry-1 dct:creator :alice >>> rdf:type :cataloging .
> > <<< :catalog-entry-1 dct:creator :alice >>> dct:created "2022-07-
> > 01"^^xsd:date .
> > 
> > << :catalog-entry-1 dct:creator :mary >> rdf:type unstar:triple .
> > << :catalog-entry-1 dct:creator :mary >> dct:created "2022-08-
> > 04"^^xsd:date .
> > 
> > Now, if I understand your previous emails right, you say that the
> > meaning of the dct:created property in the second of
> > these triples is that it is "a property stating the created date of
> > the creating event induced by the embedded triple"
> > whereas the meaning of dct:created in the fourth triple is that it
> > is "a property stating the created date of the triple
> > denoted by the embedded triple itself." So, the same IRI,
> > dct:created, has two different meanings in this example. Do
> > you agree?
> 
> The unique meaning of dct:created has been specified by the Dublin
> Core community:
> 
>  Vocabulary:  DCMI Metadata Terms
>  URI  http://purl.org/dc/terms/created

>  Label  Date Created
>  Definition  Date of creation of the resource.
>  Comment  Recommended practice is to describe the date,
> date/time, or period of time as recommended for the property Date, of
> which this is a subproperty.
>  Type of Term  Property
>  Has Range  http://www.w3.org/2000/01/rdf-schema#Literal

>  Subproperty of 
>  Date (http://purl.org/dc/elements/1.1/date)
>  Date (http://purl.org/dc/terms/date)
> 
> This property can be used in different contexts, exactly like in the
> example above, where the date of creation of the resource refers to a
> resource being a cataloging event or a triple.

Okay, so the issue is that the definition of dct:created is not
sufficiently detailed regarding the distinction in our discussion.

My intuition then would be that, if someone wants to use this property
with a more specific meaning, namely with a 'semantic predication'
interpretation, then they can, and should, make this fact explicit by
using a sub-property of dct:created that is defined to be a TEP (i.e.,
essentially what you have done in the TEP version of your Example 2).

I also understand, however, that using such a TEP sub-property of
dct:created would not be necessary (but still good practice perhaps?)
if there were two different forms of embedded triples, one that
indicates the intention to use syntactic predication and another one to
indicate semantic predication instead. And your point is that this is a
better idea.

> What I am suggesting is that you have to look at the predication (in
> this case dct:created) in the context, and understand which is the
> context it is applied to, and make such context unambiguous — in this
> case specifying explicitly which meaning the embedded triple has.
> 
> [...]
> 
> But even if we have two distinct IRIs for the two possible uses of
> dct:created in this example (as, e.g., :event-created and :triple-
> created), this does not avoid the necessity to disambiguate the
> context, by making explicit the use of <<<...>>> or <<...>>. Indeed,
> if you assume that the use of :event-created is enough to
> disambiguate the meaning of the embedded triple, then you get the
> same counterexample to Timothée's trick:
> 
> << :catalog-entry-1 dct:creator :alice >> rdf:type :cataloging .
> << :catalog-entry-1 dct:creator :alice >> :event-created "2022-07-
> 01"^^xsd:date .

I think what you want to get to here is a bit different than the
counterexample to Timothée's trick.

With his trick, he wanted to get a transparency-enabling interpretation
of dct:created by making a separate statement about the embedded
triple, assuming that this would make the embedded triple transparent
also in the triple with dct:created (which it doesn't). 

When using :event-created, assuming it is defined to be a TEP, the
trick is not needed and one gets the desired outcome that the embedded
triple is transparent in the triple with :event-created. Desired
outcome here means that

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

entails

<<:catalog-entry-1 dct:creator :alicia>>
                                 :event-created "2022-07-01"^^xsd:date.

when considering the OWL semantics of owl:sameAs. It would, however,
not entail

<<:catalog-entry-1 dct:creator :alicia>>
                                 rdf:type :cataloging.

Whether additionally entailing the latter is desirable or not depends
on the use case I would say. And I understand now that your proposal is
to enable users to make this intention explicit by giving them two
different forms of embedded triples (or even a third form for the modal
/epistemic predication).

Cheers,
Olaf

Received on Friday, 17 February 2023 08:55:07 UTC