The W3C JSON-LD Community Group

Go Back


W3C Logo

JSON-LD CG

Minutes for 2023-11-01

Topic: Announcements and Introductions

Gregg Kellogg is scribing.

Topic: YAML-LD

Anatoly Scherbakov: I've introduced a few more tests to verify that keys must be strings.
... I've also adjusted my own implementation accordingly.
... We had some more discussions about the treatment of types supported by YAML, but not JSON.
Ted Thibodeau Jr.: I/meeting: JSON-LD CG/scribe: gkellogg
Gregg Kellogg: What's the remaining work to do?
Anatoly Scherbakov: We have a suggestion to use extractAllScripts as a way to handle YAML-LD streams.
... Generally, I think we're getting to the end.

Topic: JSON-LD Issue Discussion

gsaumier-finch: I am willing to help proof read the YAML-LD
Gregg Kellogg: No particular issues to discuss on JSON-LD

Subtopic: New work on JSON-LD

Benjamin Young: The VCWG is adopting some of JSON-LD language value objects.
... They're falling down rabbit holes of term aliases and the like.
... JSON-LD does a comprehensive support for languages.
... We have language value objects, but if aliased, it becomes difficult to understand when looking just at the JSON.
... The proposal is to write a note extracting the processing steps and expression of @language/@value/@direction into a standalone note.
... This could be extracted to its own note that could describe a pattern useful outside of JSON-LD itself.
gsaumier-finch: Also @container: @language is very powerful and used frequently in my group
... This would put in a single place best practices for describing language text in JSON.
... I think the "@" symbol is an immportant part of this.
Benjamin Young: I think the core foundation should be language value objects.
... We can then describe ways of extending this, including language maps.
Benjamin Young: I think a WG note is the way to go, but work can happen in the CG.
... I'd start in the JSON-LD CG.
gsaumier-finch: There's not concern in the context with getting rid of the "@", to be clear?
Benjamin Young: Because it would exist outside of JSON-LD, we would loose aliasing functionality.
... I'm proposing that we use the expanded forms outside of JSON-LD. If a pattern is established without these, there's a danger that different systems would behave differently.
... This would allow libraries to process these expanded value objects without needing to do other JSON-LD processing.
... Once you use aliases, the meaning becomes less clear.
... Note that schema.org/value is a thing that could be mistaken.
gsaumier-finch: When we use @container: @language; in that form, the languages don't have at-signs.
... This creates a nicely compact representation that avoids a lot of use of @language.
Benjamin Young: We can point to the language map bits from JSON-LD, but the pattern is for using the expanded value objects with @language
... I think the note is something to involve the I18N folks in.
... I'd keep @none in there.
Gregg Kellogg: I don't think that has meaning in the expanded representation.
Benjamin Young: We want to avoid people adding other properties inside a language object.
gsaumier-finch: I'll stop aliasing @none as none in the contexts ;-)
Gregg Kellogg: Next step is to discuss with @pchampin as staff contact.

Topic: Open Discussion

Subtopic: PyLD

Anatoly Scherbakov: I'd like to discuss PyLd.
... The PyLd library is probably the most popular python library.
... It seems that DB has not been focusing on it, as it's no longer on their critical path and needs attention.
... My understanding is that it is a product targeted at developers.
... In order to get it up to speed, we'd need to ensure that testing of the library is easy.
... The library has a test runner, and to run it, you need to clone the test repositories locally. I started something to do those as git submodules.
... There also should be a way to write these in the library itself.
... Many people write their tests in an ad-hoc way, as there is no standard way to do this already.
... It should also run test during CI/Pull Requests.
... Secondly, we should address open Pull Requests. Not all of them are ready to go, but they require a systematic review.
... I've reviewed some, and they are suffering from bit-rot.
... There is still a lot of interest in the community.
... Even though JSON-LD is still not in the mainstream.
... Lastly, the issues need to be audited. But, we should address open PRs first.
... This would enhance the experience of developers using the library.
... Hopefully, this can lead to a more regular release process.
Benjamin Young: I agree on your priorities.
... It's going to be about chipping through them together, and noting what seems to be ready.
... There are a few changes that seem simple, but aren't.
... If anyone depends on the library and wants to contribute, we need contributions that help with triaging the submissions.
David I. Lehn: Thanks for helping out with this stuff, and I've been slow in being able to look at things.
... I need some help on polishing things up.
... Some of the testing infrastructure needs some work. We have a similar pattern of testing in jsonld.js
... I thought we had an independent test runner, but I don't see it looking at it.
... In JS we use Mocha, not sure what to use in Python.
... We do need tests, and getting the infrastructure in place is important.
Anatoly Scherbakov: It is a lot of work. I think the most widely use testing platform is PyTest.
... We could also add some code coverage tests, which can also help with pull requests.
David I. Lehn: As far as testing goes, we do run the tests in jsonld.js all the time.
... When we're working on an implementation it's easy to work on things locally, but we should encourage that such tests get into the main test suite.
... The long term goal is that every implementation can run the same tests.
Anatoly Scherbakov: As an example of python-specific things. There's an "expand" function and it follows python conventions.
... However, it uses a signature that's not familiar to most developers, where kwargs are more common.
... Perhaps we could support both styles. This would improve the developer experience.
David I. Lehn: +1, Awaiting a PR :-)
David I. Lehn: I can add some access to the repo for people that want more access.
Anatoly Scherbakov: I have created some PRs.
David I. Lehn: Mostly an issue of time.
Benjamin Young: Keep doing what you're doing.
... Create an issue saying what PRs can be merged.
gsaumier-finch: Thanks.