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
>

Reply via email to