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