15:50:50 <RRSAgent> RRSAgent has joined #json-ld
15:50:50 <RRSAgent> logging to https://www.w3.org/2019/04/26-json-ld-irc
15:50:51 <ivan> rrsagent, set log public
15:50:51 <ivan> Meeting: JSON-LD Working Group Telco
15:50:51 <ivan> Chair: azaroth
15:50:51 <ivan> Date: 2019-04-26
15:50:51 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Apr/0038.html
15:50:51 <ivan> ivan has changed the topic to: Meeting Agenda 2019-04-26: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Apr/0038.html
15:51:15 <ajs6f> ajs6f has joined #json-ld
15:51:23 <simonstey> present+
15:51:38 <azaroth> azaroth has joined #json-ld
15:53:40 <azaroth> present+
15:53:44 <ivan> present+
15:54:03 <pchampin> pchampin has joined #json-ld
15:54:53 <rubensworks> rubensworks has joined #json-ld
15:59:42 <timCole> timCole has joined #json-ld
16:00:24 <bigbluehat> present+
16:00:27 <rubensworks> present+
16:00:40 <pchampin> present+
16:00:44 <dlongley> present+
16:00:54 <timCole> present+
16:01:01 <azaroth> zakim, pick a victim
16:01:01 <Zakim> Not knowing who is chairing or who scribed recently, I propose simonstey
16:01:45 <gkellogg> present+
16:02:19 <azaroth> TOPIC: Approve minutes of previous call
16:02:25 <bigbluehat> scribenick: bigbluehat
16:02:30 <azaroth> PROPOSAL: Approve minutes of previous call  https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-04-19-json-ld
16:02:33 <azaroth> +1
16:02:34 <bigbluehat> +1
16:02:36 <dlongley> +1
16:02:37 <rubensworks> +1
16:02:37 <ivan> +1
16:02:40 <gkellogg> +1
16:02:40 <pchampin> +0
16:02:45 <timCole> +1
16:02:51 <simonstey> scribe: simonstey
16:02:52 <azaroth> RESOLVED: Approve minutes of previous call  https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-04-19-json-ld
16:02:57 <bigbluehat> scribenick: simonstey
16:03:02 <azaroth> TOPIC: Announcements / Reminders
16:03:15 <workergnome> workergnome has joined #json-ld
16:03:18 <bigbluehat> q+
16:03:21 <ivan> q+
16:03:22 <simonstey> azaroth: any announcements/reminders?
16:03:23 <azaroth> ack bigbluehat
16:03:41 <simonstey> bigbluehat: fyi, Ivan and I will be at the publishing WG f2f in a couple of days
16:03:55 <simonstey> ... json-ld is talking a rather important role there
16:04:19 <dlehn> present+
16:04:21 <azaroth> ack ivan
16:04:26 <simonstey> ... would be helpful to have some review/comments on their work
16:05:00 <simonstey> ivan: from now on, the minutes I'll create will have schema.org mark up in it too
16:05:03 <workergnome> present+
16:05:10 <azaroth> q?
16:05:54 <azaroth> TOPIC: Scoping of 1.1 issues
16:06:20 <simonstey> ivan: we will have to mark up the issues properly
16:06:55 <simonstey> ... at the end of the day we have to report what we plan to do
16:07:21 <simonstey> azaroth: now that we are at the point of deciding what issues to tackle and what not
16:07:36 <simonstey> ... I'm fine with changing the label
16:08:05 <azaroth> link: https://github.com/w3c/json-ld-framing/issues/38
16:08:10 <simonstey> azaroth: we have 3 issues in syntax, 1 in api and 2 in framing currently labelled as deferred
16:08:17 <ivan> Subtopic: several frames in the same document
16:09:01 <simonstey> azaroth: are we still agreeing that we don't do this particular issue in the scope of the current wg?
16:09:25 <azaroth> q?
16:09:39 <simonstey> gkellogg: SPARQL 1.2 CG discusses framing in the context of construct queries
16:09:50 <simonstey> ... I'm fine with deferring
16:10:04 <azaroth> PROPOSAL: Defer framing #38 until future WG
16:10:10 <ivan> +1
16:10:11 <azaroth> +1
16:10:11 <dlongley> +1
16:10:13 <timCole> +1
16:10:13 <bigbluehat> +1
16:10:15 <gkellogg> +1
16:10:16 <simonstey> +1
16:10:16 <rubensworks> +1
16:10:17 <workergnome> +1
16:10:18 <pchampin> +1
16:10:22 <azaroth> RESOLVED: Defer framing #38 until future WG
16:10:42 <ivan> Subtopic: class-scoped framing
16:11:08 <ivan> link: https://github.com/w3c/json-ld-framing/issues/29
16:11:34 <simonstey> azaroth: idea is that framing starts with a tree, but if you don't know where a class starts in a tree then things get complicated
16:11:46 <simonstey> ... likely would require multiple frames within a frame document
16:11:49 <bigbluehat> +1
16:11:52 <workergnome> +1
16:11:53 <azaroth> PROPOSAL: Defer framing #29 until future WG
16:11:55 <ivan> +1
16:11:55 <dlongley> +1
16:11:55 <workergnome> +1
16:11:55 <rubensworks> +1
16:11:56 <gkellogg> +1
16:11:56 <azaroth> +1
16:11:57 <pchampin> +1
16:11:58 <dlehn> +1
16:11:59 <timCole> +1
16:12:00 <simonstey> +1
16:12:04 <azaroth> RESOLVED: Defer framing #29 until future WG
16:12:20 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/108
16:12:26 <ivan> Subtopic: context by reference with metadata
16:12:43 <simonstey> azaroth: metadata specified in a document without context
16:13:11 <simonstey> ... this has been asked for and discussed (as it has some privacy/security implications)
16:13:14 <ivan> q+
16:13:21 <azaroth> ack ivan
16:13:41 <simonstey> ... we need to have a good answer for not doing it, if we do so
16:13:54 <simonstey> ivan: the example given in the issue is now outdated
16:14:11 <simonstey> ... is there any other example that would require this? (other than the SRI one)
16:14:37 <simonstey> azaroth: I don't.. other than comment, description, etc.
16:14:52 <workergnome> q+
16:15:06 <simonstey> gkellogg: by providing metadata one might not to have to download a context
16:15:30 <azaroth> ack workergnome
16:15:56 <simonstey> ... just verify that the remote context hasn't changed
16:16:01 <ivan> q+
16:16:29 <simonstey> workergnome: the other thing we talked about was finding documentation about contexts
16:16:35 <azaroth> ack ivan
16:17:04 <dlongley> q+
16:17:04 <simonstey> ivan: back to the various URI schemes, if we use that argument then some people might raise some eyebrows
16:17:29 <simonstey> ... as most of those schemes are more or less experimental
16:17:54 <simonstey> ... it would require fundamentally new syntax to be able to handle those
16:17:56 <azaroth> ack dlongley
16:18:28 <simonstey> dlongley: I think we can refer to other work that's going on in that space
16:18:34 <azaroth> +1 that this would be a bigger change than a .1 ; and to refer abstractly to other work
16:18:51 <simonstey> ... not necessarily say one has to use them
16:19:00 <ajs6f> present+
16:19:44 <azaroth> PROPOSAL: Defer syntax #108 to future WG, too large a syntactic change for 1.1, refer in HR to other ongoing work
16:19:47 <gkellogg> +1
16:19:48 <rubensworks> +1
16:19:49 <azaroth> +1
16:19:54 <timCole> +1
16:19:56 <bigbluehat> +1
16:19:57 <dlongley> +1
16:19:57 <ivan> +1
16:20:00 <simonstey> +1
16:20:06 <simonstey> subtopic: Can SRI be used in JSON-LD and for which use cases?
16:20:13 <azaroth> RESOLVED: Defer syntax #108 to future WG, too large a syntactic change for 1.1, refer in HR to other ongoing work
16:20:27 <ivan> https://github.com/w3c/json-ld-syntax/issues/86
16:20:28 <dlehn> +1
16:20:32 <simonstey> azaroth: answer is no
16:21:08 <ajs6f> +1
16:21:11 <simonstey> ivan: I propose this issue can simply be closed by referring to the previous issue
16:21:26 <azaroth> PROPOSAL: Close syntax #86, as being dependent on deferred #108, and duplicates only use case for it
16:21:28 <gkellogg> +1
16:21:29 <bigbluehat> +1
16:21:30 <azaroth> +1
16:21:31 <rubensworks> +1
16:21:31 <simonstey> +1
16:21:32 <timCole> +1
16:21:32 <pchampin> +1
16:21:32 <dlongley> +1
16:21:38 <workergnome> +1
16:21:44 <azaroth> RESOLVED: Close syntax #86, as being dependent on deferred #108, and duplicates only use case for it
16:21:44 <ivan> +1
16:21:44 <dlehn> +1
16:21:56 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/128
16:22:01 <ivan> Subtopic: riG graphs in JSON-LD
16:22:06 <simonstey> subtopic: TriG graphs in JSON-LD
16:23:32 <simonstey> [ivan contemplating about issue 128]
16:24:20 <simonstey> ivan: there was some activity on this issue in february
16:24:59 <simonstey> ... there is a comment on it from pchampin providing a solution and asking whether that's valid
16:25:07 <gkellogg> q+
16:25:08 <simonstey> ... idk though
16:25:12 <azaroth> ack gkellogg
16:25:28 <simonstey> gkellogg: I think I had an action on looking into interaction with nest/container stuff
16:25:50 <simonstey> ivan: then let's leave it open for now
16:25:55 <azaroth> PROPOSAL: Leave #128 open until we can determine the effects of @container / @nest
16:26:05 <rubensworks> +1
16:26:06 <azaroth> +1
16:26:08 <simonstey> ... we def. need a dedicated section on graphs/trig etc. in the bpr document
16:26:08 <pchampin> +1
16:26:09 <gkellogg> +1
16:26:10 <timCole> +1
16:26:10 <simonstey> +1
16:26:11 <ivan> +1
16:26:15 <dlongley> +0
16:26:43 <ajs6f> +1
16:26:45 <azaroth> RESOLVED: Leave #128 open until we can determine the effects of @container / @nest
16:26:46 <workergnome> +1
16:26:49 <ivan> Subtopic: Streaming Profiles for JSON-LD to/from RDF
16:26:50 <dlehn> +1
16:27:00 <azaroth> link: https://github.com/w3c/json-ld-api/issues/5
16:27:18 <simonstey> azaroth: this came from the community group
16:27:25 <ivan> q+
16:27:28 <azaroth> ack ivan
16:27:35 <gkellogg> q+
16:27:37 <simonstey> ivan: what does profile means?
16:27:41 <azaroth> ack gkellogg
16:27:47 <simonstey> s/means/mean
16:28:13 <rubensworks> q+
16:28:45 <simonstey> gkellogg: I reckon in the sense of serializing json-ld in a way that it's easier for stream processors to deal with it
16:29:09 <simonstey> ... or how would you create json-ld from a stream
16:29:37 <azaroth> ack rubensworks
16:29:37 <simonstey> ... the best thing we can do is to provide requirements that should be followed
16:30:12 <simonstey> ivan: so not like profiles in the http context
16:30:28 <simonstey> rubensworks: basically like gkellogg described
16:31:02 <simonstey> ... I'm more than happy to summarize this in the best pract. document
16:31:09 <gkellogg> q+
16:31:12 <azaroth> ack gkellogg
16:31:45 <simonstey> +q
16:32:11 <azaroth> ack simonstey
16:32:20 <dlongley> +1 to doing this is best practices
16:32:27 <dlongley> s/is/in/
16:32:34 <azaroth> q?
16:32:44 <gkellogg> q+
16:33:14 <dlongley> simonstey: I don't think it should be normative. You can do what you want. But it's perfectly fine for a best practices document and should be in there, giving guidelines on this.
16:33:17 <ivan> q+
16:33:21 <ivan> ack gkellogg
16:33:32 <azaroth> ack ivan
16:33:48 <azaroth> q?
16:34:12 <simonstey> gkellogg: the one thing I'm not sure whether we can move to a bp document is something that allows one to require stream data (?)
16:34:32 <ivan> q+
16:34:51 <timCole> q+
16:34:52 <dlongley> q?
16:34:57 <azaroth> ack ivan
16:35:11 <simonstey> ivan: I would propose to leave it to best pract.
16:35:19 <azaroth> ack timCole
16:36:21 <ajs6f> q+
16:36:28 <azaroth> ack ajs6f
16:36:30 <simonstey> timCole: I'm a little concerned that by not following gkellogg's suggestions people will create json-ld that cannot be used properly by a streaming processor
16:36:53 <simonstey> ajs6f: we frequently get questions about streaming json-ld
16:37:25 <bigbluehat> q+
16:37:35 <simonstey> ... I second the concern timCole raised
16:37:44 <ivan> q+
16:38:15 <azaroth> ack bigbluehat
16:38:24 <bigbluehat> https://github.com/w3c/json-ld-bp/issues/3
16:38:46 <simonstey> bigbluehat: a lot of the stuff I'm reading there is about key ordering
16:39:18 <simonstey> ... one potential option could be not to require ordering
16:39:29 <simonstey> ... but processors outputting a preferred ordering
16:39:52 <gkellogg> q+
16:40:08 <azaroth> ack ivan
16:40:58 <azaroth> q?
16:41:02 <azaroth> ack gkellogg
16:41:18 <simonstey> ivan: I hear bigbluehat's argument which is perfectly valid, and maybe a feature version of json-ld will have key ordering
16:41:39 <pchampin> s/feature/future/
16:42:38 <azaroth> +1  - unordered keys are ordered by necessity of a serialization
16:42:56 <simonstey> gkellogg: serialization vs. data model wrt. ordering
16:43:07 <azaroth> q?
16:43:08 <ivan> q+
16:43:10 <azaroth> ack ivan
16:43:37 <timCole> + to @ivan since it will provide experience to inform normalization
16:43:40 <azaroth> q?
16:43:42 <simonstey> ivan: I repeat what I just said, getting into a normative thing in that area is probably premature
16:43:53 <simonstey> ... or too much work
16:44:09 <bigbluehat> q+
16:44:12 <azaroth> ack bigbluehat
16:44:20 <simonstey> azaroth: what's the happy middle ground? key ordering for streaming?
16:44:38 <simonstey> bigbluehat: I would like to get as much as possible into the best pract. document
16:44:49 <rubensworks> q+
16:44:52 <azaroth> ack rubensworks
16:45:07 <simonstey> rubensworks: scoped contexts shouldnt be an issue
16:45:11 <azaroth> q?
16:45:15 <simonstey> ... as long as they are the first object
16:45:40 <azaroth> PROPOSAL: Describe preferred key ordering for serialization over the wire to enable streaming parsers as a best practice
16:45:43 <gkellogg> +1
16:45:45 <ajs6f> +1
16:45:46 <azaroth> +1
16:45:46 <ivan> +1
16:45:48 <dlongley> +1
16:45:48 <bigbluehat> +1
16:45:49 <simonstey> +1
16:45:50 <dlehn> +1
16:45:53 <rubensworks> +1
16:45:58 <gkellogg> Scoped contexts might require that `@type` come after `@id`
16:45:59 <pchampin> +1
16:46:03 <timCole> +1 as long as leave defer for future
16:46:17 <azaroth> RESOLVED: Describe preferred key ordering for serialization over the wire to enable streaming parsers as a best practice
16:46:20 <workergnome> +1
16:46:46 <simonstey> azaroth: move the issue to the bp repo
16:47:14 <simonstey> gkellogg: if you have a pointer on how to move an issue, I would be interested
16:47:43 <azaroth> q?
16:48:06 <simonstey> ivan: top right corner, but maybe only visible to owners
16:48:22 <azaroth> TOPIC Issue: context response as HTML
16:48:24 <azaroth> link: https://github.com/w3c/json-ld-api/issues/66
16:48:51 <simonstey> azaroth: what happens if you deref. a context and you ge back HTML
16:49:05 <simonstey> ... currently it's an error
16:49:20 <gkellogg> q+
16:49:35 <simonstey> ... however we opened the door of dealing with HTML within json-ld
16:49:45 <azaroth> ack gkellogg
16:49:50 <simonstey> ... is it justified though?
16:50:13 <simonstey> gkellogg: we did look to this as part of our solution on how to document json-ld
16:50:35 <azaroth> q+ to agree re documentation, and that content negotiation is a thing that processors already do
16:50:43 <simonstey> ... I created an example as part of one of the pull requests
16:51:00 <simonstey> ... what does this mean in terms of processing
16:51:23 <simonstey> ... you get HTML turn that into JSON and pass that to the processor
16:51:41 <simonstey> ... where that didnt work was with contexts
16:51:45 <ivan> q+
16:52:30 <azaroth> ack azaroth
16:52:30 <Zakim> azaroth, you wanted to agree re documentation, and that content negotiation is a thing that processors already do
16:52:42 <simonstey> ... related to webidle section of the api spec that discusses framing (?)
16:52:54 <workergnome_> workergnome_ has joined #json-ld
16:53:26 <bigbluehat> q+
16:53:29 <simonstey> azaroth: having a context that selfdocuments with HTML seems like a potential benefit
16:53:44 <ivan> q-
16:53:47 <azaroth> q?
16:53:49 <azaroth> ack bigbluehat
16:54:08 <simonstey> ... if you don't want to have HTML then just use content negotiation to request json only
16:54:10 <ivan> q+
16:55:27 <simonstey> bigbluehat: web of things/credentials/etc. more than likely won't ship with dom parsers
16:55:46 <azaroth> ack ivan
16:55:55 <simonstey> ... if there's a way of making html parsing more modular
16:55:56 <gkellogg> q+
16:56:17 <simonstey> ... or at least not making it a requirement, would be preferred
16:56:20 <rubensworks> q+
16:56:35 <dlongley> +1 to everything bigbluehat just said
16:57:21 <simonstey> ivan: if I don't care about the implementation, and that I can use json-ld with HTML
16:57:42 <azaroth> q?
16:57:55 <azaroth> ack gkellogg
16:58:20 <bigbluehat> q+
16:58:20 <rubensworks> q-
16:58:20 <simonstey> ... user's might be confused when they can actually use json-ld+html
16:58:49 <azaroth> ack bigbluehat
17:00:28 <simonstey> bigbluehat: if there's any req. that a context stays the same (e.g. for hashing or what not) than you would properly not want to have it in HTML
17:01:24 <simonstey> ... verifiable claims would properly freak out if they have to include a dom parser too
17:01:50 <gkellogg> q+
17:01:50 <simonstey> ... if there's a way to achieve this in the api spec, then +1!
17:01:54 <azaroth> ack gkellogg
17:02:02 <dlongley> perhaps we can have a conformance class around document loaders and push everything that way -- and say that you have to use a document loader that understands JSON-LD in HTML if you want to support that
17:02:29 <dlongley> and then we don't need two specs, just more conformance classes around document loaders
17:02:32 <dlongley> (maybe)
17:02:36 <simonstey> gkellogg: wondering whether we can actually pull the HTML part out into an own spec, or define a profile for it
17:03:44 <ivan> rrsagent, draft minutes
17:03:44 <RRSAgent> I have made the request to generate https://www.w3.org/2019/04/26-json-ld-minutes.html ivan
17:03:44 <ivan> zakim, bye
17:03:44 <ivan> rrsagent, bye
17:03:44 <RRSAgent> I see no action items
17:03:44 <Zakim> leaving.  As of this point the attendees have been simonstey, azaroth, ivan, bigbluehat, rubensworks, pchampin, dlongley, timCole, gkellogg, dlehn, workergnome, ajs6f
17:03:44 <Zakim> Zakim has left #json-ld