From a4432d78518957384ca6c7d551e910235e25e3a1 Mon Sep 17 00:00:00 2001 From: Gregg Kellogg Date: Wed, 13 Nov 2024 10:01:50 -0800 Subject: [PATCH] Minutes for 2024-11-13. --- 2024-11-13/index.html | 254 ++++++++++++++++++++++++++++++++++++++++++ 2024-11-13/irc.log | 178 +++++++++++++++++++++++++++++ index.html | 6 +- 3 files changed, 437 insertions(+), 1 deletion(-) create mode 100644 2024-11-13/index.html create mode 100644 2024-11-13/irc.log diff --git a/2024-11-13/index.html b/2024-11-13/index.html new file mode 100644 index 0000000..9900134 --- /dev/null +++ b/2024-11-13/index.html @@ -0,0 +1,254 @@ + + + + + + + + + + JSON-LD Community Group + + + + +
+

The W3C JSON-LD Community Group

+

Go Back

+ +
+

W3C Logo

JSON-LD WG

+

Minutes for 2024-11-13

+
+
+
Present
Ted Thibodeau Jr., Gregg Kellogg, Pierre-Antoine Champin, Niklas Lindström, Anatoly Scherbakov, David I. Lehn
+
Chair(s)
Gregg Kellogg, Benjamin Young
+
Scribe(s)
Gregg Kellogg
+
Agenda
https://www.w3.org/events/meetings/3509d178-04b3-43ae-9bb2-79fb946a91c1/20241113T120000/
+
Topics
  1. Announcements and Introductions
  2. Issue Discussion
Resolutions
  1. Address the concerns around when to use `@protected` (which were raised in https://github.com/w3c/json-ld-syntax/issues/443) through new content in the JSON-LD Best Practices document.
+
+
Gregg Kellogg is scribing.
+

+Topic: Announcements and Introductions +

+

+Topic: Issue Discussion +

+
Benjamin Young: We're working through the project list.
+
Gregg Kellogg: Added issues that are class 1-3.
+
Subtopic w3c/json-ld-syntax#436
+
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]
+
Gregg Kellogg: Might just create "tokens" for profile paraemters.
+
Gregg Kellogg: Tokens not being namespaced is mitigated by the fact that the media-type is the namespace.
+
Benjamin Young: So, it treats the media-type as the namespace.
+
... Profile parameters not having a colon is wide-reaching
+
Gregg Kellogg: Not sure how we update guidance for using profile parameters.
+
Benjamin Young: This would be a breaking change for web annotations.
+
... That would mean web annotations needs their own media type.
+
Niklas Lindström: Dlehn's reply may mean this isn't as horrible as it seems.
+
... I think the datasets working group has done something with this.
+
Pierre-Antoine Champin: This doesn't seem to be a problem where things can't work, but making them work is tricky, due to pre-flight requests.
+
... If we expect a server to support profile-based content-negotiation, it doesn't come automatically.
+
... If you want to support this, you'll also need to support pre-flight requests.
+
Benjamin Young: Q|
+
... This is difficult to configure and easily forgotten.
+
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]
+
Benjamin Young: There were some suggestions for defining enumerated values (tokens).
+
Pierre-Antoine Champin: I think it wouldn't hurt to define "short names" for the profiles in addition to the currently defined IRIs
+
... The key is to not make it a breaking change.
+
... This would affect the media-type registration.
+
Niklas Lindström: Aren't link headers defined similarly, where there are pre-defined tokens and IRIs may also be used.
+
Benjamin Young: Browsers have made decisions which are affecting what we can do.
+
Benjamin Young: > When processing the "profile" media type parameter, it is important to note that its value contains one or more URIs and not IRIs. In some cases it might therefore be necessary to convert between IRIs and URIs as specified in section 3 Relationship between IRIs and URIs of [RFC3987].
+ +
Niklas Lindström: Application/ld+json;profile="http://iiif.io/api/presentation/3/context.json"
+
Niklas Lindström: I think it would be good to add tokens. Rob's specific problem are more about the other uses of profiles.
+
... I wonder if our solution would be considered a solution for the issue; maybe parts of the issue can't be solved in the JSON-LD spec. Might recommend IIIF to use profile negotiation.
+
... But, using pre-flight does work, so that would be on their end.
+
... It's more that we put forward the design pattern and it has become more tricky.
+
Benjamin Young: The ramifications of this are not just expand/compact/... Rob's point is for other specifications that used the same pattern.
+
... No we know to avoid it.
+
Niklas Lindström: See also: https://www.w3.org/TR/dx-prof-conneg/ (and https://profilenegotiation.github.io/I-D-Profile-Negotiation/I-D-Profile-Negotiation.html )
+
... There's reason to document this in the best-practices document. How this affects other specs would mean that they cannot treat profile as being extensible, and will need a new media type.
+
Gregg Kellogg: We might create a registry to allow other specifications to add their profile parameters without needing a new media-type.
+
Benjamin Young: Niklasl shared a document on using the profile parameter for content negotiation.
+
Pierre-Antoine Champin: Reaching out the that TAG would be a good idea, as other specs rely on this, and they would be impacted.
+
... I'd like to see their thoughts and how much we should make the effort to try to change this.
+
... Regarding the spec, note that this is a working draft which has been inactive for a while. This might not be the strongest argument to take before the TAG. (The dataset exchange WG)
+
... Part of the reason that spec is stalled is that there are contentious discussions with IETF on where it belongs.
+
Niklas Lindström: From the dx-prof-conneg draft: During 2018, DXWG members had a longer discussion with the JSON-LD WG at the annual forum TPAC in Lyon, France and it was concluded that the "profile” parameter in the Accept and Content-Type headers should be seen to convey profiles that are specific to the Media Type [such as JSON-LD's expanded .... ]
+
... But, is there enough interest in IETF to continue the work?
+
Niklas Lindström: There are aspects of the draft that goes into the profile parameter of the media type is the right way to go.
+
... The design of IIIF and Activity Streams I appreciate more when not looking at it from an RDF perspective.
+
... These are more useful at the intersection of JSON and RDF, which makes it easier to create specifications in a distributed way.
+
... If I believed (from RDF perspective) that format is irrelevant, general content negotiation works well.
+
... I can see how the TAG might argue from one of these perspectives. Maybe we shouldn't invent media-types on the fly.
+ +
Pierre-Antoine Champin: Regarding the value of using JSON-LD media-type with parameter vs a new media-type, VC has had to rely on this for a while.
+
... The current solution is to have a dedicated media-type with additional language to explain the relationship between the two media types.
+
... We might point other specs to that solution.
+
Niklas Lindström: +1 To mentioning that "third" point of view (very pertinent IMHO)
+
Benjamin Young: I think we need to move on and come back to this issue.
+
... It would be great to write some of these things up on the issue so that we have something coherent to bring to the TAG.
+
... IETF has shifted their approach, and we're stuck in the middle. In the mean time, if we can collect thoughts in the issue.
+
... I don't think we know enough to lay out the preferred solution.
+
... If we go the short-name route, we run the risk of turning into a registry.
+ +
https://github.com/w3c/json-ld-syntax/issues/443 -> Issue 443 `@protected` creates unresolvable conflicts when the same term is defined in two contexts top-level (by trwnh) [spec:editorial] [wr:commenter-agreed-partial] [class-2]
+

+Subtopic: w3c/json-ld-syntax#443 +

+
Benjamin Young: This dove-tails with the profile-parameter conversation for other communities
+
... If a media type expects a context to exist, they would inject one if not provided.
+
... We could make other discussion issues from comments in this issue.
+
Niklas Lindström: IIRC, Activity Streams says you should put their context last because of this issue.
+
... If you use short names that have meaning, you must lock them down.
+
David I. Lehn: I need to re-review the issue.
+
... In the case of the controller, it would be to change the activity streams URL, but that's kind of strange. People expect terms to be gathered in one place.
+
Niklas Lindström: Maybe what is asked for is how to use this design pattern to have partial extensibility, extensions which are always subordinate to the "hardcoded" context (that may evolve)?
+
... This would conflict with other things where JWT is also used.
+
Pierre-Antoine Champin: The comment at the end is interesting as it resonates with TPAC discussions.
+
... There are two types of JSON-LD, one which is more about the RDF semantics, the other is about general representation of knowledge.
+
... I sympathize that we should make this more clear, but don't think it's a bug in the spec.
+
Benjamin Young: There's a tension between generic JSON-LD which is endlessly pluggable, which confuses people.
+
... In this view, JSON-LD isn't the end product, but adding in @protected you constrain it into a use case, as you are using very specific terminology and limiting the extension points.
+
... At TPAC there was a discussion about other things, such as schema.org, or are we going to specific content formats with self-defined semantics.
+
... Maybe this is not a syntax change, but a best practices note. If you're in ld+json land you can do what you want, but if you're in something that provides more constraints, you may need different solutions.
+
Niklas Lindström: +1 For best practice
+
Anatoly Scherbakov: +1
+
Gregg Kellogg: +1
+
David I. Lehn: It seems to be a bit more than best-practices as you need to tell people how to get around the rules.
+
David I. Lehn: It's nice when things live together.
+
Benjamin Young: In the future, maybe there would be a way to link from the spec to BP.
+
PROPOSAL: Address the concerns around when to use `@protected` (which were raised in https
+
https://github.com/w3c/json-ld-syntax/issues/443 -> Issue 443 `@protected` creates unresolvable conflicts when the same term is defined in two contexts top-level (by trwnh) [spec:editorial] [wr:commenter-agreed-partial] [class-2]
+
Benjamin Young: +1
+
Niklas Lindström: +1
+
Pierre-Antoine Champin: +1
+
Gregg Kellogg: +1
+
Anatoly Scherbakov: +1
+
Ted Thibodeau Jr.: +1
+
David I. Lehn: +1
+
David I. Lehn: Is it more "when" or "how" to use @protected?
+
+RESOLUTION: Address the concerns around when to use `@protected` (which were raised in https://github.com/w3c/json-ld-syntax/issues/443) through new content in the JSON-LD Best Practices document. +
+
Benjamin Young: We can make it as "best practice" and notify the commenter.
+
Niklas Lindström: ... And *why* to...
+
... @protected needs more content.
+
David I. Lehn: "... When, how, and why to use ..."
+
Anatoly Scherbakov: That's the one: https://github.com/json-ld/yaml-ld/pull/157
+
https://github.com/json-ld/yaml-ld/pull/157 -> Pull Request 157 Fix: #156. Update media type registration information. (by ioggstream)
+

+Subtopic: w3c/json-ld-api#608 +

+
https://github.com/w3c/json-ld-api/pull/608 -> Pull Request 608 Resolve the questions about "JSON Serialization" term (by anatoly-scherbakov) [spec:substantive] [ErratumRaised] [class-3]
+
Gregg Kellogg: Once we have approvals, we can merge.
+
Benjamin Young: There are more issues to discuss, but we'll continue to just move through the list. Cleaning house before worrying about the charter makes sense.
+ +
Benjamin Young: The project manager should include YAML-LD, CBOR-LD, JSON-LD-star and other things the WG is working on.
+
+ + \ No newline at end of file diff --git a/2024-11-13/irc.log b/2024-11-13/irc.log new file mode 100644 index 0000000..dc224f1 --- /dev/null +++ b/2024-11-13/irc.log @@ -0,0 +1,178 @@ +17:00:04 RRSAgent has joined #json-ld +17:00:08 logging to https://www.w3.org/2024/11/13-json-ld-irc +17:00:08 RRSAgent, make logs Public +17:00:09 please title this meeting ("meeting: ..."), gkellogg +17:00:14 meeting: JSON-LD WG +17:00:33 agenda: https://www.w3.org/events/meetings/3509d178-04b3-43ae-9bb2-79fb946a91c1/20241113T120000/ +17:00:34 clear agenda +17:00:34 agenda+ Announcements and Introductions +17:00:34 agenda+ Issue Discussion +17:00:34 agenda+ Charter Discussion +17:00:34 agenda+ Next call +17:00:55 present+ +17:00:58 chair+ +17:01:06 present+ +17:01:13 scribe+ +17:01:19 present+ +17:01:29 zakim, next agendum +17:01:29 agendum 1 -- Announcements and Introductions -- taken up [from agendabot] +17:01:39 present+ +17:02:10 zakim, close item 1 +17:02:10 agendum 1, Announcements and Introductions, closed +17:02:12 I see 3 items remaining on the agenda; the next one is +17:02:12 2. Issue Discussion [from agendabot] +17:02:14 zakim, next agendum +17:02:14 agendum 2 -- Issue Discussion -- taken up [from agendabot] +17:02:33 anatoly-scherbakov has joined #json-ld +17:02:37 bigbluehat: We're working through the project list. +17:03:12 present+ +17:03:48 gkellogg: added issues that are class 1-3. +17:03:59 subtopic w3c/json-ld-syntax#436 +17:04:00 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] +17:04:59 gkellogg: might just create "tokens" for profile paraemters. +17:05:54 gkellogg: tokens not being namespaced is mitigated by the fact that the media-type is the namespace. +17:06:14 bigbluehat: So, it treats the media-type as the namespace. +17:07:07 ... Profile parameters not having a colon is wide-reaching +17:07:41 q+ +17:08:03 q+ +17:08:04 gkellogg: not sure how we update guidance for using profile parameters. +17:08:29 niklasl has joined #json-ld +17:08:35 present+ +17:08:38 bigbluehat: This would be a breaking change for web annotations. +17:08:42 q? +17:09:00 ... That would mean web annotations needs their own media type. +17:09:03 ack niklasl +17:09:27 anatoly-scherbakov has joined #json-ld +17:09:31 present+ +17:09:48 niklasl: dlehn's reply may mean this isn't as horrible as it seems. +17:10:02 ... I think the datasets working group has done something with this. +17:10:13 ack pchampin +17:10:44 present+ +17:10:54 pchampin: This doesn't seem to be a problem where things can't work, but making them work is tricky, due to pre-flight requests. +17:11:19 ... If we expect a server to support profile-based content-negotiation, it doesn't come automatically. +17:11:33 ... If you want to support this, you'll also need to support pre-flight requests. +17:11:47 q| +17:11:50 q? +17:11:52 ... This is difficult to configure and easily forgotten. +17:12:04 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] +17:12:44 bigbluehat: There were some suggestions for defining enumerated values (tokens). +17:13:09 I think it wouldn't hurt to define "short names" for the profiles in addition to the currently defined IRIs +17:13:51 ... The key is to not make it a breaking change. +17:14:17 q+ +17:14:20 ... This would affect the media-type registration. +17:14:29 ack niklasl +17:14:59 niklasl: Aren't link headers defined similarly, where there are pre-defined tokens and IRIs may also be used. +17:15:36 bigbluehat: Browsers have made decisions which are affecting what we can do. +17:16:17 > When processing the "profile" media type parameter, it is important to note that its value contains one or more URIs and not IRIs. In some cases it might therefore be necessary to convert between IRIs and URIs as specified in section 3 Relationship between IRIs and URIs of [RFC3987]. +17:16:25 https://www.w3.org/TR/json-ld11/#iana-considerations +17:17:22 q+ +17:18:21 ack niklasl +17:18:50 application/ld+json;profile="http://iiif.io/api/presentation/3/context.json +17:18:53 niklasl: I think it would be good to add tokens. Rob's specific problem are more about the other uses of profiles. +17:19:08 q+ +17:19:22 s/context.json/context.json"/ +17:19:52 ... I wonder if our solution would be considered a solution for the issue; maybe parts of the issue can't be solved in the JSON-LD spec. Might recommend IIIF to use profile negotiation. +17:20:10 ... But, using pre-flight does work, so that would be on their end. +17:20:25 ack bigbluehat +17:20:26 ... It's more that we put forward the design pattern and it has become more tricky. +17:21:07 bigbluehat: The ramifications of this are not just expand/compact/... Rob's point is for other specifications that used the same pattern. +17:21:18 ... No we know to avoid it. +17:21:51 See also: https://www.w3.org/TR/dx-prof-conneg/ (and https://profilenegotiation.github.io/I-D-Profile-Negotiation/I-D-Profile-Negotiation.html ) +17:22:02 ... There's reason to document this in the best-practices document. How this affects other specs would mean that they cannot treat profile as being extensible, and will need a new media type. +17:23:05 q+ +17:23:38 q+ +17:23:38 gkellogg: we might create a registry to allow other specifications to add their profile parameters without needing a new media-type. +17:23:47 ack bigbluehat +17:23:58 bigbluehat: niklasl shared a document on using the profile parameter for content negotiation. +17:24:05 ack pchampin +17:24:32 pchampin: Reaching out the that TAG would be a good idea, as other specs rely on this, and they would be impacted. +17:24:57 ... I'd like to see their thoughts and how much we should make the effort to try to change this. +17:25:17 q+ +17:25:48 ... Regarding the spec, note that this is a working draft which has been inactive for a while. This might not be the strongest argument to take before the TAG. (The dataset exchange WG) +17:25:50 ack niklasl +17:26:25 ... Part of the reason that spec is stalled is that there are contentious discussions with IETF on where it belongs. +17:26:38 From the dx-prof-conneg draft: During 2018, DXWG members had a longer discussion with the JSON-LD WG at the annual forum TPAC in Lyon, France and it was concluded that the "profile” parameter in the Accept and Content-Type headers should be seen to convey profiles that are specific to the Media Type [such as JSON-LD's expanded .... ] +17:26:40 ... But, is there enough interest in IETF to continue the work? +17:27:19 niklasl: There are aspects of the draft that goes into the profile parameter of the media type is the right way to go. +17:28:07 ... The design of IIIF and Activity Streams I appreciate more when not looking at it from an RDF perspective. +17:28:38 ... These are more useful at the intersection of JSON and RDF, which makes it easier to create specifications in a distributed way. +17:28:40 q+ +17:29:17 ... If I believed (from RDF perspective) that format is irrelevant, general content negotiation works well. +17:29:50 ... I can see how the TAG might argue from one of these perspectives. Maybe we shouldn't invent media-types on the fly. +17:30:12 ack pchampin +17:30:37 https://www.w3.org/TR/vc-data-model-2.0/#media-type-precision +17:30:46 pchampin: Regarding the value of using JSON-LD media-type with parameter vs a new media-type, VC has had to rely on this for a while. +17:31:16 ... The current solution is to have a dedicated media-type with additional language to explain the relationship between the two media types. +17:31:22 q+ +17:31:33 ... We might point other specs to that solution. +17:31:40 +1 to mentioning that "third" point of view (very pertinent IMHO) +17:31:50 bigbluehat: I think we need to move on and come back to this issue. +17:32:16 ... It would be great to write some of these things up on the issue so that we have something coherent to bring to the TAG. +17:32:43 ... IETF has shifted their approach, and we're stuck in the middle. In the mean time, if we can collect thoughts in the issue. +17:32:59 ... I don't think we know enough to lay out the preferred solution. +17:33:19 ... If we go the short-name route, we run the risk of turning into a registry. +17:33:49 https://github.com/w3c/json-ld-syntax/issues/443 +17:33:50 https://github.com/w3c/json-ld-syntax/issues/443 -> Issue 443 `@protected` creates unresolvable conflicts when the same term is defined in two contexts top-level (by trwnh) [spec:editorial] [wr:commenter-agreed-partial] [class-2] +17:33:53 subtopic: w3c/json-ld-syntax#443 +17:35:41 bigbluehat: This dove-tails with the profile-parameter conversation for other communities +17:36:05 ... If a media type expects a context to exist, they would inject one if not provided. +17:36:14 q+ +17:36:19 ack bigbluehat +17:36:20 q+ +17:36:23 ... We could make other discussion issues from comments in this issue. +17:36:23 ack niklasl +17:36:45 q+ +17:37:13 niklasl: IIRC, Activity Streams says you should put their context last because of this issue. +17:37:28 ... If you use short names that have meaning, you must lock them down. +17:37:43 ack dlehn +17:38:03 dlehn: I need to re-review the issue. +17:38:40 ... In the case of the controller, it would be to change the activity streams URL, but that's kind of strange. People expect terms to be gathered in one place. +17:39:30 q+ +17:39:32 Maybe what is asked for is how to use this design pattern to have partial extensibility, extensions which are always subordinate to the "hardcoded" context (that may evolve)? +17:39:33 ack pchampin +17:39:40 ... This would conflict with other things where JWT is also used. +17:40:06 pchampin: The comment at the end is interesting as it resonates with TPAC discussions. +17:40:37 ... There are two types of JSON-LD, one which is more about the RDF semantics, the other is about general representation of knowledge. +17:41:00 ... I sympathize that we should make this more clear, but don't think it's a bug in the spec. +17:41:43 bigbluehat: There's a tension between generic JSON-LD which is endlessly pluggable, which confuses people. +17:42:28 ... In this view, JSON-LD isn't the end product, but adding in @protected you constrain it into a use case, as you are using very specific terminology and limiting the extension points. +17:43:07 ... At TPAC there was a discussion about other things, such as schema.org, or are we going to specific content formats with self-defined semantics. +17:44:00 ... Maybe this is not a syntax change, but a best practices note. If you're in ld+json land you can do what you want, but if you're in something that provides more constraints, you may need different solutions. +17:44:00 +1 for best practice +17:44:05 +1 +17:44:07 +1 +17:44:15 q+ +17:44:24 ack bigbluehat +17:45:01 ack dlehn +17:45:26 dlehn: It seems to be a bit more than best-practices as you need to tell people how to get around the rules. +17:47:04 dlehn: It's nice when things live together. +17:48:44 bigbluehat: In the future, maybe there would be a way to link from the spec to BP. +17:48:52 PROPOSAL: Address the concerns around when to use `@protected` (which were raised in https://github.com/w3c/json-ld-syntax/issues/443) through new content in the JSON-LD Best Practices document. +17:48:53 https://github.com/w3c/json-ld-syntax/issues/443 -> Issue 443 `@protected` creates unresolvable conflicts when the same term is defined in two contexts top-level (by trwnh) [spec:editorial] [wr:commenter-agreed-partial] [class-2] +17:49:01 +1 +17:49:02 +1 +17:49:03 +1 +17:49:03 +1 +17:49:04 +1 +17:49:10 +1 +17:49:18 +1 +17:49:42 dlehn: Is it more "when" or "how" to use @protected? +17:49:49 RESOLVED: Address the concerns around when to use `@protected` (which were raised in https://github.com/w3c/json-ld-syntax/issues/443) through new content in the JSON-LD Best Practices document. +17:50:16 bigbluehat: We can make it as "best practice" and notify the commenter. +17:50:17 ... and *why* to... +17:50:33 ... @protected needs more content. +17:50:48 "... when, how, and why to use ..." +17:51:05 That's the one: https://github.com/json-ld/yaml-ld/pull/157 +17:51:05 https://github.com/json-ld/yaml-ld/pull/157 -> Pull Request 157 Fix: #156. Update media type registration information. (by ioggstream) +17:51:14 subtopic: w3c/json-ld-api#608 +17:51:14 https://github.com/w3c/json-ld-api/pull/608 -> Pull Request 608 Resolve the questions about "JSON Serialization" term (by anatoly-scherbakov) [spec:substantive] [ErratumRaised] [class-3] +17:51:54 gkellogg: once we have approvals, we can merge. +17:52:38 bigbluehat: There are more issues to discuss, but we'll continue to just move through the list. Cleaning house before worrying about the charter makes sense. +17:53:10 q+ +17:53:16 ack anatoly-scherbakov +17:53:39 https://github.com/orgs/w3c/projects/84 +17:54:42 bigbluehat: The project manager should include YAML-LD, CBOR-LD, JSON-LD-star and other things the WG is working on. +17:56:29 ack anatoly-scherbakov +17:57:49 zakim, end meeting +17:57:49 As of this point the attendees have been TallTed, gkellogg, pchampin, niklasl, anatoly-scherbakov, dlehn +17:57:51 RRSAgent, please draft minutes diff --git a/index.html b/index.html index 86eee6a..6431f8b 100644 --- a/index.html +++ b/index.html @@ -119,7 +119,11 @@

The W3C JSON-LD Community Group

Go Back

-

W3C Logo

Joining Teleconferences

All JSON-LD teleconferences are open to the public. Anyone may join and participate in the discussion. All teleconferences are announced at least 24 hours in advance on the JSON-LD mailing list.

  • Meetings: generally every other week
  • Time: Every other Wednesday 1800 UTC, 9am San Francisco, 12pm Boston, 6pm Berlin
  • Where: Zoom (details in W3C calendar)
  • IRC: irc://irc.w3.org/#json-ld
  • Duration: 60 minutes

Make sure you have a good headset with a microphone as any background noise is distracting to others during the call. If there is excessive noise on your connection, you will be muted until you need to speak. Make sure you join the IRC channel as links and code examples are usually shared over the chat channel.

Minutes for meetings prior to the creation of the JSON-LD Working group may be found here.

Meeting for 2024-10-30

+

W3C Logo

Joining Teleconferences

All JSON-LD teleconferences are open to the public. Anyone may join and participate in the discussion. All teleconferences are announced at least 24 hours in advance on the JSON-LD mailing list.

  • Meetings: generally every other week
  • Time: Every other Wednesday 1800 UTC, 9am San Francisco, 12pm Boston, 6pm Berlin
  • Where: Zoom (details in W3C calendar)
  • IRC: irc://irc.w3.org/#json-ld
  • Duration: 60 minutes

Make sure you have a good headset with a microphone as any background noise is distracting to others during the call. If there is excessive noise on your connection, you will be muted until you need to speak. Make sure you join the IRC channel as links and code examples are usually shared over the chat channel.

Minutes for meetings prior to the creation of the JSON-LD Working group may be found here.

Meeting for 2024-11-13

+

Resolutions

    +
  1. Address the concerns around when to use `@protected` (which were raised in https://github.com/w3c/json-ld-syntax/issues/443) through new content in the JSON-LD Best Practices document.
    2. +
+

Meeting for 2024-10-30

Meeting for 2024-10-16

Meeting for 2024-10-02

Meeting for 2024-09-23