- From: Hugh Glaser <hg@ecs.soton.ac.uk>
- Date: Tue, 28 Jul 2009 20:49:35 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>
- CC: Eric Lease Morgan <eric_morgan@infomotions.com>, "public-lod@w3.org" <public-lod@w3.org>
On 28/07/2009 14:46, "Kingsley Idehen" <kidehen@openlinksw.com> wrote: > Hugh Glaser wrote: >> Good stuff. >> However, I don't think that Named Graphs are the answer. >> I get my Linked Data by resolving URIs over http. >> If I ask your Linked Data Space (I hope that is the right use of your >> terminology) for something like >> curl -H "Accept: application/rdf+xml" http://dbpedia.org/resource/London >> and follow the redirect don't I still get the non-wikipedia data with the >> wikipedia data? >> Or am I not understanding something? >> > The link chain shouldn't be broken. Named Graphs should have zero impact > on HTTP URIs. That is what I thought. So how is the linkage data kept separate when I do URI resolution? Cheers > > I think Alan is saying: put what is best described as a linkbase dump in > a separate Named Graph. Doing this shouldn't break the tapestry inherent > in the HTTP URIs (the data conductors). We have tons of data in > <http://lod.openlinksw.com> partitioned across named graphs, and none of > that breaks the "follow-your-nose" pattern. Remember, I am a stickler > for keeping the HTTP URIs of entities in full scope of user agents :-) > > The only time you might have an issue is when performing SPARQL, where > explicitly identifying the Named Graph in the FROM Clause may aid > performance (and even here this depends on the indexing in placece re, > the RDF DBMS insta, these days re. Virtuoso that doesn't even matter > since the default indexing scheme has been changed). > > Kingsley >> Best >> Hugh >> >> >> On 28/07/2009 11:17, "Kingsley Idehen" <kidehen@openlinksw.com> wrote: >> >> Hugh Glaser wrote: >> >>> 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. >>> >>> >> For terminology consolidation purposes, what you call a KB is a >> "Linked Data Space" in my parlance :-) >> >> Yes, the partitioning suggested above is very important. Thus, you need >> purpose specific Linked Data Spaces (hosing many Named Graphs) if you >> seek to make things a little clearer to data consumers and their agents. >> >>> 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.) >>> >>> >> >> Note, we've partitioned DBpedia in such a way that you now have a Graph >> IRI for each data set within this particular Linked Data Space. >> >> Kingsley >> >>> On 28/07/2009 02:23, "Eric Lease Morgan" <eric_morgan@infomotions.com> >>> wrote: >>> >>> >>> >>> On Jul 25, 2009, at 5:09 AM, Bill Roberts wrote: >>> >>> >>> >>>> Regarding linking to external resources, what it seems you want >>>> to do is to identify the dc:creator of the book, hence say that >>>> the creator is the person whose name was Thomas More. You could >>>> create your own URI and if you are managing a whole bunch of data >>>> about books and authors, then there could be reasons to do that, >>>> but in general if there is a satisfactory existing URI, it is >>>> preferable to use it. Dbpedia seems to have become the de facto >>>> standard... >>>> >>>> >>> Okay, then how's this for a recipe to create rich linked data of >>> electronic books and authors within my own site as well as to the >>> outside world: >>> >>> 1. Mint URIs pointing to representations of local etexts >>> 2. Mint URIs pointing to representations of authors of local etexts >>> >>> 3. In resources of etexts, include owl:sameAs links to DBpedia >>> resources >>> 4. In resources of etexts, point to local URIs of authors >>> >>> 5. In resources of authors, include owl:sameAs links to DBpedia >>> resources >>> 6. In resources of authors, include owl:creatorOf links to local >>> etexts >>> >>> 7. For extra credit, do the same thing for subjects/keywords >>> >>> For example, the following resource descriptions: >>> >>> <!-- etext #1; points to local author and remote title --> >>> <rdf:RDF >>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >>> xmlns:dcterms="http://purl.org/dc/terms/" >>> xmlns:owl="http://www.w3.org/2002/07/owl#"> >>> <rdf:Description >>> rdf:about="http://infomotions.com/etexts/id/more-utopia-221" >>> owl:sameAs="http://dbpedia.org/resource/Utopia_(book)"> >>> <dcterms:title>Utopia</dcterms:title> >>> <dcterms:creator >>> rdf:resource="http://infomotions.com/etexts/authors/resource/thomas-more >>> " /> >>> </rdf:Description> >>> </rdf:RDF> >>> >>> >>> <!-- etext #2; points to local author and remote title --> >>> <rdf:RDF >>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >>> xmlns:dcterms="http://purl.org/dc/terms/" >>> xmlns:owl="http://www.w3.org/2002/07/owl#"> >>> <rdf:Description >>> rdf:about="http://infomotions.com/etexts/id/more-reality-404" >>> owl:sameAs="http://dbpedia.org/resource/Reality_(book)"> >>> <dcterms:title>Reality</dcterms:title> >>> <dcterms:creator >>> rdf:resource="http://infomotions.com/etexts/authors/resource/thomas-more >>> " /> >>> </rdf:Description> >>> </rdf:RDF> >>> >>> >>> <!-- author; points to local etexts and remote author --> >>> <rdf:RDF >>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >>> xmlns:owl="http://www.w3.org/2002/07/owl#"> >>> <rdf:Description >>> rdf:about="http://infomotions.com/etexts/authors/resource/thomas-more >>> " >>> owl:sameAs="http://dbpedia.org/resource/Thomas_More"> >>> <owl:creatorOf >>> rdf:resource="http://infomotions.com/etexts/id/more-utopia-221 >>> "/> >>> <owl:creatorOf >>> rdf:resource="http://infomotions.com/etexts/id/more-reality-404 >>> " /> >>> </rdf:Description> >>> </rdf:RDF> >>> >>> -- >>> Eric Lease Morgan >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> -- >> >> >> Regards, >> >> Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen >> President & CEO >> OpenLink Software Web: http://www.openlinksw.com >> >> >> >> >> >> >> > > > -- > > > Regards, > > Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen > President & CEO > OpenLink Software Web: http://www.openlinksw.com > > > > >
Received on Tuesday, 28 July 2009 19:50:30 UTC