Re: Decision from the Semantics TF: liberal baseline

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