JSON-LD Working Group Telco — Minutes

Date: 2020-02-07

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Ruben Taelman, Benjamin Young, Ivan Herman, Tim Cole, David I. Lehn, Adam Soroka, Pierre-Antoine Champin

Regrets: Gregg Kellogg

Guests:

Chair: Benjamin Young

Scribe(s): Rob Sanderson, Benjamin Young

Content:

1. approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2020/2020-01-24-json-ld

Proposed resolution: approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2020/2020-01-24-json-ld (Rob Sanderson)

Rob Sanderson: +1

Benjamin Young: +1

Ruben Taelman: +1

Resolution #1: approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2020/2020-01-24-json-ld

Ivan Herman: +1

2. Announcements / Reminders

Benjamin Young: Any announcements / reminders?
… have a specific ask
… No? Any implementation status reports?

Rob Sanderson: so, Greg (who works with Rob) has gone through more of the spec
… but that’s not new news
… in Python, though, there’s a separate from the PyLD project and they’ve been making good progress
… rdflib and rdflib-jsonld

Ruben Taelman: Have been working on the streaming parser implementation lately
… things are going well. Don’t see any major issues to parse in a streaming way
… most of the spec tests currently pass, so hope to be done with it by the end of the month

Benjamin Young: Very valuable! ANy other news?

Benjamin Young: add to https://json-ld.org/#developers-description

Benjamin Young: one thing to ask is if anyone directly or through other groups know of things, we should make sure it gets added to the developer description in json-ld.org
… including tagging for what they support
… to help people decide which to use. If you can take it on, great, otherwise I will try to do it

Ruben Taelman: working on the parser now, will do serializer later but shouldn’t be any issues

Benjamin Young: rdflib. PHP is getting stale. Ruby is good with Gregg

David I. Lehn: We don’t use PHP actively unless someone picks up the torch it’ll stay where it is

Benjamin Young: I think there was work going on in java
… don’t know about the bottom row in general
… any status would be appreciated, now or later in issues in the json-ld.org repo
… any other reminders?

3. Issues

Benjamin Young: Dug through syntax, api and framing … didn’t find anything discussable, it’s all editorial
… pierre-antoine, anything you want to raise or highlight?

Pierre-Antoine Champin: Nothing to discuss :)

4. Best Practices

Benjamin Young: Adam has done a lot of work on BP issues recently

Adam Soroka: Mostly workflow issues – some duplicates. Was tapping people about new sections to move forward
… example for order in the context matters, where it normally doesn’t
… but does in one particular place.
… Some other very similar ones, where there’s some uncertainty should have an example
… eg language maps and multilingual, with the choices and what you get from each
… other than that there’s some streaming ones, should close one, and just a mention that streaming is possible
… but it has to obey certain rules to work
… those are the biggest ones that I saw
… a few smaller ones but mostly typos

Benjamin Young: Why don’t we look at streaming

4.1. Streaming best practice

Benjamin Young: https://github.com/w3c/json-ld-bp/issues/3

Ruben Taelman: historically issue 4 was earlier, but in a different tracker and then moved to BP repository
… I made 3 as a way to summarize the things that are needed to parse efficiently in a streaming manner
… I think that we can close 4, but I should go through it in more detail to make sure we don’t lose anything

ajs6f> +1 to closing #4

Ruben Taelman: that isn’t in #3
… It would be safe to write some text about those guidelines that I mention in #3, but Gregg appeared to agree with most of it except for the properties
… the special case where contexts are applied to specific properties, and we would need some more work
… that we should still look into

Benjamin Young: Are you up for doing some of the work for the doc?

Ruben Taelman: Can help with that, but next 2 weeks are very busy
… only be able to work on it after that, if that’s okay

Benjamin Young: Some time is better than never! Even just sections and rough pointers for where to flesh out and what you have in mind
… any content is great and it can be polished later
… in #4 Adam suggested that this could be a stand alone note, but I don’t think we have time to add a new note
… It would also need promotion

Adam Soroka: The impetus behind it was that it’s not part of the specs directly, but we do want to specify precisely
… in an ideal world it would be nice to have a separate formal note, but not a spec, and the BP doc would just refer to it
… but whatever mention in the BP doc should be informal rather than pseudo-normative
… don’t think we have time for a careful spec either, especially in a BP doc

Benjamin Young: Get what we can into the BP doc

Adam Soroka: Can potentially publish a note later. Can see what use people make of the notes in the BP doc

Benjamin Young: Ruben, you mentioned wanting to close #4
… should we leave that one open?
… You wanted to go through issue 4 to see what was there

Ruben Taelman: Assign it to me and I can see if we can close it

Benjamin Young: Happy to leave opening and closing to you
… can leave #3 open as the primary topic
… has a good looking outline

Ruben Taelman: about the note, I also think it’s valuable to have it at some point. Maybe not in the scope of this WG. Problem I have now is that when I discover JSON-LD docs I want to parse, I have to assume that they are not stream-enabled to be parsed
… so I parse them the normal way, and can’t use the optimizations for streaming parsing
… good to add a specific content type or similar to say that it can be parsed in a streaming way

Benjamin Young: Maybe a profile?

Rob Sanderson: it seems to ajs6f’s point about formality/informality of the BP…
… that if we wanted to have event a profile parameter/IRI, that it would raise it to a Note

Ivan Herman: +1 to Rob

Rob Sanderson: because we’d want to refer to it from the IANA profile
… so this does seem like something to consider
… I agree with rubensworks that if you don’t know you can stream it, you won’t
… so there needs to be something in the header that tells you it’s possible
… and perhaps we need to discuss priority of the notes

Benjamin Young: I think with priority of notes it’s who works on what
… if they show up then they’ve been prioritized :)
… if folks want to work on streaming, that’s great. We’re not stealing time from one to the other
… Have the time to discuss
… Ivan is this something we can do?

Ivan Herman: We can add as many notes as we can write

Ruben Taelman: What are the requirements for such a note?
… should be more extensive than a section in a BP doc

Benjamin Young: I think the biggest part is the profile parameters section, but start with whatever you have
… Is there more plumbing we should set up, Ivan?

Ivan Herman: In a note we can do what we want.

Ruben Taelman: Where should it live? Also in the BP repo?

Benjamin Young: Maybe we should use it as a notes repo

Ivan Herman: what do you guys want?
… don’t expect me to make the decision :) To make a new repo is 10 minutes max. You tell me

Adam Soroka: Was going to ask if we change it to a notes repo, then the BP is a note?

Benjamin Young: It’s a note already
… the only one we have content for

Ivan Herman: the only practical thing, if we want to use things like echidna, it makes it harder if there’s 5 notes in one repo
… but if we publish only once, it’s not a big deal

Rob Sanderson: a thought about publishing frequency
… for a note, having lots and lots of working drafts seems useful to draw attention to it and possibly get input
… so, I’d prefer we set it up with the best tooling to get drafts into the public

Ivan Herman: we can set up echidna that every commit to master is auto published

Benjamin Young: That sounds great
… a repo for each note

Ivan Herman: One for BP, one for CBOR. Now there’s a nice bikeshed question … what name for the repo?

Benjamin Young: json-ld-stream ?

Benjamin Young: our repos https://github.com/w3c?utf8=%E2%9C%93&q=json-ld-&type=&language=

Ivan Herman: +1

Tim Cole: +1

Pierre-Antoine Champin: +1

Proposed resolution: add json-ld-streaming repo; automate all note repos with echidna to publish on each commit (Benjamin Young)

Rob Sanderson: +1

Ivan Herman: +1

Adam Soroka: +1

Ruben Taelman: +1

Benjamin Young: +1

Tim Cole: +1

David I. Lehn: +1

Ivan Herman: first we have to go tyhrough the pedestrian way, and then we can publish each time

Benjamin Young: some time in the next couple of weeks we make a drafty working draft

Resolution #2: add json-ld-streaming repo; automate all note repos with echidna to publish on each commit

Ivan Herman: that’s something we have a plan to republish CR, and not via echidna but a new CR
… I have some time constraints about that. I sent a separate note, but I will have a trip to the US at the end of Feb and then a week out 10th of March
… so the timing might have some consequences
… that said, the whole procedure has been moved to github, so I believe that chairs can also initiate a FPWD by making an issue
… and FPWD is more automatic than anything else
… but still a discussion to have with the webmaster

Rob Sanderson: if it’s a matter of a week or so, then no need to rush

Benjamin Young: can always use GH previews for discussion in the mean time
… ivan do you want an action for the repo?

Action #1: set up json-ld-streaming repo (Ivan Herman)

4.2. CBOR Note?

Benjamin Young: Okay another issue…
… is anyone working on CBOR note?

Pierre-Antoine Champin: A number of issues were raised, he intends to work on it
… still have to process the issues that were sent
… and interested to contribute

Benjamin Young: awesome
… one side note, GH will not automatically subscribe you to the repos, so go in and watch them
… lots of people watching the CBOR note

Benjamin Young: https://github.com/w3c/json-ld-bp/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

Benjamin Young: Go through the BP in most active order
… done streaming, first one is ordering impact on protected

4.3. issue on protected

Benjamin Young: https://github.com/w3c/json-ld-bp/issues/2

Ruben Taelman: this issue was created to clarify that for protection of terms that order is important
… in the first snippet, the overriding of the term would result in a failure, but if you reverse the contexts, the failure doesn’t happen
… so clarify order is important

Benjamin Young: where you introduce the protection has an effect
… protected in the middle of the list is different from at the end
… anyone want to help on this?
… dlehn did you work on this?
… Or was it more dlongley?

David I. Lehn: I’d have to take a look. Partly involved but not core.

Ruben Taelman: I can also help

Benjamin Young: that woudl be super. I can assign to you for now
… thank you very much
… streaming got some love, so lets look at #13

4.4. generic discussion on bp issues

Benjamin Young: JSON-LD to RDF to JSON-LD … what can happen with things being moved around
… anyone has a handle on this that could write it up?
… [crickets] …
… feels pretty core to JSON-LD developer. don’t want crickets on every issue
… what’s the best way to handle it? All are of interest and we all want to see them written … how to put them into the path?
… Ruben was dealing with the streaming head on, so taking notes in public
… anyone working on this stuff and could do the same?

David I. Lehn: A question … what sort of text do we want? More like a tutorial, a teaching thing?

Benjamin Young: I think it’s what you should know in order to do it well. Do this, don’t do that

David I. Lehn: Might want to show why the other options are bad, and then it turns into a book

Benjamin Young: more minimal versions are fine. Just want some content that we as a group are aware that some things are tricky
… doesn’t need to be a book
… looking for draft content that can make its way in and then be edited
… json-ld continues to take it on the chin for people not understanding how to use it properly
… in VC, everything got assigned to someone, not to do the work, but to find someone who can do the work
… perhaps we need to come at this another way
… perhaps involving the CG

Rob Sanderson: I think involving the CG could be an interesting way
… but the question is how to organize it
… if not via these calls
… we could try the mailing list
… but it’s pretty quiet there
… so probably not many folks would show up
… one way to pick one issue and at least make progress–per call–to try and get notes down during the call
… and then we can tidy those up later

Benjamin Young: +1 on that
… so maybe we can use call time for getting notes down
… anyone up for that?
… can do a blended approach - a larger piece of work can be handed out, but for smaller ones we can note-jam and (e.g.) get the round tripping covered

Rob Sanderson: +1 to approach

Benjamin Young: does that seem okay?

Pierre-Antoine Champin: +1

4.5. issue on RDF roundtripping

Benjamin Young: https://github.com/w3c/json-ld-bp/issues/13

Benjamin Young: 13 minutes left …
… Lets look at 13, the round tripping one
… take a minute to go through comments together and then as people have thoughts, chime in

Pierre-Antoine Champin: To be sure … the original text of the issue mentions lists of lists which is out of date for lack of support

Benjamin Young: BP should call out when one is required to accomplish it, people can already have json-ld content

Ivan Herman: rob, I think you raised this … what do we mean by round-tripping. Strictly rdf model level, or is it from a particular serialization and round trip back tot he closest one?
… rdf has “wonderful” feature of a zillion different ways to express it

Rob Sanderson: I was thinking that if you have JSON-LD and you parse it into the abstract graph
… then manipulate it and re-serialize it, that you end up at the same place.
… does all of the information in the JSON-LD make it into the RDF graph and then back into the output JSON-LD
… and then there’s framing to make sure you get it exactly into the same tree structure…or not
… if you’re JSON-LD with blank nodes and go into RDF and back into JSON-LD then those blank nodes will vanish
… so work to be done on this issue is still correct
… find the things that are important to note in these scenarios
… and document in the best practice: if you want to have your data round-tripable, here’s what you should and shouldn’t do
… and Gregg’s comments that follow around array ordering is interesting…especially if you’re thinking JSON
… and thinking only JSON-LD then you get consistent blank node naming, but not if you go through RDF

Ivan Herman: CURIE in JSON-LD then into Turtle, does the CURIE stay the same? or are the rules different?

Rob Sanderson: I don’t know

Pierre-Antoine Champin: the way I read this was round trip between rdf abstract syntax and json-ld
… I don’t know if I can round trip turtle to turtle
… in fact I know that I can’t, e.g. the curies, as the implementations don’t have a notion of prefixes as they’re not part of the abstract syntax
… shouldn’t talk about other syntaxes, only abstract and json-ld

Rob Sanderson: +1 to pa

Pierre-Antoine Champin: Maybe it’s worth mentioning that … other syntaxes have their own problems that we can’t address

Benjamin Young: Good points!
… do we feel like we have a complete list on the issue?
… or can we write in other issues to the issue
… the things that we’re up against and whether we can solve them

Rob Sanderson: throw in whatever notes you can

Benjamin Young: consolidate and summarize from what you’ve read above would be good
… or just take that on to make sure the end of the issue we have something to take forward
… rather than rereading the whole time

5. next meetings

Benjamin Young: next friday is valentine’s day

Rob Sanderson: I am out the following week tho

Benjamin Young: meet on regular schedule
… best practices and note jams …we’ll get better at it :)

6. Resolutions

7. Action Items