search

ad-freiburg / qlever

Very fast SPARQL Engine, which can handle very large knowledge graphs like the complete Wikidata, offers context-sensitive autocompletion for SPARQL queries, and allows combination with text search. It's faster than engines like Blazegraph or Virtuoso, especially for queries involving large result sets.
Apache License 2.0
367 stars 43 forks source link

Blank nodes in results should be shown as 'unknown value' in the UI #451

Closed graue70 closed 2 years ago

graue70 commented 3 years ago 
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
SELECT ?0 WHERE {
  wd:Q710099 wdt:P20 ?0 .
}

yields the following result: :1d420e146c92547669e403aa015b1e1b.

On wikidata you can see that the result should be 'unknown value' (and it's been like that since 2016).

joka921 commented 3 years ago

This is a socalled "blank node" which does not have a proper iri <http://something.org/...> but just an internal numeric identifier that starts with _: . It is legal to export these internal identifiers. If you want to show "unknown value" as the Wikidata query Service does, you can just replace all results that start with _: by unknown value.

graue70 commented 3 years ago

In that case, would you agree that it is a UI issue? I strongly suggest showing 'unknown value' to the user. Could you please transfer the ticket if you agree?

justin2004 commented 2 years ago

identifiers like _:1d420e146c92547669e403aa015b1e1b are used in most triplestores i've used. fuseki, stardog, etc.

graue70 commented 2 years ago

identifiers like _:1d420e146c92547669e403aa015b1e1b are used in most triplestores i've used. fuseki, stardog, etc.

I'm not arguing about the data format when downloading the data as a file or about the RDF specs. I am saying that a Graphical User Interface like QLever UI which tries to be user friendly should not show internal identifiers but 'no value' instead.

Similarly, the QLever UI already shows a literal like "8850.0"^^<http://www.w3.org/2001/XMLSchema#decimal> as 8850.0 so the UI makes the data more visually appealing and understandable already in some regards.

(Note that this issue should be in https://github.com/ad-freiburg/qlever-ui. That's why I asked @joka921 to transfer it there.)

hannahbast commented 2 years ago

@graue70 Thanks, but I am not convinced that how results are displayed on a Wikidata entity page should be a yardstick for how the results of a SPARQL query are displayed.

The Wikidata entity pages are an abstract view of the data, independent of a particular serialization format and independent even of the RDF model. Indeed Wikidata also provides their data as JSON (with arrays and stuff), which is not RDF. See https://www.wikidata.org/wiki/Wikidata:Database_download , where you have subsections "JSON Dumps", "RDF Dumps", "XML Dumps", etc.

A SPARQL query is a query on RDF data and the result are flat tables with excerpts of that RDF data. Also note that the result of a SPARQL query is never nested, like much of the information on a Wikidata entity page.

joka921 commented 2 years ago

There is no clear consensus on this, and it does not concern QLever but rather the qlever UI, so I'm closing this.