- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Mon, 9 Apr 2018 11:32:47 -0700
- To: Linked JSON <public-linked-json@w3.org>
Thanks to Benjamin Young for scribing this week! The minutes now available: https://json-ld.org/minutes/2018-04-10/index.html.
Full text of the discussion follows for W3C archival purposes.
Gregg Kellogg
gregg@greggkellogg.net
JSON-LD Community Group Minutes for 2018-04-09
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 and 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
Robert Sanderson: PR:
https://github.com/json-ld/json-ld.org/pull/628
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
https://github.com/json-ld/json-ld.org/pull/629
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
Gregg Kellogg: https://github.com/json-ld/json-ld.org/projects/2
...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
Received on Monday, 9 April 2018 18:33:15 UTC