The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD CG

Minutes for 2022-08-31

Present
Gregg Kellogg, Anatoly Scherbakov, David I. Lehn, Juuso Autiosalo, Benjamin Young, Niklas Lindström, Melinda Minch
Chair(s)
Gregg Kellogg, Pierre-Antoine Champin
Scribe(s)
Pierre-Antoine Champin, Gregg Kellogg
Agenda
https://www.w3.org/events/meetings/37dfdfbe-ffa4-4fff-9589-0bdc12401128/20220831T160000
Topics
  1. Announcements and Introductions
  2. Approve Minutes
  3. YAML-LD
  4. yaml-ld#77
  5. yaml-ld#78
  6. Next call
Resolutions
  1. turn PR yaml-ld#77 to draft, and consider move this to Best Practices
Pierre-Antoine Champin: The repo manager will require that a contribution be non-substantisve [scribe assist by Gregg Kellogg]

Topic: Announcements and Introductions

Pierre-Antoine Champin is scribing.
Gregg Kellogg: Today is the last day of the JSON-LD working group charter
... I was surprised to learn this.
... I hope we can discuss a charter extension during TPAC,
... so we can handle this work to the WG.
Benjamin Young: How did you find out? Did you get a notification?
Gregg Kellogg: This was raised by Ivan on a github issue
Benjamin Young: Strange that there were no notification
Pierre-Antoine Champin: I assume that WG are assumed to self monitor their charter deadline as part of their "day-to-day" activity
... does not work well for so called "maintenance group" though
... should be reported to the Process CG

Topic: Approve Minutes

Gregg Kellogg: Moving on
Gregg Kellogg: There was a bug in the generated minutes, I had to regenerate all of them

Topic: YAML-LD

Topic: yaml-ld#77

https://github.com/json-ld/yaml-ld/issues/77 -> Pull Request 77 Definition of yaml-ld namespace documents (gkellogg) needs discussion, spec
Gregg Kellogg: I setup to do a number of updates. Apologies for the massive update that resulted.
... began with the yaml-ld namespace, to institude a convenience contexte aliasing `@` keywords to `$` keywords
... Roberto Polli was quite critical about it.
... Unfortunately, he could not join today (conflicting IETF meeting).
... Q: is this context specific to YAML?
Gregg Kellogg: Following the practice of the Verifiable Credential group, it semmed like a good idea to version the context
... a future version of JSON-LD may introduce new keywords.
... Suggestion for implementations to cache that context.
Ted Thibodeau Jr.: I previously suggested to use a w3id namespace, but that would not be a good ID.
... Namespaces in the w3.org NS are more recognized.
Gregg Kellogg: We would need pchampin to setup the yaml-ld namespace on w3.org
... ivan has done that in the past for other namespaces, with content-negociation (JSON-LD + HTML version)
Pierre-Antoine Champin: We can also set the Cache-control HTTP header to make the caching happen
Gregg Kellogg is scribing.
Benjamin Young: We discussed previously to use a convenience context, which uses the "+" but doesn't replace it. (See https://github.com/json-ld/convenience-context)
... We discussed the potential conflict with JSON schema.
... I'd support a context which "hides" the "@" symbol, but I don't think switching makes sense.
... It's confusing to the developer to use "$" in one place and "@" elsewhere.
... I'd think we'd do that outside of the YAML-LD spec. My preference is to use the "@keyword" form.
... The "$" thing is asking for trouble.
Anatoly Scherbakov: I think I agree, in the sense of using "$" could be factored out of the spec. I proposed putting it in the Best Practices area.
... My approach to YAML-LD is it must be accessible to people that don't know what JavaScript it.
... YAML has it's own community and is perhaps more accessible to non-computer professionals.
... I don't insist on that, and the convenience context can be placed anywhere.
... I think inclusion of the "$" helps usability by the general audience.
... I think such simplifications in syntax might be useful for getting wider adoption.
Benjamin Young: I'd say that JSON-LD's widest adoption is among people who don't know JavaScript, or even JSON-LD.
... We don't have a lot of JSON-LD typed by hand, but by genertors.
... The SEO folks don't know what JSON-LD is; if they're not working in Wordpress, they're copying and pasting from online examples.
... I question the use-case without a justifiable audience.
... I don't think more than a convenience context is warranted.
... The use of DSLs in YAML is already wide-spread, which would continue here.
Anatoly Scherbakov: I see your point, and don't want to scare off people.
... We don't yet see the use case, as the applications for which it is applicable don't yet exist.
... People like to get code everywhere; structure as code, security as code.
... Structured Data as code should come next.
... visusal interfaces for describing complex data can be too cumbersome, and people end up wiring code.
... YAML folks do end up inventing their own languages and syntaxes.
... A convenience context might be thought of a kind of example for how to do this.
David I. Lehn: As far as requiring quotes, the YAML folks wanted to preserve "@", IIRC. It could take years to undo this.
... In a lot of cases having contexts to override keywords seems like a good approach.
Gregg Kellogg: From the discussion, it seems that we should consider the convenience context as a separate thing, mentioned in the BP document
PROPOSAL: turn PR yaml-ld#77 to draft, and consider move this to Best Practices
https://github.com/json-ld/yaml-ld/issues/77 -> Pull Request 77 Definition of yaml-ld namespace documents (gkellogg) needs discussion, spec
Gregg Kellogg: +1
Pierre-Antoine Champin: <Pchampin> +1
Niklas Lindström: +1
Ted Thibodeau Jr.: +1
Benjamin Young: +1
David I. Lehn: +1
Juuso Autiosalo: +1
Melinda Minch: +1
Anatoly Scherbakov: +1
RESOLUTION: turn PR yaml-ld#77 to draft, and consider move this to Best Practices
Pierre-Antoine Champin: Okay, let's move this over to a future best-practices document.

Topic: yaml-ld#78

https://github.com/json-ld/yaml-ld/issues/78 -> Pull Request 78 Spec progress (gkellogg) spec
Gregg Kellogg: This PR is sort of a brain-dump, following the implementation that I am working on
... my time will be limited with the coming 2 working groups (RCH and RDF-star)
... I wanted to get things done in the spec
... Some parts are controversial -- we have discussed them but didn't come to a resolution.
... The idea is to spell out the details of how you convert between YAML and the internal representation
... taking into account the additional capabilities of YAML compared to JSON
... 2 profiles: JSON prodile has a 1-to-1 relationship between JSON and YAML (no tags, no anchors/node aliases for document compaction)
... the language makes use of the concepts of the YAML spec
... Since YAML tags are essentially URLs, this makes them a good candidate for representing typed literals.
... To capture that, the idea is to extend the internal representation by allowing RDF literals in them.
... Interestingly, this does not require any change in the JSON-LD API algorithms, except for passing RDF literals through.
Anatoly Scherbakov: I think this is great work; thanks for moving it forward.
Niklas Lindström: I'm sorry I haven't had a chance to read the PR in detail.
Niklas Lindström: Can you elaborate on the rationale for extending the internal representation,
... rather than using JSON-LD value objects (`@value`, `@type`)?
Gregg Kellogg: Value objects would create complications in round tripping
... the value of the JSON-LD processor is to keep track of the context where an attribute is used
... imagine that `@value` and `@type` are aliased, this would be hard to manage
... Imagine also that a YAML-LD contains a tagged scalar in one place, and a value object in another place;
... if you expand and compact again, you may not be able to reconstruct an identical YAML-LD document.
Pierre-Antoine Champin: When you say it doesn't change the algorithms in JSON-LD API; it changes them in a trivial way.
... I"m a bit concerned in how it changes the algorithms.
... When we talk about round-tripping, we should be more explicit.
... The argument is about expansion/compaction there are already things you'll lose
... I'm not sure if it's important enough for changing the algorithms.
Niklas Lindström: Thanks for the elaborations. Would it technically be possible to use a new keyword "not compatible" for a literal object so it would be treated specially?
... The reason for that would be to represent it somehow in JSON-LD?
... Is there a risk that someone already uses aliases?
... I'm not sure that complicating the algorithms is warranted.
Gregg Kellogg: Adding a keyword to JSON-LD would be even more disruptive
... note also that the extended internal representation can not be represented in JSON
... the PR proposes a "down-conversion" to JSON
... currently converts RDF literals to the closest JSON-LD form (e.g. xsd:decimal to number)
... unknown datatypes become strings; an alternative would be to convert them to value objects
Niklas Lindström: I see the point about not serializing in JSON.
... What if a compactor would compact to the most compact form available? In YAML that would involved tagged scalar valiues.
... I'd expect someone using YAML to want that all the time.

Topic: Next call

Gregg Kellogg: We have a 4 hour time-slot during TPAC
... on 12 Sep, Vancouver time; this is a hybrid meeting, don't hesitate to join
Ted Thibodeau Jr.: For future reference -- "If the current agendum has been open for less than a minute use `close this agendum` explicitly to permit moving to the next agendum." -- from https://www.w3.org/2001/12/zakim-irc-bot.html