Meeting minutes
Announcements and Introductions
pchampin: development on the Rust json-ld crate seems to be active again
… I'm using it in Sophia, but it is an independant library
anatoly-scherbakov: I received a message about W3C inclusion fund accepting applications
bigbluehat: that's good news; I also heard about a Hackathon during TPAC; canivc.com will be part of it
YAML-LD check-in (5-ish minutes)
anatoly-scherbakov: last week we discuss the relevance of visualizations in the spec
… (sharing screen)
… the visualization strictly contains what is available in the document; nodes with links are clickable
… reviews are welcome
bigbluehat: I'm wondering about including the IRI scheme in the properties
pchampin: to be clear: the goal is to represent the RDF graph, not the YAML structure, right? [anatoly-scherbakov confirms]
CBOR-LD check-in (5-ish minutes)
bigbluehat: skipping this, as Wes is not here
JSON-LD Specs - PRs & Issues
Pull Request 671 Fix use native types flag with non-native values (by niklasl) [needs discussion]
niklasl: this issue has been around forevever; I think that implementations do not follow the spec (they would encounter issues),
… but instead implement the suggested change in this PR
… note that the HTML diff is easier to follow than the PR diff
bigbluehat: I agree on the separate PR for the change on the "quote" thing
<Zakim> pchampin, you wanted to react to anatoly-scherbakov
pchampin: the CI issue is due to an problem I created with common files,
… which w3c/
<gb> Pull Request 693 fix bug in Rakefile after removing common/ (by pchampin)
w3c/json-ld-api#693
pchampin: this PR is doing two things: fixing an issue created by the mutualization of common files
… but also commenting out the checking all the tests in the spec;
… the reason for commenting it out is that the tools we have currently do not support JSON-LD 1.2, which the examples are
… we can not rely on our tools being constantly up-to-date with the spec
anatoly-scherbakov: IIUC, the problem is the Ruby implementation lacking a maintainer;
… what would be the process to chose another implementation
TallTed: if we comment out, we should open an issue to keep track of this
niklasl: anatoly-scherbakov, good question, I'm conflicted.
… I would recommend my own tool, CONS: it is a one-man-show, no other contributors,
… PROS: no dependency (no dependency rot, not induced security issue)
pchampin: anatoly-scherbakov, the problem is not so much chosing another impl, but relying on it being constantly up-to-date
… for the dependency issue, dependabot is doing a good job
anatoly-scherbakov: the absence of implementations should not impede the development of the spec;
… we could run the tests in a way that provides a dashboard, but does not block PRs to be merged
bigbluehat: yes, that would be useful; anatoly-scherbakov could you work on that?
anatoly-scherbakov: yes, I could do that with PyLD, with which I'm more familiar
bigbluehat: I don't want to frame this as a change of tooling, though I'm not opposed to it
… the main goal is to solve the race condition we have
<anatoly-scherbakov> +1
<niklasl> +1
bigbluehat: let's not rush to solution; let's merge the PR to unlock other PRs, and discuss this further
<pchampin> +1
<anatoly-scherbakov> +1
bigbluehat: a first action would be to tweak the GH action to be non-blocking, regardless of the implementation
… then decide on switching to a different implementation
<niklasl> Apart from already having 671 in, TRLD is apparently bug-for-bug compatible with the spec even. ;D
Pull Request 481 Editorial: remove comma in section 4.1.8 (issue #477) (by anatoly-scherbakov)
<bigbluehat> bigbluehat: looks good to me.
Issue 558 Compaction cannot round-trip terms using `@container: @list` and `@type: @vocab` (by niklasl) [spec:enhancement] [spec:substantive] [ErratumRaised] [substantive:class 3]
niklasl: I have a change for this in my implementation, I could make a PR on the spec out of it.
… It is a shame that it is not behaving as expected, but from my organization's perspective this is not a priority.
… It is merely a convenience.
… We don't have a way to set `@container` to both `@set` and `@list`, where the outer array would be considered a set, and inner arrays would be considered lists
bigbluehat: agreed, very few people are going to trip over this
… thank you niklasl for your insight
Issue 492 Terms defined using list containers only preserve the latest-declared list value? (by trwnh) [needs discussion]
<bigbluehat> bigbluehat: related issue: w3c/
<gb> Issue 428 List of lists? (by puckipedia)
bigbluehat: this relates to a discovery recently in the VCWG: selective disclosure does not play nice with JSON-LD
… also a list-related issue, we seem to have a number of those
… we have a week to think about that
other PRs and issues
bigbluehat: I'm assuming that most of the pending errata are editorials and could be discussed in a separate meeting
TallTed: the challenge is to be disciplined and not solve the issued "inline"
<anatoly-scherbakov> w3c/
<gb> Pull Request 87 Promote vetted JSON-LD contexts (by anatoly-scherbakov)
anatoly-scherbakov: I wanted to raise a PR that I raised (above)
bigbluehat: we don't have time, but I'll add it to the discuss-call list
niklasl: I think we discussed a potential joint TPAC session with the RDF & SPARQL WG
bigbluehat: let's email the chairs and discuss the matter with them
<niklasl> Re. json-ld/
<gb> Issue 49 Adapting to Triple Terms and Reifiers (by gkellogg)
niklasl: I commented on the issue above, even though I know we should not spend too much time on 1.3 at the moment
bigbluehat: thanks everyone, next call in a week
m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/