– DRAFT –
JSON-LD WG/CG Meeting

bigbluehat: This is WG and CG call, welcome to new participants

bigbluehat: we're now focusing on YAML-LD, CBOR-LD, and then JSON-LD

azaroth: I was involved with JSON-LD 1.1

azaroth: Yale is not a member of W3C so I was unable to participate so much lately

azaroth: would like to describe a few JSON-LD related projects

<azaroth> IIIF: https://iiif.io/

azaroth: IIIF was around since JSON-LD 1.0

azaroth: we benefitted from Scoped Contexts in 1.1

azaroth: IIIF is i18n-first, so all labels are internationalized

azaroth: all labels have langString datatype

azaroth: there are > 1000 institutions using IIIF, estimated 2 billion images managed

azaroth: it is a standard for libraries, museums, etc

<azaroth> Linked Art: https://linked.art/

ivan: ePub WG works on ePub annotations based on Web Annotations Framework

ivan: labels being not properly internationalized is an issue

<azaroth> https://iiif.io/api/presentation/3.0/#47-term-collisions-between-contexts

ivan: latest release of RDF has a better support for i18n

azaroth: library world has been using one standard for 50 years and we are stuck with it

azaroth: museums do not have one standard

azaroth: seen success in introduction of JSON-LD based APIs for museums to describe their collections in a standard way

azaroth: ...as https://linked.art/api/1.0/ project

azaroth: we also have a Search API where we define a straightforward Activity Streams based response format

azaroth: https://linked.art/api/rels/1/activitycarriedoutbyagent/ is an example of an API

azaroth: we're trying to use best practices and JSON-LD 1.1 features

azaroth: design principles: https://linked.art/api/1.0/principles/

<azaroth> https://lux.collections.yale.edu/

azaroth: provides an interface to browse collections

roberto-polli: is there an OpenAPI definition of the API?

azaroth: schema is very recursive and difficult to be expressed in OpenAPI or JSON Schema

azaroth: definitions end up being quite complex

azaroth: OpenAPI-generated classes tend to be very complicated

azaroth: interested in use cases for it

bigbluehat: next bit of our show will be about JSON Schema

<azaroth> Our json schemas: https://linked.art/api/1.0/schema_docs/

azaroth: we have an open call for Linked Art every 2 weeks

azaroth: it is in Zoom, 11 AM US Eastern

azaroth: IIIF is mostly in Slack, there are community calls every 3 months

<azaroth> Linked Art github: linked-art/linked.art

<azaroth> IIIF github: iiif/api

roberto-polli: we'd like to add semantic information to JSON Schema

<azaroth> Thank you anatoly-scherbakov for the scribing, apologies for speaking quickly and my New Zealand accent!

azaroth: I apologize for the things I couldn't catch! I really hope I did capture the most important things!

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

<azaroth> IIIF Community: https://iiif.io/get-involved/ and Linked Art community: https://linked.art/community/

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: Presentation: https://docs.google.com/presentation/d/1qAWX1LRq9XKuPjnwSDvS0WJ2d3mlKre-0VwD_IXYKJ4/edit?slide=id.g3bfd86f75b3_0_28#slide=id.g3bfd86f75b3_0_28

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

Repository: ioggstream/draft-polli-restapi-ld-keywords

roberto-polli: Specification ioggstream/draft-polli-restapi-ld-keywords

<bigbluehat> schema editor repo: teamdigitale/dati-semantic-schema-editor

roberto-polli: schema editor teamdigitale/dati-semantic-schema-editor

<bigbluehat> schema editor: https://teamdigitale.github.io/dati-semantic-schema-editor/latest/

roberto-polli: https://teamdigitale.github.io/dati-semantic-schema-editor/latest/

bigbluehat: great to see this coming together!

acoburn: we're working on Containers for Linked Data Storage, similar to Linked Data Platform or Solid

acoburn: what's the media type to use and how does it work with content negotiation?

acoburn: Web Annotations use a media type application/ld+json with a Profile URL

acoburn: this doesn't work very well in browsers due to CORS restrictions

acoburn: we want anything we end up using to work in a browser

<bigbluehat> Linked Web Storage WG https://www.w3.org/groups/wg/lws/

acoburn: Activity Streams support the same Profile URL approach but they also support activity+json, or lws+json

acoburn: another approach - VC and CID approach - is application/lws

acoburn: interested to hear opinions and feedback

acoburn: we want a container object that'

acoburn: ...is parseable by a JSON parser and a JSON-LD processor

acoburn: that's what we're discussing in Linked Web Storage WG

azaroth: we're using the Profile URI, what is happening with it?

acoburn: it seems at least certain browsers will raise an error against a profile string that is a URL

bigbluehat: this is a recent issue, maybe during last year

bigbluehat: it's CORS which forbids URLs in media type parameters

bigbluehat: this starts throwing errors

<dlehn> related cors issue: w3c/json-ld-syntax#436

<gb> https://github.com/w3c/json-ld-syntax/issues/436

<ioggstream> 👋

<bigbluehat> azaroth:

<Zakim> azaroth, you wanted to ask bout the CORS issue

<dlehn> part of that is the "simple" requests restrictions, and profiles cause an issue with that

ioggstream: is it related to European Wallet?

acoburn: it could be used for that

acoburn: but LWS is not necessarily a requirement though

bigbluehat: lately the last two options have been more popular

bigbluehat: if you want to put a thing on disk and open it then you want a media type

acoburn: this could be relevant to users who wish to download all content from a storage into files

bigbluehat: JSON-LD notably has five profile URLs

bigbluehat: they do not necessarily need five file extensions

bigbluehat: there are also ideas to replace strings with enums to describe JSON-LD profiles

bigbluehat: we should improve the Best Practices documentation which Gregg had started

bigbluehat: it is in the list of deliverables

Announcements and Introductions

bigbluehat: great demos! we'd love everyone to participate in the WG

bigbluehat: especially editorial help on JSON-LD specs

bigbluehat: our focus in the nearest months will be YAML-LD and CBOR-LD

bigbluehat: and then we'll be getting to JSON-LD 1.2

bigbluehat: and then we can look into 1.3/2.0

bigbluehat: reach out to me or in the IRC to discuss participation, or in the GitHub Discussions space