IRC log of json-ld on 2018-08-10

Timestamps are in UTC.

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