- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 12 Aug 2009 16:10:45 -0400
- To: Hugh Glaser <hg@ecs.soton.ac.uk>
- CC: Peter Ansell <ansell.peter@gmail.com>, "public-lod@w3.org" <public-lod@w3.org>, "dbpedia-discussion@lists.sourceforge.net" <dbpedia-discussion@lists.sourceforge.net>
Hugh Glaser wrote: > Hi Kingsley. > > On 12/08/2009 20:07, "Kingsley Idehen" <kidehen@openlinksw.com> wrote: > > >> Peter Ansell wrote: >> >>> 2009/8/12 Hugh Glaser <hg@ecs.soton.ac.uk>: >>> >>> >>>> Are you saying that the only way to access Linked Data is via SPARQL? >>>> >>>> >>> That is going a bit far, but in the end if you want to allow people to >>> extend the model it has to be done using SPARQL. If the extension is >>> taken well by users then it could be included in what is resolved for >>> the URI but that doesn't mean it is not Linked Data up until the point >>> it is included. >>> >>> I for one loved the recent addition of the Page Links set in a >>> separate Named Graph, and I don't see how this is different. >>> >>> Cheers, >>> >>> Peter >>> >>> >>> >>> >> Amen! :-) >> >> Hugh: the important point is this: the person that deems a piece of data >> to be fit for sharing on the Web can mint a HTTP URIs for said data, >> even it this happens from afar e.g. via Pubby or Virtuoso's Linked Data >> Deployment services against remote SPARQL endpoints. Of course, the same >> thing can happen via RDFizers that produce proxy/wrapper URIs from a >> variety of data sources. None of this breaks the principles behind the >> Linked Data meme :-) >> > I agree with all that - it is a description of what I have been saying. > We clearly have a strong agreement here. > > On the other hand: > Thus SPARQL is not a required part of the Linked Data meme. Also if Named > Graphs are not visible without using SPARQL, Named Graphs are not a good > solution to problems in the Linked Data meme. > Of course they are. You have to partition data for a myriad of reasons. You just can put it all in one real or virtual bucket. You must partition or you are on a high speed boat to data maintenance hell, and that's just one of the problems. > This will become a more significant issue with the forthcoming explosion of > Linked Data from governments such as the UK, where the data provider will > not be offering a SPARQL endpoint. > Nice example, assuming you are implying that each of the data items will have HTTP URIs but no SPARQL endpoints. If so, what stops me making a set of statements about the published data in my own Web accessible Linked Data Space (which is partitioned using Named Graphs) using my own HTTP URIs ? You can simply like of dislike the data exposed by my URIs, that's it re. the broader Web. btw - in my world view, SPARQL is an implementation detail re. Linked Data meme. I've even been tapped (by Juan Sequeda) saying that :-) > Telling them to put their co-ref data in a Named Graph is just not an > option. > In their particular case, here is the very important point to note. They are the original data publishers. Thus, I am not expecting them to move any "owl:sameAs" or "owl:equivalentClass" style assertions into a separate graph per se. What I am saying is this: If you, I, or anyone else decides to construct a set of co-reference style statements about the UK data, best we do it in our own Linked Data spaces. Now zipping back to the DBpedia example: We have multiple parties contributing Linked Data to the project, many are outside the original trinity of: ASKW, Freie, and OpenLink. Thus, in situations like this it's preferable to put the contributed datasets in their own Named Graphs albeit within a single Virtuoso instance. It also means that even if the contributed datasets are pseudo hot-staged in their own Named Graphs, anyone can use still tools like Pubby or Virtuoso's Linked Data Deployment services to mint HTTP URIs in their own Linked Data Spaces via the DBpedia SPARQL endpoint. I note that the UK example reveals where we have crossing wires a little :-) > Best > Hugh > > > -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President & CEO OpenLink Software Web: http://www.openlinksw.com
Received on Wednesday, 12 August 2009 20:11:22 UTC