JSON Triple Sets

Contents

Description

A JSON triple set is a JSON array of objects. Each object represents a single triple. Objects have the following keys:

s

The subject as a string - this may be an IRI, or a blank node identifier prefixed with "_:".

p

The predicate as a string - this will be an IRI.

o

The object as a string - this will be an IRI, a prefixed blank node identifier, the value of a plain literal or the string representation of a typed literal.

s_type

Either uri or bnode. This is optional as it can always be inferred. If present though and set to an unrecognised value, the triple must be ignored by parsers.

p_type

uri. This is optional as it can always be inferred. If present and set to an unrecognised value, the triple must be ignored by parsers.

o_type

Either literal, uri or bnode. This can be inferred to be literal if either the o_datatype or o_lang key is present. Otherwise if it's absent the object type is ambiguous. (Should parsers use heuristics, or just raise an error??) If present and set to an unrecognised value, the triple must be ignored by parsers.

o_datatype

If the object of the triple is a typed literal, this will be a URI. If o_type is present and not equal to literal, then this key is ignored.

o_lang

If the object of the triple is a plain literal with a language identifier, this will be the language identifier. If o_type is present and not equal to literal, then this is ignored.

No significance is attached to the ordering of the outer array, nor to the order of the keys within each triple object. Any additional keys should be ignored

Extensions

A few trivial extensions allow the JSON Triple Sets format to represent data outside the normal RDF model. (X in the list below is taken to be a placeholder for s, p or o.)

Literal subjects can be added by allowing s_type to be literal and using s_datatype and s_lang keys. Unlike o_type which can automatically be inferred to be literal in some cases, serializers must always set s_type to literal explicitly.

Blank node and literal predicates can be added similarly.

The original ARC2 structure allows SPARQL-style variables too. This is accomplished by setting X_type to var. It's not clear from the ARC2 documentation whether the value of X should then be ?foo or $foo or perhaps just foo.

A subset of Notation 3's formula concept (without @forAll, @forSome) can be added by allowing X_type to be formula, in which case the X value is not a string, but a nested array of triples.

Named graphs can be encoded in the same structure by adding g and g_type where g_type would be uri. Anonymous graphs can be added by allowing g_type to be bnode. Literally named graphs can be added by allowing g_type to be literal and providing g_lang and g_datatype keys.