Re: Extended types in JSON(-LD)

I don't think it's so much about the underlying RDF (or actually XSD data types as Greg pointed out in a related reply), but rather it's about consulting some other document (ala JSON Schema or JSON-LD Context File) or some inline `@context` area (in JSON-LD's case) which further describes or limits what's contained in the "raw" JSON file.


There's not much we can do directly to the JSON format itself other than either super-setting it (YAML post-historically as well as BSON, JSON5, Hjson, etc.) and sub-setting it (I-JSON).

Augmenting it via JSON-LD contexts, JSON Schema files, etc provides the ability to stay within a single parsing model while still being able to (dare I say ;) ) annotate that model with further meaning, value, restrictions, or enhancements.

If you desperately need the format itself to provide non-augmented data type storage...then JSON's not the right format, and doesn't seem likely to become that. It's either a blessing or a curse depending on what you need and want. ;)

References...
YAML: http://yaml.org/
BSON: http://bsonspec.org/
JSON5: https://json5.org/
Hjson: https://hjson.org/
I-JSON: https://tools.ietf.org/html/rfc7493

Cheers!
Benjamin


--

http://bigbluehat.com/

http://linkedin.com/in/benjaminyoung

________________________________
From: Leonard Rosenthol <lrosenth@adobe.com>
Sent: Monday, August 6, 2018 10:47:24 AM
To: Patrick Golden; public-json-ld-wg@w3.org
Subject: RE: Extended types in JSON(-LD)

Thanks Patrick.

I agree with you that for JSON-LD a full understanding/implementation of RDF is required, however for standard JSON that's not true and also problematic in some workflows.  (but hopefully folks will come around to -LD...)

Leonard

-----Original Message-----
From: Patrick Golden <ptgolden@email.unc.edu>
Sent: Friday, August 3, 2018 7:25 PM
To: public-json-ld-wg@w3.org
Subject: Re: Extended types in JSON(-LD)

Since JSON-LD is a serialization of RDF, it seems like this would be done through using RDF literal datatypes:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Frdf11-concepts%2F%23section-Datatypes&amp;data=02%7C01%7Clrosenth%40adobe.com%7C736ecd13171e4ebe073d08d5f998770a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636689355584717762&amp;sdata=vRD6vjihUDk2EYqdOkW5IP5kki7xtyRf0iCFRPivCxM%3D&amp;reserved=0
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjson-ld.org%2Fspec%2Flatest%2Fjson-ld%2F%23typed-values&amp;data=02%7C01%7Clrosenth%40adobe.com%7C736ecd13171e4ebe073d08d5f998770a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636689355584717762&amp;sdata=CQta2ODYbQlIZiGTNBQNHTTeIOYagiHK8g5o7HuRvyU%3D&amp;reserved=0

The datatypes that are almost always used with RDF are defined in XML Schema. It includes types for long, short, float, double, and more.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fxmlschema11-2%2F%23ordinary-built-ins&amp;data=02%7C01%7Clrosenth%40adobe.com%7C736ecd13171e4ebe073d08d5f998770a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636689355584717762&amp;sdata=uVLvVnm5qcO%2BsLJSwGkKQIEewvsThL4q2602ATAACRo%3D&amp;reserved=0

For example, if I wanted to say that some parameter has the value of "178", expressed as a short integer, I could produce the JSON-LD:

{
   "@context": {
     "ex": "https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.org%2F%23&amp;data=02%7C01%7Clrosenth%40adobe.com%7C736ecd13171e4ebe073d08d5f998770a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636689355584717762&amp;sdata=ZqY3eT64iWQNkfubgz5dCzrHT163sQkEX91%2FWsu6fIQ%3D&amp;reserved=0",
     "xsd": "https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23&amp;data=02%7C01%7Clrosenth%40adobe.com%7C736ecd13171e4ebe073d08d5f998770a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636689355584717762&amp;sdata=0XgDJsXaKFrcxRDFeFSMHtwzb6yzMxjJp%2FmmfyKiqGw%3D&amp;reserved=0"
   },
   "@id": "ex:parameter1",
   "ex:hasValue": {
     "@value": "178",
     "@type": "xsd:short"
   }
}

Or, more tersely:

{
   "@context": {
     "ex": "https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.org%2F%23&amp;data=02%7C01%7Clrosenth%40adobe.com%7C736ecd13171e4ebe073d08d5f998770a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636689355584717762&amp;sdata=ZqY3eT64iWQNkfubgz5dCzrHT163sQkEX91%2FWsu6fIQ%3D&amp;reserved=0",
     "xsd": "https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23&amp;data=02%7C01%7Clrosenth%40adobe.com%7C736ecd13171e4ebe073d08d5f998770a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636689355584717762&amp;sdata=0XgDJsXaKFrcxRDFeFSMHtwzb6yzMxjJp%2FmmfyKiqGw%3D&amp;reserved=0",
     "value": {
       "@id": "ex:hasValue",
       "@type": "xsd:short"
     }
   },
   "@id": "ex:parameter1",
   "value": "178"
}

Both of which produce the triple:

<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.org%2F%23parameter1&amp;data=02%7C01%7Clrosenth%40adobe.com%7C736ecd13171e4ebe073d08d5f998770a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636689355584717762&amp;sdata=Pfnu0%2F%2FEeFtwkW87UKgpL3gV4xi9f9Jm39JuA%2B9FFqc%3D&amp;reserved=0> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.org%2F%23hasValue&amp;data=02%7C01%7Clrosenth%40adobe.com%7C736ecd13171e4ebe073d08d5f998770a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636689355584717762&amp;sdata=f3L6Zlf%2FBLxKpi1Ev6%2F%2FimiHP3iCQL%2FEhM7CJSJ2kfw%3D&amp;reserved=0>
"178"^^<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23short&amp;data=02%7C01%7Clrosenth%40adobe.com%7C736ecd13171e4ebe073d08d5f998770a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636689355584717762&amp;sdata=T2eOvFF8wc%2BFQ%2BLB9LwBpfuTFChtk7s02122ZqfeTiA%3D&amp;reserved=0> .

Such triples could then be further validated or constrained using OWL or SHACL.

Of course, it depends on what you mean by "simple exchange" and "raw"
JSON, since it necessarily relies on having a working RDF stack. That might be simple for some users of JSON-LD, and not so simple for others who are not used to working with RDF.

Best,
Patrick

On 07/30/2018 12:59 PM, Leonard Rosenthol wrote:
> Figuring I have the right group of experts here...
>
> Has anyone done work on extending JSON(-LD) with additional data types
> - or more specifically more clarity on the precision of existing types.
> For example, declaring that an "integer" is long vs. short or that a
> "number" can be represented as a float instead of a double.
>
> We can see how one could define it with JSON Schema, but that doesn't
> help in simple exchange.
>
> Any thoughts on this?
>
> Thanks,
>
> Leonard
>
> P.S. Yes, I know that most of the binary flavors of JSON support
> extended types, but havent' seen a solution for "raw" JSON.
>