User:Rcygania2/JSON User Story

In client-side application development and in integrating between RDF-based systems and JSON-based APIs, the problem of mapping between the RDF data model and the JSON data model recurs.

In the unconstrained RDF data model, there are too many variations to map arbitrary RDF graphs cleanly to JSON. By selecting an RDF vocabulary that covers the desired JSON structure, and using Shapes to express constraints over the vocabulary, the mapping could be made sensible and predictable. In other words, Shapes could be used to constrain RDF graphs in a way that gives them a well-defined isomorphic mapping to some JSON model. As a side effect, we also get better UI for these constrained RDF graphs.

This gives rise to a number of requirements:

• MaxCardinality 1: Properties with a maximum cardinality of 1 can be mapped easily to keys in JSON objects.
• Support for RDF lists: Ordered lists are a standard feature of JSON. A clean mapping requires the ability to declare that the value of a property must be an rdf:List, and the ability to place constraints on the members of the list (e.g., be of a certain class or have a certain shape). This has UI advantages too. Knowing that an RDF property is an ordered multi-valued property calls for specific UI widgets. (Partially already covered in S26)
• Maximum one string literal per language: For i18n-capable applications, “one string per language” is an important kind of value. In RDF, this shows up simply as a multi-valued string property. An example is skos:prefLabel. In JSON, the natural representation of this is an object with language codes as keys and the string literals as values. This pattern has special support in JSON-LD for example (“language maps”). Again, if we can declare this constraint on a property, we can use better UI widgets and better API access.