Re: "embedded predicate triples"

> On 1. Dec 2020, at 13:06, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu> wrote:
> 
> On 01/12/2020 12:24, thomas lörtsch wrote:
> 
>> On 1. Dec 2020, at 12:01, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
>>  wrote:
>> 
>>> James,
>>> 
>>> First, Singleton Properties (SP) use IRIs in the predicate position. They do not attempt to extend the RDF abstract syntax, and this is in fact one of their selling points (although, as pointed out by several authors, including Olaf [2], it has practical issues in many implementations).
>>> 
>>> Second, the very idea of SP is to have single-use predicates, and consider them as identifying the only triple in which they appear. By contrast, Jerven's suggestion would allow the same triple to be used in predicate position multiple times, but most importantly, to be used as the predicate of a triple whose subject and object are different from its own subject and object:
>>> 
>>>     :s2 << :s1 :p :o1 >> :o2.
>>>     :s3 << :s1 :p :o1 >> :o3.
>>> What on earth that would mean, I have absolutely no idea!
>>> 
>> It could mean something. People can get deeply related by events they commonly lived through:
>> 
>>     :Bob << :Alice :saved :Bob >> :Alice .
>> 
>> might describe such a relation.
>> 
> Granted, altough I would find
> 
>     :Bob :loves :Alice {| :because << :Alice :saved :Bob >> |}.
> 
> would look much clearer (and explicit) to me ;)

See, this is much more explicit, but unfortunately it's also different. Bob doesn't necessarily fall into the kind of romantic relationship with Alice that one commonly associates with the property :loves relating two persons. He might have very complex feelings of gratitude, relief, also affection - probably a whole bunch of emotions that are really best described by mentioning the evoking event itself.

Oh, I :love semantics :-)

>> In the tradition of RDF’s rather restrictive stance on which resource type to allow in which position of a triple it seems sensible to disallow embedded triples in predicate position.
> More precisely, in the tradition of RDF's syntax . RDF semantics is much more permissive, since ultimately, IRI, blank nodes and literals all denote resources...
> 
> And by the way, the current proposal for RDF* semantics does the same with embedded triples :)
> 
>> In some "generalized RDF*" it should be allowed. After all it’s easy to mint an IRI owl:sameAs an embedded triple and use that as a predicate. Predicates are expected to make sense, provide shared meaning etc, but requiring an IRI in predicate position doesn’t guarantee that either.
> I absolutely agree.
> 
> But I think we should focus on "regular" RDF* to start with.

Yes.

>> 
>>> On 30/11/2020 12:12, james anderson wrote:
>>> 
>>>> the 27.11 discussion included a question about whether to permit “embedded triples” in the predicate role and why.
>>>> 
>>>>     jerven: Question: why we don't have embedded triples in the property position?
>>>>     ... we need to put in down somewhere in the proposal
>>>>     Olaf: why would it be used for?
>>>>     Is that use case somewhere in the use case list?
>>>>     …
>>>>     <pfps_> Indeed, if the meaning of RDF* is defined as just a vocabulary extension to RDF, and embedded triples are IRIs, then embedded triples should be allowed in predicate position in surface syntaxes. However, it looks as if embedded triples have to be blank nodes in this definition of RDF*, so they can't be in predicate position.
>>>>     pchampin: We should stick for now with the restrictions
>>>>     james_: Embedded quad is actually in one of the use case. I react on the the point of using embedded triples in the predicate
>>>>     ... Describing a use case.
>>>>     <pfps_> I don't see how embedded triples as predicates advances similarity to property graphs. I would need an example of a property graph to see how this might work.
>>>>     Could james_ add that use case somewhere?
>>>>     <Olaf> I don't understand
>>>> 
>>>> this is not a new topic.
>>>> the mechanism was described at length by nguyen along with an extended use case in [1] and rejected for rdf* by hartig in [2].
>>>> ---
>>>> [1]
>>>> 
>>>> https://mor2.nlm.nih.gov/pubs/pdf/2014-www-vn.pdf
>>>> 
>>>> 
>>>> [2]
>>>> 
>>>> http://ceur-ws.org/Vol-1912/paper12.pdf
>>>> 
>>>> 
>>>> ---
>>>> james anderson |
>>>> 
>>>> james@dydra.com | http://dydra.com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>