JSON-LD 1.1 Update -- 17 Sep 2019

<scribe> scribenick: azaroth

gkellogg: Presentation about the updates for 1.1
... after 1.0 release had a number of languishing issues
... that didn't make the cut. We started a CG 3 or 4 years ago to do a draft of update
... work culminated 2 years ago in Burlingame TPAC, WG was chartered
... addressed some before WG, including indexing data
... want to index into a set of objects based on the id of those objects
... added a raft of new ways to use json objects
... Anonymous graphs are used in verifiable credentials, so added ability to put properties in different graphs
... nesting method in various JSON API, that put various properties under a non-semantic property
... can put arbitrary depth using @nest
... JSON-ld 1.0 didn't do recursive lists, which is 1.1
... scoped contexts within a property or type
... term definitions importing and then modifying with 1.1 features
... more capabilities for framing, and a more robust, uniform way to match
... added JSON literals
... deprecated blank node properties, most notably in activitystreams context. Supported in 1.1 but marked for removal
... Normalized the way we extract json-ld from html
... plus a variety of other features
... Want to take advantage of the abstraction of the model to allow for alternative serializations such as YAML
... in 1.1 there needs to be a version announcement: @version: 1.1
... this will cause 1.0 processors to fail completely, so 1.0 processors will not process 1.1 contexts incorrectly
... id maps -- indexed by the uri of the object.
... [looks at example from spec]
... Also have type maps, and graph maps

sander: Are the slides online so we can look at them?

<bigbluehat> slides https://json-ld.org/presentations/JSON-LD-Update-TPAC-2019/assets/player/KeynoteDHTMLPlayer.html

gkellogg: Graph containers -- use named graphs in rdf 1.1 without heavyweight syntax
... Can put triples in a different graph, named by a blank node
... property in the default graph that references the blank node
... so BN in object position denotes the graph named by the same blank node
... not exactly rdf 1.1, but is a common convention
... Nested properties. See this often in the wild. Lots of features in 1.1 are to adapt to native JSON APIs. One such is putting properties into groups
... e.g. specific labels within a label group, and the labels get folded up into the main resource semantically
... 1.0 allowed blank node vocabs to ease burden of people coming to -LD that didn't want to create vocabularies for everything
... more common in RDF is to use a document relative term.
... so now @vocab can be a relative URL based against the *document* URL, and thus that we can deprecate blank node properties due to this
... slide 8
... We're going through the changes section of the spec, btw
... Recursive lists come from GeoJSON. Can say it in turtle (rdf:List of rdf:Lists), but couldn't in json-ld 1.0
... So now any array inside an array that's a List is also a List

question: Can this be any depth?

gkellogg: Yes, any number of lists, in any position
... did have some fancier versions requested, to have properties for the items, but that got very hairy
... Scoped contexts -- the ability to define a context within a term within a context
... if you follow a property to a term with a scoped context, that context comes into effect
... If we go to a node that has foaf as a scoped context, then it becomes active instead of the higher node's context (e.g. schema.org(
... can also do this on classes / types, not just properties
... one of the concerns that came up is that some groups have just JSON interpretation, and important that semantics don't change in lower terms
... so want to protect that name means something, even if other contexts are used
... added @protected for terms, and if a downstream context tries to redefine a term, then it will raise an error
... can only undo this if you have a property that defines a context of null, that wipes out the context.

(discuss extensions)

question: How to validate, with extensions?

gkellogg: Some ways to validate RDF such as shacl and shex that work here as well
... I run a linter that follows the vocabularies and determines if they're consistent

mmccool: schema validators don't understand extensions but then misspellings can then be okay

bigbluehat: What for rdf validators?

mmccool: Not sure
... need to meet up with the json schema guys
... like the intro that it's JSON with added semantics. Happy to see the messaging
... one thing that will help is a unified set of validation tools
... want to connect this structural constraint with the semantic constraints

gkellogg: SHACL does do this.

bigbluehat: Constant confusion between json-schema and json-ld, which is apples and oranges
... talking to the json-schema folks to go towards a CG

gkellogg: Will be going to CR soon, which will get more feedback
... still time to address things

mmccool: think -schema is important because it's used as a sub-schema

(discussion of IETF json-schema debacle)

scribe: Used in WoT, STF, and in open api

gkellogg: Anything that looks at structure to determine correctness can miss a lot of variations
... semantic validation needs attention too
... one of the reasons that we chose RDF as the data model
... Imported contexts. Can import 1.0 contexts, and use it, but also add JSON-LD 1.1 features
... Can fill in 1.0 gaps with this. Also for other things that we have not done, such as sub-resource integrity

(azaroth explains SRI use case)

mmccool: Frozen contexts that will never change. Don't want to require processing of a context, just as an identifier such that the processing can be cooked
... ended up waffling a little and saying we might update for errors in the context
... intent that version number in the URL would be fixed

gkellogg: Not a JSON-LD problem, it's a web problem generally. Other URI schemes that can help address. Advice is to use the document loader and fix the interpretation of the URIs there
... e.g. never fetch a frozen document

mmccool: out of band a little, as opposed to in band.

bigbluehat: hashlink as well -- URI would indicate that it's cacheable

gkellogg: if you have a local copy you know you can always use it, and have several ways to get the content

bigbluehat: can get via HTTP or IPFS or whatever

mmccool: Interesting in other contexts.
... agree this is a web problem not JSON-LD

gkellogg: JSON literals. RDF/XML and RDFA had XML and HTML literals that aren't interpreted, so we added the same for JSON
... Can put raw JSON that gets preserved in the RDF as a literal, in a canonical form
... c18n is based on a draft spec but uses js capabilities for ordering and so on

mmccool: what about xml in json?
... want the structure to be reflected, e.g. turn xml attributes into json properties

gkellogg: XML is complicated by several things :)
... Included nodes. Recent feature. A way in an object definition to have a block of objects that go along with it.
... from separate spec, JSON-API
... Return current resource, plus all related ones. Has also helped in other ways as @graph can be used for identifying named graphs, and at the top level to have a set of objects
... more consistent just to use @included
... no property relationship to the top
... Framing. There is no 1.0 Rec for Framing, but is widely used. Will be 1.1 framing in new Rec.
... Adds a few capabilities, including order dependent embedding
... removed requirements for lexical ordering. Embed once rather than embed last
... support for named graphs in framing
... would previously only frame the merged graph, now either merged or default
... can match on ids. Specify a set of ids to match on, only possible in a frame for matching
... thus match for objects with any of those URIs
... can be used at lower levels as well
... e.g. an empty object is a wild card
... @included in frames, and for @reverse properties
... better value matching, with wildcarding
... or matching without an @type (for example)
... HTML data block extraction spec. JSON-LD in HTML used since the beginning. Principle reason is schema.org use, in the script block with a type
... have standardized that and added capabilities
... set of types that can be applied. In media types can now ask for expanded form, or a frame etc. Can do that in a script tag too
... with a parameter after the media type
... investigated doing that for contexts but elected not to do that
... they must be json-ld documents
... but have added a way to do it with content negotiation and a link header, rel=alternate
... we prefer conneg but in static environments not always possible, thus the link header
... If didn't have jsonld, can embed the reference, and a document loader will follow that link to find the right context doc
... lightweight mechanism for documenting it

mmccool: looking at directories and core-link (?) format
... notice you use alternate ... has a special meaning in other contexts
... might need to find a new rel type

gkellogg: Would be document loader behavior
... abstracted from json objects to maps, meaning the syntax doc goes to an internal represetnation such as what you would get for JS, and then lets us map out to other formats

mmccool: OCF had a lot of trouble with YAML. JSON quotes names used for keys, YAML does not. Some problems with certain characters not allowed in some places. Some round tripping issues

gkellogg: Should highlight that in the note

mmccool: Can I serialize, parse, reserialize and have the same thing

gkellogg: Also interest in binary, such as CBOR
... question about literal features that aren't in JSON such as dates

mmccool: also different number precisions
... extended json-schema for non-json native types such as lengths of numbers
... may or may not cause the same problem

gkellogg: definitely caveat emptor here!
... Will align with xsd: data types, so might need c18n algorithms

mmccool: internationalization?
... text direction!

everyone: dedicated session for this :D

mmccool: We have a bandaid solution

<bigbluehat> Getting Text Direction into RDF https://w3c.github.io/tpac-breakouts/sessions.html#rdf-dir-literal breakout session this afternoon

gkellogg: We won't have an elegant solution, as RDF won't have it yet
... blank node with a value property or something like that

mmccool: ease of use -- needs to be default text direction, like default language

gkellogg: Yes. Would be good to have @direction in JSON-LD. It's an RDF problem

mmccool: thing that motivates us is inferring from language is impossible. Doesn't always work and in small devices is painful

gkellogg: complete in june. CR in Q4, and we're ready in the next few weeks
... playground is not fully up to date with the spec
... (a bit of a problem at times)
... ruby implementation is up to date
... working on getting underlying JS implementation updated, as basis of the playground, in the next month or so
... Call for implementations coming!

<scribe> ... new implementations as well as updates to 1.0 implementations

mmccool: current implementations?

gkellogg: list of implementations on the site. 1.1 on track are ruby, js and python. Want to see Java. Others include C#, C and erlang

mmccool: C++ useful for embedded devices.
... js might be okay if it uses a specific subset of features

bigbluehat: request semantics extracted in -js, as then you cut out a lot of security issues and dependencies
... but still need to get them

gkellogg: if there's an interest, and bandwidth to contribute, a C++ implementation would be great

dave_raggett: testing?

gkellogg: close to accepting implementation reports. Have a full test suite.
... available for anyone developing, thousands of tests
... more implementations would be grat
... Questions? :)

ssstolk: JSON literals very nice. Seeing in GIS sector prefer to use well known text type
... states coordinates in a particular way. So JSON literals will help there.

dave: what kind of information do you have about usage?
... a report to management sort of thing

gkellogg: web of things is a major use. Automotive. Hard to track.

mmccool: who would we like to be using it?
... Have things converge, such as Open API.

gkellogg: There's lots of bias to overcome

bigbluehat: thankfully top people at open api are not opponents
... you guys have started to map json-schema terms to a vocab

mmccool: json-schema as json-ld also a good target

gkellogg: talked about it a bit. Seems like an interest group?

draggett: CG or IG

gkellogg: There is a CG, which is dormant at the moment when the WG is done
... but best form for advocacy?

draggett: CG would be good for advice. MDN is good for JS in the browser ... would those guys pick it up?

bigbluehat: json-ld going into chrome's lighthouse.

gkellogg: MDN would be nice

bigbluehat: From what dom has said, if you show up with content and willing to maintain it
... then they're okay to include it

gkellogg: If google interested, esp given lighthouse inclusion, then have some resources maybe

bigbluehat: in context of integration, growing pattern to have an active CG with an active WG and run in tandem
... rather than ebb and flow between the two
... keeping in parallel would be good

gkellogg: Group is very close to CR. But have notes to do

bigbluehat: Figuring out what JSON-LD needs is a big part. applications of it is a different part

gkellogg: a cg might maintain a timeline, get input as to what to see on that, and use it to drive interest

ssstolk: DCAT?

gkellogg: JSON-LD widest RDF representation
... for 1.0 it wasn't quite full rdf 1.1, but now it is

mmccool: upgrading applications to use 1.1?

gkellogg: schema.org to use 1.1 features would be very good :)

bigbluehat: schema.org user base is authors, not context folks. Not clear how search engines use it internally
... need to push processing of the SEO driven content. Want to go to lighthouse rather than structure data testing tool
... maybe merging pieces is one task of the CG

gkellogg: need to kickstart the CG again
... should see people to step up :)

bigbluehat: could do a monthly call in the CG

- DRAFT -

JSON-LD 1.1 Update

17 Sep 2019

Attendees

Contents

Adjourn :)

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output