JSON-LD 1.1 Update — Minutes
Date: 2019-09-18
See also the Agenda and the IRC Log
Attendees
Present: Rob Sanderson, Benjamin Young, vivien lacourba, gregg kellogg, michael mccool, dave raggett, ssstolk
Regrets:
Guests:
Chair:
Scribe(s): Rob Sanderson
Content:
Gregg Kellogg: 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?
Benjamin Young: slides https://json-ld.org/presentations/JSON-LD-Update-TPAC-2019/assets/player/KeynoteDHTMLPlayer.html
Gregg Kellogg: 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?
Gregg Kellogg: 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.
Rob Sanderson: (discuss extensions)
question: How to validate, with extensions?
Gregg Kellogg: 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
Benjamin Young: 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
Gregg Kellogg: SHACL does do this.
Benjamin Young: Constant confusion between json-schema and json-ld, which is apples and oranges
… talking to the json-schema folks to go towards a CG
Gregg Kellogg: 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
Rob Sanderson: (discussion of IETF json-schema debacle)
mmccool: Used in WoT, STF, and in open api
Gregg Kellogg: 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
Rob Sanderson: (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
Gregg Kellogg: 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.
Benjamin Young: hashlink as well – URI would indicate that it’s cacheable
Gregg Kellogg: if you have a local copy you know you can always use it, and have several ways to get the content
Benjamin Young: can get via HTTP or IPFS or whatever
mmccool: Interesting in other contexts.
… agree this is a web problem not JSON-LD
Gregg Kellogg: 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
Gregg Kellogg: 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
Gregg Kellogg: 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
Gregg Kellogg: Should highlight that in the note
mmccool: Can I serialize, parse, reserialize and have the same thing
Gregg Kellogg: 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
Gregg Kellogg: 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
Benjamin Young: Getting Text Direction into RDF https://w3c.github.io/tpac-breakouts/sessions.html#rdf-dir-literal breakout session this afternoon
Gregg Kellogg: 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
Gregg Kellogg: 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
Gregg Kellogg: 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!
… new implementations as well as updates to 1.0 implementations
mmccool: current implementations?
Gregg Kellogg: 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
Benjamin Young: request semantics extracted in -js, as then you cut out a lot of security issues and dependencies
… but still need to get them
Gregg Kellogg: if there’s an interest, and bandwidth to contribute, a C++ implementation would be great
dave raggett: testing?
Gregg Kellogg: 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
Gregg Kellogg: 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.
Gregg Kellogg: There’s lots of bias to overcome
Benjamin Young: 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
Gregg Kellogg: talked about it a bit. Seems like an interest group?
draggett: CG or IG
Gregg Kellogg: 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?
Benjamin Young: json-ld going into chrome’s lighthouse.
Gregg Kellogg: MDN would be nice
Benjamin Young: From what dom has said, if you show up with content and willing to maintain it
… then they’re okay to include it
Gregg Kellogg: If google interested, esp given lighthouse inclusion, then have some resources maybe
Benjamin Young: 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
Gregg Kellogg: Group is very close to CR. But have notes to do
Benjamin Young: Figuring out what JSON-LD needs is a big part. applications of it is a different part
Gregg Kellogg: a cg might maintain a timeline, get input as to what to see on that, and use it to drive interest
ssstolk: DCAT?
Gregg Kellogg: 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?
Gregg Kellogg: schema.org to use 1.1 features would be very good :)
Benjamin Young: 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
Gregg Kellogg: need to kickstart the CG again
… should see people to step up :)
Benjamin Young: could do a monthly call in the CG