Re: Merging RDF graphs

thinking it up a little, it seems 'upper ontologies' should be dynamic
(semantic) by nature. please read the last paragraphs of this document:

https://github.com/CognescentBI/BISemantics/blob/master/Document.pdf?raw=true

 if we need 'upper ontologies' why not stay with relational databases and
views / queries, for example, without needing rigid schemas again. Even OOP
provides us yet the concept of alignment to a class hierarchy...

Best,
Sebastián Samaruga
---
http://exampledotorg.blogspot.com.ar


On Nov 16, 2017 3:57 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
>
>