Re: Decision from the Semantics TF: liberal baseline

On 08/01/2025 17:35, Franconi Enrico 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
>
I assume that what you really mean is

{ x | (x, [I+A](rdfs:Resource)) ∈ IEXT(rdf:type) } ≠ IR
{ x | (x, [I+A](rdf:Property)) ∈ IEXT(rdf:type) } ≠ IP

but even then, I'm very confused.

Granted, the semantic constraint /alone/ does not entail those equalities.
But they are entailed by /other/ semantic constraints that are /already/ 
part of RDF(S) semantics!
So I don't think that you need the additional semantic constraints that 
you propose below...

Entailment patterns, on the other hand, still need to take the recursion 
into account...

   pa

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