The W3C JSON-LD Community Group
Go Back
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
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)