15:12:53 <RRSAgent> RRSAgent has joined #json-ld
15:12:53 <RRSAgent> logging to https://www.w3.org/2019/06/14-json-ld-irc
15:12:54 <ivan> rrsagent, set log public
15:12:54 <ivan> Meeting: JSON-LD Working Group Telco
15:12:54 <ivan> Chair: azaroth
15:12:54 <ivan> Date: 2019-06-14
15:12:54 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jun/0012.html
15:12:54 <ivan> ivan has changed the topic to: Meeting Agenda 2019-06-14: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jun/0012.html
15:12:55 <ivan> Regrets+ azaroth
15:56:03 <pchampin> pchampin has joined #json-ld
15:58:58 <ajs6f> ajs6f has joined #json-ld
15:59:45 <ivan> present+
15:59:58 <pchampin> present+
16:00:02 <bigbluehat> present+
16:00:56 <timCole> timCole has joined #json-ld
16:01:07 <gkellogg> present+
16:01:40 <dlongley> present+
16:01:42 <workergnome> workergnome has joined #json-ld
16:02:13 <timCole> present+
16:02:23 <workergnome> present+
16:02:42 <ajs6f> present+
16:03:55 <ajs6f> scribenick: ajs6f
16:04:12 <bigbluehat> Topic: Approve minutes of previous call:  https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-06-07-json-ld
16:04:18 <bigbluehat> +1
16:04:22 <gkellogg> +0
16:04:24 <timCole> +1
16:04:28 <ajs6f> +1
16:04:30 <pchampin> +1
16:04:33 <dlongley> +0
16:04:33 <ivan> +1
16:04:38 <bigbluehat> Resolved: minutes approved.
16:04:50 <bigbluehat> Topic: Announcements / Reminders
16:04:58 <bigbluehat> Subtopic: TPAC registration is open https://www.w3.org/2019/09/TPAC/ Early bird pricing ends June 21
16:05:42 <ajs6f> some discussion of who is likely to attend TPAC
16:05:53 <ajs6f> bigbluehat: tickets are cheaper earlier
16:05:58 <bigbluehat> Subtopic: Horizontal Reviews
16:06:02 <ajs6f> topic: horizontal review
16:06:13 <bigbluehat> https://github.com/w3c/json-ld-wg/issues
16:06:34 <ajs6f> bigbluehat: not all those issues are labelled as horizontal review
16:06:43 <ajs6f> ... but we will fix that
16:07:06 <ajs6f> ... there're i8n, accessibility, privacy, WoT, VC
16:07:57 <ajs6f> ivan: these are two different kinds of things: i8n, accessibility, privacy, and secutiry
16:08:01 <ajs6f> ... are required review
16:08:18 <ajs6f> ... WoT and VC are major constituencies.
16:08:40 <ajs6f> bigbluehat: if anyone has interests in these things, please volunteer
16:09:12 <ivan> q+
16:09:16 <bigbluehat> ack ivan
16:09:37 <ajs6f> ivan: for security we must notify the folks who do that
16:09:55 <ajs6f> ... also for privacy, and for that we need one or two persons to join a PSIG meeting
16:10:32 <jeff_mixter> jeff_mixter has joined #json-ld
16:10:34 <ajs6f> ... for i8n and accessibility, I'm not quite sure, but we must contact IATA WG  for i8n
16:10:47 <ajs6f> ... we needn't decide today
16:10:55 <dlongley> s/i8n/i18n/
16:10:55 <bigbluehat> https://github.com/w3c/json-ld-wg/issues/88
16:11:04 <ajs6f> present+ jeff_mixter
16:11:18 <bigbluehat> https://github.com/w3c/json-ld-wg/issues/89
16:11:35 <ajs6f> ivan: these things are important-- they can stop us
16:11:55 <bigbluehat> our four horizontal review issues https://github.com/w3c/json-ld-wg/issues?q=is%3Aissue+is%3Aopen+label%3Ahorizontal-review
16:11:59 <ajs6f> ... we cannot go to PR without these things being settled
16:12:12 <ajs6f> ... but we should not be doing these things while we are in CR
16:12:12 <gkellogg> q+
16:12:30 <ajs6f> ... if we want to go to CR, that creates a deadline
16:12:49 <ajs6f> bigbluehat: so do we need this done before TPAC?
16:12:54 <ajs6f> ivan: well before
16:13:11 <ajs6f> bigbluehat: we need to submit to these groups to start it off
16:13:35 <ajs6f> ... let's say we need drafts of the required submisssions done before the 28th
16:13:41 <bigbluehat> ack gkellogg
16:13:50 <ajs6f> gkellogg: we need to assign responsibility for these things
16:14:23 <ajs6f> ... we ar looking for the impact of changes from 1.0->1.1 , not the complete review that was required for 1.0
16:14:41 <ajs6f> ivan: but we can have problems found in any layer of history
16:15:11 <ajs6f> bigbluehat: there are new fertile ground for review in our new features for security like @protected
16:15:34 <ajs6f> .... we should start sooner rather than later
16:15:45 <ajs6f> ... I'll leave these other two (which?) unassigned
16:16:23 <bigbluehat> s/(which?)/security and privacy
16:16:28 <bigbluehat> Topic: Issues
16:16:40 <bigbluehat> Subtopic: 2019-06-07-action2: test if `@prefix: false` without `@id` works as expected (Pierre-Antoine Champin) #87
16:16:59 <ajs6f> bigbluehat: next two issues are rleated
16:17:48 <ajs6f> pchampin: some background: it was possible to define certain URI schemes as prefixes
16:18:03 <ajs6f> ... leading to confusing them with the start of CURIs
16:18:12 <gkellogg> q+
16:18:13 <ajs6f> ...I tried to alter @prefix to avoid this
16:18:22 <ajs6f> ... but that turns out not to be possible
16:18:45 <ajs6f> .... so @prefix must be accompanied by @id
16:18:55 <bigbluehat> issue #87 https://github.com/w3c/json-ld-wg/issues/87
16:19:03 <ajs6f> ... even if you accept ruben's alteration, it is still not simple
16:19:06 <bigbluehat> born from #76 https://github.com/w3c/json-ld-api/issues/76
16:19:21 <ajs6f> ... @prefix is only used during compaction as a hint to the algo
16:19:30 <ajs6f> ... but never it is used in expansion
16:19:42 <ajs6f> ... to block interpretation as a CURI
16:19:54 <ivan> s/CURI/CURIE/
16:20:03 <bigbluehat> q?
16:20:07 <ajs6f> ... so doing this with @prefix would radically change the meaning of @prefix, to add an effect during expansio
16:20:12 <ivan> q+
16:20:25 <ajs6f> ... this thing will come back and bite other people than us
16:20:35 <ajs6f> .. users would expect @prefix to work both ways
16:20:45 <bigbluehat> ack gkellogg
16:20:46 <ajs6f> ... but that may have real effects on implementors
16:21:02 <ajs6f> gkellogg: yes, @prefixis only meaningful during compaction
16:21:13 <ajs6f> ... in 1.0 any prefix could be used
16:21:20 <ajs6f> ... so we made some changes
16:21:39 <ajs6f> ... including restrictions and a keyword @prefix to overcome them
16:21:58 <ajs6f> ... we do run into 1.0 compat issues here
16:22:06 <ajs6f> ... but this is something we just didn't complete
16:22:14 <ajs6f> ... it's not a major rewrite
16:23:31 <ajs6f> ... now we are forcing the use of expanded term defns for things that used to be simple prefixes
16:23:33 <dlongley> +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
16:23:41 <ajs6f> ... the imact isn't too bad on the algos
16:23:44 <bigbluehat> q?
16:24:14 <bigbluehat> ack ivan
16:24:16 <ivan> original-original https://github.com/w3c/json-ld-syntax/issues/177
16:24:18 <ajs6f> ... we did make changes to limit the use of prefixes during compaction, we should make the same changes for expansion
16:24:32 <ajs6f> ivan: I thikn this issue arose in a different ticket ^^^^
16:24:45 <ajs6f> ... I have said before that we shouldn't add too many things to the spec
16:24:51 <pchampin> q+
16:24:54 <ajs6f> ... do we really have to do anything about #177?
16:25:09 <ajs6f> ... does it occur significantly in 1.0 usage?
16:25:16 <ajs6f> ... do we need to spend two meetings on it?
16:25:27 <ajs6f> ... i don't think so. my feeling is that we should either close or defer
16:26:11 <ajs6f> ... we struggled whether this is really a secutiry issue
16:26:16 <ajs6f> ... it can be ackward
16:26:29 <ajs6f> ... in severl years it did not bite us
16:26:33 <gkellogg> q+ to argue for consistency
16:26:39 <ajs6f> bigbluehat: we haven't had @prefix very long eitehr!
16:26:49 <ajs6f> ivan: but it's not a matter of just @prefix
16:27:01 <bigbluehat> ack pchampin
16:27:13 <ajs6f> pchampin: I agree with ivan
16:27:21 <ajs6f> ... I'm not convinced that this is a security issue
16:27:36 <ajs6f> .... I'm not convinced that @prefix would be a good way to solve it if it were
16:27:44 <ajs6f> .. getting this right with @prefix would be challenging
16:27:49 <dlongley> q+ to talk about how it's probably not the right solution if we're considering it a security issue
16:28:10 <ajs6f> ... @prefix was introduced for other reasons
16:28:21 <ajs6f> ... the way we have it now is counterintuitive
16:28:30 <bigbluehat> ack gkellogg
16:28:30 <Zakim> gkellogg, you wanted to argue for consistency
16:28:40 <ajs6f> ... we were all talking last week about using it this way without even realizing we couldn't. that's not good!
16:29:04 <ajs6f> gkellogg: when we introduced the restrictions for prefixes, we overloooked expansion
16:29:10 <ajs6f> ... we left the job partly done
16:29:25 <ajs6f> ivan: we are adding features and making the spec more complicated
16:29:42 <ajs6f> gkellogg: is inconsistency complicated?
16:30:06 <bigbluehat> ack dlongley
16:30:06 <Zakim> dlongley, you wanted to talk about how it's probably not the right solution if we're considering it a security issue
16:30:07 <ajs6f> ivan: we are complicating the spec a few months before we try to get to CR
16:30:18 <ajs6f> dlongley: I sympathize with ivan
16:30:43 <ajs6f> ... if we consider this a secutiry issue, then @prefix is not how we should address it
16:31:08 <ajs6f> ... we could instead introduce a rule that you don't expand prefxes when @vocab = true
16:31:32 <ajs6f> gkellogg: I agree with dlongley; that would solve the problem but burn all the fields
16:31:43 <ajs6f> ivan: I propose that we defer one of the two
16:32:12 <ajs6f> gkellogg: I don't thinl we can roll back prefix
16:32:24 <ajs6f> ... it fixes actual errors in 1.0
16:32:28 <pchampin> q+
16:33:05 <bigbluehat> ack pchampin
16:33:40 <ajs6f> pchampin: I suggest we make no decision before the next agenda item
16:34:06 <ajs6f> gkellogg: I can do a speculative PR
16:34:28 <ajs6f> bigbluehat: let's go to the next issue, discuss, then come back to this
16:34:35 <bigbluehat> Subtopic: "Create term definition" algorithm expands schema part of an absolute IRI as if it is a compact IRI #96
16:34:39 <pchampin> https://github.com/w3c/json-ld-api/issues/104
16:34:54 <bigbluehat> Subtopic: compaction changes the meaning of absolute IRIs in some cases #104
16:34:56 <gkellogg> https://github.com/w3c/json-ld-api/issues/76
16:36:11 <ajs6f> pchampin: the problem: through compaction, I can end up with a different graph than I started with
16:36:18 <ajs6f> ... i thin kthis is a 1.0 problem as well
16:36:30 <ajs6f> .. there are examples in the issue that display the problem
16:36:51 <ajs6f> ... there is shown an IRI that is indistinguishable from an IRI.
16:36:59 <ajs6f> ... you can tell which it is only from contet
16:37:48 <ajs6f> gkellogg: there are other things that you can add to a context that would change the interpretation of things
16:39:09 <ajs6f> gkellogg: [gives example of similar phenomenon using lang tags]
16:40:01 <ajs6f> gkellogg: this goes right back the previous discussion
16:40:09 <ajs6f> ... you might want to say here that @prefix=false
16:40:24 <dlongley> +1 to `@prefix: false` to solve this
16:40:26 <ajs6f> ... which could impact the expansion algo to not use it in this case
16:40:35 <pchampin> { "http://ex.co/prop": "foo" }
16:40:38 <ajs6f> ... but that could still be surprising
16:40:52 <ajs6f> pchampin: consider my example above
16:41:07 <ajs6f> ... and compact it with a context that I just recited out loud
16:41:29 <ajs6f> gkellogg: there is no compaction w/o expansion
16:41:41 <ajs6f> ... but what is the contxt used for expansion?
16:42:05 <ajs6f> pchampin: okay, yeah. I didn't want to show expansion for brevity
16:42:45 <ajs6f> ... i can get this phenomeno using the same context for compaction and expansiobn
16:43:16 <ajs6f> dlongley: adding the context he verbalized, you can no lnger distinguish between the two uses of the term
16:43:31 <ajs6f> gkellogg: even with a mechanism to prevent that, mistakes will appear
16:43:47 <ajs6f> ... if this was one line in 10,000 triples
16:43:51 <bigbluehat> q?
16:43:52 <ajs6f> ... it might get missed
16:44:42 <ajs6f> pchampin: if I expand and compact with the same context, it should round-trip, right?
16:44:45 <ajs6f> gkellogg: yes
16:44:57 <ajs6f> ... but the semantics would change
16:45:41 <ajs6f> pchampin: if we had a way to say that something isn't a CURIE
16:45:45 <ajs6f> ... that would solve it
16:46:03 <ajs6f> .. compaction should protect certain IRIS
16:46:33 <ajs6f> ... when compaction sees a term macthing an IRI scheme, the problem can arise
16:46:47 <dlongley> q+ to poop on proposal 3
16:46:55 <ajs6f> ... I made three proposals, bt I prefer the third
16:47:42 <ajs6f> ... i don't like µsyntax, but...
16:48:04 <ajs6f> gkellogg: a 4th proposal is to use @prefix=false during expansio
16:48:40 <ajs6f> pchampin: I can't always move my data out of th way of this
16:49:45 <ajs6f> .... my contexts may be coming from someone else
16:50:03 <ajs6f> gkellogg: @prefix=false can prevent this problem. maybe not perfectly
16:50:18 <ajs6f> ... going back to the dawn of time, we had to make some choice because of JSON
16:50:30 <bigbluehat> ack dlongley
16:50:30 <Zakim> dlongley, you wanted to poop on proposal 3
16:50:39 <ajs6f> ... this may be a bubble we are pushing around,
16:51:03 <ajs6f> dlongley: I would formally oject to proposal 3; I hate µsyntaxes
16:51:20 <ajs6f> ... this might be a corner case we can't solve because of previoius deciusions, in the senes that
16:51:26 <gkellogg> +1 to dlongley
16:51:30 <ajs6f> ... there may be contexts you just can't use with your data
16:51:41 <ajs6f> ... I wish we had not done CURIEs at all
16:51:48 <ajs6f> ... it was probably a mistake
16:51:56 <ajs6f> ... they introduce surprise
16:52:09 <ajs6f> ... we may have to accept certain corner cases
16:52:29 <ajs6f> ... it might require some kind of processing mode change, it might be a 2.0 issue
16:52:49 <ajs6f> bigbluehat: we are wrangling a passle of issues
16:53:19 <ajs6f> ... gkellogg: do you still think we could make @prefix clearer
16:53:22 <dlongley> `@prefix: false` would solve this in *some cases*
16:53:30 <ajs6f> gkellogg: we already detect whether a term could be used as a prefix
16:53:51 <ajs6f> ... it's an addition of ½ a line
16:53:57 <ajs6f> ... it's a simple change
16:54:18 <ajs6f> ... it's gets more complicated when we bring in different modes
16:54:31 <ajs6f> ... but the easy play is to make it symettrical from compaction to expansion
16:54:40 <ajs6f> ... which would solve #104
16:54:56 <ajs6f> ... by offering a context author a way to avoid that problem
16:55:07 <ajs6f> ... it might solve #87 or #76
16:55:23 <ajs6f> bigbluehat: this merits an action at this point, not resolution
16:56:00 <bigbluehat> Action: gkellogg to write another proposed solution to #104 (which may also solve for #87 or perhaps #76)
16:56:25 <pchampin> q+
16:56:46 <bigbluehat> ack pchampin
16:57:07 <ajs6f> pchampin: i agree with this action, but I don't thikn it will solve #104
16:57:21 <ajs6f> ... where dlongely's position is my solution 1
16:57:34 <ajs6f> ... some contexts simply cannot work with some data
16:58:22 <ajs6f> ... if we cannot provide a solution, we should at least have an answer ready
16:58:51 <ajs6f> gkellogg: if you create the opportunity for this collision, we should raise a warning
16:58:54 <dlongley> it's an error
16:59:03 <dlongley> in my view
16:59:38 <ajs6f> pchampin: one could bring in a local context
16:59:42 <ajs6f> gkelllogg: bleh
17:00:37 <ivan> rrsagent, draft minutes
17:00:37 <RRSAgent> I have made the request to generate https://www.w3.org/2019/06/14-json-ld-minutes.html ivan