15:30:00 RRSAgent has joined #json-ld 15:30:00 logging to https://www.w3.org/2018/08/10-json-ld-irc 15:30:01 rrsagent, set log public 15:30:01 Meeting: JSON-LD Working Group Telco 15:30:01 Chair: azaroth42 15:30:01 Date: 2018-08-10 15:30:01 Regrets+ 15:30:01 Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Aug/0007.html 15:30:02 ivan has changed the topic to: Meeting Agenda 2018-08-10: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Aug/0007.html 15:47:37 ajs6f has joined #json-ld 15:53:51 azaroth has joined #json-ld 15:54:43 present+ Rob_Sanderson 15:54:48 regrets+ hsolbrig 15:54:50 present+ Benjamin_Young 15:55:41 present+ Gregg_Kellogg 15:55:49 present+ 15:56:22 present+ 15:57:10 jeff_mixter has joined #json-ld 15:59:20 timCole has joined #json-ld 15:59:52 present+ 16:00:23 present+ Tim_Cole 16:00:33 present+ 16:01:20 scribenick: timCole 16:01:42 TOPIC: Approve minutes of last call 16:01:45 +1 16:01:50 +1 16:01:51 PROPOSAL: Approve minutes of last call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-03-json-ld 16:01:51 +1 16:01:57 +1 16:02:00 +1 16:02:02 +1 16:02:03 +1 16:02:07 +1 16:02:13 RESOLVED: Approve minutes of last call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-03-json-ld 16:02:22 TOPIC: Announcements 16:02:26 regrets+ dlongley 16:02:42 azaroth: reminder about TPAC 16:02:53 ... any other announcements? 16:03:05 https://github.com/w3c/json-ld-api/pull/16 16:03:36 gkellogg: we don't have an issue for PR 16, json-ld api, but we need input 16:04:14 azaroth: hearing no further announcement, move to next 16:04:34 ... how much discussion does PR need? 16:05:10 gkellogg: I think we approved the idea, we would like another implementation to make sure we've got it right for the PR 16:05:11 q+ to ask about version compatibility 16:05:11 q+ on something purely procedural 16:05:40 azaroth: Dave Longley could be helpful, but not on call 16:05:56 q? 16:05:58 ack bigbluehat 16:05:58 bigbluehat, you wanted to ask about version compatibility 16:06:19 ack ivan 16:06:19 ivan, you wanted to comment on something purely procedural 16:06:52 ivan: procedural - this PR is a new feature not in the Community Report, so we need to make sure we list it 16:06:55 q+ to ask about version compatibility & mention new implementors 16:07:16 gkellogg: there is a recently added entry in the changes since 1.0 16:07:20 ivan: thanks 16:07:22 ack bigbluehat 16:07:22 bigbluehat, you wanted to ask about version compatibility & mention new implementors 16:07:36 bigbluehat: about getting more implementators in the room 16:07:38 https://github.com/json-ld/json-ld.org/pull/667 16:07:57 ... I've been reaching out to other developers and json-ld.org 16:08:10 ... hoping that will at least watch repositories 16:08:42 ... is this something that needs the 1.1 toggle? OR can json 1.0 handle it? 16:09:01 gkellogg: 1.0 processor might generate a list of list error 16:09:27 q+ 16:09:28 ... it's a matter of what happens when a processor encounters it 16:09:50 ... in the test suite there is an option for this 16:10:12 ... this does not require to put the processor in the 1.1 mode 16:10:19 ... but we could discuss / debate 16:10:25 ack ivan 16:10:31 ... there is no change in the context processing 16:10:52 bigbluehat: as I talk to implementers, there's always the 'we'll implement it when it's ready' 16:11:18 ... so is this the kind of thing that they could start working on ahead of final 1.1 syntax rollout 16:11:38 ... encourage implementers to get started on new features as soon as viable 16:12:13 gkellogg: I try to test as the API changes go into the draft spec 16:12:52 +1 to longer versioning discussion later 16:12:52 ivan: would like to take versioning / singaling probably needs a longer discussion independent of this PR 16:12:55 q+ to ask about a sense of the WG acceptance of CG features in general. 16:13:10 ack gkellogg 16:13:10 gkellogg, you wanted to ask about a sense of the WG acceptance of CG features in general. 16:13:14 ... let's add it to a near term agenda 16:13:42 gkellogg: bigbluehat raised question of when features are stable enough to begin implementing 16:13:59 q+ 16:14:03 ack azaroth 16:14:14 ... so do we need some form of a statement of when developer can implement something without having to worry about it going away 16:14:41 azaroth: good if worded carefully so we don't paint ourselves into a corner 16:15:08 ... for example, in the frozen and sealed context, we may come up with a solution that is different than some change the CG came up with 16:15:36 q+ 16:15:38 ... so we could say something like, 'lacking further reasoning, we accept the CG drafts, but...' 16:15:40 ack ivan 16:15:51 q+ 16:16:15 ivan: even that may be too much. There may be features CG added that don't fit with WG criteria/charge 16:16:23 ... so we have to be very careful. 16:16:58 ack bigbluehat 16:17:00 ... I remember from RDFa group that some of us went through implementation for features subsequently thown out. 16:17:32 bigbluehat: to clarify, I wasn't wanting promises outside normal publishing cycle, but would like others to be paying attention 16:18:00 ... so they can see what's happening and get ready for, and if excited take a crack at it to inform our discussions. 16:18:15 ... looking for ways to involve developers sooner rather than later 16:18:34 azaroth: back to PR do we need to wait for further review? 16:19:06 gkellogg: not urgent, and we have some review already, but would like for this and future PRs to make sure changes we make to API are up to snuff 16:19:12 TOPIC: Documentation Issues 16:19:57 azaroth: issue #32 was split into 4 potential issues, 3 of which have been written up and Manu commented about the 4th 16:20:22 ... propose we discuss in order, 40, 42, 43 16:20:24 SUBTOPIC: Inline metadata escaping 16:20:27 Link: https://github.com/w3c/json-ld-syntax/issues/40 16:21:01 ... Harold send regrets, but clarified end of line question that came up 16:21:34 ... proposal is that we use '@@' to indicate that the following value is not processed. 16:21:48 ... processors not expected to retain through any transformation 16:22:02 ... convention is that '@@' and its value must be ignored 16:22:25 ... so, we reserve '@@' and is should not appear in a context 16:22:39 q? 16:22:47 ... what do we all think about that proposal 16:23:44 gkellogg: two-fold concerns - example he points to, the comment is outside the context 16:23:54 ... second, is asethic 16:23:57 q+ 16:24:00 ack bigbluehat 16:24:28 q? 16:24:33 bigbluehat: example also shows using the key over and over, which creates duplicate keys 16:25:04 azaroth: my objection is that proposal is really a bikeshed paint color on @comment 16:25:10 q? 16:25:14 ... not what we want 16:25:38 gkellogg: we now have 5 minuses on this issue 16:25:45 q+ 16:25:49 ack ivan 16:26:25 q+ 16:26:31 ivan: in another group, thumbs up and thumbs down not frozen, so we cannot rely on github comments for formal vote 16:26:45 ack ajs6f 16:26:59 q+ 16:27:24 ajs6f: if i understand correctly we can't use github to record votes, we could use it to vote and then record these votes in the minutes 16:27:27 ack bigbluehat 16:27:29 ... if its convenient 16:28:39 ivan: in this case all the thumbs down are members of the WG, but in general we should be careful not to record non-WG votes 16:28:42 PROPOSAL: Close #40 wontfix. 16:28:46 +1 16:28:46 +1 16:28:48 +1 16:28:50 +1 16:28:52 +1 16:28:54 =1 16:29:00 s/=1/+1 16:29:09 RESOLVED: Close #40 wontfix. 16:29:23 +1 16:29:36 SUBTOPIC: @documentation keyword 16:29:44 Link: https://github.com/w3c/json-ld-syntax/issues/42 16:29:56 scribenick: azaroth 16:30:25 timCole: This stems in part from the discussion last week and on #32 that we should allow use of a keyword like @documentation that can point to external information about a context or frame 16:30:44 ... there were a couple constraints suggested that it could appear only at the root of the context and not within term definitions 16:31:18 ... Avoids allowing people to put @documentation everywhere. Ivan mentioned documenting data. This lets you connect something to the context 16:31:38 ... it's at times unnecessary, if you've done a good job like schema has. But there is value in having human readable information about the scheme you're using as a whole 16:31:39 q+ to support this, but to ask how we'd prevent scope creep 16:31:42 ... so I still like the idea 16:31:51 scribenick: timCole 16:31:53 ack bigbluehat 16:31:53 bigbluehat, you wanted to support this, but to ask how we'd prevent scope creep 16:32:02 q+ 16:32:13 bigbluehat: reasonable as a fallback to next approach we will discuss 16:32:27 ajs6f has joined #json-ld 16:32:29 q+ 16:32:31 ... my concern is that key will be mis-used, e.g., for each term definition 16:32:49 q+ to suggest making it an error condition that processors must check 16:32:50 ... people will expect that they can use it wherever 16:32:56 ajs6f_ has joined #json-ld 16:32:59 ... could even start showing up in data 16:33:02 ack gkellogg 16:33:02 q+ 16:33:06 \q+ 16:33:06 ... may not be avoidable 16:33:13 q+ 16:33:25 gkellogg: well if it does show up outside of context it will be ignored 16:33:27 q- 16:33:39 q+ 16:33:55 ... there is evidence that use of @ is already an issue 16:34:00 q+ to ask if the issue is blocked by the @keyword issue? 16:34:14 ... within in term definitions if it appeared that would generate an error 16:34:45 ... other question to what extent is it ignored, e.g., should @documentation appear in compacted document 16:35:11 (The @ as keyword issue: https://github.com/w3c/json-ld-syntax/issues/16 ) 16:35:12 ... generally ambivalent, given that follow your nose works pretty well maybe not needed 16:35:16 q? 16:35:18 ack azaroth 16:35:18 azaroth, you wanted to suggest making it an error condition that processors must check and to ask if the issue is blocked by the @keyword issue? 16:35:24 ... could create questions we'll likely stumble over 16:35:52 azaroth: to bigbluehat's point we could require that @documentation could only appear in particular places 16:36:19 ... but what does the group think about relationship to issue #16, should we table until we discuss that issue 16:36:58 ... for example, if we say non-defined keywords starting with @ not allowed, then any misuse would generate warning or error 16:37:03 q? 16:37:05 ack ivan 16:37:13 q- 16:37:30 ivan: to clarify, @documentation is for context as a whole 16:37:51 ... but I could still put @documentation in a nested context 16:37:58 azaroth: yes 16:38:08 q+ to ask about implementations of this 16:38:30 q+ 16:38:31 gkellogg: anywhere @version could exist, @documentation could exist 16:38:36 ack bigbluehat 16:38:36 bigbluehat, you wanted to ask about implementations of this 16:38:41 ivan: co-context not nested 16:38:55 bigbluehat: continue to be concerned about scope creep 16:39:01 +1 to bigbluehat’s concern 16:39:08 q+ 16:39:12 ack ajs6f 16:39:17 +1 to bigbluehat's cocerns 16:39:40 ajs6f: my concern is similar, additionally not sure this meets the concern we started with 16:39:51 +1 to ajs6f 16:39:53 q? 16:39:54 ack timCole 16:39:55 ... while this might be useful, may not align with original concern 16:40:00 scribenick: azaroth 16:40:32 timCole: In terms of benjamin's concern, I think that's a reason to defer until we face #16. If we outlaw @keys except those defined, then the issue goes away as it's not a special case, it's just a misuse 16:40:45 ... I think Adam's concern is relevant, but that it is still useful to do 16:40:46 q? 16:40:54 scribenick: timCole 16:41:04 azaroth: any further comments? 16:41:56 ... to summarize, there is general agreement that it doesn't really solve original use case from #32, but we generally have agreed we're not going to solve that 16:42:21 ... 2nd there is concern about mis-use, which might be affected by decision on issue #16 16:42:47 ... regardless of original, I think I've heard that documentation in general might be useful, but let's quantify 16:43:06 ... do we think documentation of context is a valeuable thing to specify somehow? 16:43:11 0 16:43:11 +1 16:43:15 0 16:43:16 +1 16:43:18 0 16:43:23 0 16:43:24 0 16:43:27 q+ 16:43:50 q- 16:43:56 ivan: my problem is that in practice I belive that proper documentation of data is really much more important 16:44:12 ... in practice people reuse other people's context, so this is secondary 16:44:15 +1 to ivan 16:44:50 azaroth: so while no one is dead set against it, there seems minimal support for the feature we should close, won't fix 16:44:58 q+ 16:45:04 q+ 16:45:23 ... and leave whether you'll use content neogtiations as a best practice. 16:45:27 q? 16:45:29 ack gkellogg 16:46:05 ack ivan 16:46:09 gkellogg: if we decide not to go forward it doesn't mean that the issue has gone away, we could still talk about this in best practice 16:46:18 ... a way to solve without adding new features 16:46:46 ivan: reason I raised issue #44, I'd rather make it easier for developers to use existing mechanisms 16:47:08 ... so we should focus on making it easier for users to make use of these mechanisms 16:47:37 gkellogg: doesn't solve documenting context, but..l. 16:48:07 PROPOSAL: Close documentation issues won't fix and defer a future best practice non-normative discussion 16:48:26 There are other mechanisms we’ve discussed for documenting a context that don’t require adding to the language, these should go in best practices. 16:48:38 +1 16:48:39 +1 16:48:41 +1 16:48:42 +1 16:48:42 +1 16:48:44 +1 16:48:47 +1 16:48:52 +1 16:48:56 q+ 16:49:03 RESOLVED: Close documentation issues won't fix and defer a future best practice non-normative discussion 16:49:11 q+ to ask about https://github.com/w3c/json-ld-syntax/issues/43 as best practice 16:49:24 ack ivan 16:49:25 ivan: can processors mix yaml and json-ld? can I decide to write my context in yaml? 16:49:46 ack bigbluehat 16:49:46 bigbluehat, you wanted to ask about https://github.com/w3c/json-ld-syntax/issues/43 as best practice 16:49:49 gkellogg: we've opened the door, but we have not place normative requirements on processors 16:50:04 bigbluehat: you can write json file inside of yaml 16:50:30 ... is there work needed now (for best practices) on content-negotiation 16:50:41 azaroth: let's come back to it a little later 16:50:50 +1 to Ivan to not close 16:50:58 i've put json-ld with comments in yaml files before and just processed the data into json later. works fine. 16:51:05 ivan: may not want to close that issue but mark it as postponed 16:51:22 azaroth: i will open a new issue to make sure we discuss later 16:51:41 azaroth: do we need a best practice label? 16:51:50 ACTION: Rob to create new best practice issue, tracked back to 43,42,40,32 and whether WG or CG should do it 16:51:53 gkellogg: do we or the CG make the best practices? 16:52:44 azaroth: should we summarize the type issues to encourage comments over the next 7 days? 16:52:50 TOPIC: @type issue block 16:53:00 link: https://github.com/w3c/json-ld-api/issues/4 16:53:27 gkellogg: sure - issue #4 would relax an existing constraint that only one alias for a keyword, e.g., both type and profile as aliases for @type 16:53:35 q+ 16:53:48 q+ to describe use case 16:53:52 ack timCole 16:54:29 ack azaroth 16:54:29 azaroth, you wanted to describe use case 16:54:55 q+ 16:55:19 ack bigbluehat 16:55:31 q+ wants to ask why the restriction was instituted? 16:55:56 azaroth: useful if coming from an existing json that has multiple ways to say the same thing 16:56:14 bigbluehat: examples would be good 16:56:29 azaroth: we should reach out to original commentor 16:56:31 q? 16:56:43 zakim, pointer 16:56:43 I don't understand 'pointer', azaroth 16:57:14 ACTION: Rob to put in pointer to #4 16:57:15 rrsagent, pointer? 16:57:15 See https://www.w3.org/2018/08/10-json-ld-irc#T16-57-15 16:57:38 Link: https://github.com/w3c/json-ld-syntax/issues/34 16:58:17 gkellogg: issue #34 would allow us to use containers to put type in array form 16:58:48 azaroth: what we wanted to do was have a resource with only a single type where the type was given in an array 16:59:11 ... if it can ever have multiple values, then it is always an array (json best practices) 16:59:39 q+ 16:59:47 q- 16:59:50 ... but because type is defined by specification, in the context you can't specify that it is always an array. 17:00:00 ... the playground example shows that it doesn't work 17:00:02 q? 17:00:19 ack wants 17:00:19 wants, you wanted to ask why the restriction was instituted? 17:01:00 gkellogg: the concern (#7) is that the way type is expanded can be influenced by a number of things 17:01:12 link: https://github.com/w3c/json-ld-api/issues/7 17:01:26 ... initial requestor wants to customize the model for this, CG had a lot of discussion, will review before next time. 17:01:48 azaroth: please review the type issues and comment before next call. 17:01:54 q? 17:01:58 ... adjourn. 17:02:04 rrsagent, draft minutes 17:02:04 I have made the request to generate https://www.w3.org/2018/08/10-json-ld-minutes.html ivan