Re: Merging RDF graphs

Hi Pat, 

Thanks for pointing this out to me. I wasnt't aware. If I understand the spec correctly, graph merging in the presence of blank nodes in those graphs is quite the opposite if what we want to achieve. When I chose a term for this operation, I thought about 'unifying', but 'blending' seems better because it has much less baggage. 

Best, Florian

Am 18. November 2017 10:15:56 MEZ schrieb Pat Hayes <phayes@ihmc.us>:
>Florian, a quick note. The operation you are describing, involving
>identifying two previously distinct URI nodes by replacing two URIs by
>one new one, is interesting, but please could you not use the term
>‘merging RDF graphs’ to describe it, as this terminology is already in
>use in the RDF community and indeed in the RDF specification documents
>themselves, to refer to a different operation on RDF graphs (viz, one
>in which *blank nodes* in the two graphs are identified). 
>
>Using this already widely used terminology to mean something different
>will only cause confusion. If I may suggest an alternative, you might
>refer to your operation as ‘blending’ or ‘unifying’ or even ‘node
>merging’; but please not ‘graph merging’.
>
>Thanks
>
>Pat Hayes
>
>
>> On Nov 16, 2017, at 12:37 PM, Florian Kleedorfer
><florian.kleedorfer@austria.fm> wrote:
>> 
>> Hi,
>> 
>> As you may recall, I've asked this list about messaging/negotiating
>using linked data[1], and it led me and my colleagues to a concept of
>RDF-based agreements[2]. (Thanks again for your input!)
>> 
>> Now it's time for us to define how the negotiating parties come up
>with the data (set of rdf triples) that they agree on.
>> 
>> One Idea we have is that both particpants (P1,P2) specify 'goals',
>each consisting of a SHACL shapes graph and a data graph. Two goals can
>be tested for compatibility by merging the two data graphs and then
>testing if the resulting graph is valid given the shapes defined by
>both goals. The problem we face with this approach is merging the two
>data graphs. Consider the example in this gist:
>> 
>> https://gist.github.com/fkleedorfer/81b32e3235105a4a4743e9fa76ba9332
>> 
>> In that example, we would want to merge these two graphs:
>> 
>> ex1:p1g-data {
>>    ex1:ride1 a taxi:Ride .
>>    ex1:ride1 taxi:hasDriver ex1:p1 .
>>    ex1:ride1 taxi:hasPickupLocation ex1:pickup1;
>> }
>> 
>> and
>> 
>> ex2:p2g-data {
>>    ex2:myRide a taxi:Ride.
>>    ex2:myRide taxi:hasClient ex2:p2 .
>>    ex2:myRide taxi:hasPickupLocation ex2:myPickupLocation .
>>    ex2:myPickupLocation a s:GeoCoordinates ;
>>        s:latitude   "48.213814" ;
>>        s:longitude  "16.340870" .
>> }
>> 
>> We want that merge to happen in such a way that the shapes in
>ex1:p1g-shapes and ex2:p2g-shapes can be evaluated, which will require
>to merge some of the nodes. (In the example, we'll find out that a
>taxi:hasPickupTime property is missing. One of the participants is then
>to add that property, and the whole structure becomes valid according
>to both goals' shapes.)
>> 
>> The question is how exactly to achieve that merge. Intuitively, the
>result in this case should be
>> 
>>   :mergedNode1 a taxi:Ride .
>>   :mergedNode1 taxi:hasDriver ex1:p1 . # note: p1 links her own
>identifier to the structure
>>   :mergedNode1 taxi:hasPickupLocation :mergedNode2;
>>   :mergedNode1 a taxi:Ride.
>>   :mergedNode1 taxi:hasClient ex2:p2 .
>>   :mergedNode1 taxi:hasPickupLocation :mergedNode2 .
>>   :mergedNode2 a s:GeoCoordinates ;
>>        s:latitude   "48.213814" ;
>>        s:longitude  "16.340870" .
>> 
>> and after removal of duplicate triples
>> 
>>   :mergedNode1 a taxi:Ride .
>>   :mergedNode1 taxi:hasDriver ex1:p1 .
>>   :mergedNode1 taxi:hasClient ex2:p2 .
>>   :mergedNode1 taxi:hasPickupLocation :mergedNode2 .
>>   :mergedNode2 a s:GeoCoordinates ;
>>        s:latitude   "48.213814" ;
>>        s:longitude  "16.340870" .
>> 
>> (I currently don't care about the URIs of the mergedNodes - just
>something one can mint when doing the merge)
>> 
>> 
>> Do you have any hints on how to perform such a merge reliably, also
>with more complex structures?
>> 
>> Thank you very much in advance!
>> 
>> Best regards,
>> Florian
>> 
>> 
>> Links:
>> 1. Negotiations discussion thread:
>https://lists.w3.org/Archives/Public/semantic-web/2017Jul/0004.html
>> 2. Agreements paper: http://ceur-ws.org/Vol-1934/contribution-07.pdf
>> 
>> 
>>