Why would you think the # does not matter? :)

On Tue, Sep 15, 2015 at 4:10 AM, Daniel Leite
<[email protected]> wrote:
> 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
>> >
>>

Reply via email to