- From: Thomas Lörtsch <tl@rat.io>
- Date: Thu, 9 Jan 2025 16:42:38 +0100
- To: Doerthe Arndt <doerthe.arndt@tu-dresden.de>
- Cc: "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
- Message-Id: <C6BF0428-73A0-439A-AE4E-E08661D2E8CD@rat.io>
Hi Dörthe, thank you for your [inadvertandly private] comments! > On 9. Jan 2025, at 15:29, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote: > > Dear Thomas, > >> >> >> >> On the other hand, I’m concerned but unsure what entailments rdf:reifies enables, so let me ask this by means of an example. Does, according to the current semantics, the following hold (and I really hope that it does and that my question only reveals my ignorance): >> >> :r rdf:reifies <<( :s :p :o )>> . >> :s owl:sameAs :s2 . >> >> entails >> >> :r rdf:reifies <<( :s :p :o )>> , >> <<( :s2 :p :o )>> . >> :s owl:sameAs :s2 . >> >> I really hope it does. > > > It does if we allow for equality and the reason is the transparency. Aha, so I take it that it’s still up for discussion. I hope it’s clear that I’m talking about the reification here, not about the abstract triple term, i.e. the reificatuion entails more triple terms, whereas the triple terms themselves do nothing. >> Of course it then also entails >> >> :r rdf:reifies <<( :s :p :o )>> , >> <<( :s2 :p :o )>> , >> <<( :p a rdf:Property )>> . >> :s owl:sameAs :s2 . >> >> I.e. according to this approach reifications are always fully transparent, but they don’t leak. In case of rdfs:states they do indeed "leak", but that is then intended (and therefore not leakage in its negative sense). > > No, it does not. Not sure where your „of course“ comes from From the assumption that if any entailments can be applied (like e.g. the owl:sameAs entailment) then necessarily also axiomatic triples are fair game. > but > > :p a rdf:Property. > > Is a totally different triple than > > :s :p :o > > And I see no reason to assume this derivation. Hm. Maybe I’m misunderstanding something about axiomatic triples? >> >> One important aspect is the question of how to refer to a proposition in its transparent meaning, like how to say that a certain theory is considered debunked. E.g.: >> >> <<( :Earth a :Disc )>> >> a :Theory ; >> :refutedBy :Galilei . >> >> Clearly the triple term here needs to be understood as being transparent. As with ordinary IRIs we can state that >> >> <<( :Earth a :Disc )>> owl:sameAs <<( :PlanetEarth rdf:type :RoundPlane )>> . >> >> and entail that >> >> <<( :PlanetEarth rdf:type :RoundPlane )>> >> a :Theory ; >> :refutedBy :Galilei . >> >> How much of this can be expressed in entailment patterns is another question. > > You would need to have patterns for equality in this case, but RDFS does not include that, therefore it is out of scope. Right. > (But I can think about your patterns if you want them) You probably don’t mean that you have a lot of free time rthat you’d happily spend on coming up with entailment patterns if I kindly ask you to :) But what do you mean? I’m still pondering the discussion from the last SemTF meeting before Christmas, but that’s a different enough topic to better not load it into this already hefty thread I guess. >> I know some do not like this and would rather like to have the triple term as opaque and literal-like as possible. > > Here, you confuse me. But most likely, I do not see the whole picture. You always wanted transparency and now it reads like you changed your mind? No, I didn’t change my mind, but I got older and milder and want us all to be happy ;-) So I’m trying to find a solution that does that. And since it is impossible to take back opacity I reckon that the most basic primitive has to be opaque - as Pierre-Antoine and you already argued in the CG. And RDF literals unexplicably haven’t gained much traction, so I kinda gave up on them (but I might change my mind about that again). >> Is this either-or? Would another property that creates a reference to the type, not to an occurrence, help? E.g: >> >> :o rdf:objectificationOf <<( :Earth a :Disc )>> , >> <<( :PlanetEarth rdf:type :RoundPlane )>>; >> a :Theory ; >> :refutedBy :Galilei . >> >> I’m not sure I like this, but maybe it’s worth a discussion. >> > > Not sure, I understand what you want. You could write and use constructs like that. But if you ask whether it would „help“ I need to better understand what you want. I was long convinced that occurrences are all we need, and best suited to prevent seminal mistakes. But William’s and your insistance made me aware that a) there are indeed use cases that sorta require triple terms as types (as representing them via occurrences, while possible is actually a rather bad hack) b) this is not just a question of "are triple terms allowed in subject position", because as my example tries to show also the type should be referentially transparent (at least in non-metamodelling cases). Best, Thomas > Kind regards, > Dörthe > > >> >> Thomas >> >> >> >>> On 8. Jan 2025, at 19:28, Thomas Lörtsch <tl@rat.io> wrote: >>> >>> Kinda looks like "unstar mapping in terms of entailment patterns" to me. So basically, to say anything about the constituents of a triple term it first has to be described with standard triples (much like standard reification has done it for decades w.r.t. rdf:Statements ;-) >>> >>> >>>> On 8. Jan 2025, at 18:26, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote: >>>> >>>> >>>> >>>>> Am 08.01.2025 um 18:14 schrieb Franconi Enrico <franconi@inf.unibz.it>: >>>>> >>>>> With this in mind: >>>>> >>>>> if the triple structure appears in S then S RDF(S) entails >>>>> reif0 sss aaa ooo sss rdf:type rdfs:Resource . >>>>> ooo rdf:type rdfs:Resource . >>>>> aaa rdf:type rdf:Property . >>>>> reif1 sss aaa <<(xxx yyy zzz)>> <<(xxx yyy zzz)>> rdf:type rdfs:Proposition . >>>>> reif2 <<(xxx yyy zzz)>> aaa ooo <<(xxx yyy zzz)>> rdf:type rdfs:Proposition . >>>>> reif3 sss rdf:reifies ooo ooo rdf:type rdfs:Proposition . >>>>> >>>>> On 8 Jan 2025, at 18:07, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote: >>>>> >>>>>> General: >>>>>> - Niklas made an interesting point: If you derive from >>>>>>> sss aaa <<(xxx yyy zzz)>> >>>>>> >>>>>> that >>>>>> xxx a rdfs:Resource. and zzz a rdfs:Resource. >>>>>> then we do not need the „if the triple structure appears in S“ for rdf:Resource and can stick to „if S contains“. >>>>> >>>>> What if this triple structure is deeply embedded? >>>> >>>> >>>> I propose an alternative (based on Niklas idea): >>>> >>>> >>>>> if S contains then S RDF(S) entails >>>>> reif0 sss aaa ooo sss rdf:type rdfs:Resource . >>>>> ooo rdf:type rdfs:Resource . >>>>> aaa rdf:type rdf:Property . >>>>> reif1 sss aaa <<(xxx yyy zzz)>> <<(xxx yyy zzz)>> rdf:type rdfs:Proposition . >>>>> xxx rdf:type rdfs:Resource. >>>>> zzz rdf:type rdfs:Resource. >>>>> yyy rdf:type rdf:Property. >>>>> reif2 <<(xxx yyy zzz)>> aaa ooo <<(xxx yyy zzz)>> rdf:type rdfs:Proposition . >>>>> xxx rdf:type rdfs:Resource. >>>>> zzz rdf:type rdfs:Resource. >>>>> yyy rdf:type rdf:Property. >>>>> reif3 sss rdf:reifies ooo ooo rdf:type rdfs:Proposition . >>>>> >>>> >>>> >>>> If I now have >>>> >>>> s p <<(a b <<(x y z)>>)>>. >>>> >>>> I get with reif1: >>>> >>>> <<(a b <<(x y z)>>)>> rdf:type rdfs:Resource. >>>> >>>> But from that, I get with reif2: >>>> >>>> <<(x y z)>> rdf:type rdfs:Resource. >>>> >>>> I can again apply reif2 and get: >>>> >>>> x a rdfs:Resource. >>>> z a rdfs:Resource. >>>> y a rdf:Property. >>>> >>>> Kind regards, >>>> Dörthe >>>> >>>>> >>>>> It seems I fixed your comment below with my latest proposal above. >>>>> Comments welcome! >>>>> —e. >>>>> >>>>>> Problem keeps being rdf entailment and the property. >>>>>> >>>>>> RDF: >>>>>> - I guess aaa in reif1 and reif2 should be yyy? >>>>>> >>>>>> RDFS: >>>>>> - we do not need >>>>>>> <<(xxx yyy zzz)>> rdf:type rdfs:Resource . >>>>>> in reif1 and reif 2 because we get that with the existing rules from RDFS. >>>>>> We do need >>>>>> xxx a rdfs:Resource. >>>>>> and >>>>>> yyy a rdfs:Resource. >>>>>> instead. >>>>>> >>>>>> >>>>>> Kind regards, >>>>>> Dörthe >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> On 8 Jan 2025, at 17:35, Franconi Enrico <franconi@inf.unibz.it> wrote: >>>>>>>> >>>>>>>> Option 1 (the current option) adds metamodelling inference only for asserted triples.: >>>>>>>> Option 1 (shallow metamodelling) >>>>>>>> >>>>>>>> ⏩ <[I+A](r), [I+A](rdf:Proposition)> ∈ IEXT([I+A](rdf:type)) >>>>>>>> if r is a triple term and ∃ x,y . (<x,[I+A](r)> ∈ IEXT(y)) ⋁ (<[I+A](r),x> ∈ IEXT(y)) >>>>>>>> or if ∃ x . <x,[I+A](r)> ∈ IEXT([I+A](rdf:reifies)) ⏪️ >>>>>>>> >>>>>>>> Note that this is just wrong since in this case we have >>>>>>>> [I+A](rdfs:Resource) ≠ IR >>>>>>>> [I+A](rdfs:Property) ≠ IP >>>>>>>> Option 2 (true metamodelling) >>>>>>>> >>>>>>>> ⏩ <r, [I+A](rdf:Proposition)> ∈ IEXT([I+A](rdf:type)) >>>>>>>> if r ∈ range(RE) or >>>>>>>> if ∃ x,y . RE(x,[I+A](rdf:reifies),r)=y ⏪️ >>>>>>>> ⏩ <r, [I+A](rdfs:Resource)> ∈ IEXT([I+A](rdf:type)) >>>>>>>> if r ∈ range(RE) or >>>>>>>> if ∃ x,y,z . RE(x,z,r)=y or >>>>>>>> if ∃ x,y,z . RE(r,z,x)=y ⏪️ >>>>>>>> ⏩ <r, [I+A](rdfs:Property)> ∈ IEXT([I+A](rdf:type)) >>>>>>>> if ∃ x,y,z . RE(x,r,z)=y ⏪️ >>>>>>>> >>>>>>>> >>>>>>>> Option 2 adds new metamodelling conditions, which implies that >>>>>>>> [I+A](rdfs:Resource) = IR >>>>>>>> [I+A](rdfs:Property) = IP >>>>>>>> as it should. >>>>>>>> The entailment pattern for option 2 will have "if the triple structure appears in S”. >>>>>>>> >>>>>>>> —e. >>>>>>>> >>>>>>>>> On 8 Jan 2025, at 17:17, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote: >>>>>>>>> >>>>>>>>> Dear Niklas, >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think that it should be derived. And I agree that the triple constituents are resources (due to transparency). >>>>>>>>>> >>>>>>>>>> I believe the following rule does that (given the existing RDF 1.1 entailment): >>>>>>>>>> >>>>>>>>>> If S contains: >>>>>>>>>> >>>>>>>>>> sss aaa <<(xxx yyy zzz)>> . >>>>>>>>>> >>>>>>>>>> or S contains (in symmetric RDF): >>>>>>>>>> >>>>>>>>>> <<(xxx yyy zzz)>> aaa ooo . >>>>>>>>>> >>>>>>>>>> then S RDF(1.2)-entails (in symmetric RDF): >>>>>>>>>> >>>>>>>>>> <<(xxx yyy zzz)>> rdf:type rdf:Proposition . >>>>>>>>>> <<(xxx yyy zzz)>> rdf:propositionSubject xxx . >>>>>>>>>> <<(xxx yyy zzz)>> rdf:propositionPredicate yyy . >>>>>>>>>> <<(xxx yyy zzz)>> rdf:propositionObject zzz . >>>>>>>>>> >>>>>>>>>> Then define: >>>>>>>>>> >>>>>>>>>> rdf:propositionPredicate rdfs:range rdf:Property . >>>>>>>>>> >>>>>>>>>> To make yyy a property. (Which I think makes sense, even though weird triple terms misusing e.g. classes as properties would have weird consequences.) >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> It is a little bit more complicated because of the nesting. We could have >>>>>>>>> >>>>>>>>> :a :b <<( :s :p <<( :x :y :z )>> )>>. >>>>>>>>> >>>>>>>>> we would want to derive that >>>>>>>>> >>>>>>>>> :y a rdf:Property. >>>>>>>>> >>>>>>>>> But that could still be done with a detailed version of Enrico’s "triple structure appears in“ notation. We could still get your triples. >>>>>>>>> >>>>>>>>> Another problem I see with your approach here is that we depend on RDFS while the properties are already derived in RDF and I assume that we want to keep it that way. >>>>>>>>> >>>>>>>>> Another question is whether or not we want the proposition subject, predicate and object, but they could serve the purpose. >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> Dörthe >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
Received on Thursday, 9 January 2025 15:42:48 UTC