The W3C JSON-LD Community Group
Go Back
JSON-LD WG
Minutes for 2025-03-12
- Present
- Ted Thibodeau Jr., David I. Lehn, Benjamin Young, Gregg Kellogg, Ivan Herman, Pierre-Antoine Champin, Niklas Lindström
- Chair(s)
- Gregg Kellogg, Benjamin Young
- Scribe(s)
- Gregg Kellogg, Benjamin Young
- Agenda
- https://www.w3.org/events/meetings/c7ab3fcd-4dc4-4444-ae8a-c91ca2131113/20250312T120000/#agenda
- Topics
Topic: Announcements and Introductions
Gregg Kellogg is scribing.
Benjamin Young: Next meeting we expect dlongley and Wes Smith to discuss CBOR-LD.
... dlehn and I are also working to catch up on that work.
... TPAC is in November, we will consider having a meeting there.
Topic: Polyglot discussion at TAG
Benjamin Young is scribing.
Pierre-Antoine Champin: https://github.com/w3ctag/design-principles/pull/562
https://github.com/w3ctag/design-principles/pull/562 -> Pull Request 562 Principle: Write only one algorithm to accomplish a task. (by jyasskin)
Benjamin Young: Conversation has moved forward. This would be a good time to chime in.
> When specifying how to accomplish a task, write a single algorithm to do it, instead of letting implementers pick between multiple algorithms.
... As far as I can tell, it's the opening statement about polyglot formats that drives most discussion.
... If you can apply this principle elsewhere, there may be a principle to follow
Ivan Herman: I admit that I couldn't go through this thoroughly. This is not new, it's been around for a long time.
... Do we know why the document was created in the first place?
... Does the TAG have a long-term goal of addressing concerns over JSON-LD?
Benjamin Young: Jeffery is bringing up something on his own accord. Not sure it's a general TAG concern.
Pierre-Antoine Champin: I wanted to mention that Sarven put this on my radar.
... I'll talk with him this week.
... I didn't see that this was on the agenda, or I would have invited him.
Ivan Herman: The VC PR transition request was approved, so a lot of things may be related to that.
... Can we expect formal objections on VC publication based upon this?
... It's interesting, as Jeffery was a regular contributor on VC matters.
Benjamin Young: Wondering if this could result in a FO on VC. The concerns seem to be on VC 1.1, but VC 2.0 may have solved this, although different things have been said.
... VC has only one processing model. It may point to conversations that relate to the TAG note.
... Some big companies seem to be antagonistic towards VCs.
> When specifying how to accomplish a task, write a single algorithm to do it, instead of letting implementers pick between multiple algorithms.
... I intend to try to focus on the point I posted earlier.
... The concern is about multiple algorithms doing essentially the same use case.
... At minimum, that could be refined irrespective of technologies. The TAG could be asked to find other examples.
... XHTML/HTML might not be related.
... My hope is to move the conversation away from JSON-LD.
Pierre-Antoine Champin: If Polyglots are such a bad thing, then maybe JSON is not an appropriate basis for standards.
... In Python, floats and integers are distinct types, while they're not in JavaScript
... Strings have different lengths.
... There are different ways that JSON is parsed into different languages, and clearly multiple algorithms are used to do this.
... I'd rather start by not focusing on polyglots.
... Risks come up with different developers in different languages or different eco-systems.
Benjamin Young: I'm weighing how much I really want to get into this, but I'm concerned about what this could mean for our collective future.
... The aim may be to not encourage the use of JSON-LD by other standards.
... Members of the VC group were also concerned about taking in the JSON-LD processing model, as there are ways to pick and select to parse what you need.
... The argument is that if you don't need all the stuff JSON-LD processing does, it's to compute intensive.
... Focusing on goal (was task) model, is not the case for all specs.
... There are a number of ways you can parse a document; the spec should provide just a single way to do things.
... Conflating this with "polyglot" only makes things more confusing.
Ivan Herman: My answer to pchampin is to say that his points should be made.
... Applications read JSON in different programming languages, and learn to deal with it.
... The datatypes differ between RDF specifications.
Ted Thibodeau Jr.: "I want to make a peanut butter and jelly sandwich. What's the One True Algorithm to achieve this goal?"
... The history of VC is what happened. I try to be self-critical, but the criticism of JSON-LD is not so much processing, but the complexity of JSON-LD.
... There is a feature-bloat problem in JSON-LD which makes it hard to understand for non-experts.
... We used to say that the complexity is hidden in the context (like a DTD), but that is a weak argument.
... I wonder is the new WG can look for was to simplify JSON-LD, or carve out a profile. We need to understand the critisism.
... That should be part of the new charter.
Pierre-Antoine Champin: +1 To ivan's statements. I was thinking of finding some academics to help understand such profiles.
... It would be better if we could point to such a result to guarantee things about it.
Gregg Kellogg: Maybe focus on direct transformation to RDF.
Benjamin Young: The TAG might say that developer use of different algorithms, is different than using them in a spec.
... HTML processing and XHTML processing is an example, they should result in the same output, but don't.
... Those arguments are used against JSON-LD.
... Arguments are made that there are different ways to express data in JSON-LD. But in JSON, you can only do this as direct values of a key.
... In JSON-LD, you can split these over different objects with the same at-id.
... Different object models can exist over the same syntax.
... I don't think we've claimed that JSON parsing and JSON-LD parsing necessarily result in the same model.
... What we've seen since or last charter, are documents that go through other specifications.
... Spec authors don't have the guidance they need from us. We don't really cater to the needs of spec authors.
... If we aimed at spec authors, we'd try to push all JSON-LD features and work on how to write a context file which addresses specific needs.
... Where Activity Streams has had problems is in not knowing how to deal with contexts to do what they need to do.
Ivan Herman: I disagree with gkellogg about what people need from JSON-LD, only a small fraction convert to RDF.
... I would say they look for is to solve the problem of de-centralized vocabulary definitions.
... I was looking at the TDMRep spec, which is quite small, which is aimed at robot/AI text.
Ivan Herman: TDMRep
... (Data mining spec).
... They use JSON-LD because they need terms that are defined in contexts, nothing else.
... Or they want to bring in terms from other vocabularies, which JSON-LD provides.
Ted Thibodeau Jr.: https://www.w3.org/community/reports/tdmrep/CG-FINAL-tdmrep-20240510/
... The single biggest thing JSON-LD provides for them is a way of brining in terms from different vocabularies.
... They don't care about RDF.
Ted Thibodeau Jr.: https://www.w3.org/ns/tdmrep/
Ted Thibodeau Jr.: https://www.w3.org/community/tdmrep/
... We have to keep in mind that we need to address these specific needs, and hide what they don't need.
Pierre-Antoine Champin: Bigbluehat covered much of what I wanted to say.
... Would it be fair to say that these specs are only interested in data?
Ivan Herman: Yes.
Pierre-Antoine Champin: I think we might encourage the use of framing more.
... A new media-type based on JSON-LD may be something we could encourage.
... JSON-LD based formats have their own mediatype.
Ted Thibodeau Jr.: "This is not the @context you're looking for."
... A context is not enough; they should also have a schema, and a frame that would guarantee that you can turn data back into a format which matches the schema, and RDF isn't particularly useful.
... We need to guarantee that framing is part of the solution.
Benjamin Young is scribing.
Gregg Kellogg: My request for clarification from ivan would be, if they care about what is in vocabs and contexts
... what can we do to help them then?
... the expanded form which turns the compact form into IRIs
... maybe what they need is JSON transformation rather than RDF transformation
... because that may be sufficient for getting them the graph understanding of the data
... and would still give them access to framing
... which would let them re-express that graph into those various shapes
... the concern with complexity may be around the number of algorithms we have: contexts, expansion, flatten, etc.
... there are a lot of things to understand to get that transformation
... so maybe we need a simpler route to framing
... which could potentially use a simplified understanding of the document
Ivan Herman: In many groups, where JSON-LD is not used. They don't really want IRIs, they just want to say that "name" is the same as the schema.org name.
... IRI looses people right way.
Benjamin Young: Just recently I talked about IRIs with a developer, and they were unaware that such IRIs could be dereferenced.
... It's always confusing that "http:" is in the name. It may or may not loose its value if dereferenced.
... If it returns something, it should be appropriate, but it may not return anything at all.
... Most research documents result in a 404.
Gregg Kellogg: Linked Data because of RDF
... maybe it's time for updating the LD design principles
... it's a bigger problem than just JSON-LD
Benjamin Young: I was going to echo what ivan said that a lot of people can benefit from the fact that a JSON-LD processor can process the format, without actually caring about the resulting RDF.
... They just need to know that the model results in valid data.