Meeting minutes
url: https://
Announcements and Introductions
pchampin: work on our charter has been announced to the AC
… so others can have a chance to chime in
pchampin: the announcement pointed the members to the public repo (link above)
JSON-LD Issue Discussion
https://
bigbluehat: I don't think the project has been re-sorted. Let's look at pending PRs.
Pull Request 625 (closes #555) Fall back to default logic in `useNativeTypes` mode for RDF numbers which are not JSON numbers (by anatoly-scherbakov) [class-3]
bigbluehat: this one was heavily approved
anatoly-scherbakov: I've recently applied suggestions from TallTed and pchampin
bigbluehat: the people involved in the review are all here. Any objection to merge it now?
pchampin: none from me
bigbluehat: hearing none, let's merge this PR
w3c/json-ld-api#559
<gb> Pull Request 559 Add JSON literal tests. (by davidlehn) [spec:substantive] [test:missing-coverage]
w3c/json-ld-api#585
<gb> Pull Request 585 Add graph container array tests. (by davidlehn) [test:missing-coverage]
bigbluehat: for this one (and the previous one), we don't have the commenters here. Hard to discuss them here.
w3c/json-ld-api#627
<gb> Issue 627 Recommend a way for dependent specs to call into this one, that's not WebIDL (by jyasskin) [ms:future-work] [needs discussion]
bigbluehat: we discussed this last call. I asked Jeffrey for more examples, which he provided.
… ivan, you pointed out that DID-Resolution uses INFRA instead of WebIDL.
… The main remaining issue is the amount of editorial work.
pchampin: we could maybe automate the WebIDL to INFRA conversion?
bigbluehat: or have an AI do that...
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]
bigbluehat: niklasl, this one is yours. No activity in the past 2 years (almost exactly).
<niklasl> https://
niklasl: I have a proposal about what to do. I have refactored my implementation accordingly.
… (link above)
… AFAICT this fixes the issue.
bigbluehat: niklasl, would you be willing to write a PR for that?
niklasl: yes, I can try
… I also need to check whether there are any side effects.
bigbluehat: this needs to be wrapped in <ind>/<del> tags, like the other PRs we have.
w3c/json-ld-syntax#436
<gb> Issue 436 URI in Profile triggers CORS Unsafe Request Header Byte rule (by azaroth42) [spec:w3c] [needs discussion] [tag-needs-resolution]
pchampin: I discussed this with Yves Lafon, staff contact of the TAG.
… This restriction of fetch is considered as an important security feature, this is unlikely to go away.
… To mitigate this issue, should we (JSON-LD WG) set up a registry for short-names for profiles of application/ld+json ?
niklasl: I don't think that a registry would solve the problem.
… We need to distinguish data shapes from the semantics of data.
… Activity Streams went for a specific media-type, others may have to do that.
… This issue seems specific to an RDF mindset.
… E.g. I want RDF, and I only understand SKOS.
… I have not seen the same kind of issue in other contexts, where structure and semantics are the same.
<niklasl> ... does the web need "compound media type negotiation" ... 🤔
pchampin: actually, video formats also suffer from the coarseness of media-types
bigbluehat: CORS breaks a lot of things. I don't think Ruben's proposal will fly.
<niklasl> (Or in the video format context, I guess "Accepts-Codex", ... And in the RDF context, maybe what I really want is "Accepts-Vocabulary" ... but try to realize that through "Accepts-Profile", for better or worse...)
bigbluehat: We have been discussing recently with the people working on profile-based conneg.
pchampin: activity on the dx-connegp has been on and off for a while. We may want to provide some help.
bigbluehat: JSON-LD mostly needs to help downstream specifications know what to choose among the media type vs. profile negotiation vs. something else
… we can and should point to the profile negotiation doc when it's available
niklasl: we at the National Libarry of Sweden, would really like to see a form of profile-based conneg. I think I could spend some time on this.
… Part of it is orthogonal to JSON-LD.
bigbluehat: agreed, it is not a core issue for us.
dlehn PRs
dlehn: what should I do about those, until we have a solid decision about the desired behaviour.
bigbluehat: if you would post a comment spelling out the decision that we need to make, this would be helpful.
dlehn: this mostly came out from somebody reporting a bug.
TallTed: a possible resolution is "this is an edge case, we won't solve it now"
json-ld/cbor-ld-spec#22
<gb> Pull Request 22 Add OpenBadges v3.0.0 context URL to registry. (by BigBlueHat)
bigbluehat: this PR adds a context URL in the CBOR-LD registry
… Dmitri suggested to change from the version-less URL to the versionned one.
dlehn: aren't we moving away from the registry, for CBOR-LD?
… People may continue to use the old stuff, though...
… We need to refine how it is supposed to work.
bigbluehat: I'll ask Wes dans Dave Longley (who are most active on CBOR-LD these days) what they think of it.
… This should be a more general discussion.
pchampin: I'm uncorfortable with CBOR numbers pointing to URL with changing content.
… But we need to discuss this with Wes and Dave Longley.