"Create term definition" algorithm expands schema part of an absolute IRI as if it is a compact IRI

[lo48576]

Summary

playground: https://json-ld.org/playground/#startTab=tab-expanded&json-ld=%7B%22%40context%22%3A%7B%22http%22%3A%22schema%3A%2F%2Fhello%22%2C%22http%3A%2F%2Fexample.com%22%3A%7B%22%40type%22%3A%22http%3A%2F%2Ftype%22%7D%7D%2C%22http%3A%2F%2Fexample.com%22%3A%222000%22%7D

"Create term definition" algorithm has a step that replaces schema part of an absolute IRI to another IRI (the IRI mapping for the term that equals to the schema string).
This causes "http://example.com" to be replaced to "schema://hello//example.com" (in example above), but this is unexpected for me.

I'm not sure if this is a bug, but I want to know this is intended behavior or not.

If this is not intended, step 14.2 in JSON-LD-API 1.0 and step 17.2 in JSON-LD-API 1.1 (TR) should be like this:
"If term is a compact IRI and term's prefix has a term definition in active context, set the IRI mapping of ...".

Details

Create term definition has the steps below:

• If term contains a colon:
  • If term is a compact IRI with a prefix that is a key in local context, recursively create term definition for the prefix.
  • If term's prefix has a term definition in active context, concatenate IRI mapping for the prefix and the term's suffix.
  • Otherwise, term is an absolute IRI or blank node identifier. Use it as is.

For exact definitions, see step 14 in JSON-LD-API 1.0 §6.2 Create Term Definition, and JSON-LD-API 1.1 §4.2 Create Term Definition step 17.

json-ld-api/index.html

Lines 1405 to 1422 in 4725397

	<li>
	Otherwise if the <var>term</var> contains a colon (<code>:</code>):
	<ol>
	<li>If <var>term</var> is a <a>compact IRI</a> with a
	<a>prefix</a> that is a <a>member</a> in <var>local context</var>
	a dependency has been found. Use this algorithm recursively passing
	<var>active context</var>, <var>local context</var>, the
	<a>prefix</a> as <var>term</var>, and <var>defined</var>.</li>
	<li>If <var>term</var>'s <a>prefix</a> has a
	<a>term definition</a> in <var>active context</var>, set
	the <a>IRI mapping</a> of <var>definition</var> to the result of
	concatenating the value associated with the <a data-lt="prefix">prefix's</a>
	<a>IRI mapping</a> and the <var>term</var>'s <var>suffix</var>.</li>
	<li>Otherwise, <var>term</var> is an <a>absolute IRI</a> or
	<a>blank node identifier</a>. Set the <a>IRI mapping</a>
	of <var>definition</var> to <var>term</var>.</li>
	</ol>
	</li>

The problem is the second substep, "If term's prefix has a term definition in active context, ...".
This step replaces prefix of a compact IRI (for example xsd:dateTime to http://www.w3.org/2001/XMLSchema#dateTime), which is expected behavior.
However, this condition does not require term to be a compact IRI (which is required in the previous substep), and this causes an absolute IRI to be replaced if the schema (such as http) has a corresponding term definition.
For example, http://example.com is replaced to schema://hello//example.com in such cases.

I think the second substep should be like this: "If term is a compact IRI and term's prefix has a term definition in active context, set the IRI mapping of ...".

Example

playground: https://json-ld.org/playground/#startTab=tab-expanded&json-ld=%7B%22%40context%22%3A%7B%22http%22%3A%22schema%3A%2F%2Fhello%22%2C%22http%3A%2F%2Fexample.com%22%3A%7B%22%40type%22%3A%22http%3A%2F%2Ftype%22%7D%7D%2C%22http%3A%2F%2Fexample.com%22%3A%222000%22%7D

input

Attempt to associate "2000" value to the absolute IRI http://example.com.

{
  "@context": {
    "http": "schema://hello",
    "http://example.com": {
      "@type": "http://type"
    }
  },
  "http://example.com": "2000"
}

actual output

Absolute IRI http://example.com in input document is replaced to schema://hello//example.com, as if it was a compact IRI.

[
  {
    "schema://hello//example.com": [
      {
        "@type": "http://type",
        "@value": "2000"
      }
    ]
  }
]

expected

http://example.com is preserved even when a term http is expandable to another IRI, because http://example.com is not a compact IRI.

[
  {
    "http://example.com": [
      {
        "@type": "http://type",
        "@value": "2000"
      }
    ]
  }
]

[gkellogg]

@lo48576 thanks for the detailed analysis. The meta-issue you're noting is that in JSON-LD, there is an ambiguity between compact IRIs and absolute IRIs. The definition of compact IRI simply says "a compact IRI has the form of prefix:suffix ...". A prefix is defined as "the first component of a compact IRI which comes from a term that maps to a string prepended to the suffix of the compact IRI results in an absolute IRI".

In IRI Expansion we do distinguish values containing a colon where the suffix begins with "//", but this is not carried out uniformly.

Given the definitions, JSON-LD does allow http to be used as a prefix. One thing we've considered is a way to define terms that cannot be used as prefixes (@prefix allows this, but there's more to do on expansion). This would allow you to pre-register various URI schemes to prevent this usage.

I don't see that your suggested wording change would have an effect, unless the compact IRI definition were updated similarly to what is done in IRI expansion to prohibit a string containing "://" from being considered as a compact IRI. There could potentially be some backwards compatibility issues with doing this, but it may be the best way to go.

[lo48576]

In JSON-LD 1.0 §6.3 Compact IRIs, suffix seems to be already prohibited starting with two slashes:

Prefixes are expanded when the form of the value is a compact IRI represented as a prefix:suffix combination, the prefix matches a term defined within the active context, and the suffix does not begin with two slashes (//).

(emphasis mine)

According to this description, I've thought http://〜 is an absolute IRI and is not considered as a compact IRI in current specification.
However, this is not enough, because §6.3 is "non-normative" section.
The restriction should be forced and checked by each algorithm, not by non-normative section.

Is my understanding correct?

[gkellogg]

This should be fixed by #110.

[azaroth42]

Fixed in #110, closing.