The W3C JSON-LD Community Group

Go Back

W3C Logo


Minutes for 2024-05-15

Gregg Kellogg is scribing.

Topic: Announcements and Introductions

Pierre-Antoine Champin: Not sure if we've made a decision for TPAC, but we need to do so.
... I'd also like to report on the new GH Project.

Subtopic: TPAC

Benjamin Young: Can we take a call of people expecting to be at TPAC?
... I'll be there in person.
Gregg Kellogg: I'll be at TPAC
Pierre-Antoine Champin: Me too.
Ted Thibodeau Jr.: Online, most probably
Gregg Kellogg: How much time do we need?
Niklas Lindström: Unsure if I can be there in person, hope to be able to attend online.
Benjamin Young: Time will be relative to groups with other commitments.
Pierre-Antoine Champin: 23-27 September 2024, Anaheim, CA, USA
Benjamin Young: Can't conflict with VC.
Gregg Kellogg: Not RDF-star and convenient for WoT.
Benjamin Young: +1 To hafl-day meeting
... suggest 1/2 day slot consistent with the other groups.
Pierre-Antoine Champin: Bigbluehat will you respond to the link?
Benjamin Young: Yes, I'll respond.
Pierre-Antoine Champin: VC asked for Thursday and Friday morning. RDF-star for Tuesday and Thursday mornings.
Gregg Kellogg: We should ask for Thursday afternoon.
Ted Thibodeau Jr.: I'm in RDF-star and VC, so already double booked Thursday morning
Benjamin Young: It's broken into two-hour chunks. We can ask for 2-6.
Pierre-Antoine Champin: There are other questions related to mask policies.
... Do people feel strongly about masks?
Benjamin Young: It's really a survey question about making policy.

Topic: YAML-LD

Anatoly Scherbakov: It's been a while since I've had a YAML-LD update.
... We've removed the "extendedYAML" flag and now use "processingMode".
... Also, JSON-LD 1.0 is not supported.
... We've improved handling of script tags including "extractAllScripts", which also handles individual YAML documents within a YAML stream.
... I've created testing issues for YAML-LD features such as flatten, and so forth.
... I think most tests are for expansion and conversion to RDF.
... My implementation is a work in progress.
... There is a question about the return-type for YAML-LD functions; what should expand return.
... It seems it should return a string serialization, but we have an agreement that this is not very practical. Returning a Dict is more practical.
... We might file an issue against JSON-LD API to explicitly allow this.
Gregg Kellogg: Covering JSON-LD algorithms with tests specifically for YAML-LD might be repetitive, as JSON-LD already tests those. [scribe assist by Anatoly Scherbakov]
Niklas Lindström: +1
Anatoly Scherbakov: Agreed that we shouldn't duplicate all JSON-LD tests.
... My implementation runs both, as YAML is a superset of JSON so I can run all the JSON tests, too.
... But, there are some corner-cases which which aren't properly tested.
... We should test such cases.
Anatoly Scherbakov: Can we use a flag for returning internal representations vs strings to the API?
David I. Lehn: Output format related issue: -> Issue 143 Should output type of `expand()` be `dict` or `str`? (by anatoly-scherbakov)
Gregg Kellogg: Output values of JSON-LD, YAML-LD, CBOR-LD would then be identical. [scribe assist by Anatoly Scherbakov]
David I. Lehn: This would be the same for different formats, when there are differences in how you serialize.
... In some cases, it's obvious, but if there are special YAML or CBOR serializations used, I'm not sure how that would be described.
David I. Lehn: Do any of the API methods describe serialization?
Anatoly Scherbakov: I think having the behavior controlled by a flag would be confusing.
... It's difficult to describe in a type system.
... We might want separate functions for native vs serialized representations.
Pierre-Antoine Champin: I find this confusing, as when I look at the WebIDL, it describes that the result is serialized.
Gregg Kellogg: I think serialization is the ultimate step, which may be skipped.
David I. Lehn: Do we need to be explicit about that?
Pierre-Antoine Champin: Static Promise<JsonLdRecord> compact( ... )
Pierre-Antoine Champin: Typedef record<USVString, any> JsonLdRecord;
Pierre-Antoine Champin: Does not look like a serialized string to me!
Anatoly Scherbakov: What we add a new function to JSON-LD API? static UVString serialize(input: JsonLDRecord, format: UVString)
... In our JS code, we have explicit format flags.
Anatoly Scherbakov: ...On par with JSonLdRecord parse(serialized_input: UVString, format: UVString)
Anatoly Scherbakov: I agree with using format names when describing how to serialize, but I suggest two different functions, parse and serialize.
... Thus, you expand a document and explicitly serialize.
... This makes the API clear.
Pierre-Antoine Champin: I think there's some inconsistency in the JSON-LD API spec. The result is a Promise of a JsonLdRecord which is a map, not a string.
... If anything, it should say to turn the internal representation into a JsonLdRecord.
Niklas Lindström: +1 Something is inconsistent (but the API IDL is informative...)
Niklas Lindström: (Non-normative)
... Currently, the IR is mapped on JSON, so the serialization is standard JSON.
... I'd be happy if the API says to return the IR.
... The expectation is that if it's an HTTP interface, the result needs to be serialized.
... We should try not to over-specify this. Its up to implementers to decide best encoding.
Gregg Kellogg: PR and/or issue against JSON-LD API welcome.
Anatoly Scherbakov: I agree that specifying the details of serialization is out of scope, but I would propose that we describe serialization and deserialization functions.
... I don't think we need to specify this in detail, just that they exist.
... We're focusing on the YAML-LD basic profile, but we do have non-normative sections describing extended forms.
... If we have a serialize function, we might add a note there.
Anatoly Scherbakov: I will look into preparing a PR for the spec, and see what everyone thinks.

Topic: JSON-LD Issue Discussion

Pierre-Antoine Champin: I had an action for creating a new project that is automatically updated.
... The original project is "old style", and the actions only work with "new style" projects.
... I suggest we close the old one and continue with the new one.
PROPOSAL: close the old project in favor of the new.
Ted Thibodeau Jr.: +1
Anatoly Scherbakov: +1
Gregg Kellogg: +1
Benjamin Young: +1
Pierre-Antoine Champin: +1
Niklas Lindström: +1
David I. Lehn: +1
RESOLUTION: close the old project in favor of the new.
Pierre-Antoine Champin: Do we want to merge CG and WG issues together?
Pierre-Antoine Champin: It should work with the json-ld organization
Gregg Kellogg: Maybe we can apply some labels to the CG repositories.

Subtopic: website

David I. Lehn: I haven't quite had time to finish, but the new site mostly works.
... Depends on where we want to host it, and we have a lot of .htaccess files floating around.
... We'll have to write some custom workers for things like content negotiation.
Gregg Kellogg: Playground should used cached version of the context.
David I. Lehn: Next steps are to include such features.
... Not sure how to best update the playground, may be an NPM package.
Anatoly-scherbakov Pointer to the repo? -> Pull Request 836 Convert to Eleventy. (by davidlehn) [website]
Gregg Kellogg: Next meeting in two weeks.