How is keyword-aliasing supposed to work

[lanthaler]

Keyword aliasing is currently not really specified. We have only one paragraph in the syntax spec and do not describe it at all in the expansion algorithm. I think we might have different ideas of how it should work so lets try to find a consensus.

1) Can multiple aliases exist for a keyword?

I would say yes

2) Why is aliasing of @context disallowed?

I see no reason for this

3) Are aliased keywords supported within a context?

I would say no, this makes things just more complex without bringing any advantage.

4) How is this processed during context processing/expansion/compaction

I think during context processing a separate keyword-mapping should be created.
In expansion we then would have a preprocessing step which checks if property is subject to keyword-mapping, if so, replace property with the keyword and continue processing (in case of collisions the values are merged).
In compaction I think we should have a similar preprocessing step which replaces a keyword with the shortest mapped term.

[gkellogg]

1. Yes, this is necessary when there are different coercion rules.
2. I believe not allowing alias of @context was because of the problem in ambiguity of a document if it is opened with an external context which defines an alias for @context or not. In any case, alias is there typically to support legacy JSON, where, say, an API commonly uses "id" as the identifier, and not just to give some syntactic sugar to JSON-LD developers. As @context implicitly points to a JSON-LD document (context), it really can't have a legacy meaning.
3. I would say no. We were close to resolving to not use alias expansion when processing a context, but the call ended early. I think this is a good idea, for similar reasons: it is a JSON-LD document, and there are no legacy considerations.
4. This is how expansion works, we check expansion based on the stated property, not the expanded property. Note that I recently updated the expansion terms to check expanded property when looking for specific matches against keywords for this very purpose. There's also a step at the end which performs merging. For compaction, the intention is that the closest term is chosen, which could mean that multiple values are split into different properties, based on coercion rules for defined terms.

[lanthaler]

So, are you saying we don't support @context aliasing or that it makes no sense but we don't restrict it? I think there's no reason to restrict it and introduce a special case.

Regarding 4): You are right, there were just a few minor things missing. I added those in 3d9f652.

[gkellogg]

We currently don't support @context aliasing, and I don't see a reason to start now. Note that the same arguments could be made about use of @type in the context of @value, @value, @set, @list and @language. If aliasing is intended to be applied to existing JSON, or JSON which conforms to a different (but compatible) semantic, then the object form of values we've introduced really can't apply. Not a proposal, just an observation.

[dlongley]

1. Can multiple aliases exist for a keyword?

The processors I've written don't currently support this but I don't remember a specific reason not to (other than I didn't think we intended to support it). I think I'm ok with changing this if we want to.

2. Why is aliasing of @context disallowed?

I agree with Gregg but am open to a good argument either way.

3. Are aliased keywords supported within a context?

No, let's not support that. The processors I work on support this, but I'm happy to remove it.

4. How is this processed during context processing/expansion/compaction

The code I've written currently keeps track of keyword mappings and uses aliases when compacting and replaces them when expanding. Expansion always removes aliasing and compaction puts it back -- but I haven't had to deal with multiple aliases yet as I mentioned before. I imagine this will mean we'll have to make some kind of shortest then lexicographically least choice to resolve conflicts.

[lanthaler]

I agree with what Gregg says but see no reason to introduce a special case just for @context since it would work out-of-the box without any changes to the algorithms. If we don't support it, we have to add a specific check to dissallow it.

Note that the same arguments could be made about use of @type in the context of @value, @value, @set, @list and @language. If aliasing is intended to be applied to existing JSON, or JSON which conforms to a different (but compatible) semantic, then the object form of values we've introduced really can't apply. Not a proposal, just an observation.

If you see it that way, the whole feature is hmm... questionable. The only thing that you could reasonably expect to be in existing JSON are IRIs and even there mostly just as references to other documents and not as subject identifiers. But don't lets move in that direction as you can also use it to make prettier JSON-LD - whatever that means. I think Niklas uses it a lot.

[lanthaler]

RESOLVED: JSON-LD supports multiple aliases for a JSON-LD keyword.

RESOLVED: Re-affirm that the aliasing of @context is disallowed due to algorithmic complexity/ambiguity and lack of a compelling use case.

RESOLVED: A @context is processed without regard to keyword aliases. Keyword aliases are taken into account when processing the body of a JSON-LD document.

The group notes that the processing rules for compaction, expansion and framing are not affected by the previous 3 decisions.