More compact @prefix

[rubensworks]

Currently, @prefix has boolean as range, and can be used as follows:

{
  "@context": {
    "@version": 1.1,
    "compact-iris": { "@id": "http://example.com/compact-iris-", "@prefix": true }
  },
}

In most cases, @prefix will probably be used together with @id.
For this reason, it might be beneficial to also allow the following as equivalent representation:

{
  "@context": {
    "@version": 1.1,
    "compact-iris": { "@prefix": "http://example.com/compact-iris-" }
  },
}

As far as I can see, this should not cause conflicts or major performance issues when processing.

[BigBlueHat]

See PR #77 for more.

[dlongley]

PROPOSAL: If @prefix is present in a term definition, and its value is a string, then the term may only be used as a prefix. Additionally, including @id in the same term definition is an error.

Note that this adds additional complexity to processing as we would now have a new class of term that has no @id. I'm not sure how complex it would be.

To be clear, this would be different from treating @prefix: <string> as just syntactic sugar for @id: <string>, @prefix: true as I believe was originally proposed in this issue. Instead, this syntax would be a way to define a prefix that cannot be used on its own as a term.

[dlongley]

@pchampin -- Does the above sound like what we meant on the call?

[rubensworks]

PROPOSAL: If @prefix is present in a term definition, and its value is a string, then the term may only be used as a prefix. Additionally, including @id in the same term definition is an error.

So this would mean that if @id and @prefix: true would be used, that the term can be used as both a prefix and a property, right?

This would only be useful for some exotic use cases, but indeed important for backwards-compatibility with 1.0 behaviour. (We may want to clarify that this kind of usage is discouraged)

[dlongley]

@rubensworks,

So this would mean that if @id and @prefix: true would be used, that the term can be used as both a prefix and a property, right?

Yes.

This would only be useful for some exotic use cases, but indeed important for backwards-compatibility with 1.0 behaviour. (We may want to clarify that this kind of usage is discouraged)

And yes. +1

[pchampin]

@dlongley yes, that's how I understand the outcome of our discussion.
and +1 as well to @rubensworks comment above.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: dlongley and pchampin to craft alternate proposal to #76 with @prefix having 3 values

View the transcript

More compact @Prefix
Benjamin Young: link: #76
Gregg Kellogg: related: #77
Benjamin Young: proposal from rubenworks, to make it simpler to declare @Prefix terms
Ruben Taelman: a similar thing is already possible with @reverse, so it should not be too hard to add in implementations
Dave Longley: is this an error?
… what do we do when @id and @Prefix are both strings and they disagree? is that an error?
… my understanding is that the proposal is that "@Prefix": `` is just syntactic magic for `"@id": ``, "@Prefix": true` … not a replacement
Gregg Kellogg: it is with @reverse, so it should be an error, yes
… there is a point in the issue about terms which are not appropriate as prefixes
… there are two aspects in the PR: 1/ use @Prefix where the value is an IRI, while the current practice is to use @id with an IRI, and @Prefix is a boolean. Should we obsolete the current practice?
… 2/ what if the value of @Prefix is a pname?
Ruben Taelman: [answers to gkellogg]
Gregg Kellogg: we must keep in mind the JSON 1.0 behavior
Ruben Taelman: I see this as an alternate representation
Ivan Herman: does the combination of @id and @Prefix:false come up in practice?
Gregg Kellogg: there are reasons to use it. I don’t know if it is used in the wild?
Ivan Herman: that would be a reason to keep the current practice, and consider the new version as a shorthand
… and I wouldn’t be shocked if the new notation @Prefix:IRI was roundtripped to @id+@Prefix:true
Gregg Kellogg: we don’t roundtrip contexts anyway
Benjamin Young: there seems to be a consensus on considering the proposal as a shorthand for the current syntax
Benjamin Young: https://w3c.github.io/json-ld-syntax/#compact-iris (for current text)
Gregg Kellogg: there are some implications; must be some working on the implications of combinations of @id and @Prefix
… you probably would not use the prefix term as a property
Dave Longley: perhaps if @Prefix is a string, then also including @id is an error … and then process @Prefix as a string first and do the transformation to @id: `, @Prefix: true`
Benjamin Young: https://w3c.github.io/json-ld-syntax/#example-32-using-explicit-prefix-declaration-to-create-compact-iris
Benjamin Young: @id+@Prefix:true feels a lot like using @vocab
Gregg Kellogg: it works a little differently in the compactIRI algo
… we are going contrary the trend of moving compact IRIs away
… the reason it is there is that, in 1.0, many terms were used to build compact IRIs, but were not intended to do that
… eg: Sport := schema:Sport, then using Sport:Event
… @Prefix was a way of capturing the intention of the creator of the term
Dave Longley: lots of unwanted CURIEs being greedily generated in 1.0
Benjamin Young: strange compact IRIs can be used maliciously, to misdirect users to an unexpected endpoint URL
Benjamin Young: w3c/json-ld-syntax#155
Dave Longley: I like the syntax, makes it more obvious that the term is intended to be used as a prefix
… even though I don’t like CURIEs in general
… in JSON-LD
… It was a mistake in 1.0 to allow any term to be used as a prefix
Benjamin Young: curie spec https://www.w3.org/TR/curie/
Benjamin Young: I agree with that
Pierre-Antoine Champin: Proposal is not to make @Prefix:false the default?
Dave Longley: No
Gregg Kellogg: we did change 1.0 behavior by limiting the terms that can be used as prefixes
… only IRIs ending with gen-delims can be used as prefixes
Dave Longley: instead of just “property”
Benjamin Young: gendelim https://tools.ietf.org/html/rfc3986#section-2.2
Ivan Herman: what does @Prefix:false means?
Ivan Herman: for the records: https://tinyurl.com/yxw7qv98 (example)
Gregg Kellogg: it means that we do not want this term to be used by compaction to generate a compact IRI
Gregg Kellogg: https://w3c.github.io/json-ld-syntax/#example-32-using-explicit-prefix-declaration-to-create-compact-iris
Gregg Kellogg: for expansion, it does not matter whether @Prefix is true or false
Dave Longley: if you click on compact in the link above
… by copying the context to the right and changing the value of @Prefix
… you can see the difference
… but you can’t make a term only a prefix, this is a 1.0 problem, we can’t go back
Gregg Kellogg: but we could define @Prefix:IRI to mean exactly that
… but we still mean @Prefix:false
Dave Longley: yes, but that would differ from what we said earlier. This is not syntactic sugar anymore
Pierre-Antoine Champin: another way would be add 3 values for @Prefix
Rob Sanderson: +1 to PA
Pierre-Antoine Champin: @default would say you can use this prefix as a term
… false as you can not use this as prefix
… true, the proposed new meaning that gregg proposed about @Prefix IRI
… this way we can keep backwards compatibility with 1.0
Proposed resolution: dlongley and pchampin to craft alternate proposal to #76 with @Prefix having 3 values (Benjamin Young)
Gregg Kellogg: +1
Adam Soroka: +1
Benjamin Young: +1
Ruben Taelman: +1
Ivan Herman: +1
Dave Longley: +1 sure
David I. Lehn: +1
Dave Longley: the third value would be an IRI, and we’re back to what gkellogg just proposed
Rob Sanderson: +1
Resolution #2: dlongley and pchampin to craft alternate proposal to #76 with @Prefix having 3 values

[davidlehn]

This may be mixing topics, but another potential @prefix feature would be to use it to limit the scope of prefixes to the current context. We've had the issue of wanting a local prefix alias within a context, but didn't want the prefix to leak out and pollute the outer scope namespace. One of many possible syntaxes for this would be a flag like "@prefix": "@context" which may need consideration while discussing string values of @prefix.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

2019-06-07-action2: test if @prefix: false without @id works as expected (Pierre-Antoine Champin) #87
Benjamin Young: issue #87 w3c/json-ld-wg#87
Benjamin Young: born from #76 #76
Ivan Herman: original-original: w3c/json-ld-syntax#177
Benjamin Young: next two issues are related
Pierre-Antoine Champin: some background: it was possible to define certain URI schemes as prefixes
… leading to confusing them with the start of CURIs
… I tried to alter @prefix to avoid this
… but that turns out not to be possible
… . so @prefix must be accompanied by @id
… even if you accept ruben’s alteration, it is still not simple
… @prefix is only used during compaction as a hint to the algo
… but never it is used in expansion
… to block interpretation as a CURI
… so doing this with @prefix would radically change the meaning of @prefix, to add an effect during expansion
… this thing will come back and bite other people than us
Adam Soroka: .. users would expect @prefix to work both ways
Pierre-Antoine Champin: but that may have real effects on implementors
Gregg Kellogg: yes, @prefixis only meaningful during compaction
… in 1.0 any prefix could be used
… so we made some changes
… including restrictions and a keyword @prefix to overcome them
… we do run into 1.0 compatibility issues here
… but this is something we just didn’t complete
… it’s not a major rewrite
… now we are forcing the use of expanded term defns for things that used to be simple prefixes
Dave Longley: +1 to what gregg is saying … it seems to mostly be restricted to very local change in IRI expansion where we need one extra flag check
Gregg Kellogg: the impact isn’t too bad on the algos
… we did make changes to limit the use of prefixes during compaction, we should make the same changes for expansion
Ivan Herman: I thikn this issue arose in a different ticket ^^^^
… I have said before that we shouldn’t add too many things to the spec
… do we really have to do anything about #177?
… does it occur significantly in 1.0 usage?
… do we need to spend two meetings on it?
… i don’t think so. my feeling is that we should either close or defer
… we struggled whether this is really a security issue
… it can be awkward
… in several years it did not bite us
Benjamin Young: we haven’t had @prefix very long either!
Ivan Herman: but it’s not a matter of just @prefix
Pierre-Antoine Champin: I agree with ivan
… I’m not convinced that this is a security issue
… . I’m not convinced that @prefix would be a good way to solve it if it were
Adam Soroka: .. getting this right with @prefix would be challenging
Pierre-Antoine Champin: @prefix was introduced for other reasons
… the way we have it now is counterintuitive
… we were all talking last week about using it this way without even realizing we couldn’t. that’s not good!
Gregg Kellogg: when we introduced the restrictions for prefixes, we overlooked expansion
… we left the job partly done
Ivan Herman: we are adding features and making the spec more complicated
Gregg Kellogg: is inconsistency complicated?
Ivan Herman: we are complicating the spec a few months before we try to get to CR
Dave Longley: I sympathize with ivan
… if we consider this a security issue, then @prefix is not how we should address it
… we could instead introduce a rule that you don’t expand prefixes when @vocab = true
Gregg Kellogg: I agree with dlongley; that would solve the problem but burn all the fields
Ivan Herman: I propose that we defer one of the two
Gregg Kellogg: I don’t think we can roll back prefix
… it fixes actual errors in 1.0
Pierre-Antoine Champin: I suggest we make no decision before the next agenda item
Gregg Kellogg: I can do a speculative PR
Benjamin Young: let’s go to the next issue, discuss, then come back to this

[niklasl]

If this is eventually revisited (POST 1.1 I presume), I strongly recommend that another form is considered:

{
  "@context": {
    "@prefix": {
        "dc": "http://purl.org/dc/terms/",
        "tag": "tag:example.org,2020:ns:",
        "compact-iris": "http://example.com/compact-iris-"
    }
  },
}

This should be the way to declare "prefix-only" prefixes, and keep them cleanly separated from regular term declarations (and the latter should never be considered as prefixes if a @prefix map is defined within the context).