The JSON-LD WG was chartered in June, 2018 to specify the next iteration of JSON-LD syntax, API, and framing features. Our first face-to-face for this group was at the W3C’s TPAC conference in Lyon, France. We met on Thursday and Friday to discuss a host of core issues regarding JSON-LD syntax, processing, as well as JSON-LD’s present and future as a key component in the Web architecture and Web application development.
On Thursday, we explored syntax changes related to blank node identifiers being used as properties. This resulted in further discussion around our depreciation/obsolescence policy, and how that would be handled going forward. The issue at hand also spawned interesting discussions around encoding non-open-world assuming graphs into the JSON-LD data model–which is itself built upon the RDF data model. There was desire for further exploration, but an ultimate trend toward encouraging greater understanding and modeling with “open world assumptions” in mind.
Following that, we dove into issue #9 Content addressable contexts and #20 a request for sealed contexts together. The general concern and desire was to improve the trust placed in referenced context files. Content addressable contexts discussion resulted in further clarifications desired on the document loading process and how lists of contexts are combined. The sealed contexts discussion explored similar ground and resulted in actions toward exploring some system for integrity expressions related to context files. Ultimately, these issues began to highlight needs within the wider Web architecture for confirmable integrity and stability of resources. We now plan to discuss this further with the W3C’s Technical Architecture Group (TAG) to see both where we can assist and where a more general solution might server the entire Web better.
The early afternoon centered around how embedded JSON-LD relates to the surrounding HTML content via the DOM. The initial topic was around whether the base URI of an HTML document (which can be overridden by a tag) had any effect on any relative URIs with an embedded JSON-LD document. Checkout the JSON-LD syntax issue #23 for more. Since this so closely tied to HTML document processing and contextualizing of other data within them, this too resulted in action to connect with the TAG on the wider concerns. That discussion with the TAG is ongoing, but may result in greater value for Web developers interested in combining JSON-LD’s more descriptive JSON format into their Web apps.
Following that topic, we revisited the sealed contexts issue and related extensibility questions with the help of visitors from the Verifiable Claims WG. This discussion resulted in several new questions and potential solutions around both the security and extensibility of contexts. Plenty more to explore in this area, and input is welcome!
We ended our busy first day with a joint session with the Web of Things WG. The Web of Things group is building a JSON-LD-based description format for “Things” and their related actions. Much of our discussions included thoughts from the morning around the integrity and stability of contexts–especially when deployed in disconnected scenarios such as code running in a “smart light bulb” for instance. The WoT WG also had other needs related to storing internationalized content within JSON-LD documents. Language expression is easy in JSON-LD, but multiple languages in a single string usually involved expressing the string in HTML or a limited subset. Consequently, further exploration is planned by both groups to narrow in on requirements and the options available for both easy and rich expressions of multilingual content.
On Friday, we kicked off the morning with a discussion around the handling of blank node identifiers for graph containers (see issue json-ld-api#26 for more). Eric Prud’hommeaux was our guest for that session and helped describe (and whiteboard) some of the issues around the current approach and the proposed approach to consistently identifying unnamed graphs. The group moved to address the problem by keeping the blank node assignments consistent, but is eager for more input from implementers and developers to help inform future work.
Discussion then moved to considering options for disambiguating the use of the
@type keyword which is currently mapped to both
rdf:type and to data type when searlized to an RDF representation. The group concluded the discussion by proposing a new aliased keyword
@datatype for uses within “value objects.” The discussion has continued post TPAC resulting in the reversal of that decision due to concerns of it causing fresh confusion. The group is now pursuing further clarifying the distinction between the uses of
@type in value objects and node objects.
The next two related topics concerned the use of relative IRIs as values to the
@vocab keyword and how
@vocab’s value is used throughout the expansion process. In both scenarios the fact that
@vocab uses string concatenation vs. relative URI resolution was a central concern. The group determined that relative IRI’s were permissible because
@vocab is based on string concatenation. Additional work will be done to better explain the security issues around IRI dereferencing for systems which lean on those IRIs to take further action (i.e. hypermedia formats based on JSON-LD). Also, further work is planned to more fully explain how
@vocab and term expansion are done throughout the data documents to hopefully remove further confusion.
In the afternoon, the group visted the Data Exchange WG where we discussed various approaches to providing profile information to further refine processing of JSON-LD based document formats. The Data Exchange WG’s minutes cover the full conversation. Approaches discussed included the current MIME type-based
profile="" parameter system used by the Web Annotation Data Model and by JSON-LD itself for deciding between compacted, expanded, etc. Additional approaches were also explored such as a Linked Data Platform’s use of the
Prefer header and a new proposal for an
Accept-Profile header. Rob Sanderson will be exploring the issue further with the Data Exchange WG in their issue 261.
Our group returned to our room to continue conversation specifically around the current use of the
profile MIME type parameter. We resolved in issue 8 to improve our “IANA Considerations” section to include a frame related profile option as well as adding text about related security concerns.
We were then joined by TAG member, Hadley Beeman, and Schema.org representative, Dan Brickley for a discussion around embedding JSON-LD into HTML.The conversation concluded with plans to submit a “design review” to the TAG, and has resulted in ongoing discussions and preliminary spec text to make the JSON-LD embedded in HTML a normative part of the JSON-LD syntax specification.
We then moved on to content addressable IRIs and related document loading proposals. The group determined that the Web is facing an increasing need for stability, longevity, and authority for its identification infrastructure, and that widely distributed JSON-LD (such as in the Web of Things and Verifiable Credentials Working Group’s specifications) face these unique challenges head on. However, we also concluded that because of the widely applicable problem space, this was best solved by constituents from multiple WGs and via an addition TAG design review.
The document loader concerns did seem to be satisfactorily addressed in the JSON-LD API specification. Document loading is defined to delegate dereferencing of remote context files to application code and a default document loader provided by the JSON-LD document processor. Consequently, the dereferencing process is “pluggable” and can be customized to meet these growing needs and opportunities.
The week concluded with much accomplished and more to do. We’re looking forward to our next face-to-face meeting in the spring of 2019. We hope that you’ll join us on our mailing list and GitHub repositories. We’re eager to increase the range and diversity of input, and hope you’ll be able to join us!