15:59:56 <RRSAgent> RRSAgent has joined #json-ld
16:00:00 <RRSAgent> logging to https://www.w3.org/2026/06/10-json-ld-irc
16:00:00 <Zakim> RRSAgent, make logs Public
16:00:02 <Zakim> please title this meeting ("meeting: ..."), pchampin
16:00:07 <pchampin> meeting: JSON-LD Working Group
16:00:30 <bigbluehat> bigbluehat has joined #json-ld
16:01:44 <bigbluehat> present+
16:02:59 <niklasl> niklasl has joined #json-ld
16:05:57 <anatoly-scherbakov> anatoly-scherbakov has joined #json-ld
16:06:05 <anatoly-scherbakov> present+
16:06:09 <pchampin> present+
16:06:11 <niklasl> present+
16:07:02 <pchampin> regrets+ Victor
16:07:56 <TallTed> TallTed has joined #json-ld
16:09:04 <bigbluehat> present+ TallTed
16:09:29 <bigbluehat> scribe+ pchampin
16:10:22 <pchampin> topic: issue and PR triage
16:10:51 <pchampin> pchampin: I marked some issues and PR as "needs discussion" because I think they are ready for quick decision
16:10:54 <TallTed> present+
16:11:06 <bigbluehat> subtopic: https://github.com/w3c/json-ld-api/pull/692
16:11:06 <gb> s|https://github.com/w3c/json-ld-api/pull/692|-> Pull Request 692 use all common files by reference (to json-ld-wg) (by pchampin) [needs discussion] https://github.com/w3c/json-ld-api/pull/692
16:13:55 <pchampin> pchampin: this is to get rid of duplicated common files that we need to keep in sync
16:15:00 <pchampin> bigbluehat: seems like a good move; let's merge it, it won't make things worse
16:15:10 <bigbluehat> subtopic: https://github.com/w3c/json-ld-api/pull/691
16:15:12 <gb> s|https://github.com/w3c/json-ld-api/pull/691|-> https://github.com/w3c/json-ld-api/issues/691 "https://github.com/w3c/json-ld-api/pull/691"
16:15:24 <bigbluehat> scribe+
16:15:35 <bigbluehat> pchampin: anatoly-scherbakov and niklasl both made PRs on syntax and API to remove ins/del tags
16:15:41 <bigbluehat> ... this one is the missing link
16:15:52 <bigbluehat> ... it removes the blocks that were describing the candidate-level changes
16:16:08 <bigbluehat> ... so it moves that description into the changelog
16:16:57 <bigbluehat> ... oh...well...looks like I broke something by editing the `common/` files...which we just changed in the previous PR
16:20:39 <pchampin> subtopic: https://github.com/w3c/json-ld-api/pull/675
16:20:39 <gb> s|https://github.com/w3c/json-ld-api/pull/675|-> Pull Request 675 Add in memoriam text for @gkellogg. (by BigBlueHat) [needs discussion] https://github.com/w3c/json-ld-api/pull/675
16:20:56 <pchampin> pchampin: this one has a lot of approval; I don't know why it was not already merge
16:21:03 <pchampin> bigbluehat: me neither; let's merge it
16:22:30 <pchampin> subtopic: https://github.com/w3c/json-ld-api/pull/669
16:22:30 <gb> s|https://github.com/w3c/json-ld-api/pull/669|-> Pull Request 669 Improve test fromRdf#t0027. (by davidlehn) [needs discussion] https://github.com/w3c/json-ld-api/pull/669
16:22:41 <pchampin> bigbluehat: approved by two people
16:22:55 <pchampin> anatoly-scherbakov: could we setup an automerge after a given number of approval?
16:23:07 <dlehn1> present+
16:23:08 <pchampin> bigbluehat: not sure about that; there are different kinds of approval
16:24:39 <pchampin> pchampin: the reason I put the "needs discussion" label is that it was approved a long time ago, no reason to let it linger
16:25:03 <pchampin> ... whether or not my suggested change is included
16:25:43 <TallTed> q+ to speak antiautomerge
16:25:44 <pchampin> q+
16:25:55 <pchampin> anatoly-scherbakov: the reason I suggest auto-merge is that the probability to merge is high if several people approve and no one objects
16:26:27 <pchampin> ... also, reverting a PR is cheap; we could be faster with auto-merge and rare revert, than we are today
16:27:04 <pchampin> bigbluehat: a reason we are slow is that PRs have been stacking up for a long time, which also takes us time to "restore context"
16:27:05 <bigbluehat> q?
16:27:09 <bigbluehat> ack TallTed
16:27:09 <Zakim> TallTed, you wanted to speak antiautomerge
16:27:22 <pchampin> TallTed: I'm usually on the side of letting automation help the human
16:27:42 <pchampin> ... however, auto-merge because of 2 approvals does not lead to the desired effect, in my experience
16:28:12 <pchampin> ... it is too easy for people to auto-approve; and reverting can also be a nightmare
16:28:16 <bigbluehat> ack pchampin
16:28:30 <bigbluehat> pchampin: +1 to what TallTed and bigbluehat have said
16:28:42 <bigbluehat> ... there are some things about the current situation which makes things slow
16:29:03 <bigbluehat> ... but I think the discussions are helpful, especially as we get back into doing the work in this phase
16:29:11 <bigbluehat> ... I was happy to have my PRs discussed
16:29:38 <bigbluehat> ... but in interest of time, we could also give more leeway to editors to merge things more quickly
16:29:49 <bigbluehat> ... likely via some agreed upon rules from the group
16:30:01 <bigbluehat> ... something the Linked Web Storage group does is convert comments into issues
16:30:13 <bigbluehat> ... which prevents blocking PRs on commentary
16:30:27 <bigbluehat> ... so they push comments into issues to keep things in the queue
16:30:52 <pchampin> bigbluehat: I would like to see us do this more often
16:30:57 <TallTed> converting PR comments to new issues is a GREAT feature I've been using for some months if not years
16:31:09 <dlehn> q+
16:31:28 <bigbluehat> ack dlehn
16:32:20 <pchampin> dlehn: we just merged a comment in an n-quads file, which previously had no comment.
16:32:24 <pchampin> ... Is that a problem?
16:32:39 <pchampin> ... I'm not sure the custom n-quads parser we are using supports them...
16:33:02 <pchampin> bigbluehat: I think we will figure out :)
16:33:39 <pchampin> ... please, if it does break, either fix it or let us know
16:34:03 <bigbluehat> subtopic: https://github.com/w3c/cbor-ld/issues/47
16:34:03 <gb> s|https://github.com/w3c/cbor-ld/issues/47|-> Issue 47 Add discussion of processing models and their uses. (by wes-smith) [editorial] [needs discussion] https://github.com/w3c/cbor-ld/issues/47
16:34:28 <pchampin> bigbluehat: I think we can remove the "needs discussion" from this one; looks like we did discuss it
16:34:52 <pchampin> ... let's see if We resurfaces it
16:35:40 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/10-json-ld-minutes.html TallTed
16:35:53 <bigbluehat> subtopic: https://github.com/w3c/json-ld-syntax/issues/436
16:35:54 <gb> s|https://github.com/w3c/json-ld-syntax/issues/436|-> Issue 436 URI in Profile triggers CORS Unsafe Request Header Byte rule (by azaroth42) [spec:w3c] [needs discussion] [tag-needs-resolution] https://github.com/w3c/json-ld-syntax/issues/436
16:37:08 <dlehn> q+
16:37:08 <pchampin> bigbluehat: I think the conclusions we raised earlier about that one was to avoid using URLs in profiles
16:37:15 <bigbluehat> ack dlehn
16:37:44 <pchampin> dlehn: I need to wrap my head around this issue, but my recollection is that it was a user issue, not an error
16:37:52 <pchampin> ... things are behaving as expected
16:39:26 <pchampin> ... it leads to a preflight CORS request, which the server needs to handle
16:39:30 <pchampin> q+
16:39:34 <pchampin> q-
16:41:09 <pchampin> pchampin: I agree with dlehn that, in an ideal world where servers "do the right thing", this should not be an issue
16:41:18 <pchampin> ... but we don't live in an ideal world
16:41:37 <pchampin> +1 to address this in the best practices document
16:42:01 <pchampin> bigbluehat: what we can do is address it in the best practices document
16:42:13 <pchampin> ... it will probably not impact most JSON-LD users
16:42:40 <pchampin> ... and we can come back to this if it turns out we need to fix it in syntax or api
16:43:05 <pchampin> niklasl: I agree; Rob wrote in a comment that he agrees we can close it
16:44:45 <pchampin> q+
16:44:52 <bigbluehat> ack pchampin
16:45:08 <bigbluehat> pchampin: a little off topic, but regarding n-quads parsers
16:45:24 <bigbluehat> ... n-quads 1.2 adds directives, so it's now more complex than one quad per line
16:45:39 <bigbluehat> ... so having a more capable parser seems prudent.
16:46:27 <bigbluehat> https://github.com/orgs/w3c/projects/84/views/5
16:47:53 <pchampin> subtopic: https://github.com/w3c/json-ld-syntax/issues/457
16:47:54 <gb> s|https://github.com/w3c/json-ld-syntax/issues/457|-> Issue 457 is there a way to use `@container:@list` with custom props? (by VladimirAlexiev) [needs discussion] [defer-future-version] https://github.com/w3c/json-ld-syntax/issues/457
16:48:00 <pchampin> RRSAgent, make minutes
16:48:01 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/10-json-ld-minutes.html pchampin
16:49:03 <pchampin> bigbluehat: this one is labelled as "Future Version", but we are now in the future
16:49:12 <pchampin> ... we probably need more granular labels (1.2, 1.3)
16:49:37 <pchampin> ... do we want to use milestones?
16:50:01 <pchampin> niklasl: I kind of like milestones
16:50:14 <pchampin> bigbluehat: me too, but I'm not sure how it is going to play in the project
16:51:27 <pchampin> ... looks like projects support them
16:51:32 <anatoly-scherbakov> q+
16:51:37 <bigbluehat> ack anatoly-scherbakov
16:51:57 <pchampin> TallTed: I'm not against that, but the downside is that we would need to apply milestones to *everything* we have
16:52:01 <pchampin> q+
16:52:14 <pchampin> ... currently we are used to using labels
16:52:22 <bigbluehat> ack pchampin
16:54:02 <pchampin> pchampin: I slightly disagree with TallTed, just because we use milestones does not mean that we can't leave them unspecified on some issues/PRs
16:55:05 <pchampin> [discussion on whether we want to set due dates on milestones]
16:56:21 <anatoly-scherbakov> q
16:56:23 <anatoly-scherbakov> q+
16:56:45 <bigbluehat> ack anatoly-scherbakov
16:56:47 <pchampin> bigbluehat: back to this issue, that sounds like a big change
16:56:58 <pchampin> anatoly-scherbakov: this is a use-case for JSON-LD profiles
16:57:03 <bigbluehat> q+
16:57:14 <bigbluehat> ack bigbluehat
16:57:18 <pchampin> s/this is a/is this a
16:57:28 <niklasl> q+
16:57:29 <pchampin> ... can a profile deviate from the spec?
16:57:48 <bigbluehat> ack niklasl
16:57:54 <pchampin> bigbluehat: this does not affect the syntax, only the RDF output
16:58:03 <TallTed> q+
16:58:03 <pchampin> niklasl: that's also how I read it
16:58:16 <pchampin> ... I don't think it would be an easy thing to introduce
16:58:35 <pchampin> ... I would probably be against considering this for 1.2 or 1.3
16:58:53 <pchampin> +1, it also seems to big to me
16:59:54 <bigbluehat> ack TallTed
17:00:27 <pchampin> bigbluehat: I would suggest push the pain to another level
17:01:09 <pchampin> ... they would need to deal with that if they got an rdf:List from Turtle, for example
17:02:35 <pchampin> RRSAgent, make minutes
17:02:36 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/10-json-ld-minutes.html pchampin
17:02:55 <TallTed> s/seems to big to me/seems too big to me/
17:04:33 <pchampin> RRSAgent, make minutes
17:04:34 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/10-json-ld-minutes.html pchampin
17:06:09 <pchampin> RRSAgent, make minutes
17:06:11 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/10-json-ld-minutes.html pchampin
17:06:27 <pchampin> s|https://github.com/orgs/w3c/projects/84/views/5|
17:06:28 <pchampin> RRSAgent, make minutes
17:06:30 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/10-json-ld-minutes.html pchampin
17:12:05 <m2gbot> m2gbot has joined #json-ld
17:13:13 <pchampin> RRSAgent, bye
17:13:13 <RRSAgent> I see no action items