Re: Event Updated: RDF-star WG biweekly meeting

Dear Enrico,

Am 28.08.2024 um 18:18 schrieb Franconi Enrico <franconi@inf.unibz.it>:

On 28 Aug 2024, at 16:38, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote:

https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22alternative-baseline%22#rdf-semantics


This is a minor point, but I would like to have the semantics here more in line with rdf:Property (https://www.w3.org/TR/rdf11-mt/#rdf-interpretations). We can change one of the two definition, but coming from RDF as it is, I would not want to make it depend on a syntactic representation of a resource that the predicate used with it is a reification property. So, <<(:s :p :o)>> and :n could be mapped by [I+A] to the exact same resource, and thus the triples

:s1 :p1 <<(:s :p :o)>>.

and

:s1 :p1 :h.

Would have the same meaning, but only the first would entail that :p1 is a reification property.

In pure RDF you can state nor derive that <<(:s :p :o)>> and :h are mapped to the exact same resource, namely that <<(:s :p :o)>> and :h are mapped to the exact same resource in every model.

Or to make it more crisp by adding owl:sameAs:

:s1 :p1 :h.
:h owl:sameAs <<(:s :p :o)>>.

would not entail (or not directly entail, only by going back to syntax)

:p1 a rdf:reificationProperty.

I see your point.

We could easily fix that by introducing a set IT as the range of RE. Then we would get the same kind of condition we get for properties in RDF semantics where the set IP is used and the construct would still work. So, I still like the idea.

I am not sure I like your fix :-)

I totally understand why. I so far also disliked the set IP in RDF semantics and now (because of you) finally understood why we need it in the first place.

Do you like mine?

[I+A](t) = TRUE   implies
          <[I+A](t.s), [I+A](rdf:tripleTerm)> ∈ IEXT([I+A](rdf:type))
          if t.s is a triple term

[I+A](t) = TRUE   implies
          <[I+A](t.o), [I+A](rdf:tripleTerm)> ∈ IEXT([I+A](rdf:type))
          if t.o is a triple term

[I+A](t) = TRUE   implies
          <[I+A](t.p), [I+A](rdf:reificationProperty)> ∈ IEXT([I+A](rdf:type))
          if <[I+A](t.o), [I+A](rdf:tripleTerm)> ∈ IEXT([I+A](rdf:type))

I think that could work.

https://github.com/w3c/rdf-star-wg/wiki/Extending-the-baseline-with-%22asserted%22-stuff

I see two problems with

[I+A](t) = TRUE   iff   <[I+A](t.s), [I+A](t.o)> ∈ IEXT([I+A](t.p)) and
                        [I+A](t.o) = TRUE    if   t.p = rdfs:states  and t.o is a triple term

1. It is ambiguous because the first [I+A](t.o) refers to the interpretation of t.o as a term and the second [I+A](t.o) refers to the triple t.o.

Correct. That’s the fix (already implemented):


[I+A](t) = TRUE   iff   <[I+A](t.s), [I+A](t.o)> ∈ IEXT([I+A](t.p))  and
                        ([I+A](tt) = TRUE  if  (t.p = rdfs:states  and
                                                t.o is a triple term  and
                                                tt is the triple corresponding to the triple term t.o))


Better, I wonder whether we need to make a better overall notation to distinguish between triple terms and triples because in my opinion this problem keeps popping up.

Interesting at that point is that we again loose the representation level when we go into the semantics.  What if we again add equality and consider the triples

:s rdf:states :o.

:o owl:sameAs <<(:a :b :c)>>.

We cannot easily derive

:a :b :c.

because our semantics does not really know how <<(:a :b :c)>> relates to RE(:a :b :c) which is just a domain element. Maybe the fact that RE is injective could help here?


This kind of problem was in the beginning the reason why I opted for referential opacity. I wanted the representation of the triple be part of the semantics. But I see some inverse of RE as a possible solution.

2. The iff is problematic, because it excludes all other kinds of triples. I would expect that a triple can also be true if it has a dedicate other than rdf:states

I guess that if I put explicitly the parentheses (which were implicit via indentation), then you would agree with me: see above.
Wouldn’t you agree? (I already put explicit parentheses).

I indeed read the whole statement wrongly.



Having said that, I also think that the intended behavior as indicated in the examples was exactly what Thomas proposed.

:-)

cheers
—e.

Kind regards,
Dörthe