Re: DBpedia now available as triple pattern fragments

On 11/1/14 2:59 AM, Simon Heimler wrote:
> Great and interesting project!
>
> I've been using the dbpedia SPARQL endpoint for visualization purposes
> and my personal experience was that it broke on me 10-30% of the time,
> which is huge.

Huge? Maybe, but it isn't as simple as you present. Anyway, more of 
these issues will be explained in the report I am having prepared.

>   There was also that problem that when I was requesting
> JSON and an error happened, this came back as HTML, which is awful
> when working with a JSON API ;)

Are you saying, that right now, if you request a JSON-LD representation 
of an entity description from DBpedia you receive HTML? If that's true, 
then the cause is a re-write rule bug, in the content negotiation handler.

FWIW --  DBpedia (deployed using Virtuoso) was the very first project to 
publicly implement JSON-LD support [1]. It supported JSON-LD when it was 
little more than a public brainstormed idea. Please understand that many 
of these issues are not as simple and presented. There's a lot more 
history and underlying effort than is usually obvious.


[1] http://manu.sporny.org/2014/json-ld-origins-2/ -- see the last 
paragraph of that article .


Kingsley

>
> So I can absolutely understand where your project steps in and it
> makes a lot of sense to me.
>
> Regarding the slow query time: I've noticed that the results are
> "dropping" in. If you do clever visualization this might not hurt as
> much because you can already start drawing and the user sees some
> progress happening. (How much sense this makes depends on the result
> format of course)
>
> This might not remove from the actual time the process takes, but it
> might make it "feel" faster and more responsive - which is a thing
> that should not be underestimated.
>
> Regards,
> Simon
>
> 2014-10-31 17:15 GMT+01:00 Kingsley Idehen <kidehen@openlinksw.com>:
>> On 10/31/14 9:44 AM, Ruben Verborgh wrote:
>>>>> I also track the DBpedia public SPARQL endpoint; however this is more
>>>>> tricky.
>>>>>>> The Pingdom server only pings one URL, and I have sometimes get cached
>>>>>>> results,
>>>>>>> even at times when DBpedia was down.
>>
>> Because the is an ngnix proxy in front of the Linked Data resources. Again,
>> we handle the following, re: DBpedia:
>>
>> 1. SPARQL endpoint
>> 2. Linked Data Deployment -- that includes URL re-writes and content
>> negotiation etc..
>>
>>>>> That's weird... any idea why that happens?
>>> One of the layers of caching, I think.
>>> I.e., simple, previously asked queries still go through because they're
>>> cached,
>>> but any new query does not work anymore.
>>>
>>> Perhaps the SPARQLES guys have some insights into this?
>>> http://aidanhogan.com/docs/epmonitorISWC.pdf
>>
>> Back to why I said, we need to produce yet another report about DBpedia.
>>
>>
>> Links:
>>
>> [1] http://bit.ly/dbpedia-usage-analysis -- last report we publish, in
>> regards to DBpedia 3.8 (we have one in the works for 3.9, and will try to
>> make these a quarterly affair)
>>
>>
>> --
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog 1: http://kidehen.blogspot.com
>> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
>> Twitter Profile: https://twitter.com/kidehen
>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
>>
>>
>
>


-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this