Hi Paula, Here we go:
1) Really it is missing the # in the XSD IRI definition. I had ignored it because he thought it would not matter. But did... 2) I do not use the LMDB Sparql endpoint. I downloaded RDFs files and researching by Apache Jena library, which makes use of SPARQL version 1.1, which in turn contains all aggregations functions. So after just add the # in the XSD IRI definition, the query returned the expected result. Thank you so much! []´s Daniel Leite On Mon, Sep 14, 2015 at 10:54 PM, Paula Gearon <[email protected]> wrote: > It appears that you're running into 2 problems. > > The first is that your XSD IRI missed the hash sign at the end. That would > have been really tough to see. I only spotted it because I tried a simpler > query, where I just selected out the runtime and cast with xsd:int, only to > get nothing. That made me curious about the IRI of the cast function, which > is how I saw it. > > This leads to the next issue, which unfortunately is a showstopper. I'll > paste the result here: > > Parse error: > prefix movie: <http://data.linkedmdb.org/resource/movie/> > prefix xsd: <http://www.w3.org/2001/XMLSchema#> > select (SUM(xsd:int(?runtime)) as ?r) > where { <http://data.linkedmdb.org/resource/film/2014> movie:runtime > ?runtime } > > Encountered "SUM" at line 3, column 9. > Was expecting one of: > <IRIref> ... > <PNAME_NS> ... > <PNAME_LN> ... > <VAR1> ... > <VAR2> ... > "count" ... > "bound" ... > "str" ... > "datatype" ... > "lang" ... > "langmatches" ... > "isURI" ... > "isIRI" ... > "isBlank" ... > "isLiteral" ... > "regex" ... > "sameTerm" ... > "true" ... > "false" ... > <INTEGER> ... > <DECIMAL> ... > <DOUBLE> ... > <INTEGER_POSITIVE> ... > <DECIMAL_POSITIVE> ... > <DOUBLE_POSITIVE> ... > <INTEGER_NEGATIVE> ... > <DECIMAL_NEGATIVE> ... > <DOUBLE_NEGATIVE> ... > <STRING_LITERAL1> ... > <STRING_LITERAL2> ... > <STRING_LITERAL_LONG1> ... > <STRING_LITERAL_LONG2> ... > "(" ... > "!" ... > "+" ... > "-" ... > > Notice that with the exception of "count" the query parser is not looking > for any of the new functions in SPARQL 1.1. This appears to be a SPARQL 1.0 > endpoint, with a "count" extension. D2R advertises that it provides a > SPARQL 1.1 endpoint, so this must be a very old version. > > It's going to be hard to query this endpoint. What if you were to export > it? > > Paula > > On Mon, Sep 14, 2015 at 9:02 PM, Daniel Leite <[email protected] > > > wrote: > > > Hello guys, > > > > I'm working with LinkedMovieDataBase <http://data.linkedmdb.org/> + > Apache > > Jena and would like to know the sum of the runtime of the films. However > I > > have had many problems with queries using aggregates functions. > > > > It is known that literal has its standard type as a string, then it is > > necessary to cast to decimal. Thus it was formulated the following SPARQL > > query: > > > > PREFIX movie: <http://data.linkedmdb.org/resource/movie/> > > PREFIX xsd: <http://www.w3.org/2001/XMLSchema> > > SELECT (SUM(?runtime^^xsd:decimal) as ?sum_runtime) > > WHERE {?filmUri movie:runtime ?runtime} > > > > Returning the following error: > > > > Exception in thread "main" com.hp.hpl.jena.query.QueryParseException: > > Encountered " "^^" "^^ "" at line 1, column 126. > > Was expecting one of: > > "not" ... > > "in" ... > > <INTEGER_POSITIVE> ... > > <DECIMAL_POSITIVE> ... > > <DOUBLE_POSITIVE> ... > > <INTEGER_NEGATIVE> ... > > <DECIMAL_NEGATIVE> ... > > <DOUBLE_NEGATIVE> ... > > ")" ... > > "=" ... > > "!=" ... > > ">" ... > > "<" ... > > "<=" ... > > ">=" ... > > "||" ... > > "&&" ... > > "+" ... > > "-" ... > > "*" ... > > "/" ... > > > > I've done several adaptations to this query and i didn't get the expected > > result. One approach used was to modify the cast into the following form: > > > > ... > > SELECT (SUM(xsd:decimal(?runtime)) as ?sum_runtime) > > ... > > > > But the return is null, which I do not understand. If you try cast to > > integer (xsd:integer) or floating point (xsd:float) returns the same > error. > > > > Using COUNT as aggregation function the result is correct, but the count > is > > not necessary to make the conversion, so it works. With the MIN and MAX > > functions the result also goes wrong. > > > > The proof that the query is semantically correct is that if removing the > > sum function of the query returns the expected result. > > > > Can someone help me? > > > > Thanks in advance > > Daniel Leite > > >
