15:10:16 <RRSAgent> RRSAgent has joined #json-ld
15:10:16 <RRSAgent> logging to https://www.w3.org/2019/05/10-json-ld-irc
15:10:17 <ivan> rrsagent, set log public
15:10:17 <ivan> Meeting: JSON-LD Working Group Telco
15:10:17 <ivan> Chair: azaroth
15:10:17 <ivan> Date: 2019-05-10
15:10:17 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019May/0010.html
15:10:17 <ivan> ivan has changed the topic to: Meeting Agenda 2019-05-10: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019May/0010.html
15:10:18 <ivan> Regrets+ bigbluehat, pchampin, tcole, workergnome
15:46:54 <rubensworks> rubensworks has joined #json-ld
15:54:33 <azaroth> azaroth has joined #json-ld
15:58:07 <ajs6f> ajs6f has joined #json-ld
15:59:25 <gkellogg> present+
15:59:30 <ajs6f> present+
15:59:30 <rubensworks> present+
15:59:37 <azaroth> present+
16:00:52 <dlongley> present+
16:01:10 <manu> manu has joined #json-ld
16:02:21 <azaroth> scribenick: rubensworks
16:02:35 <azaroth> TOPIC:  Approve the minutes of previous call
16:02:37 <bigbluehat> present+
16:02:52 <ivan> present+
16:02:56 <azaroth> PROPOSAL: approve minutes of previous call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-03-json-ld
16:03:00 <azaroth> +1
16:03:01 <ajs6f> +1
16:03:02 <dlongley> +1
16:03:04 <rubensworks> +1
16:03:10 <ivan> regrets- bigbluehat
16:03:15 <manu> present+
16:03:29 <gkellogg> +1
16:04:03 <azaroth> regrets+ hsolbrig
16:04:06 <azaroth> regrets+ jeff_mixter
16:04:26 <bigbluehat> +1
16:04:27 <ivan> +1
16:04:34 <azaroth> RESOLVED: approve minutes of previous call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-03-json-ld
16:04:59 <simonstey> simonstey has joined #json-ld
16:05:03 <azaroth> TOPIC: Announcements / Reminders
16:05:17 <rubensworks> azaroth: Any announcements?
16:05:39 <rubensworks> gkellogg: Thanks to Simon, we figured out publishing problems. So WDs are published as of today.
16:05:48 <rubensworks> azaroth: Any others?
16:06:03 <azaroth> TOPIC: WD Publication / Echidna
16:06:23 <rubensworks> azaroth: gkellogg, could you summarize what happened with the WDs?
16:07:03 <azaroth> +1 to simonstey for expert debugging!
16:07:44 <dlehn> present+
16:07:50 <simonstey> present+
16:07:55 <rubensworks> gkellogg: When publishing and it gives a failure, it gives a log, which is unusefull. It is specberus that is complaining that this is not a WD, which makes no sense. Simon figured out a change in the tool. Also, we were pulling from the wrong version branch. Now we are using the latest version, and it works now. Only problem: the errors are not really helpfull. Thanks to Simon for helping.
16:08:18 <rubensworks> ivan: I'm traveling, so I was not able to help.
16:09:26 <rubensworks> azaroth: Could you give the new URLs for the minutes?
16:09:33 <gkellogg> https://www.w3.org/TR/2018/WD-json-ld11-20181214/
16:09:38 <gkellogg> https://www.w3.org/TR/2018/WD-json-ld11-api-20181214/
16:09:38 <rubensworks> azaroth: Next up: the issues
16:09:41 <azaroth> TOPIC: Issues
16:09:44 <gkellogg> https://www.w3.org/TR/2018/WD-json-ld11-framing-20181214/
16:09:59 <azaroth> SUBTOPIC: HTML Contexts
16:10:10 <azaroth> SUBTOPIC: Errata
16:10:21 <gkellogg> https://www.w3.org/2001/sw/wiki/JSON_LD_Errata
16:10:30 <azaroth> s/SUBTOPIC: HTML Contexts//
16:11:29 <rubensworks> gkellogg: Errata publishing for JSON-LD 1.0. Bad expansion for native values was fixed. IRI expansion creates unintended IRIs required a change in 1.0 when creating IRIs.
16:12:06 <rubensworks> ... In 1.0, IRIs were used for that. We addressed that further in 1.1 using @prefix definition.
16:12:45 <rubensworks> ... We need to ratify that this is a change we want to allow and use for purpose of old 1.0 processing.
16:12:45 <ivan> q+
16:13:18 <azaroth> ack ivan
16:13:35 <rubensworks> ... Issue 7: This is a result of a descision of this WG to not allow term set to not allow expansion ...<missed parts>... which was a security issue.
16:14:39 <rubensworks> ivan: We must explicitly propose changes to 1.0. The other thing that we disagreed on was that we refer to behaviour to 1.0, we must refer to REC 1.0, and not REC 1.0-ammended-by-errata.
16:14:55 <gkellogg> q+
16:15:09 <rubensworks> ... There was an intermediate version with errata in. As far as RECs are concerned, we must refer to official REC without the errata.
16:15:25 <azaroth> ack gkellogg
16:15:26 <rubensworks> ... It's an editorial thing.
16:15:53 <rubensworks> gkellogg: Spec text says that 1.1 processor can work in in 1.0 mode.
16:16:07 <bigbluehat> q+
16:16:26 <azaroth> ack bigbluehat
16:16:30 <rubensworks> ivan: We have to specify if it works in 1.0-mode, or 1.0-with-errata. Current text is not clear.
16:16:58 <azaroth> q+ to note future modes
16:17:28 <ivan> q+
16:17:42 <rubensworks> bigbluehat: We don't have much text around a 1.0 processing mode. It's just the default mode until 1.1 is signaled.
16:17:50 <azaroth> q?
16:18:02 <rubensworks> gkellogg: You get in 1.1 if you see 1.1 in the context. You can not set 1.0 in the version.
16:18:32 <bigbluehat> https://w3c.github.io/json-ld-syntax/#dfn-processing-mode
16:18:40 <rubensworks> gkellogg: Do we want to formally describe mode of processor without version 1.1 being seen?
16:19:01 <azaroth> ack azaroth
16:19:01 <Zakim> azaroth, you wanted to note future modes
16:19:34 <rubensworks> azaroth: Editorial note: We should not preclude future modes by defining 1.1 as everything that is not 1.0. Because there can be future versions.
16:19:40 <manu> +1 to azaroth -- ensure we're aware of future versions
16:20:18 <azaroth> ack ivan
16:20:19 <rubensworks> ... There must be a process for errata for this sort of situation where proc mode for some spec is changed by errata for security or other reasons. Is there something we can point to that could be used for justifying this?
16:20:38 <gkellogg> Notes that a hypothetical 2.0 processor likely would depend on `@version: 2.0`, as we locked down values in 1.1 processing. It could work with `@version: 1.1`
16:20:45 <rubensworks> ivan: This is fuzzy. Usually: if there is errata in one version, group issues new version, and new version incorporates errata.
16:21:07 <rubensworks> ... Here we have this extra round that says if we have data that was created years ago, that there should be a switch.
16:21:23 <azaroth> q?
16:21:50 <rubensworks> ... we should document exact expectations. It is true in 99% of cases that until 1.1 version is triggered, any data processed will be not dependent on processor version.
16:22:34 <azaroth> q+
16:22:40 <azaroth> ack azaroth
16:22:51 <rubensworks> ivan: We can do any of the two options <<<missed options>>>, but we have to decide which one.
16:23:20 <rubensworks> manu: Any experience on backwards-compat changes?
16:23:50 <rubensworks> manu: In general, I agree with what you said about future-compatibility. e.g. Not making too broad statements.
16:24:09 <rubensworks> ... I don't tbhink anyone wants to change 1.0 processing things.
16:24:35 <dlongley> i think the errata is very narrow and there may only be very few cornercases that would be affected by it -- and those probably *should* be affected by it (for those that are related to security)
16:25:08 <ivan> q+
16:25:09 <rubensworks> azaroth: It seems like we should accept errata and issue them with expectation that processors act differently when updated taking into account errata for 1.0. There should be clear signaling that this is a change for security reasons without significant impact on current usage.
16:25:11 <azaroth> ack ivan
16:25:18 <manu> Agree w/ dlongley :)
16:25:22 <rubensworks> ivan: I am fine with that. But this has to be made very clear in the doc.
16:25:48 <rubensworks> ... Say that the behaviour is not exactly the same what 1.0 doc says.
16:25:57 <manu> ... and it's "ok" in this case, because we're fixing a security concern.
16:25:58 <rubensworks> gkellogg: We'll need directions on editorial actions.
16:26:45 <rubensworks> ivan: The other errata was security issue
16:26:50 <rubensworks> gkellogg: Yes, Issue 7
16:27:32 <azaroth> PROPOSAL: Accept errata 5 on the expansion of native values to IRIs (per https://lists.w3.org/Archives/Public/public-rdf-comments/2018Jan/0001.html )
16:27:41 <azaroth> +1
16:27:42 <gkellogg> s/issue 7/erratum 7/
16:27:43 <dlongley> +1
16:27:45 <gkellogg> +1
16:27:46 <ivan> +1
16:27:46 <simonstey> +1
16:27:49 <rubensworks> +1
16:27:51 <dlehn> +1
16:28:08 <azaroth> RESOLVED: Accept errata 5 on the expansion of native values to IRIs (per https://lists.w3.org/Archives/Public/public-rdf-comments/2018Jan/0001.html )
16:28:11 <ajs6f> +1
16:28:24 <gkellogg> +1
16:28:33 <rubensworks> +1
16:29:14 <azaroth> PROPOSAL: Accept erratum 7 on expansion of IRIs to terms that are IRIs other than the input (per https://lists.w3.org/Archives/Public/public-rdf-comments/2019Apr/0000.html)
16:29:19 <dlongley> +1
16:29:19 <azaroth> +1
16:29:22 <gkellogg> +1
16:29:26 <rubensworks> +1
16:29:28 <ajs6f> +1
16:29:30 <simonstey> +1
16:29:45 <ivan> +1
16:29:51 <azaroth> RESOLVED: Accept erratum 7 on expansion of IRIs to terms that are IRIs other than the input (per https://lists.w3.org/Archives/Public/public-rdf-comments/2019Apr/0000.html)
16:29:58 <dlehn> +1
16:31:21 <azaroth> PROPOSAL: Be explicit about the processing change for the errata 5 and 7 on systems that implement current 1.0 specifications, to be written in 1.1 spec
16:31:23 <ivan> +q
16:31:25 <ivan> +1
16:31:26 <ivan> q-
16:31:35 <azaroth> +1
16:31:35 <dlongley> +1
16:31:36 <rubensworks> +1
16:31:40 <simonstey> +1
16:31:43 <gkellogg> +1
16:32:00 <dlehn> +1
16:32:02 <ajs6f> +1
16:32:05 <azaroth> RESOLVED: Be explicit about the processing change for the errata 5 and 7 on systems that implement current 1.0 specifications, to be written in 1.1 spec
16:33:01 <azaroth> PROPOSAL: Accept erratum 6, and be explicit about the processing change required for it by systems that implement the 1.0 specification (per https://lists.w3.org/Archives/Public/public-rdf-comments/2018Jan/0002.html)
16:33:11 <azaroth> +1
16:33:14 <ivan> +1
16:33:14 <dlongley> +1
16:33:15 <gkellogg> +1
16:33:18 <rubensworks> gkellogg: Item 2 is also a difference in behaviour.
16:33:19 <rubensworks> +1
16:33:33 <simonstey> +1
16:33:34 <dlehn> +1
16:33:35 <rubensworks> azaroth: Because it changes the algorithm?
16:33:40 <rubensworks> gkellogg: Yes
16:33:54 <azaroth> RESOLVED: Accept erratum 6, and be explicit about the processing change required for it by systems that implement the 1.0 specification (per https://lists.w3.org/Archives/Public/public-rdf-comments/2018Jan/0002.html)
16:35:26 <azaroth> PROPOSAL: Accept erratum 2, and be explicit about the processing change required for it by systems that implement the 1.0 specification (per https://lists.w3.org/Archives/Public/public-rdf-comments/2014Jul/0011.html)
16:35:28 <rubensworks> gkellogg: If you have a list where a bnode exists in two different graphs, then it would be incorrect to express as a representation of lists. Because the fact that that bnode was used twice, was removed. The correction is to not allow such lists to be shared. You can only use @list for subset of tail of the list that has only bnodes that exist in a single graph.
16:35:29 <azaroth> +1
16:35:34 <rubensworks> +1
16:35:39 <simonstey> +1
16:35:42 <gkellogg> +1
16:35:45 <dlongley> +1
16:35:53 <ajs6f> +1
16:36:02 <ivan> +1
16:36:13 <azaroth> RESOLVED: Accept erratum 2, and be explicit about the processing change required for it by systems that implement the 1.0 specification (per https://lists.w3.org/Archives/Public/public-rdf-comments/2014Jul/0011.html)
16:36:17 <dlehn> +1
16:37:12 <azaroth> SUBTOPIC: Contexts in HTML
16:37:23 <ivan> https://github.com/w3c/json-ld-syntax/issues/172
16:38:32 <rubensworks> azaroth: Summary: in the spec we say that (normatively) json-ld can be included in script el. There is now a requirement on <base>. It was noted that contexts are also jsonld. Hence, it is permissable to have contexts embedded in script tags inside html. This means that processors need to be able to process that.
16:38:58 <manu> q+ to provide context for Digital Bazaar's concern.
16:39:26 <rubensworks> ... We all agree that this is an extension to normal proc mode. Either we need to say that contexts have a special role, contexts are not jsonld, or we need to accept that contexts can be embedded in html and processors should have to be able to say that they support processing them.
16:39:31 <bigbluehat> q+ to provide context (not in HTML) for Wiley's concerns
16:39:40 <azaroth> ack manu
16:39:40 <Zakim> manu, you wanted to provide context for Digital Bazaar's concern.
16:40:34 <rubensworks> manu: Some context wrt VC. Purely json-based processors find information using context. Someone said it would be niceto have human-readable context. Argument in favor of this feature.
16:41:34 <rubensworks> ... Person said, It would be nice to see jsonld in html. But I don't want the burden of jsonld processor supporting html.
16:41:51 <rubensworks> ... We all agree that JSON-LD in HTML is a huge context (e.g. schema.org)
16:42:08 <rubensworks> ... I think pulling in contexts from html is controversial
16:42:10 <rubensworks> ... 2 questions
16:42:26 <rubensworks> ... 1: is jsonld context in html greatly increase jsonld usage?
16:42:29 <azaroth> q+ to channel danbri
16:42:40 <rubensworks> ... I think the answer is no
16:43:00 <rubensworks> ... There are other ways to solve issues people would have to want html for contexts.
16:43:14 <rubensworks> ... 2: is this going to create interop issues?
16:43:28 <rubensworks> ... Is this going to cause ecosystem to change by other processors to start failing?
16:43:35 <rubensworks> ... I think this is going to create issues.
16:43:50 <rubensworks> ... Some people are going to stary publishing contexts as html only.
16:43:58 <rubensworks> ... Even if we say you should not do this.
16:44:14 <rubensworks> ... The damage this feature could create is far greater than possible benefits.
16:44:24 <rubensworks> ... I have more reasons, but this is the biggest argument.
16:44:42 <rubensworks> ... We should wait until there is more demand for this feature. We could do it in the future if really needed.
16:44:51 <azaroth> ack bigbluehat
16:44:51 <Zakim> bigbluehat, you wanted to provide context (not in HTML) for Wiley's concerns
16:45:01 <rubensworks> bigbluehat: +1 to everything many said.
16:45:09 <bigbluehat> "This means that processors need to be able to process that."
16:45:38 <rubensworks> ... This is the part of what Rob said in start that jsonld in html normative somehow begets this notion that we have to ...
16:45:56 <rubensworks> ... jsonld in html has always been normative thanks to the data block in script tag
16:46:08 <rubensworks> ... we just described it better
16:46:18 <rubensworks> ... comes from HTML5 spec.
16:46:40 <rubensworks> ... Using single URL to specify context and its documentation is interesting. (Conneg can be used)
16:46:57 <rubensworks> ... Overhead of making this possible is too big for processors.
16:47:15 <dlongley> q+ to disagree (if necessary) with the premise that if X can be embedded in HTML that it means a processor for X must understand HTML (seems to be a layering violation)
16:47:22 <rubensworks> ... This is a nuclear weapon to kill a small bird.
16:47:34 <rubensworks> ... There are less damaging ways to solve the problems discussed.
16:47:45 <azaroth> ack azaroth
16:47:45 <Zakim> azaroth, you wanted to channel danbri
16:47:46 <dlongley> +1 to manu and bigbluehat
16:47:47 <manu> +1 to bigbluehat !
16:47:58 <rubensworks> ... We need to be more careful than we have before, before introducing new things like these.
16:48:21 <azaroth> ref - https://www.w3.org/TR/2018/WD-json-ld11-20181214/#embedding-json-ld-in-html-documents
16:48:23 <rubensworks> azaroth: in 1.1, we made it our problem, so we have to solve it.
16:48:57 <rubensworks> azaroth: I want to channel danbri. Search engines want to include info in their knodledge graph that they find on the web as jsonld.
16:49:27 <rubensworks> ... schema.org, or at least the engines, currently assume do not process contexts at all.
16:50:01 <rubensworks> ... If you have a template in your website, with multiple schema.org definitions, you could put into your CMS as a data script block to push this into every single page.
16:50:13 <rubensworks> ... search engines would be able to see these blocks
16:50:33 <bigbluehat> q+ to ask how that isn't just using an inline `@context` object
16:50:47 <manu> q+ to doubt that's a schema.org use case -- would prefer that danbri or someone write it up.
16:50:49 <rubensworks> ... by having google's clusteres waiting to process jsonld in page. publishers would be required to not embed into page.
16:51:05 <bigbluehat> q-
16:51:45 <ivan> q+
16:51:49 <rubensworks> azaroth: why not have it as include contexts object?: when multiple people responsible for editing context. Also, if there are templare-driven CMSs being used, you want to stripe jsonld over different templates being used. This would cause data blocks being used multiple times.
16:51:57 <bigbluehat> q+ to note that these are single request, self referencing usage--no requests, no media types, etc.
16:52:04 <azaroth> q?
16:52:07 <azaroth> ack dlongley
16:52:07 <Zakim> dlongley, you wanted to disagree (if necessary) with the premise that if X can be embedded in HTML that it means a processor for X must understand HTML (seems to be a layering
16:52:10 <Zakim> ... violation)
16:52:46 <rubensworks> dlongley: Many of these things can be solved by saying that serving should happen with application/ld+json
16:52:59 <rubensworks> ... I think there are many cases not being considered wrt complexity
16:53:12 <rubensworks> ... many use cases not covered on template-based html pages
16:53:16 <gkellogg> q+
16:53:25 <rubensworks> ... Such as dynamic pages when generated client-side with javascript
16:53:31 <azaroth> q+ to say we already are in that space :(
16:53:32 <rubensworks> ... We shouldn't get into that space.
16:53:48 <rubensworks> ... We should say that context MUST be server with proper content type
16:53:48 <azaroth> q?
16:53:50 <azaroth> ack manu
16:53:51 <Zakim> manu, you wanted to doubt that's a schema.org use case -- would prefer that danbri or someone write it up.
16:54:33 <rubensworks> manu: I could not follow schema.org use case. danbri should write this up. We should do a deep analysis on this use case, to see what could address his concern.
16:54:42 <rubensworks> ... There are a bunch of assumptions in that use case
16:55:09 <rubensworks> ... e.g. people could create their own non-schema.org contexts. This would add a huge amount of complexity.
16:55:16 <rubensworks> ... it would be good to have dan involved.
16:55:17 <azaroth> +1 to dlongley and manu
16:55:32 <rubensworks> ... Also, it feels like this is mograting away from BPs.
16:55:37 <azaroth> q?
16:55:44 <rubensworks> ..; We are learning a lot from secutrity around publishing contexts.
16:55:58 <rubensworks> ... We had discussions on the type of attacks, if you could publish contexts as html.
16:56:13 <rubensworks> ... So there are security concerns around this feature
16:56:13 <ivan> s/…;/…/
16:56:26 <rubensworks> ... Concern around complexity, interoperabiliy, ...
16:56:37 <ivan> s/..;/.../
16:56:38 <rubensworks> ... A long list of reasons for saying that this is not spec-ready.
16:56:54 <azaroth> ack ivan
16:57:06 <rubensworks> ... So we have to get use-case right. And see if it can be solved with current feature-set. Only if needed, we should look further into this html issue.
16:57:33 <rubensworks> ivan: Manu said many things what I wanted to say. We need danbri to raise his voice.
16:57:51 <rubensworks> ... We have to rely on documented requirements
16:57:56 <rubensworks> azaroth: I agree
16:58:00 <azaroth> ack bigbluehat
16:58:00 <Zakim> bigbluehat, you wanted to note that these are single request, self referencing usage--no requests, no media types, etc.
16:58:03 <azaroth> q?
16:58:04 <manu> +1 to azaroth :)
16:59:10 <manu> q+ to note "Cryptographic Hashlinks for JSON-LD Contexts... so you never have to go out to the network"
16:59:11 <ivan> q+
16:59:23 <rubensworks> bigbluehat: I think what you described, if it's on danbri's previous desire to have this in jsonld, then this is a request. Dan has expressed multiple times that search engines want to understand page contents. This is different to giving identifier that serves contexts in html.
16:59:42 <rubensworks> ... We are going to end up with RDF dataset that is compiled of multiple contexts.
16:59:49 <manu> q-
16:59:59 <gkellogg> no, doesn’t work that way
17:00:36 <azaroth> ack gkellogg
17:00:40 <ivan> q-
17:00:44 <rubensworks> ... Generating a graph is not about coupling jsonld context identifier algorithm.
17:01:06 <azaroth> q-
17:01:13 <azaroth> q?
17:01:13 <rubensworks> gkellogg: I don't think it is practical for many CMSs to do content negotation (like github pages)
17:01:30 <rubensworks> ... we have to recharacterize what jsonld in html is.
17:01:47 <rubensworks> ... I agree that these things start to increase complexity and raising barrier.
17:02:04 <rubensworks> ... We need to reconsider what processing jsonld in html means.
17:02:05 <manu> +1 to recharacterize how processors process JSON-LD in HTML.
17:02:18 <rubensworks> azaroth: We are not going to solve this today.
17:02:31 <rubensworks> azaroth: I will reach out to danbri to see if he wants to engage.
17:02:36 <rubensworks> gkellogg: He may be at WebConf
17:02:42 <bigbluehat> +1 to re-characterize it in relationship to the existing usage patterns
17:02:53 <azaroth> q?
17:03:41 <gkellogg> https://github.com/w3c/json-ld-syntax/issues/174
17:03:47 <ivan> rrsagent, draft minutes
17:03:47 <RRSAgent> I have made the request to generate https://www.w3.org/2019/05/10-json-ld-minutes.html ivan
17:03:47 <ivan> zakim, bye
17:03:47 <ivan> rrsagent, bye
17:03:47 <RRSAgent> I see no action items
17:03:47 <Zakim> leaving.  As of this point the attendees have been gkellogg, ajs6f, rubensworks, azaroth, dlongley, bigbluehat, ivan, manu, dlehn, simonstey
17:03:47 <Zakim> Zakim has left #json-ld