Fukesi insert data does not save in OWL file

[MANUEL Q]

Hello, I'm new to jena, I'm trying to use fukesi to enter data into an
owl file, using the following code, it gives me an "Update succeeded"
result:

PREFIX rdf: 
PREFIX owl: 
PREFIX: 
INSERT Date {
: leon rdf: type: Carnivoros,
  owl: NamedIndividual;
 : literal 44.
}

using a dataset: Persistent - dataset will persist across Fuseki restarts

but the new inserted data is not saved in the owl file.

how can I make the inserted data be saved in the owl file?


Thank you

Re: Problem with MAX when no result expected

[Andy Seaborne]

On 09/10/17 15:27, George News wrote:

On 2017-10-09 12:31, james anderson wrote:

good afternoon;

On 2017-10-09, at 12:03, George News  wrote:

On 2017-10-09 11:53, Lorenz Buehmann wrote:



On 09.10.2017 10:22, George News wrote:

Hi all,

Here it goes. The MWE is below.

As you can see when I execute Q_without.rq I get an empty array in
bindings. However with Qmax_without.rq I get {} (empty object) in
bindings.

What I'm saying is that if I'm getting nothing when listing the
matching entities, I don't know why I get an empty object when
listing the matching entities with an aggregate operation like MAX.


Well, I guess Andy already gave you the answer in the beginning of
the thread: A query with an aggregate always returns a row by
convention. But compared to the aggregate function COUNT which simply
can return 0 then, MAX can't return any concrete value because the
MAX of nothing is not specified.


I understood it, but I don't agree with this behaviour. Is this in the
standard or is it just Jena behaviour?


the recommendation describes the intended behaviour here :


 https://www.w3.org/TR/sparql11-query/#aggregateAlgebra



I guess this is it. If the standard says so, we have to stick to it,
although not in favour of that solution.


I haven't convinced myself that Jena is right (I haven't checked - 
virtuos seemed to do the same though which isn't proof but it's a 
completed unconnected implementation) and even if it is, whether the 
spec is saying what it means to say.  I don't see different cases for 
COUNT(*) and AnyAgg(?x) because I'd expect them to be different in the 
case of no GROUP BY.


The presence of GROUP BY fundamentally changes the nature of the query.



Does anybody knows a way to avoid loading the whole resultset in memory
to check if it has one row and then rewind it to the beginning?


ASK WHERE { pattern }

Andy



Thanks.




best regards, from berlin,


---
james anderson | ja...@dydra.com | http://dydra.com

Re: Problem with MAX when no result expected

[George News]

On 2017-10-09 12:31, james anderson wrote:
> good afternoon;
>> On 2017-10-09, at 12:03, George News  wrote:
>>
>> On 2017-10-09 11:53, Lorenz Buehmann wrote:
>>>
>>>
>>> On 09.10.2017 10:22, George News wrote:
 Hi all,

 Here it goes. The MWE is below.

 As you can see when I execute Q_without.rq I get an empty array in
 bindings. However with Qmax_without.rq I get {} (empty object) in
 bindings.

 What I'm saying is that if I'm getting nothing when listing the
 matching entities, I don't know why I get an empty object when
 listing the matching entities with an aggregate operation like MAX.

>>> Well, I guess Andy already gave you the answer in the beginning of
>>> the thread: A query with an aggregate always returns a row by
>>> convention. But compared to the aggregate function COUNT which simply
>>> can return 0 then, MAX can't return any concrete value because the
>>> MAX of nothing is not specified.
>>
>> I understood it, but I don't agree with this behaviour. Is this in the
>> standard or is it just Jena behaviour?
> 
> the recommendation describes the intended behaviour here :
> 
> 
> https://www.w3.org/TR/sparql11-query/#aggregateAlgebra
> 

I guess this is it. If the standard says so, we have to stick to it,
although not in favour of that solution.

Does anybody knows a way to avoid loading the whole resultset in memory
to check if it has one row and then rewind it to the beginning?

Thanks.

> 
> 
> best regards, from berlin,
> 
> 
> ---
> james anderson | ja...@dydra.com | http://dydra.com
> 
> 
> 
> 
> 
> 

Re: Missing solution in SPARQL select result, however this solution exists in the dataset

[Laurent Rucquoy]

Hello,

Just to recap, I was able to reload the TDB to be migrated but my migration
process became unusually slow on the reloaded TDB.
I have found a way to get better performance again by querying the union
graph named model instead of querying the dataset.
My problem seems to be solved for now.

Thank you again for your help.
Laurent


PS
Here is the source code modified in order to querying union graph model:

String sparql = "SELECT ?annotationDimension WHERE {
<
http://www.telemis.com/ImageAnnotation/000b3231-a9c3-42b1-bb71-2d416f729db8-msr>
 ?annotationDimension .
}";

Dataset dataset = TDBFactory.createDataset("C:/tdb");
dataset.begin(ReadWrite.READ);
Model model = dataset.getNamedModel("urn:x-arq:UnionGraph")

try {

try (QueryExecution queryExecution =
QueryExecutionFactory.create(sparql, model)) {

ResultSet resultSet = queryExecution.execSelect();

while (resultSet.hasNext()) {

QuerySolution querySolution = resultSet.nextSolution();
RDFNode rdfNode = querySolution.get("annotationDimension");
if(rdfNode != null) {
if(rdfNode.isLiteral()) {
 // ...
} else if(rdfNode.isResource()) {
// ...
}
}
}
}

} finally {
dataset.end();
}



On 29 September 2017 at 18:10, Andy Seaborne  wrote:

>
>
> On 29/09/17 16:34, Andy Seaborne wrote:
>
>> On 29 September 2017 at 09:27, Laurent Rucquoy <
>> laurent.rucq...@telemis.com > wrote:
>>
>> Hello,
>>
>> After having reloaded the data, we ran our TDB migration process which
>> starts to read the source model inculding the SPARQL queries in
>> question in
>> this discussion.
>> This process part took very long to finish and this seems abnormal
>> for us.
>>
>> 1 - Could it be due to missing indexes ?
>>
>>
>> No
>>
>> Its an issue with the data in the node table or in an index, not missing
>> something.
>>
>> 2 - Is there a tool in Jena to rebuild indexes of a reloaded TDB ?
>>
>>
>> No - TDB indexes are built as data is loaded.
>>
>> 3 - If the original TDB (before having be reloaded) contains corrupted
>> data, is there tool in Jena to identify the concerned corrupted data ?
>>
>>
>> There may not be the the info from but it *may* be possible to find out
>>
>
> There may not be the info but it *may* be possible to find out
>
>
> more (it depends what is broken and how).
>>
>> You can try this to attempt find out what is wrong - it may not work. I
>> have not tried this but ...
>>
>>
>> (1) With no other processes using the database, take a copy of the
>> database by copying the directory.
>>
>> (2) from the command line:
>>SELECT (count(*) AS ?C) { ?s ?p ?o }
>> (if no named graphs)
>>
>> because that does not access the node table to do the count.
>>
>> If that completes, and the count is right, then try from the command line:
>>
>> SELECT (count(*) AS ?C) { ?s ?p ?o . FILTER(?s != 1234) }
>>
>> because that forces the subject to be retrieved and nothing else.
>>
>> Same for ?p and ?o.
>>
>> This is checking the SPO index which is what ?s ?p ?o will choose.  It is
>> also the index used by backup. At least one of them should show the same
>> error.  Depending on which, it might be possible to fool the system to look
>> elsewhere as well.
>>
>>  Andy
>>
>>
>> Thank you in advance for your help.
>>
>> Regards,
>> Laurent
>>
>>
>>
>> On 28 September 2017 at 16:26, Laurent Rucquoy
>> >
>> wrote:
>>
>>  > Hello,
>>  >
>>  > I tested the tdbdump with Jena 3 instead of Jena 2.
>>  > It seemed to finish successfully (and I was able to load this
>> dump into a
>>  > TDB)
>>  >
>>  > Thank you for your help.
>>  >
>>  > Laurent
>>  >
>>  >
>>  > On 28 September 2017 at 14:04, Andy Seaborne > > wrote:
>>  >
>>  >>
>>  >>
>>  >> On 28/09/17 09:33, Laurent Rucquoy wrote:
>>  >> ...
>>  >>
>>  >>>
>>  >>> Note that the wrong behavior discussed here is strange because
>> the given
>>  >>> SPARQL query does not return any data and when I remove the
>> triple
>>  >>> pattern
>>  >>> concerning the "annotationDimension" linked resource object
>> (i.e. not a
>>  >>> literal object) the query returns the expected data (as if the
>> linked
>>  >>> resource object did not exist... but this object exists)
>>  >>>
>>  >>>
>>  >>> I've run the tdbdump on the concerned dataset but the process
>> ended
>>  >>> earlier
>>  >>> than expected with the following stacktrace:
>>  >>>
>>  >>> com.hp.hpl.jena.tdb.TDBException: Unrecognized node id type: 10
>>  >>>  at
>> 

Re: Problem with MAX when no result expected

[james anderson]

good afternoon;
> On 2017-10-09, at 12:03, George News  wrote:
> 
> On 2017-10-09 11:53, Lorenz Buehmann wrote:
>> 
>> 
>> On 09.10.2017 10:22, George News wrote:
>>> Hi all,
>>> 
>>> Here it goes. The MWE is below.
>>> 
>>> As you can see when I execute Q_without.rq I get an empty array in
>>> bindings. However with Qmax_without.rq I get {} (empty object) in
>>> bindings.
>>> 
>>> What I'm saying is that if I'm getting nothing when listing the
>>> matching entities, I don't know why I get an empty object when
>>> listing the matching entities with an aggregate operation like MAX.
>>> 
>> Well, I guess Andy already gave you the answer in the beginning of
>> the thread: A query with an aggregate always returns a row by
>> convention. But compared to the aggregate function COUNT which simply
>> can return 0 then, MAX can't return any concrete value because the
>> MAX of nothing is not specified.
> 
> I understood it, but I don't agree with this behaviour. Is this in the
> standard or is it just Jena behaviour?

the recommendation describes the intended behaviour here :


https://www.w3.org/TR/sparql11-query/#aggregateAlgebra

> …


best regards, from berlin,


---
james anderson | ja...@dydra.com | http://dydra.com

Re: Problem with MAX when no result expected

[George News]

On 2017-10-09 11:53, Lorenz Buehmann wrote:
> 
> 
> On 09.10.2017 10:22, George News wrote:
>> Hi all,
>> 
>> Here it goes. The MWE is below.
>> 
>> As you can see when I execute Q_without.rq I get an empty array in
>> bindings. However with Qmax_without.rq I get {} (empty object) in
>> bindings.
>> 
>> What I'm saying is that if I'm getting nothing when listing the
>> matching entities, I don't know why I get an empty object when
>> listing the matching entities with an aggregate operation like MAX.
>> 
> Well, I guess Andy already gave you the answer in the beginning of
> the thread: A query with an aggregate always returns a row by
> convention. But compared to the aggregate function COUNT which simply
> can return 0 then, MAX can't return any concrete value because the
> MAX of nothing is not specified.

I understood it, but I don't agree with this behaviour. Is this in the
standard or is it just Jena behaviour?

The issue here is that returning a row in the resultset in something
that leads to misunderstanding, as it seems there is a result available
when there isn't. In this sense, if there were a procedure to know in
advance that the object is empty, it will be ok, but you don't know it
is empty till you call next() and try to get the actual value. In that
case, if you want to print it you cannot rewind (if not stored
everything in memmory).

This is just my humble opinion on the issue. Nothing is nothing and not
one row although empty ;)

Thanks a lot for your understanding.

Regards,
Jorge






>> My opinion is that it should be an empty resultset as there is
>> nothing matching. That is, I cannot the max of nothing.
>> 
>> Hope now it is clear, and sorry for this long thread.
>> 
>> Regards, Jorge
>> 
>> 
[...snip...]

Re: Problem with MAX when no result expected

[Lorenz Buehmann]

On 09.10.2017 10:22, George News wrote:
> Hi all,
>
> Here it goes. The MWE is below.
>
> As you can see when I execute Q_without.rq I get an empty array in bindings. 
> However with Qmax_without.rq I get {} (empty object) in bindings.
>
> What I'm saying is that if I'm getting nothing when listing the matching 
> entities, I don't know why I get an empty object when listing the matching 
> entities with an aggregate operation like MAX. 
Well, I guess Andy already gave you the answer in the beginning of the
thread:
A query with an aggregate always returns a row by convention. But
compared to the aggregate function COUNT which simply can return 0 then,
MAX can't return any concrete value because the MAX of nothing is not
specified.
> My opinion is that it should be an empty resultset as there is nothing 
> matching. That is, I cannot the max of nothing.
>
> Hope now it is clear, and sorry for this long thread.
>
> Regards,
> Jorge
>
>
>
> $ cat dataset.ttl 
>   "Jorge" .
>   
> "30"^^ .
>   
> "20"^^ .
>   "Jorge" .
>   
> "5"^^ .
>   
> "80"^^ .
>   "Jorge" .
>   
> "8"^^ .
>   
> "32"^^ .
>   "Jo" .
>   
> "3"^^ .
>   
> "2"^^ .
>
> $ cat Q_with.rq 
> SELECT ?entity ?age  
> WHERE {
>   ?entity  "Jo" .
>   ?entity  ?age .
> }
>
> $ /opt/apache-jena/bin/sparql --query Q_with.rq --data dataset.ttl --results 
> json
> {
>   "head": {
> "vars": [ "entity" , "age" ]
>   } ,
>   "results": {
> "bindings": [
>   {
> "entity": { "type": "uri" , "value": "http://example.org/#d; } ,
> "age": { "type": "literal" , "datatype": 
> "http://www.w3.org/2001/XMLSchema#integer; , "value": "3" }
>   } ,
>   {
> "entity": { "type": "uri" , "value": "http://example.org/#d; } ,
> "age": { "type": "literal" , "datatype": 
> "http://www.w3.org/2001/XMLSchema#integer; , "value": "2" }
>   }
> ]
>   }
> }
>
> $ cat Q_without.rq 
> SELECT ?entity ?age  
> WHERE {
>   ?entity  "J" .
>   ?entity  ?age .
> }
>
> $ /opt/apache-jena/bin/sparql --query Q_without.rq --data dataset.ttl 
> --results json
> {
>   "head": {
> "vars": [ "entity" , "age" ]
>   } ,
>   "results": {
> "bindings": [
>   
> ]
>   }
> }
>
> $ cat Qmax_with.rq 
> SELECT ?entity (MAX(?age) AS ?value) 
> WHERE {
>   ?entity  "Jo" .
>   ?entity  ?age .
> } group by ?entity 
>
> $ /opt/apache-jena/bin/sparql --query Qmax_with.rq --data dataset.ttl 
> --results json
> {
>   "head": {
> "vars": [ "entity" , "value" ]
>   } ,
>   "results": {
> "bindings": [
>   {
> "entity": { "type": "uri" , "value": "http://example.org/#d; } ,
> "value": { "type": "literal" , "datatype": 
> "http://www.w3.org/2001/XMLSchema#integer; , "value": "3" }
>   }
> ]
>   }
> }
>
> $ cat Qmax_without.rq 
> SELECT ?entity (MAX(?age) AS ?value) 
> WHERE {
>   ?entity  "J" .
>   ?entity  ?age .
> } group by ?entity 
>
> $ /opt/apache-jena/bin/sparql --query Qmax_without.rq --data dataset.ttl 
> --results json
> {
>   "head": {
> "vars": [ "entity" , "value" ]
>   } ,
>   "results": {
> "bindings": [
>   {
> 
>   }
> ]
>   }
> }
>
>
>
>
>
>
> On 2017-10-09 09:25, George News wrote:
>> On 2017-10-08 11:18, Andy Seaborne wrote:
>>> Please - a complete, verifiable, minimal example.
>> I will try to compile one simple :(
>>
>>> Complete query, small amount of data.
>>>
>>> Snippets remove details that may matter.
>>>
>>> With a complete, verifiable, minimal example we can agree on what the
>>> question is.
>>>
>>> Indeed, it is not clear your output is even from Jena. The JSON
>>> formatting is not as Jena emits it.
>> I just used the Jena one. Only remove newlines in vars to make it shorter.
>>
>>>     Andy
>>>
>>> On 08/10/17 01:37, George News wrote:
 Hi,

 Forget the last one. I've just realized again I included a mistake
 this is the good one (I hope ;))

 # Case 1)
 select ?id ?value ?latitude ?longitude

Re: Problem with MAX when no result expected

[George News]

Hi all,

Here it goes. The MWE is below.

As you can see when I execute Q_without.rq I get an empty array in bindings. 
However with Qmax_without.rq I get {} (empty object) in bindings.

What I'm saying is that if I'm getting nothing when listing the matching 
entities, I don't know why I get an empty object when listing the matching 
entities with an aggregate operation like MAX. My opinion is that it should be 
an empty resultset as there is nothing matching. That is, I cannot the max of 
nothing.

Hope now it is clear, and sorry for this long thread.

Regards,
Jorge



$ cat dataset.ttl 
  "Jorge" .
  
"30"^^ .
  
"20"^^ .
  "Jorge" .
  
"5"^^ .
  
"80"^^ .
  "Jorge" .
  
"8"^^ .
  
"32"^^ .
  "Jo" .
  
"3"^^ .
  
"2"^^ .

$ cat Q_with.rq 
SELECT ?entity ?age  
WHERE {
  ?entity  "Jo" .
  ?entity  ?age .
}

$ /opt/apache-jena/bin/sparql --query Q_with.rq --data dataset.ttl --results 
json
{
  "head": {
"vars": [ "entity" , "age" ]
  } ,
  "results": {
"bindings": [
  {
"entity": { "type": "uri" , "value": "http://example.org/#d; } ,
"age": { "type": "literal" , "datatype": 
"http://www.w3.org/2001/XMLSchema#integer; , "value": "3" }
  } ,
  {
"entity": { "type": "uri" , "value": "http://example.org/#d; } ,
"age": { "type": "literal" , "datatype": 
"http://www.w3.org/2001/XMLSchema#integer; , "value": "2" }
  }
]
  }
}

$ cat Q_without.rq 
SELECT ?entity ?age  
WHERE {
  ?entity  "J" .
  ?entity  ?age .
}

$ /opt/apache-jena/bin/sparql --query Q_without.rq --data dataset.ttl --results 
json
{
  "head": {
"vars": [ "entity" , "age" ]
  } ,
  "results": {
"bindings": [
  
]
  }
}

$ cat Qmax_with.rq 
SELECT ?entity (MAX(?age) AS ?value) 
WHERE {
  ?entity  "Jo" .
  ?entity  ?age .
} group by ?entity 

$ /opt/apache-jena/bin/sparql --query Qmax_with.rq --data dataset.ttl --results 
json
{
  "head": {
"vars": [ "entity" , "value" ]
  } ,
  "results": {
"bindings": [
  {
"entity": { "type": "uri" , "value": "http://example.org/#d; } ,
"value": { "type": "literal" , "datatype": 
"http://www.w3.org/2001/XMLSchema#integer; , "value": "3" }
  }
]
  }
}

$ cat Qmax_without.rq 
SELECT ?entity (MAX(?age) AS ?value) 
WHERE {
  ?entity  "J" .
  ?entity  ?age .
} group by ?entity 

$ /opt/apache-jena/bin/sparql --query Qmax_without.rq --data dataset.ttl 
--results json
{
  "head": {
"vars": [ "entity" , "value" ]
  } ,
  "results": {
"bindings": [
  {

  }
]
  }
}






On 2017-10-09 09:25, George News wrote:
> On 2017-10-08 11:18, Andy Seaborne wrote:
>> Please - a complete, verifiable, minimal example.
> 
> I will try to compile one simple :(
> 
>> Complete query, small amount of data.
>>
>> Snippets remove details that may matter.
>>
>> With a complete, verifiable, minimal example we can agree on what the
>> question is.
>>
>> Indeed, it is not clear your output is even from Jena. The JSON
>> formatting is not as Jena emits it.
> 
> I just used the Jena one. Only remove newlines in vars to make it shorter.
> 
>>     Andy
>>
>> On 08/10/17 01:37, George News wrote:
>>> Hi,
>>>
>>> Forget the last one. I've just realized again I included a mistake
>>> this is the good one (I hope ;))
>>>
>>> # Case 1)
>>> select ?id ?value ?latitude ?longitude
>>> where {
>>> ..
>>> }
>>> --
>>> {
>>>  "head": {
>>>  "vars": [
>>>  "id", "value", "latitude", "longitude"
>>>  ]
>>>  },
>>>  "results": {
>>>  "bindings": [
>>>  ]
>>>  }
>>> }
>>>
>>> # Case 2)
>>> select ?id (MAX(?ti) as ?time) ?value ?latitude ?longitude
>>> where {
>>> ..
>>> }
>>> --
>>> {
>>>  "head": {
>>>  "vars": [
>>>  "id", "time", "value", "latitude", "longitude"
>>>  ]
>>>  },
>>>  "results": {
>>>  "bindings": [
>>>  {}
>>>  ]
>>>  }
>>> }
>>>

Re: Problem with MAX when no result expected

[George News]

On 2017-10-08 13:07, Lorenz B. wrote:
> Hello George,
> 
> right now it's really hard to help you. A complete query + sample data
> is missing to reproduce it. In addition, the second query seems to be an
> invalid SPARQL query - at least I don't see grouping by ?id and the
> other values are not aggregates. I don't think this is valid in standard
> SPARQL 1.1 .

The queries pasted where shortcut, this is why the group by, etc was not
there. However on the real execution they are.

> By the way, which triple store do you use? Virtuoso?

No. I'm using Jena TDB. In the future I'm thinking on moving to Virtuoso
to "get more speed?".


> 
> 
> Cheers,
> Lorenz
> 
>> Hi,
>>
>> Forget the last one. I've just realized again I included a mistake
>> this is the good one (I hope ;))
>>
>> # Case 1)
>> select ?id ?value ?latitude ?longitude
>> where {
>> ..
>> }
>> --
>> {
>> "head": {
>> "vars": [
>> "id", "value", "latitude", "longitude"
>> ]
>> },
>> "results": {
>> "bindings": [
>> ]
>> }
>> }
>>
>> # Case 2)
>> select ?id (MAX(?ti) as ?time) ?value ?latitude ?longitude
>> where {
>> ..
>> }
>> --
>> {
>> "head": {
>> "vars": [
>> "id", "time", "value", "latitude", "longitude"
>> ]
>> },
>> "results": {
>> "bindings": [
>> {}
>> ]
>> }
>> }
>>
>> Now you can see the difference I was noticing. In the first case
>> bindings is an empty array (resultset.hasNext() -> false) and the second
>> is an array with an empty object (resultset.hasNext() -> true).
>>
>> Why is this behaviour? Hope you now understand the issue which in my
>> opinion is a kind of a bug.
>>
>> Regards,
>> Jorge
>>
>> On 2017-10-08 00:15, George News wrote:
>>> Hi Andy,
>>>
>>> Now I understand the misunderstanding between you and me. The responses
>>> I included in my original mail where wrong :( Please accept my apologizes.
>>>
>>> These are the right query/responses:
>>>
>>> # Case 1)
>>> select ?id (MAX(?ti) as ?time) ?value ?latitude ?longitude
>>> where {
>>> ..
>>> }--
>>> {
>>> "head": {
>>> "vars": [
>>> "id", "time", "value", "latitude", "longitude"
>>> ]
>>> },
>>> "results": {
>>> "bindings": [
>>> {}
>>> ]
>>> }
>>> }
>>>
>>> # Case 2)
>>> select ?id (MAX(?ti) as ?time) ?value ?latitude ?longitude
>>> where {
>>> ..
>>> }--
>>> {
>>> "head": {
>>> "vars": [
>>> "id", "value", "latitude", "longitude"
>>> ]
>>> },
>>> "results": {
>>> "bindings": [
>>> ]
>>> }
>>> }
>>>
>>> Now you can see the difference I was noticing. In the first case it is
>>> an empty array (resultset.hasNext() -> false) and the second is an array
>>> with an empty object (resultset.hasNext() -> true).
>>>
>>> Why is this behaviour? Hope you now understand the issue which in my
>>> opinion is a kind of a bug.
>>>
>>> Regards,
>>> Jorge
>>>
>>>
>>>
>>>
>>>
>>> On 2017-10-06 16:11, Andy Seaborne wrote:

 On 06/10/17 12:26, George News wrote:
> On 2017-10-06 11:25, Andy Seaborne wrote:
>> The two result sets you show both have one row, with bindings. That's
>> consistent with aggregation of nothing (no groups, or if no GROUP BY, no
>> results from the WHERE pattern.
> I don't see it the same way. The first one (without max) is an empty
> array, while the second (with max) has an array with one object (empty).
     "results": {
     "bindings": [
     {}
     ]
     }

 both times.

 An array of rows, a row is {} i.e. no keys, no variables.

 But the query isn't legal so I don't know what is actually happening.

>> MAX() of nothing is unbound but for any aggregation, there always is
>> a row/
>>
>> c.f. COUNT(*) is 0 when there are no solution.
>>
>> It's just MAX(...) can't return a "there isn't anything value"
>>
>>  Andy
>>
> I see your point as this gives a wrong idea on the result set as it
> really is empty. If I dont get any time I cannot calculate the max of
> nothing. In principle this is what Jena is returning as the object is
> empty, but there should be a way to not get this empty object within the
> array of bindings.
>
> Is there anyway I can check the resultset pointer to get the next()
> value without moving the pointer? I need to know in advance to retrieve
> all the results if there are or aren't any.
>
>
>> On 06/10/17 10:15, George News wrote:
>>> Hi all,
>>>
>>> I am executing a SPARQL with MAX aggregate function and I'm facing a
>>> strange behaviour, or at least I think it is.
>>>
>>> The snipset of the select variables is the following:
>>>
>>> select ?id (MAX(?ti) as ?time) ?value ?latitude ?longitude
>>> where {

Re: Problem with MAX when no result expected

[George News]

On 2017-10-08 11:18, Andy Seaborne wrote:
> Please - a complete, verifiable, minimal example.

I will try to compile one simple :(

> Complete query, small amount of data.
> 
> Snippets remove details that may matter.
> 
> With a complete, verifiable, minimal example we can agree on what the
> question is.
> 
> Indeed, it is not clear your output is even from Jena. The JSON
> formatting is not as Jena emits it.

I just used the Jena one. Only remove newlines in vars to make it shorter.

>     Andy
> 
> On 08/10/17 01:37, George News wrote:
>> Hi,
>>
>> Forget the last one. I've just realized again I included a mistake
>> this is the good one (I hope ;))
>>
>> # Case 1)
>> select ?id ?value ?latitude ?longitude
>> where {
>> ..
>> }
>> --
>> {
>>  "head": {
>>  "vars": [
>>  "id", "value", "latitude", "longitude"
>>  ]
>>  },
>>  "results": {
>>  "bindings": [
>>  ]
>>  }
>> }
>>
>> # Case 2)
>> select ?id (MAX(?ti) as ?time) ?value ?latitude ?longitude
>> where {
>> ..
>> }
>> --
>> {
>>  "head": {
>>  "vars": [
>>  "id", "time", "value", "latitude", "longitude"
>>  ]
>>  },
>>  "results": {
>>  "bindings": [
>>  {}
>>  ]
>>  }
>> }
>>
>> Now you can see the difference I was noticing. In the first case
>> bindings is an empty array (resultset.hasNext() -> false) and the second
>> is an array with an empty object (resultset.hasNext() -> true).
>>
>> Why is this behaviour? Hope you now understand the issue which in my
>> opinion is a kind of a bug.
>>
>> Regards,
>> Jorge
>>
>> On 2017-10-08 00:15, George News wrote:
>>> Hi Andy,
>>>
>>> Now I understand the misunderstanding between you and me. The responses
>>> I included in my original mail where wrong :( Please accept my
>>> apologizes.
>>>
>>> These are the right query/responses:
>>>
>>> # Case 1)
>>> select ?id (MAX(?ti) as ?time) ?value ?latitude ?longitude
>>> where {
>>> ..
>>> }--
>>> {
>>>  "head": {
>>>  "vars": [
>>>  "id", "time", "value", "latitude", "longitude"
>>>  ]
>>>  },
>>>  "results": {
>>>  "bindings": [
>>>  {}
>>>  ]
>>>  }
>>> }
>>>
>>> # Case 2)
>>> select ?id (MAX(?ti) as ?time) ?value ?latitude ?longitude
>>> where {
>>> ..
>>> }--
>>> {
>>>  "head": {
>>>  "vars": [
>>>  "id", "value", "latitude", "longitude"
>>>  ]
>>>  },
>>>  "results": {
>>>  "bindings": [
>>>  ]
>>>  }
>>> }
>>>
>>> Now you can see the difference I was noticing. In the first case it is
>>> an empty array (resultset.hasNext() -> false) and the second is an array
>>> with an empty object (resultset.hasNext() -> true).
>>>
>>> Why is this behaviour? Hope you now understand the issue which in my
>>> opinion is a kind of a bug.
>>>
>>> Regards,
>>> Jorge
>>>
>>>
>>>
>>>
>>>
>>> On 2017-10-06 16:11, Andy Seaborne wrote:


 On 06/10/17 12:26, George News wrote:
> On 2017-10-06 11:25, Andy Seaborne wrote:
>> The two result sets you show both have one row, with bindings. That's
>> consistent with aggregation of nothing (no groups, or if no GROUP
>> BY, no
>> results from the WHERE pattern.
>
> I don't see it the same way. The first one (without max) is an empty
> array, while the second (with max) has an array with one object
> (empty).

  "results": {
  "bindings": [
  {}
  ]
  }

 both times.

 An array of rows, a row is {} i.e. no keys, no variables.

 But the query isn't legal so I don't know what is actually happening.

>
>>
>> MAX() of nothing is unbound but for any aggregation, there always is
>> a row/
>>
>> c.f. COUNT(*) is 0 when there are no solution.
>>
>> It's just MAX(...) can't return a "there isn't anything value"
>>
>>   Andy
>>
>
> I see your point as this gives a wrong idea on the result set as it
> really is empty. If I dont get any time I cannot calculate the max of
> nothing. In principle this is what Jena is returning as the object is
> empty, but there should be a way to not get this empty object
> within the
> array of bindings.
>
> Is there anyway I can check the resultset pointer to get the next()
> value without moving the pointer? I need to know in advance to
> retrieve
> all the results if there are or aren't any.
>
>
>>
>> On 06/10/17 10:15, George News wrote:
>>> Hi all,
>>>
>>> I am executing a SPARQL with MAX aggregate function and I'm facing a
>>> strange behaviour, or at least I think it is.
>>>
>>> The snipset of the select variables is the following:
>>>
>>> select ?id (MAX(?ti) as ?time) ?value ?latitude ?longitude
>>> where {
>>>