15:27:19 <RRSAgent> RRSAgent has joined #json-ld
15:27:19 <RRSAgent> logging to https://www.w3.org/2019/08/02-json-ld-irc
15:27:20 <ivan> rrsagent, set log public
15:27:20 <ivan> Meeting: JSON-LD Working Group Telco
15:27:20 <ivan> Date: 2019-08-02
15:27:20 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Aug/0000.html
15:27:20 <ivan> ivan has changed the topic to: Meeting Agenda 2019-08-02: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Aug/0000.html
15:27:21 <ivan> Regrets+ azaroth, workergnome, dlongley, hsolbrig, simonstey
15:27:21 <ivan> Chair: bigbluehat
15:35:34 <rubensworks> rubensworks has joined #json-ld
15:41:58 <gkellogg> gkellogg has joined #json-ld
15:53:49 <ajs6f> ajs6f has joined #json-ld
15:56:29 <ivan> present+
15:57:47 <gkellogg> gkellogg has joined #json-ld
15:59:51 <rubensworks> present+
16:00:08 <ivan> present+ ajs6f
16:00:33 <timCole> timCole has joined #json-ld
16:00:52 <gkellogg> present+
16:01:03 <timCole> present+
16:01:12 <ajs6f_> ajs6f_ has joined #json-ld
16:01:14 <bigbluehat> present+
16:03:46 <ajs6f_> present+
16:04:19 <bigbluehat> Topic: Scribe Selection
16:04:38 <ivan> scribe+ rubensworks
16:04:52 <bigbluehat> Topic: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-07-26-json-ld
16:05:25 <bigbluehat> PROPOSE: minutes look awesome
16:05:26 <bigbluehat> +1
16:05:27 <timCole> +1
16:05:28 <rubensworks> +0
16:05:30 <gkellogg> +1
16:05:35 <ajs6f_> +1
16:05:38 <bigbluehat> RESOLVED: minutes look awesome
16:06:24 <bigbluehat> Topic: Announcements / Reminders
16:06:31 <bigbluehat> Subtopic: Standing TPAC reminder
16:06:48 <rubensworks> bigbluehat: We are going to get together in Japan next month.
16:07:05 <ivan> q+
16:07:08 <rubensworks> bigbluehat: Make sure to book your room as they are getting full. Registration prices are going up sept 1st.
16:07:12 <bigbluehat> ack ivan
16:07:22 <ivan> -> https://docs.google.com/document/d/1P8ao0YPBPEqKF1bn9eSxsqovF_F__6AYHAqEWzbDbLA/edit draft agenda
16:07:49 <rubensworks> ivan: I made a page for an agenda draft.
16:08:34 <rubensworks> bigbluehat: How many of us will be there? 6?
16:09:16 <rubensworks> ivan: Registration list shows 3 people: Sebastien, Gregg and myself
16:09:37 <rubensworks> ivan: We have nine observers.
16:09:48 <ivan> -> https://www.w3.org/register/tpac2019/registrants#meeting-85 registration list
16:10:44 <rubensworks> bigbluehat: TPAC is good for interfacing with other groups using JSON-LD, such as verifiable credentials.
16:11:34 <bigbluehat> Subtopic: DID WG Charter
16:11:51 <bigbluehat> https://www.w3.org/2019/08/did-wg-charter.html
16:11:59 <rubensworks> ivan: Vote on DID if you are a member.
16:12:33 <rubensworks> ivan: I will handle F2F for that in Japan.
16:12:53 <bigbluehat> Topic: Issues
16:13:02 <bigbluehat> Subtopic: Indexing with `@includes`
16:13:24 <rubensworks> bigbluehat: We made good progress on this last week.
16:13:32 <bigbluehat> s/`@includes`/`@included`
16:13:38 <rubensworks> gkellogg: It is `@included` now.
16:13:56 <bigbluehat> https://jsonapi.org/
16:13:58 <rubensworks> gkellogg: `@included` comes from the JSON.API spec, and we are adopting this.
16:14:27 <rubensworks> gkellogg: Right now it's just a container for collecting node objects that don't have a direct rel with the node in which they are contained.
16:14:31 <ivan> -> https://github.com/w3c/json-ld-syntax/pull/208 issue PR
16:15:04 <ivan> -> https://github.com/w3c/json-ld-syntax/issues/19 issue itself
16:15:06 <rubensworks> gkellogg: There's been some exchange on the issue highlighting a bush-like use for included.
16:15:57 <rubensworks> gkellogg: In JSON-LD 1.0 the top-level graph is used to collect nodes is a corner case. Everywhere else where graphs are used are seen as named graph.
16:16:04 <rubensworks> gkellogg: Included doesn't carry that bagage.
16:16:31 <rubensworks> gkellogg: So `@included` can be used in favor of `@graph` in these places.
16:16:59 <bigbluehat> q+
16:17:02 <bigbluehat> ack bigbluehat
16:17:08 <rubensworks> gkellogg: In 1.0, you can't have a graph name being a property of another node. With `@included` you can.
16:17:39 <rubensworks> gkellogg: We can't use `@graph` to define a default graph.
16:17:51 <rubensworks> gkellogg: Except when it is the only property in a top-level object.
16:18:14 <rubensworks> bigbluehat: How does the actual inclusion take place?
16:18:54 <rubensworks> gkellogg: The shape is similar to JSON.API. The value is seen as an array of node objects. If you have a node that is a value of a prop....
16:19:53 <ivan> q+
16:20:23 <rubensworks> gkellogg: Needed in jsonapi for node references that are not included in the main document as references, but should be included aside.
16:20:42 <rubensworks> gkellogg: Included blocks can be nested, and will be flattened out when done.
16:20:57 <rubensworks> gkellogg: You won't compact back to included blocks after flattening.
16:21:14 <rubensworks> gkellogg: You can use included in a frame and have it match on diff subjects.
16:21:44 <rubensworks> gkellogg: The name `@included` is out of sync with other keywords.
16:21:54 <rubensworks> gkellogg: Dave suggested `@include`
16:22:01 <rubensworks> gkellogg: Just like jsonapi
16:22:04 <bigbluehat> ack ivan
16:22:18 <rubensworks> ivan: It's becoming bikeshedding
16:22:56 <rubensworks> ivan: I would go further than what you did. Ex 1.1.1 and 1.1.2 (bushes) should be removed.
16:23:09 <rubensworks> ivan: We should convince people to not use those forms anymore.
16:23:20 <gkellogg> https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/208.html#example-111-using-graph-to-explicitly-express-the-default-graph
16:23:58 <rubensworks> gkellogg: By removing these we won't lose anything. We would have to remove everything after the note.
16:24:16 <gkellogg> https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/208.html#example-103-simple-data-with-several-top-level-nodes
16:25:15 <rubensworks> gkellogg: Also, we may want to reverse example 103 and 104. To clarify writing bushes.
16:25:34 <rubensworks> ivan: Referring to `@graph` is misleading, as it has not been explained yet there.
16:25:48 <rubensworks> gkellogg: We may want to change an example in the `@graph` section then.
16:25:55 <bigbluehat> q+ to ask about flattened representation
16:26:05 <rubensworks> gkellogg: We can also just leave that out and use it in the best practises document.
16:26:06 <bigbluehat> ack bigbluehat
16:26:06 <Zakim> bigbluehat, you wanted to ask about flattened representation
16:26:07 <rubensworks> ivan: Yes
16:26:51 <rubensworks> bigbluehat: Flattened representation will still contain `@graph`, so readers will have to know what it does.
16:27:14 <rubensworks> bigbluehat: This plumbing shift is significant.
16:27:43 <gkellogg> q+
16:27:43 <rubensworks> bigbluehat: This is going to cause issues for the json people that are operating on the flattened form.
16:28:33 <bigbluehat> ack gkellogg
16:28:40 <bigbluehat> q+ to ask about the actual inclusion bit
16:28:41 <rubensworks> gkellogg: If you flatten with a context, it would introduce a graph to contain it. This would change the shape dramatically.
16:28:57 <rubensworks> gkellogg: Same with framing. In 1.1 we don't use an `@graph` at the top level if not needed.
16:29:08 <rubensworks> gkellogg: We could change the algo to use included instead.
16:29:25 <rubensworks> gkellogg: But we may not want to do that.
16:29:47 <ivan> q+
16:29:50 <rubensworks> gkellogg: So do we want to replace the main usage of `@graph` to `@included`.
16:29:57 <bigbluehat> ack bigbluehat
16:29:57 <Zakim> bigbluehat, you wanted to ask about the actual inclusion bit
16:30:02 <rubensworks> s/\./?/
16:32:27 <rubensworks> gkellogg: Included allows embedded nodes to go to one place. Like in jsonapi, they don't want to include referenced things inline, but only a reference to an included block.
16:33:03 <rubensworks> bigbluehat: Useful for reducing payload size. And only including referenced things once.
16:33:11 <rubensworks> bigbluehat: These are just IRI references?
16:34:14 <bigbluehat> ack ivan
16:34:24 <rubensworks> gkellogg: There is no magic going on.
16:34:34 <bigbluehat> q+ to ask about the API layer--which is where I'd wondered about the "magic" ;)
16:34:48 <rubensworks> ivan: In JSON-LD it used to be hard to do these indexed references.
16:35:01 <rubensworks> ivan: The bush features can now be expressed in two different ways.
16:35:06 <rubensworks> ivan: These things happen.
16:35:14 <rubensworks> ivan: It's a matter of taste which one you prefer.
16:35:24 <rubensworks> ivan: I personally always hated graph for representing bushes.
16:35:36 <rubensworks> ivan: I like this new included representation for bushes.
16:36:54 <rubensworks> ivan: I don't want to hide the fact that bushes can be described with included instead of the graph 'hack'.
16:37:23 <rubensworks> gkellogg: We can say that included can also be used without other props in node object for describing node objects without semantic relationship.
16:37:28 <rubensworks> ivan: I'm fine with that.
16:37:31 <bigbluehat> ack bigbluehat
16:37:31 <Zakim> bigbluehat, you wanted to ask about the API layer--which is where I'd wondered about the "magic" ;)
16:37:42 <bigbluehat> https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/208.html#included-blocks-to-be-flattened
16:38:08 <rubensworks> bigbluehat: If `@included` were `@graph`, this would make a named graph?
16:38:18 <rubensworks> gkellogg: I think this would make one or two named graphs.
16:38:29 <rubensworks> bigbluehat: With included it won't make named graphs.
16:38:35 <rubensworks> gkellogg: Yes, just objects.
16:38:52 <rubensworks> bigbluehat: I see the value, but not keen on the new keyword.
16:39:15 <rubensworks> bigbluehat: I think we need to explain these next to each other, with their nuances.
16:39:34 <rubensworks> bigbluehat: The initial reason for this feature was not meant to displace graph.
16:39:52 <rubensworks> bigbluehat: It was meant to bring in other referenced objects in the document.
16:40:55 <ivan> regrets+ pchampin
16:41:16 <rubensworks> gkellogg: What jsonld always had was the ability to reference node
16:41:34 <rubensworks> ... by defining @id or @vocab you can define that thing.
16:41:46 <rubensworks> ... our mission is to use json in the wild where this is a pattern of usage
16:41:52 <bigbluehat> q+ to ask if we can use a JSON API + `@context` example in the spec
16:42:07 <rubensworks> bigbluehat: You said exactly what I was typing.
16:42:25 <rubensworks> ... it would be good to use an example from jsonapi
16:42:39 <rubensworks> gkellogg: jsonapi examples are quite long, with a lot of nesting
16:42:47 <rubensworks> ... we have a test case from jsonapi
16:43:01 <rubensworks> ... may be too long for here. But may be good for best practises document.
16:43:02 <ivan> q+
16:43:09 <ivan> ack bigbluehat
16:43:09 <Zakim> bigbluehat, you wanted to ask if we can use a JSON API + `@context` example in the spec
16:43:09 <bigbluehat> ack bigbluehat
16:43:11 <rubensworks> ... It would overly complicated the spec to include here.
16:43:56 <rubensworks> bigbluehat: This solves the jsonapi case by aliasing `included` to `@included`.
16:44:07 <rubensworks> gkellogg: Yes, you can have multiple properties that have multiple aliases.
16:44:23 <rubensworks> ... included can be a nested object
16:44:29 <bigbluehat> ack ivan
16:44:51 <rubensworks> ivan: Can we talk about things that go to the primer?
16:45:19 <rubensworks> gkellogg: What to do with example?
16:46:01 <rubensworks> ivan: Switch the order of problem of Rob. In the primer we will have to spend more words on the fact that there are different things that can be used to do the same thing.
16:46:08 <rubensworks> ivan: We must have a primer.
16:46:16 <rubensworks> ivan: The current doc is already huge.
16:46:33 <rubensworks> bigbluehat: We need distinction in the main spec explaining diff between included and graph
16:46:51 <rubensworks> ivan: To be honest, at this level there is no real diff between the examples.
16:46:58 <rubensworks> ... this is a side-effect with included.
16:47:05 <rubensworks> ... we should not fiddle around with that
16:47:40 <rubensworks> bigbluehat: The graph foundation exists in flattened output, and this won't go away.
16:47:46 <rubensworks> ... this needs clarification
16:48:08 <rubensworks> gkellogg: The use of included on its own is a by-product of the feature.
16:48:17 <rubensworks> ... it does not need its own description in the spec
16:48:25 <rubensworks> ... There are use cases where that can be useful
16:48:32 <rubensworks> ... That better lies in a non-normative text.
16:48:44 <rubensworks> bigbluehat: The bush usage would go to the primer
16:48:54 <rubensworks> ... focus of the text would go back to inter-document referencing.
16:49:13 <rubensworks> ivan: We are falling back to other extreme that I don't agree with
16:49:24 <rubensworks> ... we are hiding a feature of included
16:49:28 <bigbluehat> q+
16:49:45 <rubensworks> ... In the inclusion part we should mention the alternative representation of bushes.
16:49:54 <rubensworks> ... because current graph-based bushes are a hack
16:50:07 <bigbluehat> ack bigbluehat
16:50:12 <rubensworks> ... It has been around for a while, but we still should mention it.
16:50:25 <rubensworks> bigbluehat: This is an accidental feature since recently.
16:50:38 <rubensworks> ... it is essential to flattened output. I don't see it as a hack.
16:50:50 <rubensworks> ... For non-turtle/trig users.
16:51:02 <rubensworks> ivan: For semweb folks you don't care it is a hack.
16:51:06 <rubensworks> ... we get into taste issues
16:51:31 <rubensworks> ivan: I don't want to hide it.
16:52:09 <bigbluehat> PROPOSAL: focus `@included` text and example on original inclusion use case; mention value of it as an `@graph` replacement for bushes--and reference primer for further reading
16:52:25 <ivan> +0.5
16:52:26 <gkellogg> +1
16:52:28 <bigbluehat> +1
16:52:28 <timCole> +1
16:52:30 <rubensworks> +1
16:52:53 <rubensworks> ivan: If we have a primer, a reference can be put into it in CR
16:53:23 <bigbluehat> RESOLVED: focus `@included` text and example on original inclusion use case; mention value of it as an `@graph` replacement for bushes--and reference primer for further reading
16:53:33 <rubensworks> ivan: include or included?
16:54:40 <rubensworks> bigbluehat: People may expect a URI to be included. But this is wrong.
16:54:55 <rubensworks> q+
16:55:01 <bigbluehat> ack rubensworks
16:55:03 <bigbluehat> scribe+ bigbluehat
16:55:10 <bigbluehat> rubensworks: what was the keyword in JSON API?
16:55:13 <bigbluehat> gkellogg: included
16:55:23 <bigbluehat> rubensworks: in that case, it might be helpful to be consistent with that
16:55:27 <timCole> +1 for @included
16:56:26 <bigbluehat> PROPOSAL: close issue #19 with merger of `@included` related PRs
16:56:31 <timCole> +1
16:56:32 <ivan> +1
16:56:32 <rubensworks> +1
16:56:33 <bigbluehat> +1
16:56:35 <gkellogg> +1
16:56:43 <bigbluehat> RESOLVED: close issue #19 with merger of `@included` related PRs
16:56:51 <bigbluehat> Subtopic: Confirm state of `@import` usage
16:57:19 <rubensworks> bigbluehat: Request by Rob to state to ourselves to not quickly add more features to `@import`.
16:57:24 <ivan> +1
16:57:38 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/108
16:57:38 <rubensworks> ... This import issue is closable, as it is in the spec
16:57:55 <gkellogg> +1
16:58:05 <rubensworks> gkellogg: This also puts the nail in for SRI?
16:58:07 <rubensworks> bigbluehat: Yes
16:58:27 <rubensworks> bigbluehat: We would defer and close the SRI issue
16:58:59 <bigbluehat> PROPOSAL: close 108 with statement that potentially related SRI issues will be closed as differed
16:59:03 <ivan> +1
16:59:05 <rubensworks> gkellogg: Can we close the issue on trig graphs?
16:59:07 <rubensworks> +1
16:59:08 <bigbluehat> +1
16:59:10 <timCole> +1
16:59:10 <gkellogg> +1
16:59:52 <bigbluehat> RESOLVED: close 108 with statement that potentially related SRI issues will be closed as differed
16:59:59 <ivan> Propose: close 128
17:00:08 <timCole> +1
17:00:10 <rubensworks> +1
17:00:11 <ivan> +1
17:00:15 <bigbluehat> +1
17:00:16 <gkellogg> +1
17:00:20 <ivan> Resolved: close 128
17:01:09 <ivan> rrsagent, draft minutes
17:01:09 <RRSAgent> I have made the request to generate https://www.w3.org/2019/08/02-json-ld-minutes.html ivan
17:01:09 <ivan> zakim, bye
17:01:09 <ivan> rrsagent, bye
17:01:09 <RRSAgent> I see no action items
17:01:09 <Zakim> leaving.  As of this point the attendees have been ivan, rubensworks, ajs6f, gkellogg, timCole, bigbluehat, ajs6f_
17:01:09 <Zakim> Zakim has left #json-ld