15:50:09 <RRSAgent> RRSAgent has joined #json-ld
15:50:09 <RRSAgent> logging to https://www.w3.org/2019/07/12-json-ld-irc
15:50:14 <azaroth> rrsagent, set log public
15:50:26 <azaroth> Meeting: JSON-LD Working Group Telco
15:50:35 <azaroth> Date: 2019-07-12
15:51:03 <azaroth> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jul/0001.html
15:51:19 <azaroth> azaroth has changed the topic to: Agenda 2019-07-12: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jul/0001.html
15:51:31 <azaroth> regrets+ ivan
15:51:38 <azaroth> present+
15:51:42 <azaroth> zakim, this is JSON-LD
15:51:42 <Zakim> got it, azaroth
15:51:52 <azaroth> Chair: azaroth
15:52:27 <gkellogg> gkellogg has joined #json-ld
15:53:49 <rubensworks> rubensworks has joined #json-ld
15:54:05 <rubensworks> rubensworks has joined #json-ld
15:59:29 <bigbluehat> present+
15:59:35 <ajs6f> ajs6f has joined #json-ld
15:59:39 <rubensworks> present+
15:59:47 <ajs6f> present+
16:01:14 <gkellogg> present+
16:01:22 <dlongley> present+
16:01:51 <azaroth> TOPIC: scribe selection
16:02:20 <bigbluehat> scribe+ ajs6f
16:02:26 <bigbluehat> scribe+ pchampion
16:02:39 <azaroth> TOPIC: Approve minutes of previous call
16:02:47 <dlehn> present+
16:02:50 <azaroth> PROPOSAL: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-06-28-json-ld
16:02:52 <ajs6f> +1
16:02:55 <azaroth> +0 (not present)
16:03:01 <gkellogg> +1
16:03:14 <bigbluehat> +1
16:03:21 <gkellogg> scribe+ pchampin
16:03:24 <dlehn> +1
16:03:30 <dlongley> +1
16:03:31 <azaroth> RESOLVED: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-06-28-json-ld
16:03:34 <gkellogg> scribe- pchampion
16:03:37 <rubensworks> +1
16:03:43 <azaroth> TOPIC: Announcements / Reminders
16:03:54 <ajs6f> Standing TPAC reminder
16:04:12 <bigbluehat> q+
16:04:15 <azaroth> ack bigbluehat
16:04:32 <bigbluehat> https://adaptivecards.io/
16:04:41 <ajs6f> bigbluehat: talking with team at MS building ^^^^
16:04:52 <workergnome> workergnome has joined #json-ld
16:05:01 <workergnome> present+
16:05:21 <ajs6f> bigbluehat: they are wondering if JSON-LD can map into their tempalting space
16:05:48 <ajs6f> ... they are excited about what that might do to avoid being dependent on particular key names
16:05:58 <ajs6f> ... I'm going to follow up with them in a month
16:06:08 <ajs6f> .... JSON-LD evangelism is good!
16:06:30 <ajs6f> ... if there are people who need some contact I can help
16:06:42 <ajs6f> ... or let us know how your own efforts are going
16:07:07 <azaroth> TOPIC: Issues
16:07:23 <azaroth> SUBTOPIC: @source and @propagates
16:07:40 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/108
16:07:48 <azaroth> link:  https://github.com/w3c/json-ld-syntax/issues/174
16:07:54 <pchampin> pchampin has joined #json-ld
16:08:48 <bigbluehat> there's also a related API PR https://github.com/w3c/json-ld-api/pull/112
16:08:52 <pchampin> scribenick: pchampin
16:09:04 <pchampin> gkellogg: we should probabley have created a new issue
16:09:23 <rubensworks> s/probabley/probably/
16:09:37 <pchampin> ... `@propagate` defines how scoped contexts are managed when traversing properties;
16:10:06 <pchampin> ... by default type scoped contexts are droped when traversing; property scoped contexts are kept
16:10:07 <azaroth> preview: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/200.html#context-propagation
16:10:38 <azaroth> q+
16:10:55 <pchampin> ... there are caveats when contexts are in arrays.
16:11:18 <pchampin> ... @azaroth and @pchampin proposed to change the default for type scoped contexts. This should be discussed in a different issue.
16:11:43 <azaroth> q+ to ask about lack of arrays, w.r.t. https://iiif.io/api/presentation/3/context.json
16:12:07 <pchampin> ... Another discussion was about what could be used together with `@source` and `@propagate`.
16:13:02 <pchampin> ... I argued that `@version` should be also used. `@protected` could be used also.
16:13:11 <bigbluehat> syntax PR https://github.com/w3c/json-ld-syntax/pull/200
16:13:11 <pchampin> ... And term definitions could be used to "edit" the sourced context.
16:13:36 <gkellogg> https://github.com/w3c/json-ld-api/pull/112
16:13:51 <pchampin> ... This is reflected in two PRs (in syntax and api).
16:14:11 <pchampin> ... One of the question is whether `@source` is the correct keyword,
16:14:26 <pchampin> ... since this is not just a reference to a context (it can be customized).
16:14:27 <dlongley> i'm currently in the `@import` camp for bikeshed colors
16:14:35 <bigbluehat> ack ajs6f
16:14:37 <bigbluehat> ack azaroth
16:14:37 <Zakim> azaroth, you wanted to ask about lack of arrays, w.r.t. https://iiif.io/api/presentation/3/context.json
16:14:58 <dlongley> q+
16:15:17 <pchampin> azaroth: You said it only works if the sourced context is an object, and not an array?
16:16:09 <pchampin> gkellogg: yes, the implementation of `@propagate` is complicated, especilally identifying what needs to be unwind.
16:16:19 <pchampin> ... Arrays make it harder to figure it out.
16:16:37 <pchampin> azaroth: This limitations should be checked agains use cases.
16:16:41 <dlongley> q+ to respond
16:17:21 <pchampin> ... In XXX, we do have an array containing the Web Annotation context, then another redefining some terms.
16:17:47 <bigbluehat> ack dlongley
16:17:47 <Zakim> dlongley, you wanted to respond
16:17:56 <pchampin> gkellogg: this could be done by a context object sourcing the Web Annotation context, and customizing it in the same object.
16:18:09 <pchampin> ... This would actually be more faithful to the intention.
16:18:51 <azaroth> Thus: `@context: { "@source": "http://www.w3.org/ns/anno.jsonld", "@propagage": true, "label": { ... } }`
16:19:30 <azaroth> s/propagage/propagate/
16:19:58 <gkellogg> q+
16:20:01 <pchampin> dlongley: There was no way in JSON-LD to inline edit a context when importing it.
16:20:10 <bigbluehat> ack gkellogg
16:20:16 <pchampin> ... What @azaroth wants to do is exactly that.
16:20:31 <dlongley> q+ to say that's always a problem ):
16:20:42 <pchampin> gkellogg: The danger is that the remote context may change, then the edits may become inaccurate.
16:21:03 <bigbluehat> ack dlongley
16:21:03 <Zakim> dlongley, you wanted to say that's always a problem ):
16:21:37 <pchampin> ... SRI in this situation could be useful, to assert something about the context being referenced.
16:22:33 <pchampin> dlongley: +1, and the constraint of having a context object (as opposed to array) would also apply to SRI
16:22:56 <pchampin> ... with arrays, this would be very brittle
16:23:08 <pchampin> ... as arrays could reference other contexts
16:23:14 <pchampin> q+
16:23:26 <bigbluehat> ack pchampin
16:23:54 <ajs6f> pchampin: this constraint (the referenced context only being an object) looked very complicated to me at first
16:24:02 <ajs6f> ... it's started to make more sense
16:24:13 <ajs6f> ... but if we want to make this a thing, it should have a name
16:24:22 <ajs6f> ... a well-identified notion
16:24:30 <ajs6f> ... we might want to reuse it in other parts of the spec
16:24:31 <azaroth> q+ to ask about implementation status in playground / python / ruby for testing
16:24:34 <ajs6f> gkellogg: I _think_ we do
16:24:45 <ajs6f> ... we talk about it in the API algo
16:24:57 <ajs6f> ... but we may not have a term defined
16:24:58 <dlongley> figuring out the language might have to do with talking about contexts as "composable" or not ... at least via certain features
16:25:09 <bigbluehat> ack azaroth
16:25:09 <Zakim> azaroth, you wanted to ask about implementation status in playground / python / ruby for testing
16:25:16 <ajs6f> ... for that matter, we don't have terms for a type-scoped context vs. a property-scoped context
16:25:56 <pchampin> azaroth: it would be useful to know about implementation status on this. Can we test it now in the distiller?
16:26:42 <pchampin> gkellogg: it is currently on a branch, but I can make it available in the distiller.
16:26:49 <dlongley> q+
16:26:53 <bigbluehat> ack dlongley
16:27:03 <pchampin> ... I was waiting for us to discuss it, and settle the `@source`/`@import` question.
16:27:27 <pchampin> azaroth: what about the python and JS implementations?
16:27:47 <pchampin> dlongley: we don't have a timeline for python at the moment
16:28:07 <pchampin> dlehn: neither for JS
16:28:26 <pchampin> azaroth: as for `@source` vs. `@import`, let's have a strawpoll
16:28:36 <bigbluehat> Those for `@source` please +1
16:28:41 <dlongley> -1
16:28:42 <gkellogg> +0
16:28:49 <azaroth> -0
16:28:50 <bigbluehat> -1
16:28:50 <ajs6f> +0
16:28:53 <pchampin> +0
16:28:54 <rubensworks> -1
16:28:58 <workergnome> +0
16:29:02 <bigbluehat> Those for `@import` please +1
16:29:04 <azaroth> +1
16:29:04 <dlongley> +1
16:29:05 <gkellogg> +1
16:29:06 <bigbluehat> +1
16:29:06 <rubensworks> +1
16:29:12 <pchampin> +0.5
16:29:12 <ajs6f> +1
16:29:28 <bigbluehat> RESOLVED: change `@source` to `@import`
16:29:43 <azaroth> :shipit:
16:30:28 <pchampin> gkellogg: there is some pressure to get a new working draft
16:32:46 <pchampin> ... (discussion on whether we need to wait for feedback on the PRs)
16:33:13 <bigbluehat> merged https://github.com/w3c/json-ld-syntax/pull/202
16:33:36 <bigbluehat> Subtopic: Content addressable contexts
16:33:41 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/9
16:34:10 <azaroth> +1 to closing, no action
16:34:22 <pchampin> bigbluehat: this one has been closed and re-opened...
16:34:25 <dlongley> +1 to closing, handled elsewhere
16:34:40 <azaroth> s/no action/no normative change needed/
16:35:09 <pchampin> gkellogg: I'd like to close it as an issue for the normative documents. Create a new one for the BP
16:35:16 <bigbluehat> PROPOSED: close #9 with no action needed; solved via DocumentLoader and possible content for the Best Practices
16:35:18 <azaroth> +1
16:35:20 <gkellogg> +1
16:35:20 <dlongley> +1
16:35:21 <bigbluehat> +1
16:35:23 <pchampin> +1
16:35:24 <ajs6f> +1
16:35:26 <rubensworks> +1
16:35:30 <workergnome> +1
16:35:32 <dlehn> +1
16:35:39 <bigbluehat> RESOLVED: close #9 with no action needed; solved via DocumentLoader and possible content for the Best Practices
16:35:46 <azaroth> SUBTOPIC: JSON-LD in HTML
16:35:55 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/172
16:36:02 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/103
16:36:51 <pchampin> bigbluehat: #172 is Manu raising the problem of parsing text/html context documents.
16:37:10 <pchampin> ... #103 is about changes in the document's base URL for embeded JSON-LD.
16:37:33 <pchampin> ... Let's discuss them separately, starting with #103.
16:38:37 <pchampin> ... The Web Publishing WG is rechartering. They are planning to focus on an audio-book format (using JSON-LD in a separate file).
16:39:09 <pchampin> ... Their work on JSON-LD in HTML would be moved to the CG.
16:40:01 <pchampin> ... So if the use case for #103 is too specific, we could decide to not address it.
16:40:19 <dlongley> q+
16:40:48 <pchampin> azaroth: (asks a question about setting the base URL to null)
16:40:52 <azaroth> +1 for consistency :)
16:41:12 <pchampin> gkellogg: if base is set to null, relative URIs are not resolved at all
16:41:44 <pchampin> ... but in the case of JSON-LD is embedded, I think the URL of the embedding document is used
16:42:08 <bigbluehat> q+ to mention script element attributes and data block behavior
16:42:10 <bigbluehat> ack dlongley
16:42:11 <pchampin> ... There has been a concern about the fact that base can be dynamically modified.
16:42:48 <pchampin> dlongley: I remember use cases where people wanted relative URIs to survive compaction/expansion.
16:43:04 <bigbluehat> ack bigbluehat
16:43:04 <Zakim> bigbluehat, you wanted to mention script element attributes and data block behavior
16:43:05 <pchampin> ... We are well aligned with what others are doing.
16:44:02 <dlongley> +1 for supporting package-scoped things
16:44:05 <pchampin> bigbluehat: I think the behaviour of *not* resolving URIs when the base is set to null, should be made explicit (if it is not already)
16:44:35 <bigbluehat> ACTION: bigbluehat to research the status `@base: null` and possibly suggest making things clearer
16:44:48 <bigbluehat> https://html.spec.whatwg.org/multipage/scripting.html#data-block
16:44:49 <pchampin> gkellogg: it is possible that it is explicit in the API doc, but not the syntax doc
16:45:38 <pchampin> bigbluehat: from an HTML perspective, any attribute of the script tag should be ignored
16:46:35 <pchampin> ... #103 should be taken care of by the action created above.
16:47:16 <pchampin> ... Now discussing #172: context documents embeded in a text/html document.
16:47:42 <pchampin> gkellogg: Note that the spec currently mentions this use case.
16:47:57 <dlongley> +1 to making it more palatable
16:48:13 <pchampin> ... There was concern about naming the HTML-enabled processors "full processors",
16:48:24 <pchampin> ... implying that otherprocessors are not "fully compliant"
16:49:10 <pchampin> azaroth: as soon as we decided to make JSON-LD in HTML, we open the door to this;
16:49:20 <bigbluehat> q+ to suggest a difference between extraction and enhancement
16:49:24 <bigbluehat> ack bigbluehat
16:49:24 <Zakim> bigbluehat, you wanted to suggest a difference between extraction and enhancement
16:49:30 <pchampin> ... so some JSON-LD will not be available to a non "full processor"
16:49:53 <pchampin> bigbluehat: currently, contexts are all in JSON-LD documents.
16:50:14 <pchampin> ... There does not seem to be a demand for embedding contexts in HTML documents.
16:50:15 <gkellogg> q+
16:50:53 <dlongley> +1 to bigbluehat, "contexts" are all in JSON-LD documents, don't change that ... fine to talk about how to pull JSON-LD blocks out of HTML
16:50:55 <pchampin> ... Additionnally, we would need a different content-type for data-blocks, to distinguish contexts from data.
16:51:33 <pchampin> ... For me, the fact that JSON-LD can be embedded in data-blocks was not normatively defined by JSON-LD; it was normatively defined by HTML.
16:51:51 <bigbluehat> ack gkellogg
16:51:57 <pchampin> ... I never expected a JSON-LD processor to get itseld the embeded JSON-LD from the data-block.
16:52:09 <dlongley> -1 to massive shifts that complicate all the things.
16:52:29 <bigbluehat> q+ to expand on what schema.org is after
16:52:53 <pchampin> gkellogg: one demand is from schema.org:
16:52:55 <pchampin> ... they would be happy to *not* have to perform content-negociation,
16:53:08 <pchampin> ... and serve their context directly in the HTML homepage.
16:53:33 <pchampin> ... Re. content-type, we don't need a new one, merely a content-type parameter for distinguishing contexts.
16:53:38 <bigbluehat> ack bigbluehat
16:53:39 <Zakim> bigbluehat, you wanted to expand on what schema.org is after
16:53:45 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/172#issuecomment-493257482
16:54:22 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/172#issuecomment-501884159
16:54:41 <azaroth> q+
16:55:25 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/172#issuecomment-502164325
16:55:43 <pchampin> bigbluehat: danbri did mentioned that he didn't want to put the actual (big) schema.org context in the HTML page;
16:56:03 <pchampin> ... merely a small context referencing the original context
16:56:32 <dlongley> -1 to using a hammer to solve a problem that may smash everything around it to bits
16:56:51 <pchampin> ... What happended before (content-negociation + redirection) was happening outside the JSON-LD processor.
16:57:12 <pchampin> ... Now, we forced this in the JSON-LD processor, making it a much bigger animal.
16:57:25 <bigbluehat> ack gkellogg
16:57:30 <bigbluehat> ack azaroth
16:58:08 <pchampin> azaroth: I see things differently.
16:59:37 <pchampin> ... As we have JSON-LD data in HTML documents, we can not make contexts in HTML invalid.
16:59:50 <pchampin> ... Would JSON-LD data with a context in it be invalid?
16:59:51 <dlongley> -1000 to referencing an HTML document as a remote context
17:00:09 <pchampin> ... This would make no sense.
17:00:26 <azaroth> q?
17:00:44 <pchampin> ... The question we could ask is: is it valid to reference an HTML-embeded context from another JSON-LD document?
17:01:10 <azaroth> +1 to explicit justifications
17:01:37 <pchampin> gkellogg: topic for next week: we need a story to justify the perceived "bloat" in JSON-LD 1.1
17:42:19 <gkellogg> gkellogg has joined #json-ld
18:38:39 <gkellogg> gkellogg has joined #json-ld
19:29:49 <Zakim> Zakim has left #json-ld
21:07:12 <gkellogg> gkellogg has joined #json-ld
21:29:17 <gkellogg> gkellogg has joined #json-ld
22:46:14 <gkellogg> gkellogg has joined #json-ld
23:38:59 <gkellogg> gkellogg has joined #json-ld