Re: Merging RDF graphs

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

Received on Saturday, 18 November 2017 09:16:30 UTC