Sustainability of Digital Formats: Planning for Library of Congress Collections |
|
![]() |
|
Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact |
Full name | JSON (JavaScript Object Notation) Data Interchange Format; also ECMA-404, JSON Data Interchange Format |
---|---|
Description |
JSON is a lightweight, text-based, language-independent data interchange format. It was derived from the JavaScript/ECMAScript programming language, but is programming language independent. JSON is considered as a lightweight alternative to XML, as in JSON: The Fat-Free Alternative to XML, a 2006 presentation by JSON's developer, Douglas Crockford. JSON defines a small set of structuring rules for the portable representation of structured data. JSON provides simple notation for expressing objects, collections of name/value pairs, and for arrays, ordered lists of values. By nesting these two basic structures, trees and other complex data structures can be represented. JSON syntax uses braces (curly brackets: {} ), square brackets ( [] ), colons, and commas to arrange values that are strings (sequences of characters in double quotes) or numbers (expressed as sequences of digits) into the two basic structures. An object is an unordered set of name/value pairs. An object begins with { (left brace) and ends with } (right brace). Each name is followed by : (colon) and the name/value pairs are separated by , (comma). An array is an ordered collection of values. An array begins with [ (left bracket) and ends with ] (right bracket). Values are separated by , (comma). A value can be a string in double quotes, or a number, or true or false or null, or an object or an array. These structures can be nested. Although the developer of JSON declared in 2006 that JSON is not a markup language, it is now often treated as such. The generic JSON is used as the basis for specific formats, which specify names and for more specific syntax for values. Examples include GeoJSON and its extension TopoJSON. A schema language has been documented at json-schema-org to support specification and validation of JSON applications. |
Production phase | An interchange format, typically used during data collection or to transmit selected structured data to a system that will further manipulate the data and/or present it to end users. |
Relationship to other formats | |
Has subtype | GeoJSON, GeoJSON. Has an extension TopoJSON. |
Used by | VRM, VRM |
Has subtype | 3D_Tiles_1.0, 3D Tiles Archive File Format, Version 1.0 |
Used by | Lyrx, ArcGIS Layer File. LYRX files are JSON-based. |
Has subtype | Formats for other specific applications where interactive data interchange on the Web is important, not described separately in this resource. |
LC experience or existing holdings |
JSON is available for item displays of many digital items in the Library of Congress collections as presented on the Web. For example, JSON is available for every page generated in the Prints and Photographs Online Catalog and maps found through Collections with Maps. As of 2022, the following parameter can be added to an item record URL to view the JSON: ?fo=json. For example, https://loc.gov/resource/cph.3b48715/?fo=json. JSON is one of the data serializations provided as an output format from id.loc.gov, a service that makes available as Linked Data standards and vocabularies promulgated by the Library of Congress. |
---|---|
LC preference | The Library of Congress Recommended Formats Statement (RFS) includes JSON as a preferred format for datasets. |
Disclosure | Openly documented. Developed by David Crockford in 2001. Later specified as RFC 4627 and ECMA-404. |
---|---|
Documentation | RFC 8259, December 2017. See Also as ECMA-404: The JSON Data Interchange Format, 2nd Edition, December 2017. See History for more information. |
Adoption |
Very widely used in web applications. The Rise and Rise of JSON, a Two-Bit History blog post from 2017, notes that JSON "has been adopted by all the big players: Of the ten most popular web APIs, a list consisting mostly of APIs offered by major companies like Google, Facebook, and Twitter, only one API exposes data in XML rather than JSON." In the 2019 InfoWorld article titled What is JSON? A better format for data exchange, author Jonathan Freeman states that XML has become less common, while JSON has become the preferred format for exchanging data between web and mobile clients and back-end services. Referring to XML's limitations compared to JSON, the author says, "In addition to being more verbose..., XML also introduces some ambiguity when parsing into a JavaScript-friendly data structure." The Two-Bit History blog post also notes that the adoption of JSON in programming is demonstrated by trends from Stack Overflow, a question and answer site for programmers, where more questions are asked about JSON than about any other data interchange format. This trend has continued into 2022. There are JSON libraries or built-in JSON support for many programming languages and systems, including: ActionScript, C, C++, C#, Cold Fusion, Java, Lisp, Perl, Objective-C, OCAML, PHP, Python, Ruby. ESRI has developed a JSON-based GeoServices REST Specification as a simple API to its GIS Server application to support "client-side development environments with the ArcGIS Web mapping APIs for JavaScript(tm), Flex(tm), Silverlight(R), iOS(R), and Android(tm)." Note that this specification is richer, and enables more functionality than the simple GeoJSON format. This specification is covered by the Open Web Foundation Agreement. "Following the open source model similar to the Creative Commons, the foundation is aimed at building a lightweight framework to help communities deal with the legal requirements necessary to create successful and widely adopted specifications." |
Licensing and patents | None associated with the basic format. |
Transparency |
JSON is based on text using UNICODE and uses a very simple structure. It is easy for humans to read and write and for machines to parse and generate. UTF-8 is most commonly used, but UTF-16 and UTF-32 are also permitted. |
Self-documentation |
Since JSON objects consist of name/value pairs, the names of fields or variables are expressed explicitly. JSON has no particular mechanism for further explaining the names used in a particular stream or file containing name/value pairs. Accessibilty Features According to results posted on Accessibility Self-Review for VC JSON Schema, "JSON Schemas, by design, are not intended to be internationalizable, since they are used for strict static validation of data. An implementer may choose to translate a JSON Schema, or make it available in a variety of languages; however, these would be considered distinct JSON Schemas. When packaging VC JSON Schemas as verifiable credentials, implementers are encouraged to follow the guidance listed in the VC Data Model. We believe that these specifications, in general, do not create accessibility concerns, but are curious to know if we have overlooked some aspect of how these technologies will be used that will create accessibility issues." In addition, a comment adds that "APA has no accessibility concerns. We also appreciate the inclusion of the Accessibility Considerations section in the spec." In practical terms, this means that JSON has no special natice support for accessibility features but it doesn't hinder them either. JSON has the potential to support accessibility depending on implementation. Comments welcome. |
External dependencies | None |
Technical protection considerations | None |
Dataset | |
---|---|
Normal functionality |
JSON is intended for data interchange and does not employ strong data-typing for numbers or have explicit support for dates. All data is represented as text, with numbers being in base 10 as sequences of digits (including the common exponent notation to express very small or very large numbers). JSON is not appropriate for applications requiring binary data. Boolean values true and false are allowed as values. There is minimal support for coding missing data, using the null value. |
Support for software interfaces (APIs, etc.) | JSON is so simple that support for reading or writing it is integrated into almost every system or programming language used for applications on the Web. |
Data documentation (quality, provenance, etc.) | There is no support in JSON per se for representing provenance metadata, but quantitative or qualitative assessments of quality or indications of provenance can be transmitted with data for applications that require such assessments. |
Beyond normal functionality | None. |
Tag | Value | Note |
---|---|---|
Filename extension | json |
|
Internet Media Type | application/json |
From RFC 8259. The MIME type registered with IANA. |
Magic numbers | Not found. | Comments welcome. RFC 8259 indicates n/a for magic number. |
Tag | Value | Note |
Internet Media Type | text/json text/javascript |
These values are found on occasion according to https://en.wikipedia.org/wiki/JSON#MIME_type. |
Other | NF00218 |
See https://www.archives.gov/files/lod/dpframework/id/NF00218.ttl |
Pronom PUID | fmt/817 |
See http://www.nationalarchives.gov.uk/PRONOM/fmt/817. |
Wikidata Title ID | Q2063 |
See https://www.wikidata.org/wiki/Q2063. |
General | JSON is minimalist. From JSON: The Fat-Free Alternative to XML, "JSON has no version number. No revisions to the JSON grammar are anticipated." |
---|---|
History | JSON 1.0 was adopted as ECMA-404 in October 2013 and version 2 was published in December 2017. IETF RFC 4627 was published in 2006 and was made obsolete by RFC 7159 in March 2014. RFC 8259 in turn made RFC 7159 obsolete in December 2017. RFC 8259 resolves the errata from the two previous RFC documents (for RFC 4627: RFC Errata IDs 607 [Err607] and 3607 [Err3607]; for RFC 7159: RFC Errata IDs 3915 [Err3915], 4264 [Err4264], 4336 [Err4336], and 4388 [Err4388]). RFC Errata IDs are available via a search from RFC Errata. A change list from each previous version is available in Appendix A of each RFC. |
|