JSON-LD Telco — Minutes

Date: 2020-04-03

See also the Agenda and the IRC Log

Attendees

Present: Benjamin Young, Gregg Kellogg, Harold Solbrig, Ruben Taelman, Ivan Herman, Pierre-Antoine Champin, David I. Lehn, Manu Sporny

Regrets: Dave Longley

Guests:

Chair: Rob Sanderson

Scribe(s): Benjamin Young, Rob Sanderson

Content:

Rob Sanderson: any announcements or reminders?
… any recent changes?

1. Changes to the documents

Gregg Kellogg: there’s been some activity on getting some implementation reports

Gregg Kellogg: https://w3c.github.io/json-ld-api/reports/

Gregg Kellogg: here’s the latest version ^^
… one is pyLD, but there’s lots more PRs to merge
… no tests for JSON-LD yet, because they’ve got PRs pending
… there are 3 implementations from rubensworks–which show great progress
… there were also some issues around compaction
… which came up along the way
… he noted a number of issues which are all editorial
… so they’re all in PR 440 on the API repo
… mostly compaction wording
… rubensworks added a test
… and I think that’s it

Rob Sanderson: some some editorial and lots of implementation report updating

Gregg Kellogg: I didn’t see any mass communication about tests

Benjamin Young: I’ll get something up today routing people to the community group

Gregg Kellogg: one thing about doing a poll would give us one place to find the info later
… whereas in the CG it’d be across lots of emails
… and the CG isn’t really the right place…since this is a WG effort

Benjamin Young: I’d prefer to put it on lists, so anyone can see it future or present

Rob Sanderson: sending an email seems easiest to do
… the WBS is…no offense…not the most user friendly thing
… I’m fine with either, though

Benjamin Young: we could curate the email output

Gregg Kellogg: the important thing is to get it out there

Action #1: send out APB about implementations–asking for folks to respond about their status (Benjamin Young)

Rob Sanderson: any updates from implementations?
… I’ll reach out to “my” Greg to see about getting his report in

Gregg Kellogg: think we decided to freeze tests today

2. Process

Rob Sanderson: so, ivan sent the draft recharter to communications, who sent it to the AC, and we have some early support

Ivan Herman: so the feedback given was very general–not specific to our charter
… but an issue for charters in general
… the criticism was that members +1 charters, but they should be clear about why they support it

Rob Sanderson: so, when the actual AC vote comes out, we can have our respective AC reps say a bit more about why they care and are supporting the work
… and that will hopefully encourage others (through modeling good behaviour)

Harold Solbrig: should we resubmit letters with more details then?

Rob Sanderson: I wouldn’t bother as this isn’t the vote
… when the AC vote actually goes out, is when the more persuasive support would be helpful

Ivan Herman: so, really all they have to say is yes or no
… and this advance content is very loose
… so hsolbrig if you want to be supportive on the list, that’s totally fine
… I wouldn’t give this whole conversation much weight yet anyway
… it’s not an official thing yet at least

Rob Sanderson: yeah, it was meant to be “don’t feel obliged to do it” (to hsolbrig), not discouragement
… so, is there a process timeline unrolling at this point?

Ivan Herman: this advance notice doesn’t have a real formal deadline
… the AC voting period is set to 4 weeks
… and due to the COVID drama, that may be extended to 6 weeks
… at the end of April, we’ll have some administrative things to do
… and then we could start the formal procedure to make it happen

Rob Sanderson: if you have charter comments, please put them in
… anyone have a link handy for the charter?
… please make issues in that repo, and if time, PRs are welcome!

Ivan Herman: charter repo

Rob Sanderson: any other comments?

3. Issues

Rob Sanderson: there don’t seem to be any open issues for our REC track docs
… which aren’t simply editorial
… anyone know otherwise

Gregg Kellogg: https://github.com/w3c/json-ld-api/issues/428

Gregg Kellogg: just that one from azaroth about a better example for included blocks
… and 428 which I summed up as basically saying you don’t have to implement it the way the spec says
… the desire was that we describe the type of all the algorithm properties
… specifically that activeProperty be null
… I think it’d be overkill
… and that a careful reading would reveal that anyhow

Rob Sanderson: there was an ask to have the exact Domain for each input variable

Gregg Kellogg: and I think he meant Range

Rob Sanderson: I do think that’s overkill

Gregg Kellogg: if WebIDL were more widely scoped, then this stuff would probably be useful
… but as it is, doing this work probably doesn’t help much

Rob Sanderson: and just makes lots of extra work
… I’m sure it’d be lovely for a statically typed language
… but wow…major document expansion

Gregg Kellogg: I don’t think any other W3C spec has as much explanation around this as we do already

Rob Sanderson: we ok with closing “wontfix” for the remaining part of the suggestion?

Benjamin Young: +1

Proposed resolution: Close api #428, won’t add possible variable values to documentation (Rob Sanderson)

Pierre-Antoine Champin: +1

Harold Solbrig: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Benjamin Young: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Resolution #1: Close api #428, won’t add possible variable values to documentation

4. Notes Issues

Rob Sanderson: any other issues? besides my need to improve the examples I provided?

4.1. Streaming Note

Rob Sanderson: so, the streaming note. rubensworks could you give us an update?

Ruben Taelman: https://github.com/w3c/json-ld-streaming/pull/11

Ruben Taelman: this morning I opened a PR for making ivan’s suggested changes
… which were related to @type
… so the wording has been changed to match that
… and I updated the test suite

Rob Sanderson: and the only issue…meaning that everything otherwise folks thing it’s in good shape/

Gregg Kellogg: I think it’s great
… I intend to implement it once I’m done with these other things I’m doing

Ivan Herman: before going to CBOR
… when to do we formally plan to formally publish the streaming note?

Rob Sanderson: how about we discuss it next week, and then publish it after that?

Ivan Herman: it seems to be mature
… I’d like to get it out there

Gregg Kellogg: I think we can review it between now and then
… and then publish it after that

Ivan Herman: I’m in favor of that

Rob Sanderson: so, give it a week? everyone up for that?
… so, let’s do that then. we’ll aim to publish next week–pending this interim week of feedback time

4.2. CBOR Note

Rob Sanderson: k. manu had a comment about the CBOR note

Rob Sanderson: https://github.com/w3c/json-ld-cbor/issues/6

Rob Sanderson: so, on to CBOR
… manu provides some useful implementation experience
… the tl;dr version is the conversion rate improvements are valuable
… is there anyone (pchampin maybe) who might be able to work on it?
… or should we see if manu and co can provide directed feedback?
… or should we manage the expectations of the community?
… by stating we’re not going to do it this time, so manu et al, don’t feel hard done by when in june there isn’t a note

Manu Sporny: we would not feel hard done by if there wasn’t a note
… very nice for you to consider our feelings, though. ^_^
… a general +1 for the CBOR stuff
… it would be nice to get the ball rolling on it
… it’s been more and more important to encode the JSON-LD parts into something like CBOR
… we’ve been saying it’d be CBOR-LD for some time, with nearly not progress on it
… that’s due to our being overwhelmed with other work…sadly
… so someone else would have to lead the charge on CBOR-LD

Pierre-Antoine Champin: I’ll try and free up some time in the coming week
… I didn’t really want to do this one on my own
… and didn’t get much back from Victor
… so even if the Digital Bazaar folks could just check my work, that’d be helpful!
… we’ll see what I can get done in the next week

Manu Sporny:
… so, thank you a tone!
… there are some necessary features we’d need to be in there
… but don’t yet have a strong suggestion for how those should be written up
… even just processing the feedback in issue 6
… starting there would be helpful
… and then gathering more input from the community would help also

Pierre-Antoine Champin: I must say I had a quick look at the issue, there’s a lot of things that go way over my head
… but I can try to frame some things
… there seem to be two parts
… JSON to CBOR stuff
… which I feel comfortable about
… but it might be naive due to my limited experience
… for the CBOR compression, though, I’d need help

Manu Sporny: happy to help!

Gregg Kellogg: it’s helpful that it tells you that you’re muted
… if you’re working in the CBOR-LD domain
… and you’re referencing a JSON-LD context
… what happens…or what if that’s reversed

Manu Sporny: +1 to be concerned about those things that gkellogg just outlined. :)

Rob Sanderson: any other comments on the CBOR stuff?

4.3. “initial” context

Rob Sanderson: so, one more item is “base context” – or the recommended context, or something

Rob Sanderson: https://github.com/w3c/json-ld-rc

Rob Sanderson: there is a repo json-ld-rc
… so, this wouldn’t be a default, but a recommended one
… so a helpful thing that other contexts could lean on to get started
… and with some recent work around context resolving
… having an initial context would potentially save quite a lot of processing
… this isn’t really a note
… but it does seem like something we could work on
… before June
… thoughts?

Harold Solbrig: I very much like seeing that there
… but I think it’d behoove us to not stray to far
… some of these are already wrong…for instance
… we should keep this to the very generic stuff
… everyone’s trying to do this, but not in consistent ways
… which then doesn’t help at all

Benjamin Young: We should just match RDFa’s initial context and then perhaps a process to keep them in sync
… no consistency currently, and this could provide that
… within a single project’s readme, I found schema.org referenced and prefixed in different ways
… written by one person, so not even internally consistent in a document
… so valuable
… but devil in the details :)
… Shouldn’t be out of sync with others, and should be consistent

Gregg Kellogg: yeah, I think self-consistency goes, that’s mostly been a monkey on ivan’s back
… and the CSV Web nominally stays in sync with that
… so, certainly, we should contemplate a process for this
… in as much as those recommendations have contexts that they recommend
… we could consider not simply referencing it, but pulling it in
… but then we’d very likely have naming conflicts
… so we should maybe at least say why not

Harold Solbrig: one possible step further, is that in the tooling it’d be danged handy to say, “I just want to start working in this context”
… in rdfLib, you can pull in some of the contexts and get going
… while it’s not this group’s thing per se, making it available programmatically would be valuable.

Rob Sanderson: how ‘bout if we reset the JSON-LD context file to the initial best practice to the @type/type, @id/id etc and the RDFa initial context
… and then we can discuss in other issues

Ivan Herman: +1 ro bigbluehat

Benjamin Young: I think we need to heavily reconsider the @id/id mapping
… it runs a fowl of so much existing JSON

Rob Sanderson: yeah…that ship has sailed….

Benjamin Young: let’s unsail it, because I think it’s a bad idea

Rob Sanderson: yeah, this is why we need a process

Harold Solbrig: yeah, it took me awhile to even know this was more than prefixing…
… clearly separating namespace prefixes form other JSON aliases would be helpful–as I’ve said before
… once we can tweak the @prefix grammer a bit, to call them out more clearly, it would simplify it
… but here, I wonder if we want to have two separate contexts–one for aliases and one for prefixes

Rob Sanderson: yep, that could work

Ivan Herman: RDFa and JSON-LD are different
… in RDFa it’s much more difficult…or ugly…to set the prefixes
… so it’s much more useful to have an initial list
… personally, I would trim this list very radically
… I agree with what bigbluehat says about prefixing
… but as azaroth said, that ship has sailed
… so maybe that’s how it has to be
… on the other hand, I’d retain the Dublin Core things, the RDF, OWL, and XSD ones, and Schema.org because it’s everywhere, and then remove all the others
… it should really just target the core of JSON-LD
… and DC and Schema are used by “everyone and his brother”

Benjamin Young: just make sure the prefixes always match what’s in RDFa
… doesn’t have to be the same list…but shouldn’t conflict

Ivan Herman: agreed

Rob Sanderson: I’ve made some initial issues, please send feedback
… thanks all for coming!
… we’ll talk next week
… bigbluehat and I will get the blog post out
… everyone read the streaming note
… and hopefully we can get it pushed next week

5. Resolutions

6. Action Items