Pregunta La consulta SPARQL con COUNT y ORDER devuelve resultados impares


La siguiente consulta cuenta todos los triples en una tienda

SELECT count(*) where { ?s ?p <http://dbpedia.org/resource/Cat> }

Y devuelve los resultados esperados

http://dbpedia.org/sparql?default-graph-uri=http://dbpedia.org&query=select+count(*)+{+%3Fs+%3Fp+%3Chttp://dbpedia.org/resource/Cat% 3E +} + & debug = on & timeout = & format = text / html & save = display & fname =

Sin embargo, cuando lo probé por primera vez lo dejé accidentalmente en una instrucción ORDER BY, por ejemplo,

select count(*) { ?s ?p <http://dbpedia.org/resource/Cat> } order by ?s

Entonces obtengo una lista muy larga de resultados

http://dbpedia.org/sparql?default-graph-uri=http://dbpedia.org&query=select+count(*)+{+%3Fs+%3Fp+%3Chttp://dbpedia.org/resource/Cat% 3E +} + order + by +% 3Fs & debug = on & timeout = & format = text / html & save = display & fname =

¿Alguien puede explicar por qué sucede este resultado y qué significa? ¿Es tal vez un error con la implementación de Virtuoso SPARQL?


5
2018-04-01 19:25


origen


Respuestas:


Parece un error, si ejecuta el mismo tipo de consultas en un almacén diferente, es decir, en http://api.talis.com/stores/bbc-backstage/services/sparql (que no se ejecuta virtuoso)

Esta primera consulta funciona ...

SELECT (count(?s) as ?c)
WHERE {
?s ?p <http://purl.org/ontology/po/Version> .
}

y el segundo ...

SELECT (count(?s) as ?c)
WHERE {
?s ?p <http://purl.org/ontology/po/Version> .
} order by ?s

... da el mismo resultado.

En realidad, contar + ordenar no tiene mucho sentido aquí porque ?s no está seleccionado para ser recuperado. Pero como dijiste, lo intentaste accidentalmente y ... parece un error.

Mi recomendación es enviar un correo electrónico a la lista de correo de virtuoso-usuario para notificar acerca de este problema


5
2018-04-02 11:21



Nosotros (= OpenLink) estamos en problemas aquí. Este ORDER BY? S es formalmente un error en la consulta: un agregado sin agrupación significa "agregado en todo", no debería haber variables fuera de los agregados en el extremo de salida de la consulta. Sin embargo, este error no se informa ahora: las violaciones de esta regla son tan numerosas que el compilador de SQL realiza una agrupación automática y nuestro preprocesador SPARQL a SQL también ignora este error si es posible.

Probablemente mantendremos el comportamiento actual tal como está. Si se agrega un modo de compilación "estricto", se activará el informe de errores en casos como este.


3
2018-04-03 18:51



Esto puede ser un error con Virtuoso, parece tratar consultas con agregados y un ORDER BY cláusula que tiene un implícito GROUP BY cláusula. Me he dado cuenta de esto en otros puntos finales de Virtuoso además del de DBPedia.

En mi opinión, esto es un error y debe informarlo a la lista de correo de los usuarios de Virutoso como sugiere msalvadores


1
2018-04-02 11:22