JSON-LD 1.1 about strategy HOT 14 CLOSED

@wseltzer @draggett : the JSON-LD Community Group has asked W3C, through yours truly, to start the chartering process. There is already an early charter draft. I would propose to send the request to W3C for an advanced notice sometimes this week.

from strategy.

The Web of Things Working Group is expecting to work on using JSON for thing descriptions. Whilst there is no explicit dependency on RDF, the WG is likely to define a means to map descriptions to RDF and to link to externally defined semantic models as a basis for semantic interoperability, discovery, composition and validation. This work could provide input to future standardisation on JSON-LD, and at the very least, there should be some exchange of ideas between the WoT WG and the JSON- LD CG.

You can see demo's for translating JSON thing descriptions to RDF at:

• https://www.w3.org/WoT/demos/td2ttl/
• https://www.w3.org/WoT/demos/td2ttl/oic.html

This uses a JSON format is intended to be easy for Web developers to understand and also easy to transform to RDF given the appropriate context definitions. It is similar to JSON-LD, and uses @context to bind names to URIs. The obvious question is likely to be why not use JSON-LD? The answer is that JSON-LD was designed to support RDF in its generality, and as such is more verbose than a JSON format designed for the purpose of describing the object model for things. We want to win over Web developers, so a concise easy to understand format is key.

from strategy.

The i18n WG needs to get JSON-LD folks to add direction metadata to strings (similar to the way they add language metadata). We have a discussion document in progress that relates to this.

from strategy.

I'd like to hear the ecosystem story, that would help to make the (business and technical) case to people who don't understand the linkage between frontend webdev and data management.

from strategy.

Applications for the Web of things is about creating value from creating and combining services involving sensing or controlling physical things and services that are cloud based, e.g. knowing the likelihood of rain can be used by smart sprinklers to reduce the need for watering your garden. In a smart factory, applications will combine data about product orders with the availability of materials, tools and production cells, for smart routing of materials through the factory floor.

Metadata is key to the Web of things for modelling the interfaces exposed to applications, interoperating with platforms, and discovery, composition and validation, based upon rich semantic models of things, their relationships and the context they are located in. Linked data vocabularies provide a scalable framework for which W3C is the acknowledged world leader. Lightweight representations of metadata reduce the learning curve and costs for developers. Scripting JSON objects is simpler than dealing with RDF in general.

The ecosystem involves:

• IoT device manufacturers, chip makers and so forth
• IoT software platform vendors
• Application device manufacturers
• Application platform vendors
• Cloud hardware platform providers
• Cloud software platform vendors
• Consumers as individual people
• Consumers as enterprises
• Companies providing services to service integrators
• Companies providing services to consumers
• Search engine operators
• Network operators
• Advertising agencies
• Payment solution providers
• Trust brokers
• Insurance companies
• Security specialists
• Legal specialists
• Regulatory bodies

The ecosystem can also be mapped across the different application domains. In general, the Web of things and Linked Data will enable integration across and within organisations, leading to greater efficiencies and opening up new opportunities.

from strategy.

@wseltzer, I am not 100% sure what you mean by 'ecosystem' story. But:

• There are a number of application areas that need the definition of some sort of metadata or structured data. @draggett gave the example of DOI; other examples of recent past include the Activity Streams, CSV on the Web, or the Web Annotation Working Groups. Schema.org is also a clear case in point. Finally, metadata is also vital for digital publishing, whether it is packaged or on the Web (publishers spend a significant amount of money on their metadata infrastructure).
• JSON-LD is in a unique position of expressing such structured data/metadata both in JSON (that is palatable for Web developers and compatible with most of the tools on the Web) as well as being mappable to RDF for Linked Data based infrastructures (mostly on the server side). It is fairly unique in this respect. This is also well accepted by the community; an example is the usage of JSON-LD by schema.org as one of their encoding alternative.
• JSON-LD has a number of, say, awkwardness when used, so a revision may be welcome if the CG can make the technical points

Is this what you were looking for?

from strategy.

Thanks @draggett and @iherman. By "ecosystem story" I'm thinking about a complete set of participants who recognize that they need interop, and recognize the same potential solution to their interop challenge. "Complete" in that if this set of participants and no others implement/use the technology, they will have a useful self-sufficient system. The story-telling (or business case) is describing how the participants fit together to create a system, and what their incentives are to do so.

In some cases, the ecosystem around a technology will be small, for example because it's used internally and for a small set of interactions, so buy-in from a small number of participants can make it succeed. If that use case is beneficial to the Web, it could be worth standardizing even with few participants. In cases where the overall ecosystem is larger, with more interdependent parts, we might ask whether a smaller set might seed the network, with a smaller "minimum viable product."

So for JSON-LD, I'm asking less "would this tech solve a problem," and more "what complete set of participants agree this tech would solve their problem."

from strategy.

The JSON-LD CG now has three reports that it would like to take through Rec Track:

• JSON-LD 1.1
• RDF Dataset Normalization
• LD Signatures

Perhaps could think about a new WG charter to encompass these three and the points that others have made in this thread?

from strategy.

This is a response to @wseltzer and a comment on the proposal for the WG: although I do not have exact data (something that we may want to collect) I believe one of the main users of JSON-LD is schema.org. JSON-LD is, alongside microdata and RDFa, the third major syntax used to encode schema.org terms. This also means that, I believe, getting this into a WG should be synchronized with the schema.org partners to see if the extensions planned by JSON-LD 1.1 agreeable to them, would be (eventually) implemented, etc.

As for the normalization & signatures: that has been a long-standing missing feature in the RDF world; if what is proposed there is mathematically correct (not a trivial problem) then it would be important to standardize this. However, it bothers me that the normalization document is edited by two persons from the same company; in view of the complex mathematical nature of the problem I think we should require other, independent parties to check the mathematics and work on the final version as co-editors.

Note, b.t.w., that the normalization and signatures are not JSON-LD specific. The charter should be careful to be general enough that allows for both of these to be part of the same group...

from strategy.

@iherman: "However, it bothers me that the normalization document is edited by two persons from the same company"

I should actually probably be an editor of the normalization document as well, as I did a fair amount of work on it, and have the second conforming implementation.

Note, b.t.w., that the normalization and signatures are not JSON-LD specific. The charter should be careful to be general enough that allows for both of these to be part of the same group...

Indeed, that's why I suggested a "Linked Data" WG. Other things of current interest that might fall in to this are:

• SPARQL Exists update – There's a CG working on this and other maintenance issues.
• SPARQL/RDF 1.1 alignment – minor work to align SPARQL 1.1 with RDF 1.1, right now SPARQL 1.1 is written to RDF 1.0

from strategy.

@r12a Regarding text-direction in JSON-LD, this seems like either a generic JSON issue or RDF issue.

Note that the CSVW WG added support for describing text direction when parsing CSV to the Tabular Data Model, but neither the JSON serialization nor RDF serialization is able to make use of these annotations when serializing. Even if we were to add some metadata to a value object, it could be lost when round-tripping to RDF.

As you note in your document, extracting directional information from the strings themselves may be the best solution.

from strategy.

Advance notice to the AC has been sent out: https://lists.w3.org/Archives/Member/w3c-ac-members/2018JanMar/0018.html

from strategy.

Formal AC vote has gone out: https://www.w3.org/2002/09/wbs/33280/jsonld-charter-201803/. Next milestone end of April to see the results of the vote...

from strategy.

Chartered: https://www.w3.org/2018/03/jsonld-wg-charter.html

https://lists.w3.org/Archives/Public/public-new-work/2018Jun/0000.html

from strategy.