TF-JSON-UC

Use cases for TF-JSON:

Add (some of) the benefits of RDF to existing JSON services

A service operator who currently runs a JSON API wants to add some RDF-like features, to allow clients to reap some of the benefits of RDF, without forcing complete re-tooling on the client or server side.

Migrating to Semantic Web Services

Frank runs a website that provides Web Services via a REST-based API that supports JSON. He would like developers using his system to be able to easily post and get RDF data RESTfully via his Web Services. He wants to make sure that the data that is exchanged looks very much like the JSON data that is passed to and from the Web Services that he already provides. He wants to make sure that developers can utilize the current JSON-based tools and workflows, perhaps with a tiny library for the serializations he uses, but still ensure that he can add semantics to that data in a way that is easy to explain to his Web Service customers.

Generalized storage of Semantic Data in Web Services

ACME Corp is operating a website with a JSON API. They want to give users the ability to store arbitrary additional data alongside certain objects managed via the API. For example, when a user account is created via the API, the client app should be able to also submit a digital signature or “My upcoming trips” data. The client app would be able to use that data on subsequent requests. To avoid accidental clashes between fields used by different client apps, ACME Corp wants to use RDF as the data model. Nevertheless, they want to keep the impact on the existing JSON API and existing clients to a minimum.

Expose a service that internally uses RDF in a JSON-friendly way

Stacy operates several Web Services. She designed the data that is sent and received by her Web Services in a way that maps very easily to RDF. She wants to be able to take the data that she is already publishing and transform it into RDF for internal use. She wants to be able to do this without impacting the developers that are currently using her system.

She also wants to be able to give the developers that care about RDF a data model that maps to RDF well. She would like to support both regular JSON developers and semantic web JSON developers at the same time via her JSON-based Web Services API.

View as RDF

Eli has an existing popular HTTP API which returns JSON and has many users, he has recently learned of the benefits of the semantic web and linked data, and would like to provide a way for users to see his data as RDF, without changing his entire heavily invested in technology stack or breaking backwards compatibility on his API. Eli can only make minor tweaks, such as adding http based id's to the objects the API returns, and providing a map which relates object property names to well known RDF properties.

Use JSON syntax to interact with a SPARQL store (or other RDF backend)

We assume a client-side developer who is familiar with RDF. She wants to access some sort of RDF back-end, for example a SPARQL store, perhaps both for reading and for writing. In certain situations, a JSON-based representation of RDF graphs would be the most convenient way of communicating with such an RDF back-end.

Developing a Javascript application that interacts with a graph store

Herbert is developing a Javascript application that interacts with an RDF store. He wants to be able to easily PUT, POST and GET RDF data RESTfully using the SPARQL RDF Dataset HTTP Protocol. Since he is working in Javascript, he wants to be able to send data to a graph store using JSON to represent the RDF data.

Access CONSTRUCT/DESCRIBE query results from JSON apps

SPARQL provides a JSON format for SELECT and ASK queries: currently a a W3C WG NOTE.

A JSON serialization of RDF would make the results of CONSTRUCT (and DESCRIBE) queries accessible as JSON-consuming clients.

Send RDF to a graph store

Alice wants to write a web application that collects data from the user during a scientific experiment and send the results to a shared data repository which is a graph store. Alice would like to use the SPARQL 1.1 RDF Dataset HTTP Protocol PUT data into the store.

RDF transfer between systems

Trevor would like to consume and produce RDF in his modern programming language. It does not yet have an RDF library but it does have a well optimised JSON parser and serialiser. He would like to take advantage of this JSON parser to perform simple but fast processing of RDF, without having to write a lot of code to parse RDF, as would be requires for other formats such as Turtle and RDF/XML.

Publish idiomatic, developer-friendly JSON from the RDF data model

The publisher already has RDF (or knows how her data would map to RDF). Now she wants to have an idiomatic JSON API that looks familiar to developers who are not familiar with RDF. Turning the JSON back into RDF is not a concern.

Universal Payment Standard for the Web

The PaySwarm Web platform is an open web standard that enables Web browsers and Web devices to perform Universal Web Payment. The nascent standard is using a form of RDF in JSON extensively in order to support distributed listing of assets, description of licenses and digital contracts, and digital signatures on graphs of RDF information. Information is published via HTML+RDFa and then used in JSON-form when transmitted to and from PaySwarm-aware Web Services.

Traditional JSON API over an RDF store

Pablo is developing a new web service. He has recently started to explore RDF, and would like to build the new service with an RDF store as the backend. However, all his other services have JSON APIs. He is concerned about alienating his customers by offering only RDF and SPARQL interfaces. He would like a solution that allows him to expose a JSON-based API on top of the RDF store. It should be similar to his other APIs and feel familiar to his users. On the other hand, he also wants to expose the full RDF data model to allow those with the right tooling to make maximum use of his data.

View arbitrary JSON as RDF

A client wants to be able to treat any arbitrary JSON as RDF, so that RDF tooling can be used. The publisher of the JSON doesn't do anything and doesn't need to be aware of this.

Treating JSON data as RDF for use in Data Spaces

In data integration scenarios it can be useful to “crawl” a JSON API, and reflect the crawled data in an RDF expression that can then be stored in a SPARQL store and further refined/mapped/linked with other RDF. A main challenge in “crawling” JSON APIs in a generic way is the question how to find/construct new URIs to GET from the first JSON response, as this often requires API specific knowledge, such as which fields contains URIs and which templates should be used to construct URIs from field values. Ideally, such URIs would be captured in the RDF representation so that the RDF representation captures the “link structure” in the original JSON. In this use case, producing “idiomatic” RDF that uses proper vocabularies etc from the JSON is perhaps not realistic; the structure of the produced RDF would closely reflect the JSON object structure, and vocabulary terms would be local to the API.

Other use cases

These use cases could be addressed with JSON as is, and don't require a new standard. They are listed here because they may give rise to additional requirements for the standard-to-be-defined.

Digital Signatures on Graphs

Graeme would like to publish assets for sale on his website via a JSON-based Web Services API. He would like this data to be cached on third party sites without the pricing information being changed or forged. He accomplishes this by digitally signing the graph of information that he publishes such that search engines and other caching mechanisms can relay the information without needing to directly access his site. By cryptographically signing the graph, he is also ensuring that information about the asset, including pricing information, cannot be changed or forged to different values.

Note: Requirement: graphs can be digitally signed

Pulling In Data From An External Linked Data Service

Joe has had a Justin Bieber fan site hosted on GeoCities forever. After GeoCities got shut down, he first considered migrating his content onto a Facebook fan site, however, having heard of the Semantic Web's recent success stories, decided to run his own site, get some server space, install WordPress, install a WordPress RDFa plugin, and be happy. From reading an article on W3Schools, he knows that if he writes...

<div xmlns:foaf="http://xmlns.com/foaf/0.1/" about="http://dbpedia.org/resource/Justin_Bieber">
  Justin Bieber's birthday is on
  <span property="foaf:birthday" content="1994-03-01">March 1, 1994</span>			
</div>

...he makes a statement about the Justin Bieber. At some point he decides to create a Justin Bieber images widget for his site with content from that cool new Semantic Web image site where he can retrieve semantically annotated images using their HTTP API like so:

GET http://cool-semantic-image-site.example.org/api/v1/for-sure-not-rest/images?q=dbp:Justin_Bieber&format=json

This API returns data in application/rdf-however-we-call-it+json, so he can simply JSON.parse the result, and use it like so:

var results = JSON.parse(responseText);
results.images.forEach(function(img) {
  // build HTML
});

He loves this API, because it is easy to work with in jQuery, plus the returned JSON code is easy to understand by just looking at it.

Note: Requirement: Use JSON.parse(), easy to work with in jQuery, easy to understand by looking at the JSON