Hello Gregory,


On Mon, 2010-07-12 at 14:22 -0400, Gregory Williams wrote:
> I ran into some strange results from the DBPedia SPARQL endpoint and was 
> directed here. This query:
> 
> SELECT * WHERE { ?s a ?o }
> 
> when run against the default dataset[1] returns several results that only 
> have one variable binding (for ?o), instead of the expected two. In the 
> results I'm seeing, two erroneous results appear directly after one with ?s=< 
> http://nasa.dataincubator.org/spacecraft/1968-089A.json>. Both of these 
> erroneous results have ?o=foaf:Document. Is this a known problem? Might I 
> expect this problem to be fixed in the DBPedia endpoint anytime soon?

It looks like something had corrupted the database. The query
SELECT ?g ?s ?o (<LONG::bif:iri_id_num>(?g))
(<LONG::bif:iri_id_num>(?s)) (<LONG::bif:iri_id_num>(?o)) WHERE
{ graph ?g { ?s a ?o } }

shows that rows with empty ?g or ?s contains IRI IDs with reasonable
values but the database does not contain string IRI values that
correspond to that IDs. Maybe some application forcibly committed ill
data instead of rollback on some error handler in hope that partial data
about something is better than nothing --- don't know, we should check.


> I also just noticed that (again on the default dataset) the of this query
> 
> DESCRIBE <http://www.cs.umd.edu/~hendler/>
> 
> doesn't include the single RDF triple in which that URI appears as the 
> subject (rdf:type foaf:Document). Obviously this is more of an expectations 
> issue than an actual error, but it struck me as odd. Is this the expected 
> behavior of DESCRIBE in Virtuoso? Is the algorithm used for DESCRIBE 
> described anywhere?

There exist few implementations of DESCRIBE, define sql:describe-mode
let you specify the required non-default implementation in the beginning
of the query. Unfortunately, if graph is not specified, all built-in
implementations try to get appropriate graphs first, then search for
specific triples in these graphs, and the search for graphs is written
with speed as top priority and may entirely miss some graphs. I'll check
if I can change the search for graphs so it will better support this
particular case without losing the speed in worst case.

Best Regards,

Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com

> [1] 
> http://dbpedia.org/sparql?default-graph-uri=&query=select+*+where+%7B+%3Fs+a+%3Fo+%7D



Reply via email to