compaction changes the meaning of absolute IRIs in some cases

[pchampin]

The problem

Some absolute IRIs are undistinguishable from compact IRIs (e.g. mailto:a@b.c or tag:champin.net,2019:xyz). This is in fact the case for any IRI that has no double-slash after the first colon.

Now consider the following data (DATA1):

{
  "tag:champin.net,2019:prop": "hello world"
}

Here, the property is interpreted (by expansion or RDF-serialization) as an absolute IRI, since there is no tag prefix to interpret it as a compact IRI.

Now consider the following context (CTX1):

{"@context": {
    "tag": "http://example.org/ns/tag/"
}}

If we compact DATA1 with CTX1, we get DATA2:

{
  "@context": {
    "tag": "http://example.org/ns/tag/"
  },
  "tag:champin.net,2019:prop": "hello world"
}

(try it in the playground).

This is wrong because in DATA2, the property is now interpreted (by expansion or RDF-serialization) as http://example.org/ns/tag/champin.net,2019:prop as shown in the playground.

The compaction algorithm should detect there will be a problem when 1) it would leave an absolute IRI unmodified AND 2) the active context contains a term definition matching that IRI's scheme – call this CONDITION1.

Proposed solution 1

If CONDITION1 above is met, an error or a warning (although I would prefer an error) is raised. The rationale is that it is impossible to produce a JSON-LD document preserving this absolute IRI with the given context.

Probably this should only happen when the context has "@version": 1.1 set, to not break backward compatibility -- even though this was a bug in JSON-LD 1.0 as well...

Proposed solution 2

If CONDITION1 above is met, another context is included in the output data, which contains a fresh prefix resolving to the IRI's scheme. That fresh prefix is used to transform the absolute IRI:

{
  "@context": [
    {
      "_abs_tag": "tag:"
    },
    {
      "tag": "http://example.org/ns/tag/"
    }
  ],
  "_abs_tag:champin.net,2019:prop": "hello world"
}

But is it acceptable for the compaction algorithm to output a different context than the one given as input? Also, it might be not trivial to coin a clash-less prefix.

Proposed solution 3

Another option would be to have a microsyntax to force a string to be interpreted as an absolute IRI. This microsyntax would be used by the compaction algorithm whenever CONDITION1 above is detected. E.g.::

{
  "@context": {
    "tag": "http://example.org/ns/tag/"
  },
  "<tag:champin.net,2019:prop>": "hello world"
}

It could also be used by data authors to address the issue raised by w3c/json-ld-syntax/issues/177.

Proposed microsyntaxes:

• put the IRI between pointy brackets, as is done in Turtle: "<tag:champin.net,2019:prop>"
• prefix the IRI with a new "keyword-like" prefix: "@abs:tag:champin.net,2019:prop"

[iherman]

This issue was discussed in a meeting.

• ACTION: write another proposed solution to #104 (which may also solve for #87 or perhaps #76) (Gregg Kellogg)

View the transcript

ompaction changes the meaning of absolute IRIs in some cases #104
Gregg Kellogg: #104
Pierre-Antoine Champin: the problem: through compaction, I can end up with a different graph than I started with
… i thin this is a 1.0 problem as well
Adam Soroka: .. there are examples in the issue that display the problem
Pierre-Antoine Champin: there is shown an IRI that is indistinguishable from an IRI.
… you can tell which it is only from context
Gregg Kellogg: there are other things that you can add to a context that would change the interpretation of things
… [gives example of similar phenomenon using lang tags]
… this goes right back the previous discussion
… you might want to say here that @prefix=false
Dave Longley: +1 to @prefix: false to solve this
Gregg Kellogg: which could impact the expansion algo to not use it in this case
… but that could still be surprising
Pierre-Antoine Champin: { "http://ex.co/prop": "foo" }
Pierre-Antoine Champin: consider my example above
… and compact it with a context that I just recited out loud
Gregg Kellogg: there is no compaction w/o expansion
… but what is the context used for expansion?
Pierre-Antoine Champin: okay, yeah. I didn’t want to show expansion for brevity
… i can get this phenomenon using the same context for compaction and expansion
Dave Longley: adding the context he verbalized, you can no longer distinguish between the two uses of the term
Gregg Kellogg: even with a mechanism to prevent that, mistakes will appear
… if this was one line in 10,000 triples
… it might get missed
Pierre-Antoine Champin: if I expand and compact with the same context, it should round-trip, right?
Gregg Kellogg: yes
… but the semantics would change
Pierre-Antoine Champin: if we had a way to say that something isn’t a CURIE
… that would solve it
Adam Soroka: .. compaction should protect certain IRIS
Pierre-Antoine Champin: when compaction sees a term matching an IRI scheme, the problem can arise
… I made three proposals, bt I prefer the third
… i don’t like µsyntax, but…
Gregg Kellogg: a 4th proposal is to use @prefix=false during expansion
Pierre-Antoine Champin: I can’t always move my data out of th way of this
… . my contexts may be coming from someone else
Gregg Kellogg: @prefix=false can prevent this problem. maybe not perfectly
… going back to the dawn of time, we had to make some choice because of JSON
… this may be a bubble we are pushing around,
Dave Longley: I would formally object to proposal 3; I hate µsyntaxes
… this might be a corner case we can’t solve because of previous decisions, in the sense that
… there may be contexts you just can’t use with your data
… I wish we had not done CURIEs at all
… it was probably a mistake
… they introduce surprise
… we may have to accept certain corner cases
… it might require some kind of processing mode change, it might be a 2.0 issue
Gregg Kellogg: +1 to dlongley
Benjamin Young: we are wrangling a pass the of issues
… gkellogg: do you still think we could make @prefix clearer?
Dave Longley: @prefix: false would solve this in some cases
Gregg Kellogg: we already detect whether a term could be used as a prefix
… it’s an addition of ½ a line
… it’s a simple change
… it’s gets more complicated when we bring in different modes
… but the easy play is to make it symmetrical from compaction to expansion
… which would solve #104
… by offering a context author a way to avoid that problem
… it might solve #87 or #76
Benjamin Young: this merits an action at this point, not resolution
Action #1: write another proposed solution to #104 (which may also solve for #87 or perhaps #76) (Gregg Kellogg)
Pierre-Antoine Champin: i agree with this action, but I don’t think it will solve #104
… where dlongely’s position is my solution 1
… some contexts simply cannot work with some data
… if we cannot provide a solution, we should at least have an answer ready
Gregg Kellogg: if you create the opportunity for this collision, we should raise a warning
Dave Longley: it’s an error
Dave Longley: in my view
Pierre-Antoine Champin: one could bring in a local context
gkelllogg: bleh