16:15:48 <RRSAgent> RRSAgent has joined #json-ld
16:15:48 <RRSAgent> logging to https://www.w3.org/2020/03/06-json-ld-irc
16:15:50 <Zakim> RRSAgent, make logs Public
16:15:51 <Zakim> please title this meeting ("meeting: ..."), ivan
16:16:05 <ivan> ivan has changed the topic to: Meeting Agenda 2020-03-06: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Mar/0005.html
16:16:17 <ivan> Date: 2020-03-06
16:16:17 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Mar/0005.html
16:16:17 <ivan> Chair: azaroth
16:16:19 <ivan> Meeting: JSON-LD Working Group Telco
16:16:21 <ivan> Regrets+ pchampin
16:17:16 <dlongley> regrets+
16:42:50 <rubensworks> rubensworks has joined #json-ld
16:50:10 <azaroth> azaroth has joined #json-ld
16:50:34 <azaroth> present+
16:50:42 <azaroth> regrets+ pchampin
16:50:48 <azaroth> regrets+ bigbluehat
16:56:27 <mpuckett> mpuckett has joined #json-ld
17:00:28 <gkellogg> gkellogg has joined #json-ld
17:00:46 <gkellogg> present+
17:00:54 <rubensworks> present+
17:02:49 <ivan> present+
17:03:46 <hsolbrig_> hsolbrig_ has joined #json-ld
17:03:49 <hsolbrig_> present+
17:04:07 <gkellogg> scribe+
17:04:31 <azaroth> TOPIC: Announcements / Reminders
17:04:31 <gkellogg> topic: Announcements
17:04:50 <gkellogg> ivan: The new CRs were published yesterday.
17:04:58 <dlehn> present+
17:05:19 <timCole> timCole has joined #json-ld
17:05:27 <gkellogg> azaroth: CR2 was published yesterday, thanks to pchampin, gkellogg and ivan for making it happen. There was some manual work involved.
17:05:32 <timCole> present+
17:05:38 <azaroth> SUBTOPIC: Daylight Savings
17:06:36 <gkellogg> azaroth: The US goes onty Daylight Savings Time on Sunday, but not in other parts of the world. So, if you’re not in the US, plan to come on an hour earlier.
17:07:19 <gkellogg> … We’ll hightlight that in agendas.
17:07:33 <azaroth> TOPIC: Issues
17:07:46 <azaroth> SUBTOPIC: Test Changes
17:08:20 <gkellogg> azaroth: There have been a few new issues in API and framing.
17:09:03 <azaroth> scribe+
17:09:24 <azaroth> gkellogg: There can be bugs in tests and we shouldn't consider those as normative changes, but instead typos
17:09:57 <azaroth> ... if the exception raised should be different based on what is the spec, and there's a bug in the test based on implementations, then that's just fixing a bug
17:10:02 <azaroth> ... there are two outstanding PRs
17:10:14 <azaroth> https://github.com/w3c/json-ld-api/issues
17:11:15 <azaroth> gkellogg: Tests are from HTML -- should be load document failed rather than an invalid element
17:11:27 <azaroth> ... so nothing changed from success to fail or vice versa, just a different exception was thrown
17:11:45 <azaroth> ... and in compact pr02, the test looks to verify that we raise an error when a protected term is changed
17:12:07 <azaroth> ... and the test wasn't sufficiently different to have a change that was picked up, so it makes more changes
17:12:25 <azaroth> dlehn: It caught things before, but we changed the spec elsewhere and didn't change the test
17:12:28 <azaroth> gkellogg: Right
17:13:14 <azaroth> ... the other PR is 405, related to issue 403. A change to the algorithm where we had a typo of result for nest result. Clear from the surrounding text, but a minor change to the algorithm
17:13:35 <ivan> i/manual work involved/scribe+ azaroth/
17:13:44 <azaroth> azaroth: Do we know who `@roptat` is and what they're doing? :)
17:13:57 <azaroth> gkellogg: Nope :)
17:14:28 <azaroth> dlehn: Doing a guile  implementation
17:14:50 <azaroth> https://www.gnu.org/software/guile/
17:14:53 <gkellogg> dlehn: Guile is a free Scheme implementation that’s been around for a while.
17:15:09 <azaroth> q?
17:16:02 <azaroth> gkellogg: Commenter agreed, so that's probably good enough to merge
17:17:40 <azaroth> SUBTOPIC: Prefixes
17:17:41 <azaroth> https://github.com/w3c/json-ld-syntax/issues/329
17:18:07 <ivan> regrets+ bigbluehat
17:18:19 <gkellogg> hsolbrig_: I put in a -1 as there is quite a bit of work the community will need to do to get around the issue, and they’re not anxioius to do it.
17:18:39 <gkellogg> … Its not that it won’t be fixed, but that we may need to wait a while.
17:18:42 <gkellogg> q+
17:19:03 <azaroth> ack gkellogg
17:19:07 <gkellogg> … One of the members went over previous 1.0 releases to find out where they were bit.
17:21:06 <gkellogg> hsolbrig_: I hate being obnoxious about this, but I find myself representing this group, and discovering that we can’t use what’s there today. It was flaws in our own codebase which hid this.
17:21:08 <azaroth> gkellogg: Need to stop adding things in order to have a release, but shouldn't stop all work and the new process should let us move more swiftly
17:21:37 <gkellogg> … Of all the proposed changes, the prefix wrapper or the prefix: true would solve the issue.
17:22:01 <gkellogg> … Or, if we could just add “_” to the list of gendelims that would go a long way towards helping.
17:22:19 <gkellogg> … I’ll need to go back to see how strongly the group feels.
17:22:49 <gkellogg> azaroth:  I don’t believe we can just add “_” to gendelim, as it would mean changing the algorithm and tests, which is what we determined to be the criteria for normative changes.
17:23:21 <gkellogg> hsolbrig_: That’s unfortunate. The only other thing I can think about is if we can get the library authors to put in a non-standard workaround.
17:23:43 <gkellogg> … Otherwise, we’re putting out a spec that has so much promise but could be unusable by this community.
17:24:29 <gkellogg> ivan: I think it’s another CR; it may change implementations that have already passed all the tests. It’s a changing feature, even if it is minor, but formally it is changing an existing feature.
17:24:47 <gkellogg> … The previous changes were addressing bugs.
17:25:13 <gkellogg> azaroth: This is an intended consequence that the community is asking us to walk back, or to give them more control in managing prefixes.
17:25:46 <gkellogg> … One concern I have about adding “_”, is that while a lot of systems use camel-case, a number also use snake_case.
17:26:12 <gkellogg> … This would lead to exactly the same problem we were trying to fix.
17:26:46 <gkellogg> hsolbrig_: Unfortunately, the fix in 1.1 is to have the ability to say I intend to be a prefix, and the syntax requires major structural edits.
17:27:19 <gkellogg> … I understand the issue, but I need to consider further and discuss with the community.
17:27:34 <ivan> q+
17:27:42 <gkellogg> … That might be a way to convince them.
17:27:43 <gkellogg> q+
17:27:45 <azaroth> ack ivan
17:28:40 <gkellogg> ivan: To discuss the possibilities, we have to realize that if we go back to a WD, we run some risk, as there is no guarantee that the AC will agree to an extension of the charter. It may not be high, but it’s non-zero.
17:29:11 <gkellogg> hsolbrig_: I’m split on the issue myself.
17:29:43 <gkellogg> … I’ll see if the number of libraries they use is limited enought that they can maintain forks.
17:29:55 <gkellogg> … How far out might it be before it can be addressed formally?
17:29:57 <dlehn> q+
17:30:34 <gkellogg> ivan: I would be hopeful that the process changes can be done relatively quickley; not 2 years.
17:31:10 <gkellogg> … The processes update is ongoing, and we’d need to have a discussion on turning the group into a maintanance group which could do such a change in 1-2 months.
17:31:28 <gkellogg> … Such a change would be backwards-compatibile, so it would make it easier to do.
17:31:56 <gkellogg> … It means that JSON-LD becomes a kind of continuously evolving standard, similar to HTML5.
17:32:19 <gkellogg> … They added an element to HTML5 fairly smoothly.
17:32:42 <gkellogg> hsolbrig_: I’m going to say that I don’t want to stop things, so I’m willing to revise my vote.
17:33:00 <gkellogg> ivan: -1 is not a-priori a formal objection.
17:33:50 <gkellogg> … At some point in time the new process will go to the AC for a vote, and there may be people that won’t do that. So any AC members here might want to speak up about that.
17:34:03 <azaroth> ack gkellogg
17:34:16 <ivan> s/quickley/quickly/
17:34:33 <azaroth> gkellogg: The CG might make a parallel extension to the spec
17:34:46 <azaroth> ... prior to this group there was interest in updating towards a 1.1
17:35:04 <azaroth> ... maybe something could be done there to hang your hat on that describes extensions to the spec
17:35:14 <azaroth> ... might be obsolete if the process changes
17:35:15 <azaroth> q+
17:35:52 <gkellogg> hsolbrig_: There’s enought new stuff in 1.1 that it’s sparking new ideas, and the CG might be a good way to incubate these types of changes.
17:35:55 <azaroth> ack dlehn
17:36:37 <gkellogg> dlehn: I’m pretty sure that people implementing it are happy to put in new features, even if it’s not in 1.1. I’m worried about people starting to use proposed features that don’t survive.
17:37:17 <gkellogg> hsolbrig_: The workaround right now is very minimal. We just added a “prefix” option defaulting to false, but if it’s true allows any term to be used as a prefix.
17:38:00 <gkellogg> … The huge cost would be to change the resources themselves.
17:38:12 <gkellogg> dlehn: Adding flags might hurt interoperability.
17:38:48 <gkellogg> … Even if we don’t do this in 1.1, it would be good to agree on a direction.
17:39:02 <azaroth> ack azaroth
17:39:08 <gkellogg> https://github.com/json-ld/json-ld.org/issues
17:39:36 <gkellogg> azaroth: It would be valuable if there were more people than just hsolbrig_; if more people could join the CG and we can have a discussion in public.
17:39:50 <gkellogg> hsolbrig_: There are several people raving on email that might join.
17:40:24 <gkellogg> azaroth: One of the easiest ways to justify the new process is to be able to point to a discussion that shows why its important to be able to move quickly to support the community.
17:40:50 <gkellogg> … This would be good to convince the AC that we should move to such a process.
17:41:17 <gkellogg> hsolbrig_: These people are interested in learning more about the process. Getting them engaged can help.
17:41:22 <gkellogg> q?
17:41:54 <gkellogg> azaroth: I think one of your proponents is at Lawrence Berkeley labs, who are W3C members.
17:42:29 <azaroth> q?
17:42:58 <azaroth> TOPIC: Best Practices
17:43:17 <azaroth> https://github.com/w3c/json-ld-bp/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc
17:43:30 <gkellogg> q+
17:43:36 <azaroth> ack gkellogg
17:44:17 <hsolbrig_> q+
17:44:34 <azaroth> ack hsolbrig_
17:44:46 <azaroth> gkellogg: Is there a document for changes in 1.1?
17:44:47 <gkellogg> azaroth: I don’t think there’s a document for what’s new in 1.1, but it would be valuable.
17:45:19 <azaroth> q?
17:45:20 <gkellogg> hsolbrig_: A cheat-sheet would be really useful too. A one page synopsis of things that you can do, and how to do it.
17:46:42 <azaroth> SUBTOPIC: Streaming
17:46:43 <azaroth> https://github.com/w3c/json-ld-streaming/pull/1
17:47:13 <gkellogg> azaroth: rubensworks has done some work on the Streaming document recently. Where is that?
17:47:32 <azaroth> https://pr-preview.s3.amazonaws.com/rubensworks/json-ld-streaming/pull/1.html
17:47:57 <gkellogg> rubensworks: At the moment, the document changes a new “streaming document form” where the order is important.
17:48:22 <gkellogg> .. In 2.3, a new profile is introduced, similar to other profiles for expanded and compacted.
17:48:59 <gkellogg> … Section 3 describes the best order for receiving triples for a serializer to effectifly create a document.
17:49:14 <gkellogg> Section 4 disucsses some tactics for processors.
17:49:47 <gkellogg> azaroth: There’s a lot of good stuff in there.
17:50:43 <azaroth> gkellogg: One comment ... should an object always have an @id ... what if you don't see one first?
17:50:53 <azaroth> ... if you don't see one first, then infer it's a blank node
17:51:19 <azaroth> ... my question is if it should always be present, so you're less subjected to out of order keys
17:51:36 <azaroth> ... if it appears in the  wrong place, then you would have already emitted the triples
17:51:55 <azaroth> ... is it okay if something is wrong to emit the bad data
17:52:16 <azaroth> ... don't think there's any other key that really has that effect
17:52:33 <azaroth> q+ to ask re type scope context note
17:53:05 <rubensworks> https://pr-preview.s3.amazonaws.com/rubensworks/json-ld-streaming/pull/1.html#streaming-deserialization
17:53:37 <gkellogg> rubensworks: The motivation was to allow streaming processors to buffer, in that case I mention that if a processor detects an out of order key it may through an error.
17:53:46 <azaroth> q+ dlehn
17:53:55 <azaroth> ack azaroth
17:53:55 <Zakim> azaroth, you wanted to ask re type scope context note
17:54:54 <gkellogg> azaroth: You note that `@type` should come before `@id` where the value indicates a type-scoped context. That seems relevant, but you will already of encountered property-scoped contexts.
17:55:13 <gkellogg> … It seems like a valuable observation that we might want to make more obvious.
17:55:32 <gkellogg> … I usually see the order `@context, @id, @type`, but this would be different.
17:55:48 <gkellogg> … Is the `@type` coming before `@id` important?
17:56:07 <gkellogg> rubensworks: I would say it’s important, as it can influence what `@id` is treated.
17:56:16 <azaroth> q?
17:56:18 <azaroth> ack dlehn
17:56:26 <hsolbrig_> q+
17:56:51 <azaroth> q?
17:56:53 <azaroth> ack hsolbrig_
17:56:58 <gkellogg> dlehn: If you do see `@id` later, you could output a triple to say that the emitted blank node was equivalent to the `@id`.
17:57:41 <gkellogg> rubensworks: I want to note that the processing is not entirely the same way my implementation works. In my case, if I don’t see `@id`, it will buffer. But that makes things a bit more complicated.
17:57:58 <gkellogg> … If you can do it without buffering the implementaiton will be simpler.
17:58:19 <gkellogg> hsolbrig_: We make statements about things not being ordered, even though they’re not.
17:59:06 <azaroth> gkellogg: there's two effects of ordering -- json objects aren't ordered, but in a serialization they are. So if some processes are to work, such as streaming, then they would need  to be
17:59:24 <azaroth> ... and secondly lists aren't ordered (unless `@list`)
17:59:53 <azaroth> ... if the backing store doesn't preserve order of unordered arrays, then the tests need to be for  unordered sets
18:00:06 <azaroth> ... reasonable for keeping object properties ordered for this to work
18:00:11 <azaroth> q?
18:01:05 <azaroth> gkellogg: should decide what to do in this case
18:01:27 <gkellogg> rubensworks: Perhaps section 4.1 we can add something about buffering rather than throughing an error.
18:02:36 <gkellogg> ACTION: gkellogg to raise issue on exception/buffer in streaming.
18:03:22 <gkellogg> azaroth: I’ll be traveling next week, but I think bigbluehat is available, so there should be a meeting next week.
18:03:28 <ivan> zakim, end meeting
18:03:28 <Zakim> As of this point the attendees have been azaroth, gkellogg, rubensworks, ivan, hsolbrig_, dlehn, timCole
18:03:30 <Zakim> RRSAgent, please draft minutes
18:03:30 <RRSAgent> I have made the request to generate https://www.w3.org/2020/03/06-json-ld-minutes.html Zakim
18:03:30 <gkellogg> … Also reminder on DST.
18:03:33 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
18:03:37 <Zakim> Zakim has left #json-ld
18:04:32 <ivan> rrsagent, bye
18:04:32 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2020/03/06-json-ld-actions.rdf :
18:04:32 <RRSAgent> ACTION: gkellogg to raise issue on exception/buffer in streaming. [1]
18:04:32 <RRSAgent>   recorded in https://www.w3.org/2020/03/06-json-ld-irc#T18-02-36