Expansion concept "key's term definition" is unclear with compact IRI keys

[iridiankin]

My use case was to determine whether
{ "@context": { p: { "@id": "e:", "@container": "@list" } }, "p:1": ["", ""], "p:7891": ["dup", "dup"] }
would treat the p:1 and p:7891 as a @list (desired for my use case) or as a @set (undesired, but actual behavior of reference implementations; I have an open issue in jsonld.js for this as I wasn't sure what is correct).

My problem was that I wasn't able to conclude the correct behavior from the ld-json-api spec. I've now been informed that intent is @set, ie. expanded term definitions only use the @id when used in prefix expansion, so that's settled; this report is to explain why I wasn't able to reach the conclusion to maybe improve the spec itself.

The expansion algorithm 5.1.2 clauses 9.5 and 9.6 refer to "key's term definition" and "key's language mapping" without explicitly specifying the algorithm on how the key string is mapped to the term definition, only (apparently) relying on the simple implicit "key string is used as an exact match lookup against the context dictionary". This implicit meaning would suffice if it wasn't for prefixes and compact IRI's, which are justified as a way to simplify repeated term definitions via a generalized pattern.

So this could perhaps be made a bit more explicit, either on 9.5/9.6 or on sections that discuss compact IRI semantics.

As for my use case I can imagine that extending arbitrarily complex expanded term definitions to results of prefix expansions is not without consequences. So my personal ask is to figure out whether there exists

1. alternative way for me to be able declare JSON array members as rdf lists (providing ordering and duplicates) using @context, in a way that the key contains arbitrary specifiers (like 1 in p:1)? Maybe using the @Prefix notation or so.
2. potential plans to include this or similar functionality in future JSON-LD iteration? Within a year or two?

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Defer syntax#191 and api#94 as new features after feature freeze
• ACTION: post blog reference for feature freeze (Rob Sanderson)
• ACTION: add feature freeze note to the syntax, api, and framing READMEs and issue template for bugs only (Benjamin Young)

View the transcript

IRI expansion
Rob Sanderson: ref: w3c/json-ld-syntax#191
Rob Sanderson: essentially, what I took away from this issue is that what is wanted is a way to set defaults per prefix
… e.g., everything with x prefix, everything is a list
… since we declare intent to close to new features (after last published draft)
… so, can we defer this?
… or is it a bug we have to address
Benjamin Young: the use of this seems to want ad hoc terms mixed in with the prefix declaration
… the first example seems that way
… seems he could get same result with slightly more verbose (less confusing) instance
Adam Soroka: this reminds me of java server tags
… not clear that this is something json-ld was supposed to do.
… this seems to be about complex structures, almost transformative
… this is not the focus of json-ld. important to do, but not really our intent here
Ivan Herman: so what I understood from the issue is that this is not a bug, but really is a new feature
… so the answer should simply be that we defer because of the feature freeze and avoid discussing the details
Adam Soroka: should we send to CG
Ivan Herman: since we are not closing issue, we don’t need to send to CG
… the person submitting may want to do so.
Proposed resolution: Defer syntax#191 and api#94 as new features after feature freeze (Rob Sanderson)
David Newbury: +1
Rob Sanderson: will do same for issue in api
Ruben Taelman: +1
Benjamin Young: +1
Rob Sanderson: +1
Tim Cole: +1
Ivan Herman: +1
Adam Soroka: +1
Pierre-Antoine Champin: +1
Resolution #4: Defer syntax#191 and api#94 as new features after feature freeze
Action #3: post blog reference for feature freeze (Rob Sanderson)
Ivan Herman: please add to issue link to blog where we declared feature freeze
Rob Sanderson: can we add mention of feature freeze in repos readme
Action #4: add feature freeze note to the syntax, api, and framing READMEs and issue template for bugs only (Benjamin Young)

[azaroth42]

Per the related w3c/json-ld-syntax#191 (comment), this default per prefix would be a new feature after feature freeze and thus is deferred.