The W3C JSON-LD Community Group

JSON-LD Syntax and API

Go Back

JSON-LD CG Telecon

Minutes for 2018-04-10

Agenda
https://lists.w3.org/Archives/Public/public-linked-json/2018Apr/0002.html
Topics
  1. Announcements?
  2. Open PRs
  3. #628 Limit the use of `@none` in language and index maps to 1.1 only
  4. #629 Remove the `pruneBlankNodeIdentifiers` option for framing
  5. Issues to Defer
  6. Finishing up work and final reports
Resolutions
  1. Accept #628
  2. Accept #629
  3. Defer #246, #333, #397, #491, #547, #583, #584, #590, #595, #598 ; Do not defer #581
Organizer
Robert Sanderson
Scribe
Benjamin Young, Robert Sanderson
Present
Robert Sanderson, Gregg Kellogg, Benjamin Young, Herm Fisher, David I. Lehn, David Newbury
Benjamin Young is scribing.

Topic: Announcements?

Robert Sanderson: As far as anyone knows, the charter process is going well
...anything else to cover? or should we dive into issues?

Topic: Open PRs

Topic: #628 Limit the use of `@none` in language and index maps to 1.1 only

Gregg Kellogg: This allows the term selection only in 1.1 mode
Robert Sanderson: Yep. this looks good to me
...as you said this is a bug fix
...and to not do this would be wrong
...any comments or objections?
PROPOSAL: Accept #628
Robert Sanderson: +1
Gregg Kellogg: +1
Benjamin Young: +1
Herm Fisher: +1
RESOLUTION: Accept #628

Topic: #629 Remove the `pruneBlankNodeIdentifiers` option for framing

Gregg Kellogg: Basically this says, when framing clean up the blank node identifiers
...this removes pruneBlankNodeIdentifiers as an option
...and makes this part of 1.1 proper
David I. Lehn: #628 Has some bugs. using <p> tag by mistake. it's rendering wrong on the live site now.
Robert Sanderson: If we were to leave pruneBlankeNodeIdentifiers in, the use is to get ride of any blank nodes only used once
...so in 1.1 all of those go away as you would expect?
Gregg Kellogg: Yes. if they are not used for referencing
Robert Sanderson: So. in 1.1 this happens automatically, so what is the 1.0 behavior?
Gregg Kellogg: Basically, all node objects get an ID during flattening
...so anything that was embedded are now referenced
...the default behavior is 1.1 is to remove any that are not necessary for linking
Robert Sanderson: So if you were wanting features from 1.1, but for some reason you wanted the blank node identifiers kept around, then there'd be no way to do that?
...not that I can think of why you'd want to keep them
Gregg Kellogg: Yes. there'd not be a way to keep them in 1.1
Robert Sanderson: If you had a client which expected the @id to always be present, then that would break
Robert Sanderson is scribing.
Benjamin Young: Some discussion in the verifiable claims group about "Developer Ergonomics". I think it's fine to strip them by default -- they're automatically assigned anyway, so would be fine to strip them as they're not part of the data. Trying to think through what it means to that camp though ... probably it's better as there's no creation of data
Gregg Kellogg: It only matters for framing. If you rely on framing to get the shape from RDF, so you frame the results so it looks like the canonical from from Claims or anywhere else
... without this you would not be able to get the expected form, especially where Claims make use of anonymous named graphs
... an alternative was discussed that would retain the option and not prune them, but still do the identifiication. It requires doing the work to find the removable ids, and then pass that through several functions, making the algorithm more complex for very little perceived benefit
... the issue of pushback on JSON-LD as a format is an advocacy thing, and I encourage people to get involved and discuss the issues
... was brought up in claims, but no follow through.
Benjamin Young: Great summary, thank you!
Benjamin Young is scribing.
Robert Sanderson: So. I think we've covered all the bases on this one
...any further questions or comments on #629 or it's related issue #627?
PROPOSAL: Accept #629
Robert Sanderson: +1
Gregg Kellogg: +1
Benjamin Young: +1
Herm Fisher: +1
RESOLUTION: Accept #629

Topic: Issues to Defer

Gregg Kellogg: I'd like to treat these as a block
...and not go into details on each one
...basically, we'd like to wrap up the CG work and take long-term or hard-to-resolve things to the WG
...the first is #246
#246 Ignoring semantically meaningless nesting – this is mostly about people not liking the @nest keyword, and we can’t really solve that here.
Gregg Kellogg: The work here is done, except for the bike shedding around the keyword @nest
...we can either bikeshed or defer
Robert Sanderson: I'd prefer we defer and avoid bikeshedding
Gregg Kellogg: Next is #333
#333 Support JSON values that aren't mapped – I thought I might get to this, but I think it’s big enough that we shouldn’t introduce more FUD right now.
Gregg Kellogg: I think the way that would work is to allow and expanded range for @value
...there is some crossover with framing
...which makes use of those references
...it's too be an issue for us to tackle
...so I recommend deferring
Robert Sanderson: +1 To deferring that also
...it's an important one to get into the spec and to get correct
Gregg Kellogg: Next is #397
#397 Support @values for describing multidimensional containers (list of lists)
Gregg Kellogg: This also handled some things related to GeoJSON--which uses lists of lists
...there were some advocates on the Semantic Web mailing list
...whom I encouraged to join the CG...and some did
...it is something that if fixed would help developers
...but it's big, so I suggest we defer it
Robert Sanderson: The next is #491
#491 Define how to specify the json-ld profile in a request to a server and include framing as an option
Robert Sanderson: I brought up the list of lists at a conference, and there was a good bit of support
...so solving this would be a great help
Gregg Kellogg: Now #491
#491 Define how to specify the json-ld profile in a request to a server and include framing as an option
...this one is how to further express HTTP headers and things to express framing, expansion, etc.
...there are a number of security concerns here
...if a client can provide frames, etc, to the server it could introduce many types of problems
...we'd first envisioned this sort of work happening on the client
...good ideas here, just not time to explore them in the CG
Gregg Kellogg: #547 Content addressable contexts
...this one is for reusing context without retrieval, but still with integrity
...there are also Verifiable Claim situations where you don't want to over-reveal your activities by retrieving contexts at claim verification time
...it's also a great thing to explore, but alas...time
Gregg Kellogg: Now #581 Multi-version processing
Robert Sanderson: I believe this is one of mine
Gregg Kellogg: Right now, if you don't state 1.1, it will be treated as 1.0--even if it includes 1.1 structure
...the other question is do we need to state a version at all?
...or are we going to expect all processors to be supportive of 1.1
David I. Lehn: What's the objective in discussing these since we're just deferring them?
Robert Sanderson: Mainly we're looking for things we can close instead of defer
David I. Lehn: Well, this #581 is rather a big deal, and should probably be solved sooner rather than later
Gregg Kellogg: We can certainly choose not to defer it, but we will need code and content written for a solution
...we might also base it off whether the @context references 1.1
...but to avoid bikeshedding this, we can either choose to defer it or decide the CG will address it
David I. Lehn: It's a question of when
...some of these have been deferred for 5+ years
...and I'm just wondering what the process is here
Gregg Kellogg: Our expectation is that the WG is starting up in June
...and we have to get our spec into a state to issue a final report
...so we have to wrap things up at some point
...but it's still April, so we do still have some time
...however I'm personally limited in my time to address all these myself
...if there are people who want to tackle these issues
...we can choose not to differ #581
Robert Sanderson: I agree with taaz
...this really is a unique issue as it's not a feature, but a question of is there a new version at all
...if we get to June without a solution, then we can defer it then
David Newbury: I'm not familiar with W3C process, but how long would be a deferral be?
Gregg Kellogg: It would be 2020 before a final recommendation would be published
...but the WG could push for working drafts far sooner
...essentially the WD could serve as a simple rubber stamp of what the CG has done
...and then we would continue from there
...all of these are points along the way where we show that the community has concluded and agrees
David Newbury: So this is more about getting the CG drafts as solid as possible before the WG starts, correct?
Robert Sanderson: Yes.
Robert Sanderson: In order to get the WG prepared we need to get it focused on
...so that it's not just reviewing the CG's work, but also knows where to go next
...and if it's more solid, then the work is clearer
...we had the same situation with the Open Annotation => Web Annotation transition
...we chose to not open certain cans of worms before the WG came along
...because it partly results in conversation bifurcation--which gets really really messy
...so doing this cleanly is helpful
...so for #581...should we set a deadline?
Gregg Kellogg: Let's defer on when to time the work on this, but yes, we'll keep it off the general defer list
Gregg Kellogg: #583 Introducing @dir ?
...this is iherman's idea for dealing with language direction in JSON-LD
...it lacks support atm, but language direction is a concern across the W3C
Gregg Kellogg: #584 Revisit empty string as term
...is partly driven by PHP implementations
...there are some reasons and scenarios where this is important, but it can wait for the WG
Gregg Kellogg: #590 "Lax” IRIs
...much of this one is about confusion over JSON-LD
...but there may be work to clarify this further
Gregg Kellogg: #595 Native support for schema:ListItem
...this partly came about from dbrickly which might benefit schema.org
...but at this point, I think it can wait for the WG
Gregg Kellogg: Lastly, #598 Warn or error if non-keyword strings having "@" are encountered
...basically, do we want to reserve `@` as a JSON-LD keyword space
...in 1.1 we've introduced new keywords which does introduce the risk that someone might have used @ + a string
...and it has come up in the past, so we should probably at least raise an error
David Newbury: Is there any reason to not just solve this one?
Gregg Kellogg: It raises some incompatibility with 1.0
...and I didn't feel I had enough insight into it to make that call
...and ideally we'd have more folks in the room when we do decide it
David I. Lehn: Maybe it could be a library-level option?
Gregg Kellogg: Well, even that should be in the spec also
David I. Lehn: Yeah...it should probably be one way or the other
Gregg Kellogg: Or perhaps some other way to announce keywords
David I. Lehn: Then let's defer it
Robert Sanderson: It's not a critical blocking feature, so +1 to deferring
Gregg Kellogg: So let's get a proposal to defer all these except #581
PROPOSAL: Defer #246, #333, #397, #491, #547, #583, #584, #590, #595, #598 ; Do not defer #581
Robert Sanderson: _Workergnome are you cool with that?
Gregg Kellogg: +1
Benjamin Young: +1
Robert Sanderson: +1
David I. Lehn: +1
Herm Fisher: +1
David Newbury: +1
RESOLUTION: Defer #246, #333, #397, #491, #547, #583, #584, #590, #595, #598 ; Do not defer #581
Robert Sanderson: One of us will wrangle the github stuff after the call
Gregg Kellogg: I also removed these from the 1.1 project as well

Topic: Finishing up work and final reports

...and we can also use the project to manage what we'll do (or won't do) within the CG
David I. Lehn: Is this different than milestones?
Gregg Kellogg: Yes, this is a separate area that's managed manually
David I. Lehn: That #628 PR had some errors in it, but it's already merged
...it had a <p> tag in it, but was maybe to be something else
Robert Sanderson: There's about 5 minutes left
...and we should talk through how to finalize this, and what happens to the CG once the WG starts
...closing the CG would be a nightmare
...but we will make it clear that the WG is where the action is happening
...in the annotation groups, we originally tried to juggle both
...but ultimately it was more work than value
...essentially, there's a good bit of IPR and discussion juggling mess that's best avoided
...however, it does mean that non-Invited Experts, and non-Members will need to send in a submission request to the lists
...are we OK with that approach?
...or is there some other way to include CG members while the WG is going on without introducing confusions or issues?
Gregg Kellogg: Perhaps we should just check who's available to join the WG
Herm Fisher: Can an individual join?
Robert Sanderson: There has been some push back against Invited Experts...so we need to be judicious with how we hand them out
Gregg Kellogg: Invited experts are essentially now provided for people already integral to the progress of the specifications or related projects
...there are also some member organizations one can join and then come in under those affiliations
...but that is something Herm or others can take up with the chairs and the team member for the group once we're chartered
Robert Sanderson: One the WG is finished, we'll have more discussions about any other work that happens beyond the WG
...as well as other work that might be best done in the CG
...things that are deferred or considered out of scope for the WG
...given the time, are there any final thoughts?
...if something like that comes to mind
...send a note to the CG mailing list
...and we'll discuss there
...next call in a couple weeks time
...thanks all!
Herm Fisher: Bye