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

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

7. Action Items