[Architecture] JSON-LD and use cases

Claudia Loitsch claudia.loitsch at tu-dresden.de
Thu Apr 10 04:35:27 EDT 2014

Hey architects,

I would like to forward some thoughts about JSON-LD (JSON-Linked Data) 
and how it can ease development of semantic approaches towards 
Cloud4all/GPII *(see original message below)*.

Comments, thoughts, experiences are more than welcome.


-------- Original-Nachricht --------
Betreff: 	JSON-LD (WAS: Re: common terms registry - task force)
Datum: 	Wed, 09 Apr 2014 12:25:12 +0200
Von: 	Claudia Loitsch <claudia.loitsch at tu-dresden.de>
An: 	Clark, Colin <cclark at ocadu.ca>
Kopie (CC): 	'Gregg Vanderheiden' <gregg at raisingthefloor.org>

Hi Colin,

Am 07.04.2014 17:48, schrieb Colin Clark:
> Claudia, I’d love to hear more about what features of JSON-LD you’re interested in. What kinds of linked data structures would you like to see, and for which use cases? Sounds interesting.

JSON-LD is a nice option to provide mappings from JSON to an RDF model 
(and vice versa) by expressing the context of the data 
<http://www.w3.org/TR/json-ld/#basic-concepts>. Through, context is no 
more than a link between object properties (JSON) and semantic concepts 
(RDF, OWL, etc). The simplest user case I have in mind for JSON-LD in 
the scope of Cloud4all is to provide a linking between a user 
preferences and the specification of preference terms (e.g. data type, 
value range) or context terms. I think we are doing this implicitly as 
the name of a preference is a URI referring to a registered term. Hence, 
it should be possible to use these URIs to go to a term an get its 
definition e.g. through an APIs to the registry. However, developers of 
semantic applications (e.g. a rule-based matchmaker) might want to 
create its own model just by using row data of user preferences and term 
specifications to infer new knowledge. JSON-LD is a perfect match for 
this kind of application as:

* identifiers can be assigned to data,
* same terms of different sources become unique and are not used in 
another terminology by developers,
* IRI dereferencing to get definitions of terms is provided.

I have attached a small example (see below; used name spaces are just 
exemplary) which include:
* *different representations of preferences* *(1 - 3*) whereupon 2 and 3 
are conform to JSON-LD <http://json-ld.org/playground/index.html>.  3 
includes more information about a term itself, e.g. what kind of 
preference it is (common or application-specific) but this could (or 
even should) be part of term specification (see 4) itself.
****a possible **specification**of a term (4)*. So, 4 refers to the 
common vocabulary of the registry.
Both data sources, the preference set on the one hand and the term 
specification on the other hand are linked now. Semantic approaches as 
the RBMM can create semantic models automatically and join the different 
sources easily. I tried this successfully and it simplifies the whole 
process as I do not need to instantiate a vocabulary and its relations. 
There are JSON-LD API implementations available and I have played with 
JSON-LD JAVA to see how and if it works. And it works well. I managed to 
instantiate a complete RDF model combining facts about the users 
preferences and preference term specification in few lines of code.

Beyond the use case above, other linked data sources that I could think 
of (some rather for future tasks) are:

* semantic association between terms
* specific information about solutions beyond descriptions, or 
* dataset of user rated solutions
* other kind of preferences e.g. more task oriented.
* etc.

But for now, I just have in mind to get preferences in JSON-LD (provided 
by the ontologizer?) and to get a specification of the preference terms 
in JSON-LD. The latter implies that we have identifiers for the registry 
term vocabulary, e.g. identifier for a common term; context term; data 
types, etc.

Let my know what you think, if you have questions or if I should give 
more details.

Warm regards,


****** Example:  ********

*1. Our flat preferences in JSON: *
"http://registry.gpii.org/common/fontSize": [{ "value": 24 }],
         "value": {
             "HighContrastOn": {
                 "path": "pvParam.dwFlags.HCF_HIGHCONTRASTON",
                 "value": true
*2. Our flat preferences in JSON-LD using full IRIs *
"http://registry.gpii.org/common/fontSize": 24,

*3. The same preferences in JSON-LD using terms: *
     "@context": {
         "preferences": "http://registry.gpii.org/preference",
         "name": "http://registry.gpii.org/preference/name",
         "type": "http://registry.gpii.org/preference/type",
         "value": "http://registry.gpii.org/preference/value",
         "condition": "http://registry.gpii.org/preference/condition"
     "preferences": [
             "@id": "http://registry.gpii.org/common/fontSize",
             "type": "common",
             "name": "fontSize",
             "value": "24",
             "condition": "null"
             "type": "applications",
             "name": "com.microsoft.windows.highContrast.HighContrastOn",
             "value": "true",
             "condition": "null"

*4. Specification of **Terms in JSON-LD (e.g. comming from the registry):*
     "@context": {
         "terms": "http://registry.gpii.org/preference",
         "datatype": "http://registry.gpii.org/preference/datatype",
         "valueRange": "http://registry.gpii.org/preference/valuerange",
         "default": "http://registry.gpii.org/preference/defaultValue"
     "terms": [
             "@id": "http://registry.gpii.org/common/fontSize",
             "datatype": "Integer",
             "valueRange": "0-*",
             "default": "8"
             "@id": "http://registry.gpii.org/common/foregroundColor",
             "datatype": "Integer",
             "valueRange": "0-*",
             "default": "8"

Dipl.-Medieninf. Claudia Loitsch

Technische Universität Dresden
Institut für Angewandte Informatik
Professur Mensch-Computer Interaktion

Tel.: 0351/463 42025
Fax: 0351/463 38491

E-Mail:claudia.loitsch at tu-dresden.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20140410/07cbf28d/attachment.html>

More information about the Architecture mailing list