Meeting minutes
Announcements and Introductions
pchampin: 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.
bigbluehat: Can we take a call of people expecting to be at TPAC?
… I'll be there in person.
gkellogg: I'll be at TPAC
pchampin: me too.
<pchampin> https://
<TallTed> online, most probably
gkellogg: how much time do we need?
<niklasl> Unsure if I can be there in person, hope to be able to attend online.
bigbluehat: Time will be relative to groups with other commitments.
<pchampin> 23-27 September 2024, Anaheim, CA, USA
bigbluehat: Can't conflict with VC.
gkellogg: not RDF-star and convenient for WoT.
<bigbluehat> +1 to hafl-day meeting
gkellogg: suggest 1/2 day slot consistent with the other groups.
YAML-LD
<pchampin> https://
pchampin: bigbluehat will you respond to the link?
bigbluehat: Yes, I'll respond.
pchampin: VC asked for Thursday and Friday morning. RDF-star for Tuesday and Thursday mornings.
gkellogg: we should ask for Thursday afternoon.
<TallTed> I'm in RDF-star and VC, so already double booked Thursday morning
bigbluehat: It's broken into two-hour chunks. We can ask for 2-6.
pchampin: There are other questions related to mask policies.
… Do people feel strongly about masks?
bigbluehat: It's really a survey question about making policy.
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.
<anatoly-scherbakov> gkellogg: Covering JSON-LD algorithms with tests specifically for YAML-LD might be repetitive, as JSON-LD already tests those.
<niklasl> +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?
<dlehn> output format related issue: json-ld/
<gb> Issue 143 Should output type of `expand()` be `dict` or `str`? (by anatoly-scherbakov)
<anatoly-scherbakov> gkellogg: output values of JSON-LD, YAML-LD, CBOR-LD would then be identical.
dlehn: 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.
dlehn: 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.
<pchampin> https://
pchampin: I find this confusing, as when I look at the WebIDL, it describes that the result is serialized.
gkellogg: I think serialization is the ultimate step, which may be skipped.
dlehn: Do we need to be explicit about that?
<pchampin> static Promise<JsonLdRecord> compact( ... )
<pchampin> typedef record<USVString, any> JsonLdRecord;
<pchampin> 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)
dlehn: 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.
pchampin: 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.
<niklasl> +1 something is inconsistent (but the API IDL is informative...)
<niklasl> (non-normative)
pchampin: 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.
gkellogg: 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.
CBOR-LD
JSON-LD Issue Discussion
<pchampin> https://
pchampin: 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.
<pchampin> https://
pchampin: I suggest we close the old one and continue with the new one.
PROPOSAL: close the old project in favor of the new.
<TallTed> +1
<anatoly-scherbakov> +1
+1
<bigbluehat> +1
<pchampin> +1
<niklasl> +1
<dlehn> +1
RESOLUTION: close the old project in favor of the new.
pchampin: Do we want to merge CG and WG issues together?
pchampin: It should work with the json-ld organization
gkellogg: maybe we can apply some labels to the CG repositories.
website
dlehn: 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.
gkellogg: playground should used cached version of the schema.org context.
dlehn: 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?
<gb> Pull Request 836 Convert to Eleventy. (by davidlehn) [website]
gkellogg: next meeting in two weeks.