Re: Merging RDF graphs

Hi, 

You may be right about the overlap between our goals. See https://github.com/researchstudio-sat/webofneeds for more context regarding our work.


Best, Florian

Am 17. November 2017 23:13:30 MEZ schrieb Sebastian Samaruga <ssamarug@gmail.com>:
>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
>>
>>