– DRAFT –
JSON-LD WG

Announcements and Introductions

bigbluehat: this is the JSON-LD WG call, going to talk about JSON schema and then discuss what our work mode will be and what our priorities can be

ajs6f: I participated in the runup to 1.1 but had to step away, that has shuffled and I am able to spend more time here again.

bigbluehat: Glad to see people familiar with the process coming back.

Jason Desrosiers on JSON Schema

jdesrosiers: I'm Jason from the JSON schema group, and I'll talk about where I see some overlap and synergies we can have with JSON-LD.
… for the most part the two are distinct things, I see JSON schema being about defining the structure of data while JSON-LD is about defining the semantics of data, so there is not a ton of overlap in that way, but there are people who would want both.
… That is something we can end up working together on.
… Roberto has done some work on bridging that gap and defining semantics in a JSON schema so you don't have to have both a schema and JSON-LD.
… What we mostly see in our community is people showing up confused about the naming of things - they think we have something to do with schema.org.
… We also see people coming in asking about defining semantics in their schemas.
… SHACL is related to this effort. JSON schema can not validate JSON-LD directly since JSON-LD does not have a fixed shape - different structures can mean the same thing.
… Some people want to add semantics to their JSON without full on using JSON-LD.
… Another reason people want to use JSON schema is that it is a little more well known and easier to use than SHACL.
… That's where we see the overlap - Roberto is working on tools/specifications for helping to make that happen.
… We are here to help in any way that we can find synergies.

bigbluehat: That's awesome - do you know much about the JSON schema vocabularies work?
… Does that have overlap with JSON-LD?

jdesrosiers: That is separate, that is for defining different versions of JSON schema, for example OpenAPI has its own flavor of JSON schema via the vocabulary feature.

<pchampin> Roberto's specification: ioggstream/draft-polli-restapi-ld-keywords

jdesrosiers: currently Roberto's specification (REST API Linked Data Keywords, ioggstream/draft-polli-restapi-ld-keywords) is a standalone specification from the main JSON schema spec, but we want to find ways to integrate it more cleanly.

<wes-smith> s/???/REST API Linked Data Keywords

jdesrosiers: One of the biggest problems we have is that there are multiple versions of JSON schema, and knowing which to reference is a big problem.
… Hopefully in the next several months we will be ready to release a new version of JSON schema that will be more of a living spec.
… There will one spot that it lives and the "what thing do you reference" problem will be solved.

ivan: Exact reference is only one problem we have hit, the other is that all the references the standard document relies on need to have a certain level of stability.
… That is related to the several version problem.
… Often what happens is that we take the easy way out and say that JSON schema is not stable, but that is not an ideal thing to do.
… There were discussions previously if JSON schema could be formally standardized, but those discussions went nowhere..
… This was a long time ago, pre-COVID.

jdesrosiers: We can certainly discuss what we can do to ensure references are stable and what we are doing is compatible with what you need.

ivan: There is stability and also assurance that there is backwards compatibility. Extending a standard and adding new features is fine, but if backwards compatibility goes away and the new standard makes older schemas invalid, that is a problem.

jdesrosiers: That's a big part of what we are changing in the next version, there are going to be some backwards incompatibilities in the next version, but those changes should allow future changes without backwards compatibility issues.
… A rough timeline for that is this year sometime, probably sooner than later. My guess would be summertime.

ivan: We are working on another standard in another working group for which JSON schema will be related, maybe we will be the first users of the new version. We will see.

jdesrosiers: A note on standardization - we have been talking to ECMA about doing something more formal with them.

bigbluehat: Is there a good place for folks to engage with the JSON schema work?

jdesrosiers: We have a slack workspace that is a pretty good place to come and there is also the spec GitHub repo.

bigbluehat: Thanks very much, did you have anything else you wanted to say?

jdesrosiers: That's all from me.

bigbluehat: Thanks for coming - it's great to hear a timeline. This standardization thing has hampered several specs, it would be great to see that cleaned up.

Planning the Plan

<bigbluehat> https://github.com/orgs/w3c/projects/84/views/1

<jdesrosiers> JSON Schema specification: json-schema-org/json-schema-spec

bigbluehat: Moving on, we have this project management tool, which frankly has been not heavily touched in the last 5 months.
… We are mostly doing things in PRs.

<jdesrosiers> JSON Schema Slack: https://json-schema.org/slack

bigbluehat: In the maintenance phase from recently we used the "future work" bucket a lot, there is also "non-TR" work and "errata", lots of this requires tests to be written or general cleanup.
… There is a lot in this space and now that we've been rechartered we have 5 specifications that we are working towards in 2 groups - YAML-LD, CBOR-LD, three JSON-LD 1.2 specs.
… What I'd like to propose is that this current view get cleaned up, by the chairs and in calls, to just focus on the JSON-LD 1.2 stuff, and we create new views and project spaces for YAML-LD and CBOR-LD.
… I'm not sure we need a separate project tool for YAML-LD and CBOR-LD.
… We can talk about timelines and how we come at issue resolution/PRs.
… Any thoughts on the general project tool/view/proposal?

<anatoly-scherbakov> +1

<pchampin> +1

<rubensworks> +1

<ajs6f> +1

bigbluehat: The proposal is to move YAML-LD and CBOR-LD out of the project management view.

<niklasl> +1

<ivan> +1

bigbluehat: Timeline wise, what I mentioned in January but is still open for today but I want to pin down today, is that because YAML-LD is essentially done per the CG effort. There aren't many pending issues. We want to push that to Candidate Rec sooner rather than later. We should move YAML-LD and then CBOR-LD towards a 1.0 ready state first.
… We should get those into horizontal review and out to pasture.

<ivan> +1

bigbluehat: Then we can move to JSON-LD 1.2.
… Hopefully mid summer we will have those five specifications in CR-ready state, than can look towards JSON-LD 1.3/2.0.

ivan: There are steps you cannot avoid, I know there is a calculation for the minimal time to go to rec, there are non-compressible steps.
… What we can do now is vote to move YAML-LD to a first public working draft. It is still a community final draft.
… That's an important step for W3C publication.
… That's also when we can start horizontal reviews.

<bigbluehat> +1

<pchampin> and for IPR

ivan: Patent review is one of the incompressible periods between first public working draft and CR.
… For CBOR-LD I don't know if it is in the same stage, but I think it's true that we can also publish first publish working draft.
… I think these are the two most urgent things.

bigbluehat: I agree with that, what actions do we need to take to move YAML-LD to first public working draft? You mentioned issues don't have to be solved, PRs don't have to be merged?

ivan: You need W3C patent policy to kick in, and for that to happen we need to publish a first public working draft.

bigbluehat: What action do we need to take as a WG?

ivan: we need to do a formal resolution that can be referred to in the minutes.
… That can be done today.
… Then there is a transition request that had to happen.
… Then there is a set of steps to publish it.

pchampin: Another step is to move the repo to the W3C organization.
… It's on the json-ld organization.
… Probably a working group resolution is enough for that, and we can make the two resolutions today.

bigbluehat: The editors on YAML-LD just list the community, but CBOR-LD lists three people including wes-smith.

<TallTed> s|s/???/REST API Linked Data Keywords||

bigbluehat: anatoly-scherbakov, you should probably list yourself as an editor on YAML-LD.

dlehn: This is just one spec, is that ok?
… In JSON-LD we separate between spec repos and APIs, and this is just one document in one repo.

ivan: W3C has no requirements there, it is up to the WG to define.

<ivan> +1

<bigbluehat> +1

pchampin: If there were multiple YAML-LD specifications it would be up to the WG whether to use multiple repos, I don't see a need for multiple specifications for YAML-LD.

<anatoly-scherbakov> +1

PROPOSAL: Move json-ld/yaml-ld to the W3C organization and publish it as FPWD with the short name of `yaml-ld`.

<bigbluehat> +1

<pchampin> +1

<ivan> +1

<TallTed> +1

<niklasl> +1

<wes-smith> +1

<rubensworks> +1

<dlehn> +1

<anatoly-scherbakov> +1

RESOLUTION: Move json-ld/yaml-ld to the W3C organization and publish it as FPWD with the short name of `yaml-ld`.

<ajs6f> +1

wes-smith: there are two repos for CBOR-LD
… one for the actual specification and one for the registry

ivan: do you mean there's also a second required repo?

wes-smith: sort of. The registry is essentially a big table
… which used to be in the spec
… but we moved it out to give it its own governance

ivan: so, those are two different things
… for the registry, I don't have a strong opinion about where it lives
… maybe we leave it where it is so it doesn't change URLs
… but we can do that next week

wes-smith: so, what decision do we still need to make for the registry?

ivan: deciding where it lives long term is something we can do later.

dlehn: the registry is pretty complicated
… I don't know how we handle it
… maybe it shouldn't even be in the W3C space?
… can anyone make changes there?

bigbluehat: There is a registry process at W3C, there is already some precedent in the DID WG for having a CG maintain a registry on behalf of a WG.
… I think the registry process is still quite new at the W3C.
… The registry is not itself a specification, we can agree on the proposal to move the spec, the registry can get its own governance and process.

ivan: We have to be careful with terms, the term "registry" has a formal definition at W3C which is not widely used yet, we have not yet decided that what we are talking about will be a W3C Registry.
… What I remember from the registry process is that it requires a formal maintenance policy that has to be voted upon by the AC.
… Let's table the discuss on the details there until later.

bigbluehat: And to confirm, it's ok to move the CBOR-LD spec to FPWD without deciding this?

ivan: Yes, let's discuss it later.

<anatoly-scherbakov> +1

PROPOSAL: Move json-ld/cbor-ld-spec to the W3C organization and publish it as FPWD with the short name of `cbor-ld`.

<wes-smith> +1

<pchampin> +1

<TallTed> +1

<anatoly-scherbakov> +1

<ivan> +1

<bigbluehat> +1

<niklasl> +1

<dlehn> +1

<rubensworks> +1

<ajs6f> +1

<ajs6f> Sorry, just type slow.

RESOLUTION: Move json-ld/cbor-ld-spec to the W3C organization and publish it as FPWD with the short name of `cbor-ld`.

JSON-LD Issue Discussion and Organization

Open Discussion

<ajs6f> Bye all!

bigbluehat: great work everyone. bye all