More compact @prefix #76
Labels
defer-future-version
Defer this issue until a future version of JSON-LD
Comments
|
See PR #77 for more. |
|
PROPOSAL: If Note that this adds additional complexity to processing as we would now have a new class of term that has no To be clear, this would be different from treating |
|
@pchampin -- Does the above sound like what we meant on the call? |
So this would mean that if 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) |
Yes.
And yes. +1 |
|
@dlongley yes, that's how I understand the outcome of our discussion. |
|
This issue was discussed in a meeting.
View the transcriptMore compact @PrefixBenjamin 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 |
Closed
|
This may be mixing topics, but another potential |
|
This issue was discussed in a meeting.
View the transcript2019-06-07-action2: test if@prefix: false without @id works as expected (Pierre-Antoine Champin) #87Benjamin 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 waysPierre-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 @prefixPierre-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 wereAdam Soroka: .. getting this right with @prefix would be challengingPierre-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 = trueGregg 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 |
gkellogg
added
defer-future-version
|
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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently,
@prefixhas 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,
@prefixwill 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.
The text was updated successfully, but these errors were encountered: