JSON-LD Working Group Telco — Minutes
Date: 2018-08-10
See also the Agenda and the IRC Log
Attendees
Present: Adam Soroka, Rob Sanderson, Benjamin Young, Gregg Kellogg, Ivan Herman, Jeff Mixter, Tim Cole, David I. Lehn
Regrets: Harold Solbrig, Dave Longley, David Newbury
Guests:
Chair: Rob Sanderson
Scribe(s): Tim Cole, Rob Sanderson
Content:
- 1. Approve minutes of last call
- 2. Announcements
- 3. Add API support for lists containing lists (PR)
- 4. Documentation Issues
- 5. @type issue block
- 6. Resolutions
- 7. Action Items
1. Approve minutes of last call
Proposed resolution: Approve minutes of last call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-03-json-ld (Rob Sanderson)
Benjamin Young: +1
Gregg Kellogg: +1
Ivan Herman: +1
Benjamin Young: +1
Ivan Herman: +1
Tim Cole: +1
Jeff Mixter: +1
Rob Sanderson: +1
Resolution #1: Approve minutes of last call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-03-json-ld
2. Announcements
Rob Sanderson: reminder about TPAC
… any other announcements?
… hearing no further announcement, move to next
3. Add API support for lists containing lists (PR)
Gregg Kellogg: link: https://github.com/w3c/json-ld-api/pull/16
Gregg Kellogg: we don’t have an issue for PR 16, json-ld api, but we need input
Rob Sanderson: how much discussion does PR need?
Gregg Kellogg: I think we approved the idea, we would like another implementation to make sure we’ve got it right for the PR
Rob Sanderson: Dave Longley could be helpful, but not on call
Ivan Herman: procedural - this PR is a new feature not in the Community Report, so we need to make sure we list it
Gregg Kellogg: there is a recently added entry in the changes since 1.0
Ivan Herman: thanks
3.1. Relationship to other implementers
Benjamin Young: about getting more implementers in the room
Benjamin Young: https://github.com/json-ld/json-ld.org/pull/667
Benjamin Young: I’ve been reaching out to other developers and json-ld.org
… hoping that will at least watch repositories
… is this something that needs the 1.1 toggle? OR can json 1.0 handle it?
Gregg Kellogg: 1.0 processor might generate a list of list error
… it’s a matter of what happens when a processor encounters it
… in the test suite there is an option for this
… this does not require to put the processor in the 1.1 mode
… but we could discuss / debate
… there is no change in the context processing
Benjamin Young: as I talk to implementers, there’s always the ‘we’ll implement it when it’s ready’
… so is this the kind of thing that they could start working on ahead of final 1.1 syntax rollout
… encourage implementers to get started on new features as soon as viable
Gregg Kellogg: I try to test as the API changes go into the draft spec
Rob Sanderson: +1 to longer versioning discussion later
Ivan Herman: would like to take versioning / signaling probably needs a longer discussion independent of this PR
… let’s add it to a near term agenda
Gregg Kellogg: bigbluehat raised question of when features are stable enough to begin implementing
… so do we need some form of a statement of when developer can implement something without having to worry about it going away
Rob Sanderson: good if worded carefully so we don’t paint ourselves into a corner
… 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
… so we could say something like, ‘lacking further reasoning, we accept the CG drafts, but…’
Ivan Herman: even that may be too much. There may be features CG added that don’t fit with WG criteria/charge
… so we have to be very careful.
… I remember from RDFa group that some of us went through implementation for features subsequently thrown out.
Benjamin Young: to clarify, I wasn’t wanting promises outside normal publishing cycle, but would like others to be paying attention
… so they can see what’s happening and get ready for, and if excited take a crack at it to inform our discussions.
… looking for ways to involve developers sooner rather than later
Rob Sanderson: back to PR do we need to wait for further review?
Gregg Kellogg: 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
4. Documentation Issues
Rob Sanderson: issue #32 was split into 4 potential issues, 3 of which have been written up and Manu commented about the 4th
… propose we discuss in order, 40, 42, 43
4.1. Inline metadata escaping
Rob Sanderson: Link: https://github.com/w3c/json-ld-syntax/issues/40
Rob Sanderson: Harold send regrets, but clarified end of line question that came up
… proposal is that we use ‘@@’ to indicate that the following value is not processed.
… processors not expected to retain through any transformation
… convention is that ‘@@’ and its value must be ignored
… so, we reserve ‘@@’ and is should not appear in a context
… what do we all think about that proposal
Gregg Kellogg: two-fold concerns - example he points to, the comment is outside the context
… second, is aesthetic
Benjamin Young: example also shows using the key over and over, which creates duplicate keys
Rob Sanderson: my objection is that proposal is really a bikeshed paint color on @comment
… not what we want
Gregg Kellogg: we now have 5 minuses on this issue, should we consider that as a vote by itself?
Ivan Herman: in another group this led to problems; thumbs up and thumbs down not frozen, so we cannot rely on github comments for formal vote
Adam Soroka: 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
… if its convenient
Ivan Herman: 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
Proposed resolution: Close #40 wontfix. (Rob Sanderson)
Benjamin Young: +1
Rob Sanderson: +1
Tim Cole: +1
Gregg Kellogg: +1
Ivan Herman: +1
Adam Soroka: +1
Resolution #2: Close #40 wontfix.
Jeff Mixter: +1
4.2. @documentation keyword
Rob Sanderson: Link: https://github.com/w3c/json-ld-syntax/issues/42
Tim Cole: 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
… there were a couple constraints suggested that it could appear only at the root of the context and not within term definitions
… Avoids allowing people to put @documentation everywhere. Ivan mentioned documenting data. This lets you connect something to the context
… 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
… so I still like the idea
Benjamin Young: reasonable as a fallback to next approach we will discuss
… my concern is that key will be mis-used, e.g., for each term definition
… people will expect that they can use it wherever
… could even start showing up in data
… may not be avoidable
Gregg Kellogg: well if it does show up outside of context it will be ignored
… there is evidence that use of @ is already an issue
… within in term definitions if it appeared that would generate an error
… other question to what extent is it ignored, e.g., should @documentation appear in compacted document
Rob Sanderson: (The @ as keyword issue: https://github.com/w3c/json-ld-syntax/issues/16 )
Gregg Kellogg: generally ambivalent, given that follow your nose works pretty well maybe not needed
… could create questions we’ll likely stumble over
Rob Sanderson: to bigbluehat’s point we could require that @documentation could only appear in particular places
… but what does the group think about relationship to issue #16, should we table until we discuss that issue
… for example, if we say non-defined keywords starting with @ not allowed, then any misuse would generate warning or error
Ivan Herman: to clarify, @documentation is for context as a whole
… but I could still put @documentation in a nested context
Rob Sanderson: yes
Gregg Kellogg: anywhere @version could exist, @documentation could exist
Ivan Herman: co-context not nested
Benjamin Young: continue to be concerned about scope creep
Gregg Kellogg: +1 to bigbluehat’s concern
Jeff Mixter: +1 to bigbluehat’s cocerns
Adam Soroka: my concern is similar, additionally not sure this meets the concern we started with
Rob Sanderson: +1 to ajs6f
Adam Soroka: while this might be useful, may not align with original concern
Tim Cole: 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
… I think Adam’s concern is relevant, but that it is still useful to do
Rob Sanderson: any further comments?
… 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
… 2nd there is concern about mis-use, which might be affected by decision on issue #16
… regardless of original, I think I’ve heard that documentation in general might be useful, but let’s quantify
… do we think documentation of context is a valuable thing to specify somehow?
Ivan Herman: 0
Tim Cole: +1
Gregg Kellogg: 0
Rob Sanderson: +1
Adam Soroka: 0
Benjamin Young: 0
Jeff Mixter: 0
Ivan Herman: my problem is that in practice I believe that proper documentation of data is really much more important
… in practice people reuse other people’s context, so this is secondary
Adam Soroka: +1 to ivan
Rob Sanderson: so while no one is dead set against it, there seems minimal support for the feature we should close, won’t fix
… and leave whether you’ll use content negotiations as a best practice.
Gregg Kellogg: 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
… a way to solve without adding new features
Ivan Herman: reason I raised issue #44, I’d rather make it easier for developers to use existing mechanisms
… so we should focus on making it easier for users to make use of these mechanisms
Gregg Kellogg: 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.
Proposed resolution: Close documentation issues as won’t fix and defer a future best practice non-normative discussion (Rob Sanderson)
Adam Soroka: +1
Rob Sanderson: +1
Gregg Kellogg: +1
Tim Cole: +1
Jeff Mixter: +1
Ivan Herman: +1
Benjamin Young: +1
David I. Lehn: +1
Resolution #3: Close documentation issues as won’t fix and defer a future best practice non-normative discussion
Ivan Herman: can processors mix yaml and json-ld (and I can comment in yaml…)? Can I decide to write my context in yaml?
Gregg Kellogg: we’ve opened the door, but we have not place normative requirements on processors
Benjamin Young: you can write json file inside of yaml
… is there work needed now (for best practices) on content-negotiation
Rob Sanderson: let’s come back to it a little later
Jeff Mixter: +1 to Ivan to not close
David I. Lehn: i’ve put json-ld with comments in yaml files before and just processed the data into json later. works fine.
Ivan Herman: may not want to close that issue but mark it as postponed
Rob Sanderson: i will open a new issue to make sure we discuss later
Rob Sanderson: do we need a best practice label?
Action #1: Rob to create new best practice issue, tracked back to 43,42,40,32 and whether WG or CG should do it
Gregg Kellogg: do we or the CG make the best practices?
Rob Sanderson: should we summarize the type issues to encourage comments over the next 7 days?
5. @type issue block
5.1. Relax the colliding keywords constraint for @type
Rob Sanderson: link: https://github.com/w3c/json-ld-api/issues/4
Gregg Kellogg: issue #4 would relax an existing constraint that only one alias for a keyword, e.g., both type and profile as aliases for @type
Rob Sanderson: useful if coming from an existing json that has multiple ways to say the same thing
Benjamin Young: examples would be good
Rob Sanderson: we should reach out to original commenter
Action #2: Rob to put in pointer to #4
Ivan Herman: pointer is: https://www.w3.org/2018/08/10-json-ld-irc#T16-57-15
5.2. @type as @container:@set?
Rob Sanderson: Link: https://github.com/w3c/json-ld-syntax/issues/34
Gregg Kellogg: issue #34 would allow us to use containers to put type in array form
Rob Sanderson: what we wanted to do was have a resource with only a single type where the type was given in an array
… if it can ever have multiple values, then it is always an array (json best practices)
… but because type is defined by specification, in the context you can’t specify that it is always an array.
… the playground example shows that it doesn’t work
Gregg Kellogg: the concern (#7) is that the way type is expanded can be influenced by a number of things
5.3. Allow processing model of @type to be customized
Rob Sanderson: link: https://github.com/w3c/json-ld-api/issues/7
Gregg Kellogg: initial requestor wants to customize the model for this, CG had a lot of discussion, will review before next time.
Rob Sanderson: please review the type issues and comment before next call.
… adjourn.
6. Resolutions
- Resolution #1: Approve minutes of last call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-03-json-ld
- Resolution #2: Close #40 wontfix.
- Resolution #3: Close documentation issues as won’t fix and defer a future best practice non-normative discussion