Re: Event Updated: RDF-star WG biweekly meeting

Enrico,

I trust you (and Dörthe ;-) to provide the right formalization for rdfs:states/asserts. If you need my vote on that, you've got it, but frankly: this is well outside my area of expertise, so my vote isn't worth much. I'm glad that Dörthe caught some errors, and from what I understand from your discussion you both understand very well what I aim for (and it would really make me wonder if you didn't because to me it seems like a very straightforward aim). 

However, it isn't yet clear at all if we want that property, and for what, if we even need it, if the annotation syntax should use it, if it should instead be a class (Andy's proposal of ":r rdf:reifies <<(:s :p :o) >>; a rdf:Stated"), if instead we aim for E/R style modelling, if rdf:reifies is fine or ambiguous or shouldn't be used at all, etc. That is the still unfinished discussion I was referring to.

Best,
Thomas


Am 28. August 2024 18:18:20 MESZ 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 :-)
>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))
>
>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))
>
>
>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).
>
>Having said that, I also think that the intended behavior as indicated in the examples was exactly what Thomas proposed.
>
>:-)
>
>cheers
>—e.