Meeting minutes
Announcements and Introductions
<bigbluehat> https://
bigbluehat: We've just merged the new playground onto the website.
… I need to implement hash fragment/query string parsing.
… After that, we can move out the old one and switch to this as the primary.
… It's missing the visualization bits; wanted to see how important people thought it was.
gkellogg: it's great to see evolution
<pchampin> +1 I have tested it a bit, and it is a very nice improvement
bigbluehat: This can be a foundation for the future.
… Probably still some bugs.
… I'll make issues for YAML-LD/CBOR-LD inputs.
gkellogg: we likely will meet.
… we usually do
… might be a good way to get folks updated and pin down some of these issues
… likely it's related how we do on rechartering by then
JSON-LD Issue Discussion
w3c/json-ld-api#650
<gb> Pull Request 650 #648 `0027-out.jsonld`: `@graph` and value objects (by anatoly-scherbakov) [test:missing-coverage]
anatoly-scherbakov: Someone said that `@graph` is not required, but it is in the test.
… Changes pchampin proposed have been taken care of.
pchampin: It doesn't seem that my suggestions were merged.
… This touches two files, and the changes seem unrelated.
… The HTML manifest has been changed.
anatoly-scherbakov: I don't know why the manifest changes are here.
gkellogg: the technology hasn't changed much, so this could be a bug in the manifest
anatoly-scherbakov: I'm going to try removing the changes to the HTML manifest.
pchampin: I was looking at the individual commits; I suspect that the change to the HTML manifest was not done by anatoly-scherbakov,
anatoly-scherbakov: Changes are done by the bot.
pchampin: The issue is that I don't see why there's a change.
w3c/json-ld-api#655
<gb> Pull Request 655 Tests t0112 and t0113 use 1.1-specific features (by gkellogg) [test:missing-coverage]
gkellogg: this one was based upon an inbound issue
w3c/
… whether or not `@graph` is necessary at some point
… these are related to 1.1 features which are meant to be tested against 1.0 and 1.1 implementations
… this change prevents them running against 1.0 implementations
bigbluehat: and look! there's that change again
pchampin: yeah. that's it.
gkellogg: it changed the `fromRDF-manifest.html`
… there must have been a change to the turtle manifest
… the issue is because the bot is not able to push commits to external repositories
… the purpose of the bot is to update all the things related to changes to the turtle manifest
… but if a change is made outside a branch, then the bot will not do it's work
… it should be a self correcting issue
… if we wanted to be clever, we could have a bot check all the manifests for consistency
… but the system will eventually stabalize
bigbluehat: If we merge 655 cold lead to a conflict
<gb> Pull Request 655 Tests t0112 and t0113 use 1.1-specific features (by gkellogg) [test:missing-coverage]
gkellogg: Shouldn't.
… Generally don't like to use merge commits.
json-ld/json-ld-star#61
<gb> Pull Request 61 Updated test results for JSON-LD-star (by gkellogg)
gkellogg: this is another call for review of this one
… I do see some feedback from pchampin and he's done a partial review
… the goal is to update JSON-LD-star to catch-up with where RDF 1.2 is
… so, rather than updating the spec, I've updated the tests
… and put in an abbreviated summary of what the changes would be
… so once that's approved, we can work on spec text changes
bigbluehat: these will need to be <ins>/<del> denoted changes?
gkellogg: no, this is on json-ld-star which is a CG report
… so this doesn't disrupt that
… there will, however, be needed work to merge the json-ld-star stuff into the main json-ld-syntax
dlehn: ...there are a lot of test files...
gkellogg: yeah...we're heavy on files
… and maybe a rework would take a different approach
… but as monumental a task as that would be, we're likely better off sticking with what we have now
… I would, however, like to annotate our spec pointing back to the tests
… I've done it elsewhere, but it'd be great here
… YAML-LD does that
… thanks to a push by ivan who did that for publishing WG
<TallTed> *cheers* for the gradual annotating / crosslinking
niklasl: I prefer to work like this than update the algorithms; it's easier for me.
… It would be catagorize tests with those that are more useful.
dlehn: Ordering would be nice, but tagging might be appropriate.
gkellogg: ideally every normative statemen links back to their tests
… but it can be challenging
ivan: We did it for ePub and it turned out to be extremely useful.
… When we had to report back on the PR, we could easily prove that we had a proper test suite.
… It's a heavy setup; The WebAPI people did it well, but I had to add some scripts to address assumptions in ReSpec.
gkellogg: I've been copying pasting from what you've been doing
… there's now a script that does much of the work for me
… it can identify the tests and make links back
… and it can be done asynchronously
… a test repo can iterate separately from the spec
… we have at least 3 specs here and each have their own test suites
… but maybe we could merge them
w3c/json-ld-api#58
<gb> MERGED Pull Request 58 Relative vocab (by gkellogg)
w3c/json-ld-api#558
<gb> Issue 558 Compaction cannot round-trip terms using `@container: @list` and `@type: @vocab` (by niklasl) [spec:enhancement] [spec:substantive] [ErratumRaised] [class-3]
niklasl: I started a PR for this, but am not quite ready for it yet.
w3c/json-ld-api#638
<gb> Pull Request 638 address #630 (by pchampin) [needs discussion] [class-2]
pchampin: This is about inverse context creation.
… I thought it was ambiguous in the definition of the active context.
… I tried to improve it without restructuring the document, which meant changing something in the terminology section.
… The end result is not 100% satisfying, as change to terminology is big.
… It's also inherited in other documents, so we need to mark changes in other documents, even though it's only in JSON-LD API.
bigbluehat: thoughts? especially on the size of the change?
bigbluehat: Looks like some validation errors.
gkellogg: I think it's good to go
… and I plan to make similar ones in the other specs
… so once we get the validation error fixed, we can merge this and make the others
bigbluehat: do we need to synchronize those changes across the specs?
gkellogg: the json-ld-commons repository is where the term changes would happen
… and then that would be copied back out to the individual spec repos
… and if we don't, then the github action will complain
… pchampin can you look at the markup issues?
pchampin: yep
w3c/json-ld-api#648
<gb> CLOSED Issue 648 Error in fromRdf/0027-out.jsonld (by marcelotto)
w3c/json-ld-api#659
<gb> Issue 659 Compacted form for the "Serialize RDF as JSON-LD Algorithm" (by multimeric)
gkellogg: this was a request related to flattening and framing
… that implies that maybe we could add some options to flattening
… my response was that recent changes should make it easier to get the original representation
… so stringing these algorithms together is still possible, but can now be shortened
… so I'd suggest we close this with no change
PROPOSAL: Close w3c/json-ld-api#659 with no change, as the ability to get the native form out of the API gets around the duplication.
<pchampin> +1
gkellogg: since this is really on the RDF side, my code handles it there
… it makes use of the JSON-LD algorithm
<niklasl> +1
gkellogg: for instance, I can pass in prefix mapping and use it later with contexts and frames
… I think trying to be a swiss army knife in the spec is not helpul
<gkellogg> +1
<ivan> +1
gkellogg: and this should be left to implementations
<bigbluehat> +1
<anatoly-scherbakov> +1
RESOLUTION: Close w3c/json-ld-api#659 with no change, as the ability to get the native form out of the API gets around the duplication.
<gb> Issue 659 Compacted form for the "Serialize RDF as JSON-LD Algorithm" (by multimeric)
gkellogg: shall we look at a few more?
… anything specific someone wants to discuss?
pchampin:
rechartering
pchampin: It might be useful to discuss rechartering.
… Talking with Ivan, CBOR-LD is going to become a dependency.
ivan: It's necessary for VCs.
pchampin: I haven't been too efficient on rechartering, I'll see what might be keeping us from moving forward.
<Zakim> bigbluehat, you wanted to say a bit about CBOR-LD
<pchampin> https://
bigbluehat: The CBOR-LD registry repo has been moved in the JSON-LD CG org. There's now an IANA registration.
… manu explained the vision for it and someone will be coming on in an upcoming meeting to discuss.
… I think the VC related (VPQR) is CBOR-LD turned into a QR code with some text.
ivan: We need to discuss how we do that as a working group. I'm a bit worried if we have a working group that does JSON- YAML- and CBOR-LD which can be complex.
… We'll also have a problem with cross registering.
… An alternative would be to create separate working groups, and charter it tightly, then it won't become a bottleneck for other groups.
bigbluehat: The cross-referencing concern is in between specs in the same WG.
ivan: We have a problem for this now.
… If we get into some VC issues that depend on CBOR-LD, it could lead to a problem.
… The counter argument is that if we have small WGs the community could be spread thin.
bigbluehat: I thought we were solving the cross-team problems by having them in one group.
ivan: I'm worried about dragging on.
gkellogg: I think specifically with CBOR-LD work has really been done by folks who are not working on JSON-LD or YAML-LD
… so in that sense, it has already been a separate group
… so we could formalize that
… but it would very much need liaison requirements
… and that we should focus on cross-compatibility and not just compression
… I would be in support, then, for a CBOR-LD group with liaison
bigbluehat: I think you're right that CBOR-LD has already been separated from this group.
… I think prior to that, we're going to need to have a conversation about what CBOR-LD is, is it an -LD format, or just a compression format?
… If it's its own working group, we're going to need to justify that.
… Generally, you need JSON-LD.
… I've reached out to more active CBOR-LD contributors for discussion.
… if it's its own charter, it may generate interest, but not result in good coordination.