Peter Coetzee wrote:
>
>
> On Mon, Apr 19, 2010 at 3:20 PM, Kingsley Idehen 
> <[email protected] <mailto:[email protected]>> wrote:
>
>     Tom Morris wrote:
>     > On Fri, Apr 16, 2010 at 9:23 PM, Kingsley Idehen
>     <[email protected] <mailto:[email protected]>> wrote:
>     >
>     >> Dan Brickley wrote:
>     >>
>     >>> On Fri, Apr 16, 2010 at 11:43 PM, Kingsley Idehen
>     >>> <[email protected] <mailto:[email protected]>> wrote:
>     >>>
>     >>>
>     >>>> Tom Morris wrote:
>     >>>>
>     >>>>
>     >>>>> This example query from the DBpedia page returns a list of
>     companies
>     >>>>> which all have exactly 151,000 employees:
>     >>>>>
>     >>>>>
>     >>>>>
>     
> http://dbpedia.org/snorql/?query=SELECT+%3Fsubject+%3Femployees+%3Fhomepage+WHERE+{%0D%0A%3Fsubject+rdf:type+%3Chttp://dbpedia.org/class/yago/Company108058098%3E.%0D%0A%3Fsubject+dbpedia2:numEmployees+%3Femployees%0D%0AFILTER+(xsd:integer(%3Femployees)+%3E%3D+50000).%0D%0A%3Fsubject+foaf:homepage+%3Fhomepage.%0D%0A}+ORDER+BY+DESC(xsd:integer(%3Femployees))%0D%0ALIMIT+20%0D%0A
>     
> <http://dbpedia.org/snorql/?query=SELECT+%3Fsubject+%3Femployees+%3Fhomepage+WHERE+%7B%0D%0A%3Fsubject+rdf:type+%3Chttp://dbpedia.org/class/yago/Company108058098%3E.%0D%0A%3Fsubject+dbpedia2:numEmployees+%3Femployees%0D%0AFILTER+%28xsd:integer%28%3Femployees%29+%3E%3D+50000%29.%0D%0A%3Fsubject+foaf:homepage+%3Fhomepage.%0D%0A%7D+ORDER+BY+DESC%28xsd:integer%28%3Femployees%29%29%0D%0ALIMIT+20%0D%0A>
>     >>>>>
>     >>>>> That seems a rather improbable result.  I'm not a real
>     SPARQL guru,
>     >>>>> but I don't see anything obviously wrong with the query.  Is
>     the query
>     >>>>> incorrect or is the issue with the database or the server?
>     >>>>>
>     >>>>> Tom
>     >>>>>
>     >>>> To save time (i.e. decoding the URL), could you please do the
>     following:
>     >>>>
>     >>>>
>     >
>     >
>     >>>
>     >> Problem:
>     >>
>     >> The Home Page URLs aren't uniform.
>     >>
>     >> I added DISTINCT and removed ?homepage.
>     >>
>     >> So not a bug :-)
>     >>
>     >> Try
>     >>
>     >> PREFIX owl: <http://www.w3.org/2002/07/owl#>
>     >> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
>     >> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
>     >> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>     >> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>     >> PREFIX dc: <http://purl.org/dc/elements/1.1/>
>     >> PREFIX : <http://dbpedia.org/resource/>
>     >> PREFIX dbpedia2: <http://dbpedia.org/property/>
>     >> PREFIX dbpedia: <http://dbpedia.org/>
>     >> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
>     >>
>     >> SELECT distinct  ?subject ?employees WHERE {
>     >> ?subject rdf:type <http://dbpedia.org/class/yago/Company108058098>.
>     >> ?subject dbpedia2:numEmployees ?employees
>     >> FILTER (xsd:integer(?employees) >= 50000).
>     >> ?subject foaf:homepage ?homepage.
>     >> } ORDER BY DESC(xsd:integer(?employees))
>     >> LIMIT 20
>     >>
>     >> Links:
>     >>
>     >> 1. http://bit.ly/byXSGf -- SPARQL Protocol URL
>     >>
>     >
>     > Thanks!  That did the trick.  It looks like the DISTINCT keyword was
>     > the main issue since it also seems to work with the homepages
>     included
>     > as long as the DISTINCT keyword is there.
>     >
>     > Hopefully one of the DBpedians will see this and update the
>     example at
>     > http://wiki.dbpedia.org/Datasets#h18-12.  (The other two example
>     > queries in that section seem to work as expected).
>     >
>     > Tom
>     >
>     >
>     Ted,
>
>     Please update the Wiki page accordingly.
>
>
>     --
>
>     Regards,
>
>     Kingsley Idehen
>     President & CEO
>     OpenLink Software
>     Web: http://www.openlinksw.com
>     Weblog: http://www.openlinksw.com/blog/~kidehen
>     Twitter/Identi.ca
>     <http://www.openlinksw.com/blog/%7Ekidehen%0ATwitter/Identi.ca>:
>     kidehen
>
>  
> Forgive an innocent bystander a little confusion, but I'm not sure I 
> understand what's going on with this query. I've taken out the 
> foaf:homepage term, as you suggested (though I'm not sure what you 
> meant by "aren't uniform"), and have fiddled with the rest of the 
> query; it seems like there's an odd interaction between ORDER BY 
> (xsd:integer(...)) and FILTER(xsd:integer(...)).
>
> For example, the query
>
> SELECT ?subject ?employees WHERE {
>   ?subject rdf:type <http://dbpedia.org/class/yago/Company108058098>;
>            dbpedia2:numEmployees ?employees.
>   FILTER (xsd:integer(?employees) >= 50000).
> } ORDER BY DESC(xsd:integer(?employees))
> LIMIT 20
>
> returns a set of results, all with the same number of employees. If I 
> change that LIMIT to (say) 30, it changes the number of employees for 
> *all* the result bindings - and they're all still the same value as 
> each other.

Yes, your observations are accurate, bottom line, there is a bug in the 
Cluster Edition variant of the SPARQL Engine (which is what DBpedia is 
now running of etc..).

So DISTINCT is both accurate, but also masking a little bug :-(


Kingsley
>
> If you discard one of either the FILTER or the ORDER BY, the results 
> seem normal. If you change it to SELECT DISTINCT, the results seem 
> normal. However, the problem isn't with duplicate result rows, so the 
> DISTINCT shouldn't be changing the values for a single binding, should it?
>
> I'll be the first to admit my SPARQL is a little hazy, so I might be 
> forgetting some nuance of the spec here...I just can't seem to figure 
> it out :-) As I say, I'm just a bystander in this conversation, too, 
> so don't expend too much effort if I seem to be heading off into the 
> weeds somewhere!
>
> Cheers,
> Peter
>
>
>


-- 

Regards,

Kingsley Idehen       
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 






------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Dbpedia-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

Reply via email to