diff --git a/2024-09-11/index.html b/2024-09-11/index.html new file mode 100644 index 0000000..fce0651 --- /dev/null +++ b/2024-09-11/index.html @@ -0,0 +1,235 @@ + + + + + + + + + + JSON-LD Community Group + + + + +
+

The W3C JSON-LD Community Group

+

Go Back

+ +
+

W3C Logo

JSON-LD CG

+

Minutes for 2024-09-11

+
+
+
Present
Ted Thibodeau Jr., Pierre-Antoine Champin, Gregg Kellogg, Niklas Lindström, Benjamin Young, Anatoly Scherbakov
+
Chair(s)
Gregg Kellogg, Benjamin Young
+
Scribe(s)
Gregg Kellogg, Benjamin Young
+
Agenda
https://www.w3.org/events/meetings/e439ee3a-38a9-4506-b9c8-8ba0a2b79cbc/
+
Topics
  1. TPAC preparation
  2. TPAC Schedule
+
+

+Topic: TPAC preparation +

+
Gregg Kellogg is scribing.
+
Benjamin Young: We're mostly talking about the breakout panel at TPAC.
+
... We need some YAML-LD slides
+
Anatoly Scherbakov: I'm working on the presentation, it's a draft now.
+
Anatoly Scherbakov: We have a template and I am using that
+
Benjamin Young: I've started using the W3C template.
+
Benjamin Young: Start presentation with JSON-LD history.
+
... Next work is on for the next version.
+
... I wasn't going to talk too much about what goes into JSON-LD 1.2.
+
... The plan is mostly built off the CBOR-LD 1.0 spec, and we'll bring in work from related specs.
+
... I'll get Wes to provide some more detail.
+
Gregg Kellogg: CBOR also needs something from YAML
+
Benjamin Young: Examples walk through a comparison of JSON-LD and YAML-LD leading to a barcode.
+
... Then discuss CBOR-LD Road Ahead
+
... I plan to bring in anatoly-scherbakov's work into this slide deck.
+
... Starting discussion on hash fragments.
+
... Hash ID interpretation potentially allows hashes to have different meanings in JSON-LD.
+
... There continue to be stones thrown at JSON-LD on issues related to hash identifiers.
+
... There is value to be had if you can reference a context via its hash.
+
... An interpreter could use or ignore the hash.
+
Pierre-Antoine Champin: Is the idea to specify that application/ld+json has a special meaning for fragment identifiers?
+
... (yes)
+
... This is important to explain to people that a context IRI is an identifier.
+
Benjamin Young: The fragment identifiers only have meaning to client code.
+
Pierre-Antoine Champin: My point was that if you insist on IRIs in general, and context IRIs in particular as being identifiers, then you have two different identifiers (with and without hash).
+
... If you want to be consistent, VC would need to use context identifiers containing this hash.
+
Benjamin Young: Are documents served with or without hash the same?
+
... The goal is to be able to say the intention of what is requested.
+
... Data integrity doesn't depend on this, as it's based on triples.
+
... There's a big need for this.
+
Benjamin Young is scribing.
+
Gregg Kellogg: It's too premature for this to be a deliverable for the new WG
+
... we could say we're exploring this for possible future standardization and handle it in a recharter
+
... it's too hand wavy right now
+
... and full of a lot of issues
+
Gregg Kellogg: This does remind me of hash link which sadly didn't go anywhere
+
... so sadly that's not available
+
... but I remain wary of adding this as a normative deliverable
+
Benjamin Young: The plan was to issue this as a note. It could eventually make its way into the spec.
+
... I think it's optional, and is experimental. I could optionally be used to validate that a JSON document matches the hash.
+
... I wanted to signal to the wider community that we recognize the issue and are exploring solutions.
+
Ted Thibodeau Jr.: I think it's a good thing to add. I think the "##" is not the say to do it.
+
... A fragment identifier is a very specific thing, and you don't use '='. It could be ...
+
Gregg Kellogg: RFC3986 has an ABNF for IRIs which we've adopted in RDF Concepts
+
Pierre-Antoine Champin: I believe that '=' is allowed in hash fragment, even though it does not have any special meaning
+
Ted Thibodeau Jr.: So some of characters may need to be encoded, but that doesn't change their meaning in the value
+
Ted Thibodeau Jr.: Some characters may need to be URL endcoded with %
+
Gregg Kellogg: Why is this a JSON-LD thing?
+
... it seems this would be generally useful
+
... to verify the hash on the URL against the retrieved content
+
... maybe it's more IETF?
+
... some sort of fragment identifier subset that could allow specifications that invoke that to have these symantics
+
Benjamin Young: We tried to do this more generally (i.e. hashlink), but IETF ties this to the media type.
+
... To be general, either client code decides to interpret this or not.
+
... Hashlink didn't work, because it was proposing something be implementable everywhere.
+
... It also proposed that it shouldn't be a hash thing, but something server sent.
+
... URLs get us into the realm of APIs.
+
Anatoly Scherbakov: I've taken another headset, should work, but my mic is supposed to be off now :./
+
... That would need to include some protocol element.
+
... A hash was chosen, because it doesn't eliminate the ability for a server to send it, but it's up the client to interpret.
+
... I'd love to work on it or propose it as a work item.
+
Ted Thibodeau Jr.: The problem with using a fragment identifier is that can't be returned by a server.
+
... A query parameter is probably better. Servers usually just ignore parameters they don't understand.
+
... It might be better as an HTTP parameter.
+
... This is the only way for a client to make a request of the server that it can choose to honor or not.
+
Anatoly Scherbakov: (Shares screen)
+
... I've prepared a presentation on YAML-LD.
+
... JSON-LD allows applications to understand metadata if they share a common understanding of the vocabularies used.
+
... JSON is a straight-forward format be tedious to write. YAML addresses this.
+
... The YAML-LD version of the example removes a lot of syntax.
+
... We're trying to make Linked Data more writable/readable for people not expert in Linked Data.
+
YAML-LD allows you to reuse existing YAML files, similar to how JSON-LD allows the use of regular JSON files.
+
... We currently have two implementations (gkellogg's and anatoly-scherbakov's).
+
... We use a convenience context to avoid having to quote '@id', for example.
+
Anatoly Scherbakov: Where do the slides go?
+
Benjamin Young: I have a repo which isn't public yet, but we can use that for slides.
+
Anatoly Scherbakov: JSON-LD doesn't require indentation, but without it, it is difficult to read. Of course, it's required for YAML.
+
Gregg Kellogg: YAML-LD does everything JSON-LD does. It's just easier for humans to write and manage
+
Gregg Kellogg: I think you have a single example in there that may be too simple
+
... maybe we can share examples with the CBOR-LD examples?
+
Anatoly Scherbakov: I suppose those are in bigbluehat's deck?
+
Benjamin Young: Yep
+
Benjamin Young: The presentation in the default template uses an odd color scheme, so I include highlight.js.
+
Pierre-Antoine Champin: Comments are a great feature of YAML that JSON doesn't support.
+
Anatoly Scherbakov: I wouldn't encourage people to use comments in YAML-LD, at least in the data. May be useful in contexts, but otherwise something like rdfs:comment could be used.
+
Pierre-Antoine Champin: I disagree, as you typilcally don't want comments in the data.
+
Gregg Kellogg: RDF-star will be discussed earlier in the week
+
... so it may not get discussed during the group call on Thursday as much
+
Niklas Lindström: I mostly do agree, that comments *in* data is also data (rdfs:comment, or ... RDF-star annotations(!)). But comments for editing *may* be* another thing (on many levels). It's... complicated. ;)
+
Ted Thibodeau Jr.: I do wish those TPAC calendar entries could all start with `TPAC:`
+
Ted Thibodeau Jr.: If they could put "TPAC:" in front of these meetings, it would be less confusing.
+

+Topic: TPAC Schedule +

+
Spatial Data joint meeting - 5-7 pm ET (2-4 pm PT)
+
RDF-star - 2-3:30 pm ET (11 am -12:30 pm PT)
+
JSON-LD main call - 5-7 pm ET (2-4 pm PT)
+
Web of Things - 7:30 - 9 pm ET (4:30-6 pm PT)
+
+ + \ No newline at end of file diff --git a/2024-09-11/irc.log b/2024-09-11/irc.log new file mode 100644 index 0000000..a4178f6 --- /dev/null +++ b/2024-09-11/irc.log @@ -0,0 +1,146 @@ +16:01:16 RRSAgent has joined #json-ld +16:01:20 logging to https://www.w3.org/2024/09/11-json-ld-irc +16:01:20 RRSAgent, make logs Public +16:01:21 please title this meeting ("meeting: ..."), gkellogg +16:01:21 present+ +16:01:21 present+ +16:01:25 meeting: JSON-LD CG +16:01:29 niklasl has joined #json-ld +16:01:30 agenda: https://www.w3.org/events/meetings/e439ee3a-38a9-4506-b9c8-8ba0a2b79cbc/ +16:01:33 gkellogg, sorry, I did not recognize any agenda in https://www.w3.org/events/meetings/e439ee3a-38a9-4506-b9c8-8ba0a2b79cbc/ +16:01:36 chair: gkellogg +16:01:39 present+ +16:01:40 present+ +16:01:49 present+ +16:01:52 present+ +16:02:26 chair+ bigbluehat +16:02:26 topic: TPAC preparation +16:03:03 scribe+ +16:03:18 bigbluehat: We're mostly talking about the breakout panel at TPAC. +16:03:30 q+ +16:03:36 ... We need some YAML-LD slides +16:03:38 ack anatoly-scherbakov +16:03:56 anatoly-scherbakov: I'm working on the presentation, it's a draft now. +16:04:12 We have a template and I am using that +16:04:36 bigbluehat: I've started using the W3C template. +16:05:41 bigbluehat: Start presentation with JSON-LD history. +16:06:10 ... Next work is on for the next version. +16:07:17 ... I wasn't going to talk too much about what goes into JSON-LD 1.2. +16:07:53 ... The plan is mostly built off the CBOR-LD 1.0 spec, and we'll bring in work from related specs. +16:08:12 ... I'll get Wes to provide some more detail. +16:09:03 gkellogg: CBOR also needs something from YAML +16:09:42 bigbluehat: Examples walk through a comparison of JSON-LD and YAML-LD leading to a barcode. +16:10:23 ... Then discuss CBOR-LD Road Ahead +16:10:57 .. I plan to bring in anatoly-scherbakov's work into this slide deck. +16:11:20 s/.. I plan/... I plan/ +16:11:42 ... Starting discussion on hash fragments. +16:12:18 ... Hash ID interpretation potentially allows hashes to have different meanings in JSON-LD. +16:13:51 ... There continue to be stones thrown at JSON-LD on issues related to hash identifiers. +16:14:29 ... There is value to be had if you can reference a context via its hash. +16:14:59 q+ +16:14:59 ... An interpreter could use or ignore the hash. +16:15:01 q+ +16:15:22 ack pchampin +16:15:47 pchampin: Is the idea to specify that application/ld+json has a special meaning for fragment identifiers? +16:15:53 ... (yes) +16:16:50 ... This is important to explain to people that a context IRI is an identifier. +16:17:49 bigbluehat: The fragment identifiers only have meaning to client code. +16:18:40 pchampin: My point was that if you insist on IRIs in general, and context IRIs in particular as being identifiers, then you have two different identifiers (with and without hash). +16:19:18 ... If you want to be consistent, VC would need to use context identifiers containing this hash. +16:20:27 bigbluehat: Are documents served with or without hash the same? +16:21:10 ... The goal is to be able to say the intention of what is requested. +16:21:23 q? +16:21:54 ... Data integrity doesn't depend on this, as it's based on triples. +16:22:50 ... There's a big need for this. +16:22:58 scribe+ +16:23:12 gkellogg: it's too premature for this to be a deliverable for the new WG +16:23:27 ... we could say we're exploring this for possible future standardization and handle it in a recharter +16:23:32 ... it's too hand wavy right now +16:23:37 ... and full of a lot of issues +16:23:39 q+ +16:23:42 ack gkellogg +16:23:55 gkellogg: this does remind me of hash link which sadly didn't go anywhere +16:24:03 ... so sadly that's not available +16:24:19 ... but I remain wary of adding this as a normative deliverable +16:24:54 bigbluehat: The plan was to issue this as a note. It could eventually make its way into the spec. +16:26:23 q+ +16:26:25 ... I think it's optional, and is experimental. I could optionally be used to validate that a JSON document matches the hash. +16:26:27 q+ +16:26:31 ack bigbluehat +16:27:12 ... I wanted to signal to the wider community that we recognize the issue and are exploring solutions. +16:27:26 ack TallTed +16:27:41 TallTed: I think it's a good thing to add. I think the "##" is not the say to do it. +16:28:11 q+ +16:28:28 ... A fragment identifier is a very specific thing, and you don't use '='. It could be ... +16:28:55 gkellogg: RFC3986 has an ABNF for IRIs which we've adopted in RDF Concepts +16:28:55 I believe that '=' is allowed in hash fragment, even though it does not have any special meaning +16:29:16 TallTed: so some of characters may need to be encoded, but that doesn't change their meaning in the value +16:29:18 TallTed: Some characters may need to be URL endcoded with % +16:29:24 ack gkellogg +16:29:34 gkellogg: why is this a JSON-LD thing? +16:29:43 ... it seems this would be generally useful +16:29:56 ... to verify the hash on the URL against the retrieved content +16:30:03 ... maybe it's more IETF? +16:30:24 ... some sort of fragment identifier subset that could allow specifications that invoke that to have these symantics +16:30:32 ack bigbluehat +16:31:07 bigbluehat: We tried to do this more generally (i.e. hashlink), but IETF ties this to the media type. +16:31:21 q+ +16:31:35 ... To be general, either client code decides to interpret this or not. +16:31:54 ... Hashlink didn't work, because it was proposing something be implementable everywhere. +16:32:12 ... It also proposed that it shouldn't be a hash thing, but something server sent. +16:32:46 ... URLs get us into the realm of APIs. +16:33:06 I've taken another headset, should work, but my mic is supposed to be off now :./ +16:33:19 ... That would need to include some protocol element. +16:33:42 ... A hash was chosen, because it doesn't eliminate the ability for a server to send it, but it's up the client to interpret. +16:34:41 ... I'd love to work on it or propose it as a work item. +16:34:44 ack TallTed +16:35:15 TallTed: The problem with using a fragment identifier is that can't be returned by a server. +16:35:40 ... A query parameter is probably better. Servers usually just ignore parameters they don't understand. +16:35:54 ... It might be better as an HTTP parameter. +16:36:16 ... This is the only way for a client to make a request of the server that it can choose to honor or not. +16:36:31 q? +16:36:43 anatoly-scherbakov: (shares screen) +16:37:16 ... I've prepared a presentation on YAML-LD. +16:38:05 ... JSON-LD allows applications to understand metadata if they share a common understanding of the vocabularies used. +16:38:40 ... JSON is a straight-forward format be tedious to write. YAML addresses this. +16:39:13 ... The YAML-LD version of the example removes a lot of syntax. +16:39:42 ... We're trying to make Linked Data more writable/readable for people not expert in Linked Data. +16:40:43 YAML-LD allows you to reuse existing YAML files, similar to how JSON-LD allows the use of regular JSON files. +16:41:11 ... We currently have two implementations (gkellogg's and anatoly-scherbakov's). +16:41:57 ... We use a convenience context to avoid having to quote '@id', for example. +16:42:20 q+ +16:42:25 q+ +16:42:54 anatoly-scherbakov: Where do the slides go? +16:42:58 ack bigbluehat +16:43:17 bigbluehat: I have a repo which isn't public yet, but we can use that for slides. +16:44:39 anatoly-scherbakov: JSON-LD doesn't require indentation, but without it, it is difficult to read. Of course, it's required for YAML. +16:45:20 gkellogg: YAML-LD does everything JSON-LD does. It's just easier for humans to write and manage +16:45:27 ack gkellogg +16:45:38 gkellogg: I think you have a single example in there that may be too simple +16:45:57 ... maybe we can share examples with the CBOR-LD examples? +16:46:06 anatoly-scherbakov: I suppose those are in bigbluehat's deck? +16:46:08 bigbluehat: yep +16:46:11 q+ +16:46:49 bigbluehat: The presentation in the default template uses an odd color scheme, so I include highlight.js. +16:47:10 q? +16:47:13 ack pchampin +16:47:37 pchampin: Comments are a great feature of YAML that JSON doesn't support. +16:48:04 q+ +16:48:13 ack anatoly-scherbakov +16:48:56 anatoly-scherbakov: I wouldn't encourage people to use comments in YAML-LD, at least in the data. May be useful in contexts, but otherwise something like rdfs:comment could be used. +16:49:14 pchampin: I disagree, as you typilcally don't want comments in the data. +16:50:18 gkellogg: RDF-star will be discussed earlier in the week +16:50:34 ... so it may not get discussed during the group call on Thursday as much +16:50:45 I mostly do agree, that comments *in* data is also data (rdfs:comment, or ... RDF-star annotations(!)). But comments for editing *may* be* another thing (on many levels). It's... complicated. ;) +16:51:35 I do wish those TPAC calendar entries could all start with `TPAC:` +16:51:46 q+ +16:52:07 ack TallTed +16:52:38 TallTed: If they could put "TPAC:" in front of these meetings, it would be less confusing. +16:50:34 topic: TPAC Schedule +16:50:34 Spatial Data joint meeting - 5-7 pm ET (2-4 pm PT) +16:50:34 RDF-star - 2-3:30 pm ET (11 am -12:30 pm PT) +16:50:34 JSON-LD main call - 5-7 pm ET (2-4 pm PT) +16:50:34 Web of Things - 7:30 - 9 pm ET (4:30-6 pm PT) +16:53:55 zakim, end meeting +16:53:55 As of this point the attendees have been TallTed, pchampin, gkellogg, niklasl, bigbluehat, anatoly-scherbakov +16:53:57 RRSAgent, please draft minutes diff --git a/index.html b/index.html index 75367e5..0338dfd 100644 --- a/index.html +++ b/index.html @@ -119,7 +119,12 @@

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-09-04

+

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-09-11

+

Topics

    +
  1. TPAC preparation
    2. +
  2. TPAC Schedule
    3. +
+

Meeting for 2024-09-04

Topics

  1. TPAC
  2. Other topics