Can't decipher IRI Expansion algorithm

[cygri]

I'm trying to work out what this should do under Expansion:

{
  "@type":"A"
}

I get lost in the IRI Expansion algorithm around here:

3. Otherwise, split the value into a prefix and suffix from the first occurrence of ':'.

This doesn't seem to apply as the value doesn't contain a colon. But then I read in 6)

Note that an empty suffix and no suffix (meaning the value contains no ':' string at all) are treated equivalently.

But 6) clearly doesn't apply to the situation, so I shouldn't even read it, no? Also, why isn't this case spelled out explicitly?

The rest of the algorithm talks about “the IRI being processed”, up until here the input has been called a “value”, so do 7) and 8) apply now?

7. doesn't make any sense—it talks about the case where there is no colon (hence no splitting into prefix and suffix is possible), but then talks about a “mapped value” (no idea what this might possibly refer to) and about a “suffix” (which doesn't exist—there was no colon, so no suffix)

So I've no idea what the result of expanding the snippet above should be. The Playground just produces "@type": ["A"], which surely can't be right, as @type values go through IRI expansion and hence should be producing IRIs, not literals.

[lanthaler]

You are right, the algorithm is not clear at all. I'll improve it (and the other algorithms) in the next days. Basically what happens here (or should happen) is described under 8)

Otherwise, if the IRI being processed does not contain a colon and is not a property, i.e., not a key in a JSON object treat it as a relative IRI and resolve it against the base IRI as per [RFC3986] using only the basic algorithm in section 5.2. Neither Syntax-Based Normalization nor Scheme-Based Normalization (described in sections 6.2.2 and 6.2.3 of [RFC3986]) are performed. Characters additionally allowed in IRI references are treated in the same way that unreserved characters are treated in URI references, per section 6.5 of [RFC3987].

Which means that "A" is interpreted as an IRI reference and resolved against the document's IRI. The "official" playground doesn't set the base IRI and that's why it isn't expanded. @dlongley could you please fix this.

[cygri]

Okay, thanks, that clarifies the issue.

Base IRIs in the “official” playground work fine in other cases like @id, but not with @type.

[dlongley]

The playground has been updated to use base IRI when expanding @type.

[cygri]

Cheers @dlongley!

[msporny]

@cygri @dlongley @lanthaler Where are we on this issue? I think it's clear that the base IRI should be used when expanding @type. @lanthaler have you been able to add this text to the spec? Is that the only thing we're waiting on here?

[lanthaler]

@msporny, please leave this issue open. I haven't had the time to fix it yet.

[dlongley]

@msporny, I think we're just waiting on the spec text now. Markus has just been busy.

[lanthaler]

I've just updated the algorithm. I will close this issue in 24 hours if there aren't any objections.