- From: <bill.roberts@planet.nl>
- Date: Tue, 28 Jul 2009 14:20:16 +0200
- To: <public-lod@w3.org>
- Message-ID: <09584178D434304885A073316C800D0C15113F36@CPEXBE-EML13.kpnsp.local>
Hugh - I understand your point about different provenance and maintenance issues with linkage vs substantive knowledge, but if you dereference a URI, don't you want to also get the linkage information at that point? Of course you could do that while still keeping the two knowledge bases separate, as long as your system for dereferencing can combine info from both KBs - perhaps that's what you mean? Cheers Bill ________________________________ Van: public-lod-request@w3.org namens Hugh Glaser Verzonden: di 28-7-2009 12:01 Aan: Eric Lease Morgan; public-lod@w3.org Onderwerp: Re: owl:sameAs [recipe] For the record ( © Alan!). I consider it bad practice to keep the knowledge about linking in the same KB as the substantive knowledge you are representing. You need two KBs: one for the knowledge you are publishing, and one for the linkage you are working on. These have very different provenance, maintenance patterns, etc.. And you can include a link from URIs that you generate to the linkage KB. In fact, this would then help Alan's problem about sameAs:- he could simply decide not to get your view of the linkage, whereas with sameAs in the resources he has no choice but to accept your view, and even your predicate when he resolves a URI or queries the SPARQL. And I do agree with you about minting URIs to your local stuff, including authors; it is error-prone to try to re-use things like dbpedia for this, on any scale. And this is why you need to tackle the linkage problem as a separate engineering activity. Best Hugh (Of course I do have some software and architecture that supports separate linkage KBs (our CRS) so I would say this, but nevertheless I think it is the correct engineering approach, however it is done. Separation of Concerns.) On 28/07/2009 02:23, "Eric Lease Morgan" <eric_morgan@infomotions.com> wrote:
Received on Tuesday, 28 July 2009 12:21:17 UTC