From the beginning, our econ-ws (terminology) web services for economics produce tabular output, very much like the results of a SQL query. Not a surprise - they are based on SPARQL, and use the well-defined table-shaped SPARQL 1.1 query results formats in JSON and XML, which can be easily transformed to HTML. But there are services, whose results not really fit this pattern, because they are inherently tree-shaped. This is true especially for the /combined1 and the /mappings service. For the former, see our prior blog post; an example of the latter may be given here: The mappings of the descriptor International trade policy are (in html) shown as:
|<http://zbw.eu/stw/descriptor/10616-4>||"International trade policy" @en||<http://www.w3.org/2004/02/skos/core#exactMatch>||"International trade policies" @en||<http://aims.fao.org/aos/agrovoc/c_31908>||<http://zbw.eu/stw/mapping/agrovoc/target>|
|<http://zbw.eu/stw/descriptor/10616-4>||"International trade policy" @en||<http://www.w3.org/2004/02/skos/core#closeMatch>||"Commercial policy" @en||<http://dbpedia.org/resource/Commercial_policy>||<http://zbw.eu/stw/mapping/dbpedia/target>|
That´s far from perfect - the "concept" and "prefLabel" entries of the source concept(s) of the mappings are identical over multiple rows.
Often, a consuming application will have to re-build the original tree structure, which can be visualized as:
In order to support such results more appropriately, we have added RDF formats (rdf-xml, n-triples, turtle and json-ld) to the output formats of the /combined1 and /mappings services. Under the hood, these outputs are generated by SPARQL CONSTRUCT (instead of SELECT) queries. In Turtle, the above result looks like this:
skos:closeMatch <http://dbpedia.org/resource/Commercial_policy> ;
skos:exactMatch <http://aims.fao.org/aos/agrovoc/c_31908> ;
skos:prefLabel "Internationale Handelspolitik"@de , "International trade policy"@en .
dcterms:isPartOf <http://zbw.eu/stw/mapping/dbpedia/target> ;
skos:prefLabel "Commercial policy"@en .
dcterms:isPartOf <http://zbw.eu/stw/mapping/agrovoc/target> ;
skos:prefLabel "WELTHANDELSPOLITIK"@de , "International trade policies"@en .
The turtle syntax reflects fact that the Agrovoc and the DBpedia concept are both connected to the STW concept. Artificially built names, such as prefLabel and targetPrefLabel, which are required in the result table above to distinguish columns, are avoided. And by the way, it allows us to output prefLabels in English and German, without having to duplicate every row in the above table.
JSON for Linking Data
Since currently our SPARQL server, Fuseki, does not deliver JSON-LD formatted results, we included Markus Lanthaler's JsonLD library to post-process turtle results delivered by Fuseki. This is working fine - for the above result we get:
"@value": "International trade policies"
"@value": "Commercial policy"
"@value": "Internationale Handelspolitik"
"@value": "International trade policy"
The result is straight JSON. The context part may or may not be used by an application. The last section of the graph part contains the overall structure for the source concept, whereas the details about the mapped DBpedia and Agrovoc concepts can be found in separate sections.
To Frame or Not To Frame
The graph showed above could transformed to an even more intuitive one by embedding the properties of the mapped concepts into the main tree derived from the source concept, resulting in one overall tree structure. This kind of shaping of the output is called "Framing" in JSON-LD. Since such a graph can take multiple forms, depending on application demands, it requires something in the kind of a template, named "Frame" here. We provide here a link to the JSON-LD Playground which will load our example and a simple frame document. (Please open the "Framed" tab, and feel free to experiment.)
An emerging pattern for unified Linked Data resource lookup and web service results?
In our Linked Data services, there is a not really satisfactory dichotomy between the econ-ws services, which mostly deliver query results of some kind, and the results you get when you look up resource URIs such as the one for International trade policy: The former delivered (up to now) easily understandable, table-shaped XML or JSON, while the latter deliver RDFa, RDF/XML or Turtle, which requires some effort for parsing, especially for web developers which are not deeply in Semantic Web technology. (BTW, this situation is reflected in the fact that we have marked the /narrower and /labels service as "deprecated" - as the data can be obtained by resource lookup -, but not yet have removed them.)
Perhaps, JSON-LD could bridge the gap, in that it can be used in both kinds of services, and in that it is able to express complex data structures in a widely familiar and easy-to-use way.