Why is (Non-Transitive) Cyclic IRI Mapping an Error?

[Aklakan]

Both versions of the spec at [1] and [2] state:

Otherwise, if the value is false, a cyclic IRI mapping error has been detected and processing is aborted.

In order to parse queries that make use of Virtuoso's bif namespace, I so far used a turtle file with prefix declarations such as @prefix bif: <bif:> . I wanted to switch to json-ld and found out that {"@context": {"bif":"bif:"}} fails to parse with JSON-LD using json-ld-java 0.12.5 via jena 3.14.0 (latest jena release at the time of writing). As a cyclic prefix declaration turns CURIEs into URIs - one would expect that a purely syntactic construct bif:Foo can be parsed into the RDF term<bif:Foo> if the prefix mapping says so.

For example, this query uses both syntactic variants and both work fine on http://dbpedia.org/sparql

PREFIX bif: <bif:>
SELECT * {
  # With strict var checking enabled, Virtuoso complains if there are no triple patterns
  OPTIONAL { ?s <urn:foobar> ?o } 

  BIND(bif:sys_stat('st_dbms_name') AS ?dbmsRawName) # CURIE
  BIND(<bif:sys_stat>('st_dbms_ver') AS ?dbmsVersion) # URI
}

So is this a bug / limitation in the json-ld spec itself or is it a bug of the json-ld-java implementation?

[1] https://json-ld.org/spec/latest/json-ld-api/#algorithm-0 [2] https://w3c.github.io/json-ld-api/#algorithm-0

[gkellogg]

Indeed, this looks like it maps a prefix to itself, as there is processing to treat "bif" and "bif:" the same way. Note, but just eliminating the "bif" term definition, it will be used as an IRI scheme.

You might using the playground to see if the expansion/RDF conversion of your test file treats this properly.

In turtle, there's a difference between <bif:sys_stat> and bif:sys_stat, but in JSON-LD they both are specified as "bif:sys_stat" where we look to see if "bif" is a term that can be used as a prefix, but it's already a scheme.

[Aklakan]

Hm, my use case was actually to just store the namespace declarations in a json-ld file with only a @context - no actual data in it.

This file is just a dump from https://prefix.cc/ and I used to use it just like

Model prefixes = RDFDataMgr.loadModel("rdf-prefixes/prefix.cc.2019-12-17.jsonld");

But I suppose for my use case, namely parsing query logs - including ones of virtuoso, I should just stick with the turtle syntax as this works as expected. So if you feel there is no need to make this kind of use case work with JSON-LD you can just close the issue as wont-fix.

[pchampin]

This problem also comes from the fact that bif: CURIEs are handled by older Virtuoso in a rather unorthodox way: assigning the bif prefix to anything else than bif: is rejected as an error.

[gkellogg]

The entry from prefix.cc/context is "bif": "http://www.openlinksw.com/schemas/bif#",

[Aklakan]

The entry from prefix.cc/context is "bif": "http://www.openlinksw.com/schemas/bif#",

This is true, but it does not work for legacy virtuosos.

According to my above query, DBpedia uses version 07.20.3232 and there the current prefix.cc entry works - however, the virtuoso I am working with is "07.20.3229" - and this one yields

Virtuoso 37000 Error SP030: SPARQL compiler, line 3: Prefixes 'sql:' and 'bif:' are reserved for SQL names at '<http://www.openlinksw.com/schemas/bif#>' before 'SELECT'

[gkellogg]

Yes, but I can't see how to classify this as a JSON-LD issue. If you're using an older version for Virtuoso, you may need to override the "bif": "bif:" entry to get around the issue, or as you say, just use Turtle.

In any event, I'm going to mark as "propose closing", please respond if you agree.

[Aklakan]

Yes, but I can't see how to classify this as a JSON-LD issue

Well, its one of those little details where things that seemed to be interchangeably turned out not to be in corner cases, i.e. that there exist namespace mappings that simply cannot be represented in JSON-LD although they work in the older turtle syntax, which feels a bit like a regression.

So closing the issue is fine, as for me using turtle solves it, and I don't want to put energy on it - but having stepped onto this issue still stings.