W3C home > Mailing lists > Public > public-lod@w3.org > June 2016

Re: Dealing with distributed nature of Linked Data and SPARQL

From: james anderson <james@dydra.com>
Date: Wed, 8 Jun 2016 15:46:34 +0000
Message-ID: <0102015530b19ec6-93165dab-499a-4b76-8f7a-df3e246c6a31-000000@eu-west-1.amazonses.com>
To: public-lod <public-lod@w3.org>
good afternoon;

> On 2016-06-08, at 17:17, David Booth <david@dbooth.org> wrote:
> On 06/08/2016 08:55 AM, Martynas Jusevičius wrote:
>> So I think it would be
>> wrong to ignore the "older" description -- or any "other" description
>> in general.
> This gets into the whole area of what data you choose to believe.  Some data is just plain wrong, and lots of data is "correct" (i.e. usable) for some uses but wrong for others and will cause inconsistency when merged.  Very little data is universally "correct".
> I think it is inescapable that when merging data from multiple sources you need to be careful about which data you choose to include.  Putting data from each source in its own named graph is one good way to help keep track of where it came from, and this is useful in deciding whether to include it.  But that provides only coarse-grained control.  You may well need to eliminate only a few triples from some source data in order to make it merge without causing inconsistencies, and it can be tedious to figure out which triples to drop.

all true, but if the goal is to leave room for the judgement call, assuming that dimension is free, to place each in its own graph gives one the latitude to make the judgement call, develop some systematic which depends on provenance, reflect the question to a manual choice, or just project FROM both and allow a naive merge.

which would see to make it the general best practice.
is there some case which argues against it?

> Bottom line: I don't think there is any simple answer to the question of which data to include.  It requires a judgement call.

best regards, from berlin,
james anderson | james@dydra.com | http://dydra.com
Received on Wednesday, 8 June 2016 15:47:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 June 2016 15:47:05 UTC