The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD WG/CG Meeting

Minutes for 2026-01-29

Present
Ted Thibodeau Jr., Anatoly Scherbakov, Benjamin Young, Robert Sanderson, Aaron Coburn, Niklas Lindström, Roger French, Ivan Herman, David I. Lehn, Roberto Polli
Chair(s)
Benjamin Young
Scribe(s)
Anatoly Scherbakov
Agenda
https://www.w3.org/events/meetings/1a0cb2ad-eb25-46af-9c3c-65783a7eb5d2/20260128T120000/
Topics
  1. IIIF and Linked.Art
  2. JSON-LD extension to JSON Schema
  3. Profile URLs? or Media Types?
  4. Announcements and Introductions
Anatoly Scherbakov is scribing.
Benjamin Young: This is WG and CG call, welcome to new participants
Benjamin Young: We're now focusing on YAML-LD, CBOR-LD, and then JSON-LD

Topic: IIIF and Linked.Art

Robert Sanderson: I was involved with JSON-LD 1.1
Robert Sanderson: Yale is not a member of W3C so I was unable to participate so much lately
Robert Sanderson: Would like to describe a few JSON-LD related projects
Robert Sanderson: IIIF: https://iiif.io/
Robert Sanderson: IIIF was around since JSON-LD 1.0
Robert Sanderson: We benefitted from Scoped Contexts in 1.1
Robert Sanderson: IIIF is i18n-first, so all labels are internationalized
Robert Sanderson: All labels have langString datatype
Robert Sanderson: There are > 1000 institutions using IIIF, estimated 2 billion images managed
Robert Sanderson: It is a standard for libraries, museums, etc
Robert Sanderson: Linked Art: https://linked.art/
Ivan Herman: EPub WG works on ePub annotations based on Web Annotations Framework
Ivan Herman: Labels being not properly internationalized is an issue
Ivan Herman: Latest release of RDF has a better support for i18n
Robert Sanderson: Library world has been using one standard for 50 years and we are stuck with it
Robert Sanderson: Museums do not have one standard
Robert Sanderson: Seen success in introduction of JSON-LD based APIs for museums to describe their collections in a standard way
Robert Sanderson: ...As https://linked.art/api/1.0/ project
Robert Sanderson: We also have a Search API where we define a straightforward Activity Streams based response format
Robert Sanderson: https://linked.art/api/rels/1/activitycarriedoutbyagent/ is an example of an API
Robert Sanderson: We're trying to use best practices and JSON-LD 1.1 features
Robert Sanderson: Design principles: https://linked.art/api/1.0/principles/
Robert Sanderson: Provides an interface to browse collections
Roberto Polli: Is there an OpenAPI definition of the API?
Robert Sanderson: Schema is very recursive and difficult to be expressed in OpenAPI or JSON Schema
Robert Sanderson: Definitions end up being quite complex
Robert Sanderson: OpenAPI-generated classes tend to be very complicated
Robert Sanderson: Interested in use cases for it
Benjamin Young: Next bit of our show will be about JSON Schema
Robert Sanderson: Our json schemas: https://linked.art/api/1.0/schema_docs/
Robert Sanderson: We have an open call for Linked Art every 2 weeks
Robert Sanderson: It is in Zoom, 11 AM US Eastern
Robert Sanderson: IIIF is mostly in Slack, there are community calls every 3 months
Robert Sanderson: Linked Art github: https://github.com/linked-art/linked.art
Robert Sanderson: IIIF github: https://github.com/iiif/api
Robert Sanderson: Thank you anatoly-scherbakov for the scribing, apologies for speaking quickly and my New Zealand accent!
Anatoly Scherbakov: I apologize for the things I couldn't catch! I really hope I did capture the most important things!
Robert Sanderson: IIIF Community: https://iiif.io/get-involved/ and Linked Art community: https://linked.art/community/

Topic: JSON-LD extension to JSON Schema

Roberto Polli: We'd like to add semantic information to JSON Schema
Roberto Polli: We'd like to leverage JSON-LD to add semantic information to JSON Schema which describes the schema of an OpenAPI endpoint
Roberto Polli: We use OpenAPI 3.0
Roberto Polli: We could insert JSON-LD context with `x-jsonld-context` property
Roberto Polli: Context is defined at design phase of the API
Roberto Polli: We do not want the API consumer to dereference anything
Roberto Polli: You should have all the data in the contract, no remote components
Roberto Polli: We provide the semantic information in the schema, not in the payload
Roberto Polli: We provide an open source Schema Editor tool
Roberto Polli: The tool interprets the schema using example data you can confirm that the RDF built from that data is what is expected
Roberto Polli: You paste the schema and the example payload, and you can start your SPARQL endpoint; you can verify the adequacy of the RDF
Roberto Polli: Example data is rendered as Turtle and as the queryable SPARQL endpoint
Roberto Polli: There are also suggestions about terms/ontologies to use
Roberto Polli: This helps you modeling data according to your ontology
Roberto Polli: You can also look at your ontologies in a graph visualization
Roberto Polli: We want syntax and semantics in one document and we do not want dereferencing
Roberto Polli: That's why we did not leverage JSON-LD paragraph 6.1 about interpretation of JSON as JSON-LD
Roberto Polli: The experience with the process has been positive
Roberto Polli: We also are experimenting with this approach for CSV
Roberto Polli: Involved organizations are Istat - Italian Statistics Agency, and Italy's Digital Transformation Dept
Benjamin Young: Great to see this coming together!

Topic: Profile URLs? or Media Types?

Aaron Coburn: We're working on Containers for Linked Data Storage, similar to Linked Data Platform or Solid
Aaron Coburn: What's the media type to use and how does it work with content negotiation?
Aaron Coburn: Web Annotations use a media type application/ld+json with a Profile URL
Aaron Coburn: This doesn't work very well in browsers due to CORS restrictions
Aaron Coburn: We want anything we end up using to work in a browser
Benjamin Young: Linked Web Storage WG https://www.w3.org/groups/wg/lws/
Aaron Coburn: Activity Streams support the same Profile URL approach but they also support application/activity+json, or for us application/lws+json
Aaron Coburn: Another approach - VC and CID approach - would be application/lws
Aaron Coburn: Interested to hear opinions and feedback
Aaron Coburn: We want a container object that'
Aaron Coburn: ...Is parseable by a JSON parser and a JSON-LD processor
Aaron Coburn: That's what we're discussing in Linked Web Storage WG
Robert Sanderson: We're using the Profile URI, what is happening with it?
Aaron Coburn: It seems at least certain browsers will raise an error against a profile string that is a URL
Benjamin Young: This is a recent issue, maybe during last year
Benjamin Young: It's CORS which forbids URLs in media type parameters
Benjamin Young: This starts throwing errors
David I. Lehn: Related cors issue: https://github.com/w3c/json-ld-syntax/issues/436
Roberto Polli: Bye
David I. Lehn: Part of that is the "simple" requests restrictions, and profiles cause an issue with that
Roberto Polli: Is it related to European Wallet?
Aaron Coburn: It could be used for that
Aaron Coburn: But LWS is not necessarily a requirement though
Benjamin Young: Lately the last two options have been more popular
Benjamin Young: If you want to put a thing on disk and open it then you want a media type
Aaron Coburn: This could be relevant to users who wish to download all content from a storage into files
Benjamin Young: JSON-LD notably has five profile URLs
Benjamin Young: They do not necessarily need five file extensions
Benjamin Young: There are also ideas to replace strings with enums to describe JSON-LD profiles
Benjamin Young: We should improve the Best Practices documentation which Gregg had started
Benjamin Young: It is in the list of deliverables

Topic: Announcements and Introductions

Benjamin Young: Great demos! we'd love everyone to participate in the WG
Benjamin Young: Especially editorial help on JSON-LD specs
Benjamin Young: Our focus in the nearest months will be YAML-LD and CBOR-LD
Benjamin Young: And then we'll be getting to JSON-LD 1.2
Benjamin Young: And then we can look into 1.3/2.0
Benjamin Young: Reach out to me or in the IRC to discuss participation, or in the GitHub Discussions space