The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD WG

Minutes for 2024-10-30

Present
Gregg Kellogg, Ivan Herman, Anatoly Scherbakov, Benjamin Young, Niklas Lindström, Ted Thibodeau Jr., David I. Lehn
Chair(s)
Gregg Kellogg
Scribe(s)
Benjamin Young, Gregg Kellogg
Agenda
https://www.w3.org/events/meetings/67486b62-8fda-478f-a379-9f8a297266fb/
Topics
  1. Announcements and Introductions
  2. Issue Discussion
  3. Open Discussion

Topic: Announcements and Introductions

Benjamin Young is scribing.
Gregg Kellogg: Announcements?

Topic: Issue Discussion

... hearing none, we'll keep going
Gregg Kellogg: Issues. we'll use the project view
...let's focus on PRs
... first up
https://github.com/w3c/json-ld-api/pull/608 -> Pull Request 608 Resolve the questions about "JSON Serialization" term (by anatoly-scherbakov) [spec:substantive] [ErratumRaised] [class-3]
... this was started by anatoly-scherbakov some time ago
... I made a few updates and classified it since it's substantive
... ivan you had some concerns about the way the changes are presented?
Ivan Herman: Yeah. they're minor editorial comments
... but when I put myself in the shoes of anyone doing a review
... the boxes make things very hard to understand what's changed
... and the colors are low contrast which make it hard to read
... maybe a slightly more careful placement of those boxes
Gregg Kellogg: Yeah, we're somewhat restricted with the boxes since they're often in lists
Ivan Herman: I realize
Gregg Kellogg: We'll see what we can do
... otherwise the text here seems very close
... though the green color used here is hard
Ivan Herman: Yes. mostly the contrast
... when I used a browser that has a dark mode it became very obvious
... but I understand it's complicated
... but don't worry too much about it
Gregg Kellogg: I was uncertain if there were best practices for this sort of thing
Ivan Herman: No. it's all new.
... so we should learn as we go
Gregg Kellogg: K. we'll just stay ready to address things as we go
Ivan Herman: We were hoping to have some tools built into respec or somewhere
... but those have not materialzed
Gregg Kellogg: So, back to this specific change. I did add PA as the other editor
... especially since Dave isn't really active any more
... there's also the technical content in this PR
... it's mostly informative
... but there was some text added into the processor interface about normative language about serializing into JSON
... that could use some more critical review
... there may be better ways to state that
... anything else to say about this PR?
https://github.com/w3c/json-ld-api/pull/617 -> Pull Request 617 Update ci.yml for Echidna rules (by gkellogg)
Gregg Kellogg: K. PR 617 is next and should be fairly non-controversial
... I think we previously would have had a decision for auto-publishing
... but we may need a new one for handling these amendments
Ivan Herman: Not sure what you mean
Gregg Kellogg: Echidna has a "decision URL" but I'm not sure we're ready to provide that
Ivan Herman: For new working drafts? I have no idea to be honest
... This is true for new WD's.
Gregg Kellogg: So. really we just need a decision to push new working drafts to TR space
Ivan Herman: Wait. of what?
Gregg Kellogg: JSON-LD API 1.1
... echidna would allow us to push those into TR space
Ivan Herman: We should check the charter
... typically in maintenance group, you can make minor changes directly
... and for larger types of changes, there's a process for that
... you can republish the spec if larger changes come in
... but if you do a working draft it means you are moving toward a new version of the spec
... but I don't think we are chartered to do that
... we can ask PA when he's back
Gregg Kellogg: I believe we're chartered to maintain these specs
Ivan Herman: Right. the lower changes do not require a working draft
... but these other changes have a process which go through an approval process and also avoids a working draft
... working drafts really mean you're starting a new version
Gregg Kellogg is scribing.
Benjamin Young: I agree that a new WD seems to point to a new version.
... We need to better understand the approval process and have the group decide the changes we want in 1.1 vs those that go in 1.2
Ivan Herman: So my understanding at TPAC was...
... there's a plan to make a new charter for this group to make a 1.2 version of JSON-LD
Ivan Herman: My understanding is that there is a plan to create a new charter in direction of 1.2 (most likely). There is no such charter yet.
... the charter is not yet ready
... I would expect that new working drafts are part of 1.2 and should be part of that charter.
... and I'd expect any working draft things to be headed to v1.2 and be done under the new charter
... In the current charter, we should remove anything that can be handled by directly re-publishing the changes or though the route for class-3 changes.
... under the current charter, anything else like errata should be handled as maintenance tasks (class 1 or 2 changes) or through the approval process for class 3 changes
Gregg Kellogg: Class 4 changes would have to wait until we have a working draft
... proposed corrections would be the next step
... it feels like many of the upcoming changes will be in limbo
Ivan Herman: So, I will try to say what I understand is the situation
... with the changes you have for the document, we publish those changes to the recommendation directly
... so we'd be republishing the recommendation + those colorful changes you produced
... this is published by asking the webmaster to publish it
... we may need an approval by management and go through a review process including horizontal review
... that version becomes the formal JSON-LD v1.1 for 30-40 days
... after that we move those changes to a new status and republish again
... a little bit like CR, we have to prove these new changes are implementable
... and have horizontal and AC review
... frankly, I've no idea how the AC review gets done
... we're about to do it in the EPUB group
... the importance difference is the latest version is the one you have just published with those candidate changes
... you main remembers all of this goes back to the "evergreen" discussion
... so the standard is more a live
... sorry that may be as clear as mud
Gregg Kellogg: It sounds like since we have a lot of time left to review these changes toward a v1.1 release
... and keep that work on `main` until we feel like we've finished those types of changes
Ivan Herman: There's an unwritten rule that maintenance groups should not publish more often then twice a year
Gregg Kellogg: Alright
... none of that gets in the way of this particular PR
... so I will take care of that at a later time
https://github.com/w3c/json-ld-api/pull/585 -> Pull Request 585 Add graph container array tests. (by davidlehn) [test:missing-coverage]
Gregg Kellogg: This is the graph container array tests next
... it needs more reviews
... dlehn can you talk about this one?
... I have some outstanding changes
... dlehn you opened this PR sometime ago, any thoughts?
David I. Lehn: I don't remember what the istatus of it s
Gregg Kellogg: Really we just need more implementers to chime in
David I. Lehn: Does it need spec changes?
Gregg Kellogg: It's just tests
David I. Lehn: Maybe it needs clarification in the spec, though?
Gregg Kellogg: I'd like to move it along if possible
... dlehn can you push this forward?
David I. Lehn: Maybe. I think I guessed how to handle this, but others should weigh in
... ugh. I need to swap this back into my head
Gregg Kellogg: Yeah. we mainly just need to get this out of our backlog
... either by closing it or by finishing it and merging it
David I. Lehn: Do any other implementers have comments
Gregg Kellogg: Niklasl ?
Niklas Lindström: No substantive comments
... I threw it into my implementation and things went OK
... but I should dig into it
Gregg Kellogg: K. we'll keep it in the stack and come back to it again
https://github.com/w3c/json-ld-syntax/pull/439 -> Pull Request 439 Fix @direction not listed under context definition's definition (by Kibubu) [spec:editorial] [class-2]
Gregg Kellogg: Syntax PR439 looks mergeable now
...k. what else do we need to talk about?
https://github.com/w3c/json-ld-api/issues/560 -> Issue 560 Various `@json` processing issues. (by davidlehn) [test:missing-coverage] [ErratumRaised]
... this `@json` processing issues one for example
... dlehn this is another one of yours
David I. Lehn: Yeah...this is over a year old
Gregg Kellogg: I think this is a case where no specific spec text needs to change
David I. Lehn: Like the other, we need more implementer input
Gregg Kellogg: Is this a class 4 change? is it a new thing? or are we fixing something?
David I. Lehn: I think it has potential to break things
... it's like a bug fix where the spec lacked clarity
... but the suggestions in here to add other sets and things to force other modes...I've no idea what current implementations would do
... I really don't know what to do with this
Gregg Kellogg: The safest thing seems to be to classify it as a class 4 change
... and defer it
Gregg Kellogg: K. any other issues to discuss?
... we do need people spending time on these things...or we'll never get out of this mode
https://github.com/w3c/json-ld-api/issues/558 -> Issue 558 Compaction cannot round-trip terms using `@container: @list` and `@type: @vocab` (by niklasl) [spec:enhancement] [spec:substantive] [ErratumRaised] [class-3]
Niklas Lindström: I'm not prepared to talk about API issue 558
... it's labeled as class 3 which I agree with
... it's something I have a real need for
... I could make a PR
... as I did a change in my implementation
... but if someone looks at it and sees something alarming, it'd be great to get feedback
Gregg Kellogg: K. I put it at the top of our list for next time.

Topic: Open Discussion

Benjamin Young: Class-4 changes are going to have to stay in discussion land until we're finished with class 1-3.
... We have a date deadline of Jan 31 for the end of the current maintanance-mode charter.
... We either need to ask for a 6-month extension, or hurry up on the re-charter.
Ivan Herman: I don't think it's realistic to have the charter done by January.
... Re-chartering has to go through several groups, and with holidays in between it won't get attention.
... The group should ask for a 6-month extension. We should clarify we're working on a new charter.
Benjamin Young: Gkellogg: yeah. +1
... we should be keeping our new charter up-to-date and devote time to planning that new group
... but I think we have enough authority to handle most of these pending changes
... so just extending that charter should allow us to continue that work
... my main concern is who can be here to work on the specs
... I'd very much like to see another editor
... we can't keep depending on the same few people
... we need greater participation
Niklas Lindström: I think this is related to the charter
... it's about a languishing document from the community group
... it's for new line delimited JSON-LD
... we're using it now from our library systems data dumps
... I may be able to put time onto this as part of my job
... and possibly help with the editing
... not sure, but it is a topic I can put work effort into it
Anatoly Scherbakov: Not sure that I can notable contribute to the JSON-LD specs
Anatoly Scherbakov: Not sure were I can contribute due to available time, but I'll try to foster through some issues.
... but I can look at an issue in the API repo by next meeting and help there before the next meeting
... is the serialization/deserialization ready to merge? sorry that's a late request.
Gregg Kellogg: I'd like to see more reviews on it
... Can we merge https://github.com/orgs/w3c/projects/84/views/1?
... is that PR608?
... I'd like to get PA's approval for one
... but I think it's close
... maybe we can merge it after the next meeting?
Ivan Herman: I'd like to understand what this ndjson-ld does
... but first a formal thing
... if we plan to put this on the rec track, then we should not publish it as a note on this round
... in the old days taking a note into a rec track spec was fine
... but there are IPR concerns
... but I'm more excited about what this actually is!
Gregg Kellogg: Just to ask if this could be rec track or note track
... not sure there's enough there to make a recommendation
... so maybe it stays as a note
Benjamin Young: I'm seeing in the next period that JSON-LD is the center-piece for other formats, such as YAML-LD and CBOR-LD.
... In that way, it would be good to extend those and clarify JSON-LD API things needed to handle the sub-types.
... My guess is that the world of streaming-parsing is where the liability is.
Niklas Lindström: First some context
... we have library centric use cases
Niklas Lindström: https://emm-spec.org/1.0/
... our own library uses linked data and are communication with the open source folio project which is gradually supporting more linked data
... there's also this EMM spec that came up recently
... it's based on Activity Streams
... there are many more library centric use cases
Gregg Kellogg: Could you give a thumbnail sketch of ndjson-ld specifically?
Niklas Lindström: Yes. Library of Congress dumps gigabytes of JSON-LD all wrapped up in a single array
... the only thing you can do with that is use a streaming parser
... there are loads of things to discuss about how to efficiently use that
... the other option is to store them in a single file, but split on new line delimiters
... and I do think there's a media type for that, but I'll need to check
... many libraries already work with named graphs, so typically they're prepared for this approach
... however, there are questions about using the first line for the context declaration on it's own
... and then all other objects in the ndjson-ld would use that context
... or there may be other options for standardization
Gregg Kellogg: Yeah. we looked at some other options back in the day
... but ndjson-ld did seem the simplest at the time
... it seems like a worthy note
Benjamin Young: I think it can continue as a note for the time being; if it looks like it needs to be a standard (maybe if it registers a media-type?) we should consider REC-track.
... Using a single context and applying to other records would be a new format. Having a spec could be needed.
... The activity-streams world is where we might find some interest.
Niklas Lindström: +1
Gregg Kellogg: I think Ivan cautioned as notes and moving to recs
Ted Thibodeau Jr.: ND-JSON doesn't appear well enough spec'ed to do much of anything -- https://json-ld.github.io/ndjson-ld/
... it might be easier to start something on the rec track and then move it back to a note
Ivan Herman: Actually...you'd leave it open as a working draft
Gregg Kellogg: So it may be better to do it as a rec track document sooner than later
Ted Thibodeau Jr.: To make an ndjson-ld there needs to be an ndjson, which doesn't seem to be adequately defined right now.
Ted Thibodeau Jr.: Doesn't seem to be enough specification nor registration yet with ndjson
... it uses an `x-` prefix for example
Niklas Lindström: We need to base on something which is formally specified; if there is none, it could be an argument for REC-track.
Gregg Kellogg: We could do this as part of YAML-LD actually
... they already support the document separation
... it might be that we express it as a subset of YAML-LD and use the JSON form
Niklas Lindström: Just wanted to say that it might not be the best way to do it
Niklas Lindström: It might not be the best way to use YAML, and it might be considered to be too heavy-weight.
... and I know the ActivityStreams community believes less is more
Anatoly Scherbakov: I wanted to mention YAML-LD can handle lots of documents
... the separator is `---`
Anatoly Scherbakov: YAML-LD does support multiple documents in a stream, but it uses "---\n" as a record separator.
... so a bit different than ndjson's approach
... and YAML-LD doesn't currently say anything about streaming
... Also, YAML-LD does not explicitly say anything about streaming, although implementations may choose to do so.
Gregg Kellogg: I was suggesting that format might be useful but maybe as a subset designed for streaming
Niklas Lindström: A possibly relevant thread: https://github.com/wardi/jsonlines/issues/19
https://github.com/wardi/jsonlines/issues/19 -> Issue 19 Standard MIME content-type (by pavelnikolov)
Gregg Kellogg: Please pick a favorite issue for next time!