- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 15 Apr 2010 16:59:56 -0400
- To: Dan Brickley <danbri@danbri.org>
- CC: Ian Davis <lists@iandavis.com>, public-lod <public-lod@w3.org>, dbpedia-discussion <dbpedia-discussion@lists.sourceforge.net>
Dan Brickley wrote: > On Thu, Apr 15, 2010 at 9:57 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote: > >> Ian Davis wrote: >> >> When you use the term: SPARQL Mirror (note: Leigh's comments yesterday re. >> not orienting towards this), you open up a different set of issues. I don't >> want to revisit SPARQL and SPARQL extensions debate etc.. Esp. as Virtuoso's >> SPARQL extensions are integral part of what makes the DBpedia SPARQL >> endpoint viable, amongst other things. >> > > Having the same dataset available via different implementations of > SPARQL can only be healthy. If certain extensions are necessary, this > will only highlight their importance. If there are public services > offering SPARQL-based access to the DBpedia datasets (or subsets) out > there on the Web, it would be rather useful if we could have them > linked from a single easy to find page, along with information about > any restrictions, quirks, subsetting, or value-adding features special > to that service. I suggest using a section in > http://en.wikipedia.org/wiki/DBpedia for this, unless someone cares to > handle that on dbpedia.org. > +1 > >> The burden issue is basically veering away from the key points, which are: >> >> 1. Use the DBpedia instance properly >> 2. When the instance enforces restrictions, understand that this is a >> Virtuoso *feature* not a bug or server shortcoming. >> > > Yes, the showcase implementation needs to be used properly if it is > going to survive the increasing attention developer LOD is getting. It > is perfectly reasonable of you to make clear when there are limits > they are for everyone's benefit. > Yep, and as promised we will publish a document, this is certainly a missing piece of the puzzle right now. > >> Beyond the dbpedia.org instance, there are other locations for: >> >> 1. Data Sets >> 2. SPARQL endpoints (like yours and a few others, where functionality >> mirroring isn't an expectation). >> > > Is there a list somewhere of related SPARQL endpoints? (also other > Wikipedia-derrived datasets in RDF) > > See: http://delicious.com/kidehen/sparql_endpoint, that's how I track SPARQL endpoints, at the current time. >> Descriptor Resource vhandling ia mirrors, BitTorrents, Reverse Proxies, >> Cache directives, and some 303 heuristics etc.. Are the real issues of >> interest. >> > > (am chatting with Daniel Koller in Skype now re the BitTorrent experiments...) > Yes, seeing progress. > >> Note: I can send wild SPARQL CONSTRUCTs, DESCRIBES, and HTTP GETs for >> Resource Descriptors to a zillion mirrors (maybe next year's April Fool's >> joke re. beauty of Linked Data crawling) and it will only make broaden the >> scope of my dysfunctional behavior. The behavior itself has to be handled >> (one or a zillion mirrors). >> > > Sure. But on balance, more mirrors rather than fewer should benefit > everyone, particularly if 'good behaviour' is documented and > enforced... > Yes, LinkedData DNS remains a personal aspiration of mine, but no matter what we build, enforcement needs to be understood as a *feature* rather than a bug or deficiency etc.. > >> Anyway, we will publish our guide for working with DBpedia very soon. I >> believe this will add immense clarity to this matter. >> > > Great! > > cheers, > > Dan > > -- Regards, Kingsley Idehen President & CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Received on Thursday, 15 April 2010 21:00:27 UTC