Difference between revisions of "JSON Syntax Options"

From RDF Working Group Wiki
Jump to: navigation, search
(JSON Syntax Options)
(JSON Syntax Options)
Line 1: Line 1:
 
== JSON Syntax Options ==
 
== JSON Syntax Options ==
  
This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF in JSON.
+
This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF, in JSON.
  
 
=== URI Properties ===
 
=== URI Properties ===

Revision as of 22:31, 11 March 2011

JSON Syntax Options

This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF, in JSON.

URI Properties

RDF uses URIs to name things, including properties. A key benefit of this is that it allows different data sources to all use properties defined in open vocabularies, thus enabling shared understanding of data.

JSON on the other hand, is typically used for domain specific / silo based information where properties are simple lexical terms (like "name") and what the property "means" is documented somewhere out of band, for instance in API documentation, or in a JSON-Schema document.

There follows a collection of different approaches we can take which enable the use of URI identified properties in JSON.

Full URIs

{ "http://xmlns.com/foaf/0.1/name": "Bob" }

Benefits:

  • Unambiguous and easy to process.
  • When following your nose around the web, property equivalence uses the in serialization URI.

Drawbacks:

  • Increased bytesize over the wire.
  • Can be verbose to use when using the returned (JSON.parsed) data without an API or tooling.
  • Verbose to author.

Example usage (assuming the returned data has been JSON.parsed):

obj["http://xmlns.com/foaf/0.1/name"]
obj[ foaf('name') ] // when using a tabulator ns style approach in your code
obj[ resolve('foaf:name') ] // when using a function which allows the resolution of CURIEs as found in the RDF API

CURIEs

Note: this example uses JSON-LD syntax for the prefix maps:

{
  "#": { "foaf": "http://xmlns.com/foaf/0.1/" },
  "foaf:name": "Bob"
}

To reconstruct the URI, one must split "foaf:name" on the colon, replace "foaf" with it's related mapping in the prefix map "http://xmlns.com/foaf/0.1/", concatenate "name" to "http://xmlns.com/foaf/0.1/".

Separator Options:

  •  : colon (familiar, but can't use . notation in JSON.parsed output)
  • _ underscore (unfamiliar, ambiguous when property also contains an underscore)
  • $ dollar (unfamiliar, but can use . notation in JSON.parsed output)

Benefits:

  • Reduced bytesize over the wire
  • Familiar to traditional RDF users
  • Easier to author

Drawbacks:

  • Requires tooling to normalize CURIEs prior to using the data when following your nose around the web.
  • Requires CURIE resolution to do property comparison (equivalence must be between URIs not CURIEs)
  • Unreliable when following your nose around the web (the same URI could be shortened to "ns0:ame" or "f:name")
  • Unfamiliar to traditional JSON users
  • Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):

obj["foaf:name"]; // but ONLY when you are familiar with the data and NOT when following your nose


TERMs (no colon)

Note: this example uses JSON-LD syntax for the prefix maps:

{
  "#": { "name": "http://xmlns.com/foaf/0.1/name" },
  "name": "Bob"
}

To reconstruct the URI, one must replace "name" with it's related value in the map "http://xmlns.com/foaf/0.1/name"

Benefits:

  • Reduced bytesize over the wire
  • Familiar to traditional JSON users
  • Easy to author
  • Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:

  • Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
  • Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
  • Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
  • Unfamiliar to traditional RDF users

Example usage (assuming the returned data has been JSON.parsed):

obj.name; // but ONLY when you are familiar with the data and NOT when following your nose

TERMs (with colon allowed)

Note: this example uses JSON-LD syntax for the prefix maps:

{
  "#": { "name": "http://xmlns.com/foaf/0.1/name", "rdfs:label": "http://www.w3.org/2000/01/rdf-schema#label" },
  "name": "Bob",
  "rdfs:label": "Bob"
}

To reconstruct the URI, one must replace the term ("name", "rdfs:label") with it's related value in the map ("http://xmlns.com/foaf/0.1/name", "http://www.w3.org/2000/01/rdf-schema#label")

Benefits:

  • Reduced bytesize over the wire
  • Familiar to traditional JSON users
  • Familiar to traditional RDF users
  • Easy to author
  • non-colon names only: Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:

  • Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
  • Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
  • Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
  • with colon names only: Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):

obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
obj["rdfs:label"]; // with colon - but ONLY when you are familiar with the data and NOT when following your nose


TERMs + Single Vocab

Note: this example uses a made up syntax!

{
  "#vocab": "http://example.org/my-vocab#",
  "name": "Bob",
}

To reconstruct the URI, one must append "name" to the value of #vocab ("http://example.org/my-vocab#")

Note: This may look wonderful, but comes with the one-vocab caveat that means when publishers require multiple terms, they will be likely to create "proxy" vocabularies that simply pull together many terms from different vocabularies and merge them. There is a processing and understanding cost to that which can't be stepped in to lightly.

Benefits:

  • Minimal bytesize over the wire
  • Familiar to traditional JSON users
  • Familiar to RDFa users
  • Easy to author
  • Unambiguous and easy to process.
  • Easy to use when using the returned (JSON.parsed) data without an API or tooling.
  • Encourages vocabulary merging and reuse.
  • Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:

  • Requires understanding of equivalent property statements in custom vocabularies when following your nose around the web.
  • Real world property equivalence is far more complicated.

Example usage (assuming the returned data has been JSON.parsed):

obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose

Option: External Maps

Three of the above options ( CURIEs, TERMs no colon, TERMS with colon ) all require a prefix or term map to be included in order to turn shortened properties in to full URIs.

There is a possibility that these maps could be factored out and referenced externally, this option comes with it's own set of benefits and drawbacks.

Benefits:

  • Minimal data over the wire.
  • When used with either of the TERMs options, allows bootstrapping of existing JSON data in the wild.
  • Encourages vocabulary merging and reuse.
  • Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:

  • Sometimes requires two GETs when following your nose.
  • External map unavailability removes your ability to see the data as RDF.
  • Some changes to external maps could change the meaning of the data.