LinkedDataFragments / HDT-Node

Native bindings for Node.js to access HDT compressed triple files.

Home Page:http://ruben.verborgh.org/blog/2014/09/30/bringing-fast-triples-to-nodejs-with-hdt/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Literal datatype notation in query

LaurensRietveld opened this issue · comments

In HDT-Node, the query syntax for a datatyped-literal is "val"^^http://datatype. In the HDT-CLI, the syntax is "val"^^<http://datatype>.
I get the motivation for HDT-Node to remove the angular brackets, as regular IRIs don't have these as well and you'd like to present a consistent API to the user.
I get the impression though that this representation only makes it more confusing (at least it does for me), for the following reasons:

  • The HDT cli does require angular brackets
  • Parsing the literal using common libs is not possible, it's not standards compliant
  • The inclusion of quotes in a literal implies that we're seeing a standard serialized term. (I know that these quotes are required to be able to differentiate between IRIs and literals. Still, it's confusing ;) )

Any thoughts?

Hi @LaurensRietveld, in time (and I hope soon), we'll migrate to RDF/JS for the JavaScript interface, so this issue will become obsolete. Nonetheless, an answer is below.

I get the motivation for HDT-Node to remove the angular brackets, as regular IRIs don't have these as well and you'd like to present a consistent API to the user.

That motivation was actually different: I follow what N3.js uses for triple representation.

The HDT cli does require angular brackets

Fair enough, but then again, no reason for the CLI to use the N3.js representation (as this library does).

Parsing the literal using common libs is not possible, it's not standards compliant

That is not possible anyway, because in addition to the missing angular brackets, no escaping happens. I.e., the 3-character string "\" is represented as ""\"

The inclusion of quotes in a literal implies that we're seeing a standard serialized term

Wrong implication 😉 The README explains how the literals need to be interpreted.


In any case, all of the confusion will disappear when we adopt RDF/JS.