15:21:29 RRSAgent has joined #json-ld 15:21:29 logging to https://www.w3.org/2019/04/19-json-ld-irc 15:21:30 rrsagent, set log public 15:21:30 Meeting: JSON-LD Working Group Telco 15:21:30 Chair: azaroth 15:21:30 Date: 2019-04-19 15:21:30 Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Apr/0028.html 15:21:30 ivan has changed the topic to: Meeting Agenda 2019-04-19: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Apr/0028.html 15:21:31 Regrets+ bigbluehat, simon, ajs6f 15:22:00 regrets+ tcole 15:37:38 regrets+ jeff_mixter 15:37:52 regrets+ workergnome 15:42:50 rubensworks has joined #json-ld 15:58:23 present+ 15:59:39 present+ 16:00:34 present+ 16:00:40 present+ Dave_Longley 16:02:03 present+ 16:03:49 regrets+ pchampin 16:04:09 scribenick: dlongley 16:04:35 TOPIC: Approve minutes of previous call 16:04:49 PROPOSAL: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-04-12-json-ld 16:04:50 +1 16:04:51 +1 16:04:51 +1 16:04:51 +1 16:04:59 +1 16:05:00 RESOLVED: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-04-12-json-ld 16:05:07 TOPIC: Announcements? 16:05:39 q+ 16:05:56 present+ 16:05:56 ack ivan 16:06:20 link: https://developers.google.com/web/tools/lighthouse/ 16:07:41 dlongley: Google Lighthouse merged jsonld.js into its master branch. Not sure when it will be released. 16:09:10 TOPIC: Logistics 16:09:13 ivan: Does Google do a blog post for releases? 16:09:15 dlongley: Yes. 16:09:21 ivan: We should watch for that and quote on our own blog. 16:09:23 dlongley: Yes. 16:09:32 SUBTOPIC: Horizontal Review 16:10:18 azaroth: For folks on AC list -- internationalization horizontal review -- requesting for people to give the i18n group time for change, we should be good w3c citizens and help review. 16:10:33 azaroth: We should start putting into motion some of the horizontal review requests. 16:10:42 azaroth: Ivan, could you briefly describe what that entails? 16:11:11 ivan: It's still a little bit messy I must say. The basic thing is, there is are some general topics i18n, security, privacy, and the TAG. These aspects should be checked in our document whenever relevant. 16:11:49 ivan: Review is done by the respective experts of these things, we already had a TAG review which is good. For each we have to have it clearly documented. We should have the right tags/labels/etc. so we can prove to the Director that we have these things. 16:12:43 ivan: It so happens that each of these areas have some sort of auto-check process. A formula that is there to get these reviews done. So we can check whether there are issues that are relevant for us or not. Either we say the issues aren't relevant or we can help the reviewers to say these are the things that seem to be relevant for us. We have to contact the necessary IG that's behind that, that's the mechanics. 16:13:40 ivan: Content-wise, what I can see is that ... let me come back to i18n. We have, I think, I don't know, if we have ever really discussed security and privacy issues, i.e. whether we have those issues. I don't remember, maybe it was discussed. I also don't remember if these issues were discussed for 1.0, because if 1.0 was OK, then we don't have (I don't think) anything new in a security/privacy sense. 16:13:56 ivan: That's up for us to find out. On the privacy side, actually, there were some noises on one of the Web of Things meetings. 16:14:30 ivan: It was forwarded a question there, whether the fact ... what kind of context files I retrieve from a site in general whether that can be used for some sort of privacy fingerprinting kind of process and whether we can do anything or think of doing anything with that. 16:14:53 ivan: Or if we have anything for the context files we receive, it may be a question we have to answer. We did have a TAG review so I think we're fine. 16:15:27 ivan: There is also Accessibility. It's a different animal in the sense in that there are two aspects. One is if our spec raises an issue, which I think is no, because our tech doesn't directly interact with the end user. 16:15:48 ivan: We may get a review to see whether our spec as a document is proper in terms of Accessibility. That may get some comments for the editors. 16:16:05 ivan: This is the general thing. I can go into the details for i18n. Any questions/issues? 16:16:26 gkellogg: We addressed the accessibility of the images some time ago, so we're ok in that regard. 16:16:29 Issues tagged with hr:* https://github.com/w3c/json-ld-syntax/issues/108 (defer) ; https://github.com/w3c/json-ld-syntax/issues/147 ; https://github.com/w3c/json-ld-syntax/issues/148 ; https://github.com/w3c/json-ld-syntax/issues/155 16:16:32 ivan: I hope that's the case but we have to sign it off. 16:17:01 q? 16:17:27 azaroth: 108 is the issue about meta data about contexts such that you could give it an SRI tag which is flagged as privacy and security for HR. 16:17:35 azaroth: We put that into the defer bucket so we should be careful of that one. 16:18:17 azaroth: There are two editorial ones 147, 148, has to do with IRI concatenation. 147 you can avoid some of the checks with relative URIs, and the URI schemes ones is that you can construct things that look like schemes and don't do that. 16:18:46 azaroth: 86 I didn't put in because it's a subset. There is one in the open set, 155, IRI terms can be misdefined and it's flagged as security for HR. 16:18:51 gkellogg: Also the case for compact IRIs. 16:19:04 q+ 16:19:06 azaroth: We don't have anything for a11y or i18n. 16:19:25 azaroth: We could call it out and say it's not in our scope to solve, but whether we want to open that door is a question. 16:19:31 gkellogg: I think a blog post would be good for that. 16:19:43 ack ivan 16:19:45 gkellogg: It could be pointed to by a future WG. 16:20:39 ivan: So let me give some background here. The question that does come up is that .. .when JSON-LD is used by other WGs for some sort of vocabulary like in the Web Publication now, if I use JSON-LD to express meta data where the value of the meta data is actual language text, that may be in the VCWG as well, but I may be wrong. 16:21:32 ivan: From an i18n why, you can set the language of the text BUT you cannot give the base direction of the text. When you have text that mixes up the direction like Hebrew and Latin or Arabic, so on, there are cases that go horribly wrong. Unicode does solve it for many things but not all the things. HTML has the `dir` attribute and when you have something of a manifest or meta data expressed in JSON-LD you can't use this attribute. 16:21:37 ivan: I raised this issue at the beginning of the WG. 16:21:50 ivan: The i18n guys have been working on a document for how to express i18n issues when using JSON. 16:22:27 ivan: And I got myself into a pretty long discussion with them, essentially what I tried to convince them ... and Rob I have been successful in convincing them as of three days ago ... you cannot solve something in JSON-LD you can't hack a direction into JSON-LD that's the effect today. 16:23:31 ivan: That's when we get to what Rob raised, essentially this not something that RDF can express. And JSON-LD cannot hack something on top of RDF properly. That's where the ball is, it's not in our yard. The i18n people have understood that I think and have accepted that. The question is if we move on or we have some informative text in the document that it is not possible to express, fully the direction of a text in JSON-LD. 16:23:44 ivan: And it should be done in a future version of RDF and in JSON-LD if RDF solves it. 16:23:59 q? 16:24:05 ivan: This issue will come up again and again and if we document it that it cannot be done I think is a good idea, but informative obviously. 16:24:34 gkellogg: Is there some a11y section where we'd put something like that? 16:24:48 ivan: I think there's only a security/privacy section requirement. For i18n it would be the same level of appendix section. 16:24:56 ivan: I don't think there's a requirement for an a11y section. 16:25:14 azaroth: An i18n section at the same level of security/privacy seems like a good thing to do rather than putting it somewhere in the text. 16:25:17 ivan: Yes. 16:25:31 gkellogg: So are you suggesting we add two new appendices? 16:25:55 gkellogg: Can we create an action for exactly what we want to do? 16:26:09 gkellogg: The privacy considerations would say there aren't any or are there any? 16:26:25 gkellogg: For example, this data format allows unencrypted information to be stored. 16:26:38 azaroth: For privacy we could put in a recommendation for HTTPS to address unencrypted information transfer. 16:26:48 ACTION: gkellog to add internationalization section discussing lack of text direction 16:27:02 ivan: But the question whether repeated retrieve of the same `@context` is something that can be used for fingerprinting. 16:27:04 q+ 16:27:21 gkellogg: When we complete the deferred issue on the integrity checking then that might show up in that section. 16:27:24 azaroth: Yes. 16:28:02 ACTION gkellog to add privacy section recommending HTTPS 16:28:06 azaroth: I think we should add a privacy section recommending HTTPS for all protocol transfers which gets us out of one thing. When we have had a chance to discuss then that would be the place to reference. 16:28:06 ack dlongley 16:28:15 +1 16:28:38 ACTION: gkellog to add privacy section recommending HTTPS 16:29:01 q+ 16:29:06 ack ivan 16:29:09 dlongley: 2 things: we should recommend https or other secure protocol 16:29:13 ... other thing for privacy if fingerprinting is and issue for you, then contexts can be stored offline or cached. 16:29:17 ... same issue for anything that has a URI in it 16:29:38 ivan: security and integrity issues, refer to future work on signatures on json-ld? 16:30:11 dlongley: yes, cover that informally and say there is upcoming work 16:30:22 ivan: say that it is a missing bit right now 16:30:54 azaroth_ has joined #json-ld 16:30:59 q? 16:31:58 azaroth__ has joined #json-ld 16:32:30 q? 16:33:16 -> security questionnaire: https://w3ctag.github.io/security-questionnaire/ 16:33:36 -> i18n questionnaire: https://www.w3.org/International/techniques/developing-specs?collapse 16:33:51 -> a11y questionnaire: https://w3c.github.io/apa/fast/checklist.html 16:34:10 gkellogg: Did we determine we needed an a11y section? 16:34:23 ivan: We have to cross section, we did it once with a checklist and maybe we're fine but we should do that. 16:35:21 regrets+ pchampin 16:35:31 azaroth: We could divide up responsibilities... Pierre-Antoine for security... 16:35:40 gkellogg: We point to IANA and we could already be comprehensive. 16:36:08 azaroth: I'm happy to the a11y one and given Benjamin's position and being part of the publications work, I think having him look at the i18n one would be appropriate. 16:36:20 ACTION: bigbluehat to check i18n questionnaire against specs 16:36:32 ivan: We will have some section/paragraph on the `dir` issue. That's something that we might take over when the time comes. 16:36:33 ACTION: azaroth to check a11y questionnaire against specs 16:37:11 gkellogg: I think describing, maybe not here, but in Best Practices using HTML content in order to get that, which is certainly unsatisfying, it's the best we have now. It provides a one-stop shop for what people are trying to go for. 16:37:41 ivan: The i18n guys just published a note on expressing these things in JSON and they are not really in favor of using that. For all kinds of reasons. For most of the cases, actually, the extra unicode that you can put in a string is also a possibility. 16:38:06 gkellogg: Certainly, that's what you'd want to do as a first choice. As I recall from observing that conversation there are many cases where that fails. 16:38:09 ivan: Yes, but the right solution is to get `dir` into RDF. 16:38:42 gkellogg: During the period where that is not available, then either avoid ... through editorial massaging of the text including those markers to avoid those problems or do you think we should not describe the use of embedded HTML at all? 16:38:45 ivan: I'm not sure. 16:38:53 gkellogg: What's happening in the Publication WG? 16:39:17 ivan: There is an acknowledgment that there certain situations that cannot be covered and that's the way it is. There was a universal pushback of using the HTML thing. 16:39:19 azaroth_ has joined #json-ld 16:39:31 ivan: Bringing in an HTML parser or partial parser to handle things for something like that. 16:39:37 ivan: This are details. 16:39:42 s/This/These/ 16:39:49 ivan: Let's not go there for now. 16:40:08 SUBTOPIC: reviews requested 16:40:30 azaroth: We have had some reviews requested of us, from WoT and OGC (?). 16:40:51 azaroth: The WoT has sent the chairs a link. We need to clarify exactly what they want a review of. 16:41:42 ACTION: azaroth to check with kaz about review of WoT 16:42:10 gkellogg: I pointed to that OGC, Pierre-Antoine spent some time to look through it. They said our descriptions of JSON-LD are too confusing and they created their own summary, but this resulted in some conflation with object and data types. 16:42:25 +1 to primer as solution to this 16:42:28 gkellogg: This highlights the need for a primer in order to provide a simpler introduction to things for groups like this. 16:42:38 q+ 16:42:41 ack ivan 16:42:46 gkellogg: And to clarify the use of data types and not confusing literals, etc. 16:42:57 gkellogg: They also referred to a lack of support for lists of lists which we do of course support in 1.1. 16:43:16 azaroth: I think it's Adam and Benjamin on the Primer. 16:43:26 ivan: I think this is a document that we should begin to have in some shape ASAP. 16:44:05 azaroth: For the OGC, are you sending a written response ... or? We will write a primer and refer them to it? 16:44:26 gkellogg: They asked if we'd share the link with the CG. I shared it with the WG, any feedback is welcome. 16:44:41 azaroth: At the very least we can say your points are well taken and we're working on this in the primer document. 16:44:45 q+ to channel Manu 16:44:53 ack dlongley 16:44:53 dlongley, you wanted to channel Manu 16:45:44 +1 to dave/manu 16:45:56 dlongley: Manu would say that we have to cleanup spec and clearer for people to understand 16:45:58 q+ 16:46:00 ... too much technical jargon too early, like blank nodes 16:46:04 ... a lot of readers have no idea what these things are 16:46:07 ... spec itself should be cleaned up and grade-level for reading. 16:46:26 gkellogg: blank nodes are needed 16:46:39 dlongley: yes, but should be pushed further away 16:47:31 azaroth_ has joined #json-ld 16:47:31 dlongley: we have an issue if we expect that non-tech people should just look at primer. 16:47:36 ack ivan 16:48:01 q? 16:48:06 +1 i also have sympathy for gregg on that 16:48:26 ivan: Hard for Gregg here because he's so well steeped in all the technology. 16:48:40 ivan: It would be nice for someone like Manu to come in with concrete text. 16:48:53 azaroth_: suggestions: blank nodes further down would be valuable 16:49:00 dlongley: +1 16:49:02 q? 16:49:06 dlongley: primer is good fallback 16:49:08 q+ 16:49:27 ack gkellogg 16:50:05 gkellogg: Pierre-Antoine has been great here and perhaps we can lean more on him. 16:50:32 gkellogg: The standard for 1.0 was to keep the text simple enough so that a Primer was not necessary. I think that ship has sailed. We've added enough advanced features here that the spec is becoming hard to keep from being overwhelming. 16:51:28 gkellogg: Being able to read a spec with fresh eyes is a skill I have yet to master. We can all help out with that. Section 1 should be general enough for people with general knowledge to go through. But once you get beyond that it's inevitable that you're going to need more knowledge. Sections 1-3 should let readers come away with a reason able understanding of what JSON-LD intends to do and how. 16:51:56 gkellogg: And if you have more details thoughts you can reasonable navigate your way in the rest of the spec from there for the things you're interested in and Ivan has helped with that organization so people can find what they're interested in. 16:52:05 TOPIC: Issues 16:52:19 SUBTOPIC: language aliasing 16:52:26 link: https://github.com/w3c/json-ld-syntax/issues/158 16:52:44 azaroth: Unless there are other people that are interested in this particular topic, I'm happy to close it. 16:53:11 azaroth: We can alias `@none` to just `none` to get rid of `@` [presumably that's what Rob said]. 16:53:25 gkellogg: Aliasing lets us alias IRIs and keywords, but that's it. 16:53:27 azaroth has joined #json-ld 16:53:48 gkellogg: Because `@none` is a keyword, we can alias it but we can't alias arbitrary string values. 16:54:26 azaroth: Yes, the thought was if we wanted to let some way of aliasing more things then `en-us` could be aliased to `en_us` for example. But as Gregg said that means introducing a new feature to do this. Unless there's interest, I'm ready to close. 16:55:00 PROPOSAL: Close syntax #158 won't fix, too complicated for the value gained 16:55:01 +1 16:55:02 +1 16:55:03 +1 16:55:03 +1 16:55:05 +1 16:55:11 RESOLVED: Close syntax #158 won't fix, too complicated for the value gained 16:55:20 +1 16:55:32 SUBTOPIC: Class-scoped framing 16:55:43 link: https://github.com/w3c/json-ld-framing/issues/29 16:56:25 azaroth: The idea here ... instead of having framing on only predicates to also have it on classes, whenever you find a resource of type X you use this subframe. But we'd deferred #38 and this seems to be a subtopic of that. 16:56:36 gkellogg: Deferred just means we're not working on this now. Or do you mean defer into another WG? 16:56:43 azaroth: Well, defer and we'll see what happens. 16:57:07 ivan: Wait, we're getting to feature freeze. Whatever is deferred at feature freeze means it goes to another version. 16:57:26 gkellogg: I think it meant we weren't accepting new proposals. It's still on the docket to work on, but the WG might decide to defer to a later version. 16:57:36 ivan: Deferring means that this will not be part of the upcoming version of JSON-LD. 16:57:47 gkellogg: Ok, I'm not prepared to say that for this or other things we've said "deferred" to. 16:58:06 azaroth: I've also thought that way, not necessarily closing. If not we're going to do it we should close. 16:58:24 azaroth: SRI and references to meta data we should continue to discuss it even though they are deferred. 16:58:57 ivan: As soon as we are CR we freeze it. For our own time tables we have to have a point where we freeze it for ourselves as well. At that point, if we say "defer" ... "if after publishing a new REC, this group or any other group should look at this feature" 16:59:23 azaroth: I'm fine with subtly changing the semantics of "defer" when we're in feature freeze. We should take those things that we've marked as defer as "in or out" 17:00:05 gkellogg: I think we should decide on the next call specific features we're going to work on for this version. Otherwise it's going to be nebulous. It's premature to say those things that don't get into this WD are deferred. We need to prioritize issues and set a time by which we will have finalized them. 17:00:10 ivan: We are dangerously close to that. 17:00:10 +1 17:00:15 gkellogg: So that's the topic for the next call. 17:00:49 azaroth: How about for now we defer based on #38? 17:00:56 ivan: Let's close the topic for now and then look at all these in general. 17:01:14 PROPOSAL: defer framing #29 to be discussed for inclusion in a future call 17:01:17 +1 17:01:18 +1 17:01:18 +1 17:01:19 +1 17:01:21 +1 17:01:24 +1 17:01:25 RESOLVED: defer framing #29 to be discussed for inclusion in a future call 17:01:42 azaroth: Thanks everyone! 17:02:11 azaroth: We will talk about the issues currently tagged as defer and what makes the cut next week. 17:02:27 TOPIC: Adjourn 17:02:37 rrsagent, draft minutes 17:02:37 I have made the request to generate https://www.w3.org/2019/04/19-json-ld-minutes.html ivan 17:02:37 zakim, bye 17:02:37 rrsagent, bye 17:02:37 I see 5 open action items saved in https://www.w3.org/2019/04/19-json-ld-actions.rdf : 17:02:37 ACTION: gkellog to add internationalization section discussing lack of text direction [1] 17:02:37 recorded in https://www.w3.org/2019/04/19-json-ld-irc#T16-26-48 17:02:37 ACTION: gkellog to add privacy section recommending HTTPS [2] 17:02:37 recorded in https://www.w3.org/2019/04/19-json-ld-irc#T16-28-38 17:02:37 ACTION: bigbluehat to check i18n questionnaire against specs [3] 17:02:37 recorded in https://www.w3.org/2019/04/19-json-ld-irc#T16-36-20 17:02:37 ACTION: azaroth to check a11y questionnaire against specs [4] 17:02:37 recorded in https://www.w3.org/2019/04/19-json-ld-irc#T16-36-33 17:02:37 ACTION: azaroth to check with kaz about review of WoT [5] 17:02:37 recorded in https://www.w3.org/2019/04/19-json-ld-irc#T16-41-42 17:02:37 leaving. As of this point the attendees have been azaroth, gkellogg, rubensworks, Dave_Longley, ivan, dlehn 17:02:37 Zakim has left #json-ld