JSON-LD Working Group Telco — Minutes

Date: 2019-06-14

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Pierre-Antoine Champin, Benjamin Young, Gregg Kellogg, Dave Longley, Tim Cole, David Newbury, Adam Soroka, Jeff Mixter

Regrets: Rob Sanderson

Guests:

Chair: Benjamin Young

Scribe(s): Adam Soroka

Content:

1. Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-06-07-json-ld

Benjamin Young: +1

Gregg Kellogg: +0

Tim Cole: +1

Adam Soroka: +1

Pierre-Antoine Champin: +1

Dave Longley: +0

Ivan Herman: +1

Resolution #1: minutes approved.

2. Announcements / Reminders

2.1. TPAC registration is open https://www.w3.org/2019/09/TPAC/ Early bird pricing ends June 21

Adam Soroka: some discussion of who is likely to attend TPAC

Benjamin Young: tickets are cheaper earlier

2.2. Horizontal Reviews

Benjamin Young: https://github.com/w3c/json-ld-wg/issues

Benjamin Young: not all those issues are labelled as horizontal review
… but we will fix that
… there’re i8n, accessibility, privacy, WoT, VC

Ivan Herman: these are two different kinds of things: i8n, accessibility, privacy, and security
… are required review
… WoT and VC are major constituencies.

Benjamin Young: if anyone has interests in these things, please volunteer

Ivan Herman: for security we must notify the folks who do that
… also for privacy, and for that we need one or two persons to join a PSIG meeting
… for i8n and accessibility, I’m not quite sure, but we must contact APA WG for i18n
… we needn’t decide today

Benjamin Young: https://github.com/w3c/json-ld-wg/issues/88

Benjamin Young: https://github.com/w3c/json-ld-wg/issues/89

Ivan Herman: these things are important — they can stop us

Benjamin Young: our four horizontal review issues https://github.com/w3c/json-ld-wg/issues?q=is%3Aissue+is%3Aopen+label%3Ahorizontal-review

Ivan Herman: we cannot go to PR without these things being settled
… but we should not be doing these things while we are in CR
… if we want to go to CR, that creates a deadline

Benjamin Young: so do we need this done before TPAC?

Ivan Herman: well before

Benjamin Young: we need to submit to these groups to start it off
… let’s say we need drafts of the required submissions done before the 28th

Gregg Kellogg: we need to assign responsibility for these things
… we ar looking for the impact of changes from 1.0->1.1 , not the complete review that was required for 1.0

Ivan Herman: but we can have problems found in any layer of history

Benjamin Young: there are new fertile ground for review in our new features for security like @protected
… . we should start sooner rather than later
… I’ll leave these other two (security and privacy) unassigned

3. Issues

3.1. 2019-06-07-action2: test if @prefix: false without @id works as expected (Pierre-Antoine Champin) #87

Benjamin Young: issue #87 https://github.com/w3c/json-ld-wg/issues/87

Benjamin Young: born from #76 https://github.com/w3c/json-ld-api/issues/76

Ivan Herman: original-original: https://github.com/w3c/json-ld-syntax/issues/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

3.2. compaction changes the meaning of absolute IRIs in some cases #104

Gregg Kellogg: https://github.com/w3c/json-ld-api/issues/104

Pierre-Antoine Champin: the problem: through compaction, I can end up with a different graph than I started with
… i thin this is a 1.0 problem as well

Adam Soroka: .. there are examples in the issue that display the problem

Pierre-Antoine Champin: there is shown an IRI that is indistinguishable from an IRI.
… you can tell which it is only from context

Gregg Kellogg: there are other things that you can add to a context that would change the interpretation of things
… [gives example of similar phenomenon using lang tags]
… this goes right back the previous discussion
… you might want to say here that @prefix=false

Dave Longley: +1 to @prefix: false to solve this

Gregg Kellogg: which could impact the expansion algo to not use it in this case
… but that could still be surprising

Pierre-Antoine Champin: { "http://ex.co/prop": "foo" }

Pierre-Antoine Champin: consider my example above
… and compact it with a context that I just recited out loud

Gregg Kellogg: there is no compaction w/o expansion
… but what is the context used for expansion?

Pierre-Antoine Champin: okay, yeah. I didn’t want to show expansion for brevity
… i can get this phenomenon using the same context for compaction and expansion

Dave Longley: adding the context he verbalized, you can no longer distinguish between the two uses of the term

Gregg Kellogg: even with a mechanism to prevent that, mistakes will appear
… if this was one line in 10,000 triples
… it might get missed

Pierre-Antoine Champin: if I expand and compact with the same context, it should round-trip, right?

Gregg Kellogg: yes
… but the semantics would change

Pierre-Antoine Champin: if we had a way to say that something isn’t a CURIE
… that would solve it

Adam Soroka: .. compaction should protect certain IRIS

Pierre-Antoine Champin: when compaction sees a term matching an IRI scheme, the problem can arise
… I made three proposals, bt I prefer the third
… i don’t like µsyntax, but…

Gregg Kellogg: a 4th proposal is to use @prefix=false during expansion

Pierre-Antoine Champin: I can’t always move my data out of th way of this
… . my contexts may be coming from someone else

Gregg Kellogg: @prefix=false can prevent this problem. maybe not perfectly
… going back to the dawn of time, we had to make some choice because of JSON
… this may be a bubble we are pushing around,

Dave Longley: I would formally object to proposal 3; I hate µsyntaxes
… this might be a corner case we can’t solve because of previous decisions, in the sense that
… there may be contexts you just can’t use with your data
… I wish we had not done CURIEs at all
… it was probably a mistake
… they introduce surprise
… we may have to accept certain corner cases
… it might require some kind of processing mode change, it might be a 2.0 issue

Gregg Kellogg: +1 to dlongley

Benjamin Young: we are wrangling a pass the of issues
… gkellogg: do you still think we could make @prefix clearer?

Dave Longley: @prefix: false would solve this in some cases

Gregg Kellogg: we already detect whether a term could be used as a prefix
… it’s an addition of ½ a line
… it’s a simple change
… it’s gets more complicated when we bring in different modes
… but the easy play is to make it symmetrical from compaction to expansion
… which would solve #104
… by offering a context author a way to avoid that problem
… it might solve #87 or #76

Benjamin Young: this merits an action at this point, not resolution

Action #1: write another proposed solution to #104 (which may also solve for #87 or perhaps #76) (Gregg Kellogg)

Pierre-Antoine Champin: i agree with this action, but I don’t think it will solve #104
… where dlongely’s position is my solution 1
… some contexts simply cannot work with some data
… if we cannot provide a solution, we should at least have an answer ready

Gregg Kellogg: if you create the opportunity for this collision, we should raise a warning

Dave Longley: it’s an error

Dave Longley: in my view

Pierre-Antoine Champin: one could bring in a local context

gkelllogg: bleh

4. Resolutions

5. Action Items