General approach

My approach involved taking the default JSON [[RFC4627]] representation of each of the RDF Interfaces (from the RDFa API), gained by calling JSON.stringify on an instance of any given interface - and then making changes one step at a time until ultimately ending up with this JSON representation of RDF [[RDF-CONCEPTS]].

Design Goals

My priorities whilst doing this are as follows:

• Maintain RDFa API compatibility
• Maintain type safety
• Ensure serialization and parsing rules remain as simple as possible
• Minimize the serialization wherever reasonable.
• Ensure the representation is human readable/understandable when formatted nicely (ie with indentation and spacing).
• Ensure the representation can be parsed quickly by a streaming processor.
• Try to make the representation familiar to those who know Turtle [[TURTLE]], Notation 3 [[N3]], or JSON [[RFC4627]].

Short example

In JSN3:

and the same in Turtle

Basic Structure

This abstract example aims to show the basic structure of a JSN3 graph.

IRI

"http://example.org/some-iri"

Dropped <iri> syntax!
Strongly considering dropping the < and > from IRIs, this isn't an issue for subject and predicate, however does raise the issue of string-literal IRI vs IRI for plain literals in the object position.

How often do users need to use the string-literal form of an IRI and is it low enough to warrent dropping < > from IRI and forcing people to use xsd:string Typed Literals to talk about the lexical form of an IRI?

Feedback to the editor is requested.

CURIE

"foaf:name"

Declaration

"@base": "http://example.org/graph#",
"@prefix": {
  "foaf:": "http://xmlns.com/foaf/0.1/"
}

Triple

":me": {
  "foaf:name": "Nathan"
}

Suggestion: Object always an array.

It has been suggested that Objects should always be inside an array container so that they can easily be iterated over.

However, this complicates the syntax somewhat and it is extremely easy to test whether a value is an array or not at runtime.

// javascript
o = (typeof o != 'array') ? [o] : o;

Plain Literals

":example": {
  "ex:boolean": true,
  "ex:number": -123.3452,
  "ex:basic": "some value here"
}

Plain Literals with repetition

This is the equivalent of comma seperated objects in N3 / Turtle

":example": {
  "ex:likes": ["Red", "Green", "Blue"]
}

Language specific Plain Literals

":London": {
  "rdfs:label": {"@en": "London"} 
}

Suggestion: Include the language in the value

It has been suggested that the form of Language specific Plain Literals be

"London@en"

However this would mean that:

• @ would need escaped, which commonly doesn't need escaping, and would be a cause of many mistakes
• The object value would not be able to be used 'as-is' which would complicate JSN3 usage
• The form of Language specific Plain Literals with repetition would have to be removed

Suggestion: Change the form of Plain Literals to be an Object with two attributes

{ "lang": "en", "value": "London" }

This suggestion is still being actively discussed and considered, any comments for or against this syntax should be sent to the editor.

Language specific Plain Literals with repetition

":London": {
  "rdfs:label": {"@en": ["London", "City of London", "London Town"]} 
}

is shorthand for:

":London": {
  "rdfs:label": [
    {"@en": "London"},
    {"@en": "City of London"},
    {"@en": "London Town"}
  ] 
}

both forms are valid JSN3 syntax.

Typed Literals

":data": {
  "ex:age": {"^^xsd:nonNegativeInteger": "29"} 
}

Suggestion: Include the type in the value

It has been suggested that the form of Typed Literals be

"29^^xsd:nonNegativeInteger"

However this would mean that:

• ^ would need escaped, which commonly doesn't need escaping, and would be a cause of a few mistakes
• The object value would not be able to be used 'as-is' which would complicate JSN3 usage
• The form of Typed Literals with repetition would have to be removed

Suggestion: Change the form of Typed Literals to be an Object with two attributes

{ "type": "xsd:nonNegativeInteger", "value": "29" }

This suggestion is still being actively discussed and considered, any comments for or against this syntax should be sent to the editor.

Typed Literals with repetition

":data": {
  "ex:dates": {"^^xsd:dateTime": ["2010-09-24T23:14:52Z", "2010-09-23T19:12:33+02:00"]} 
}

Lists ()

":data": {
  "ex:listOfNumbers": [[1,2,3,4,5]] 
}

Would equate to the following N3/Turtle

:data ex:listOfNumbers (1,2,3,4,5) .

":data": {
  "ex:lists": [
    [[1,2,3]],
    [["a","b","c"]]
  ] 
}

Would equate to the following N3/Turtle

:data ex:lists (1,2,3), ("a","b","c") .

whilst the following list of lists

":data": {
  "ex:listOfLists": [[
    [[1,2,3]],
    [["a","b","c"]]
  ]]
}

Would equate to the following N3/Turtle

:data ex:lists ((1,2,3), ("a","b","c")) .

Blank Nodes

":me": {
  "foaf:knows": {
    "foaf:name": "Jim Smithson",
    "foaf:mbox": "mailto:jim.smithson@example.org"
  }
}

An empty Blank Node in JSN3 is represented as {}, in Turtle/N3 this would be [].

":foo": {
  "ex:any": {}
}

Blank Nodes by reference

JSN3 reserves the '_' namespace / prefix for use with blanknodes, this common form is supported by N3, Turtle and NTriples.

":me": {
  "foaf:knows": "_:b0"
},
"_:b0": {
  "foaf:name": "Jim Smithson",
  "foaf:mbox": "mailto:jim.smithson@example.org"
}

Graph Literals

Graph Literals in JSN3 take exactly the same form as Graphs, however they are wrapped inside "@graph": { ... } syntax, and can only appear in the Object position of triple.

For example, the following JSN3

"_:g1": {
  "diff:delete": {
    "@graph": { ":me": { "foaf:knows": "friends:oldid" } }
  },
  "diff:insert": {
    "@graph": { ":me": { "foaf:knows": "friends:newid" } }
  }
}

Would translate to the following N3:

_:g1
  diff:delete { :me foaf:knows friends:oldid };
  diff:insert { :me foaf:knows friends:newid } . 

Should the @graph symbol be replaced with something difference? @formula, or simply @ - what about @rule's.. scope

Shorthand

JSN3 also introduces seven special shorthand predicates

@has is missing

^a can be thought of as short-short-hand for "is rdf:type of" in N3

":me": {
  "a": "foaf:Person",
  "=": "http://example.org/other/web#id"
}

"foaf:Person": {
  "^a": ":me"
}

":child": {
  "^ex:hasChild": ":parent"
}

":me": {
  ">foaf:knows": "http://webr3.org/my-friends"
}

Any Subject

Reword..

The shorthand == also allows any concept which can exist in the object position to exist in the subject position

Thus, literal subjects:

"_:four": {
  "==": 4,
  "ex:lessThan": 5
}

4 ex:lessThan 5

Graph literal subjects

"_:g2": {
  "==": {
    "@graph": { ":bob": { "foaf:knows": ":sue" } }
  },
  "a": "log:Falsehood"
}

{ :bob foaf:knows :sue } a log:Falsehood

Named Graphs

The == shorthand also allows you to 'name' graphs, and annotate them.

":myGraph": {
  "==": {
    "@graph": {
      ":me": { "foaf:name": "Nathan", "foaf:birthday": "03-31" }
    }
  },
  "dc:created": { "^^xsd:dateTime": "2010-09-25T21:48:03Z" }
}

:myGraph owl:sameAs { :me foaf:name "Nathan"; foaf:birthday "03-31" } ;
  dc:created "2010-09-25T21:48:03Z"^^xsd:dateTime.

Complex Property Example

":me": {
  "foaf:name": "Nathan",
  "=:p4": {
    "@property": { "owl:inverseOf": "dc:creator" },
    "@object": "http://webr3.org/apps/specs/jsn3#doc"
  },
  "foaf:birthday": "03-31"
}

In N3:

:me foaf:name "Nathan";
  [ owl:inverseOf dc:creator ] <http://webr3.org/apps/specs/jsn3#doc>;
  foaf:birthday "03-31" .
     

Note: The above can easier be said in JSN3 as, "^dc:creator": "http...", of by using foaf:made.

@forAll - Universal Quantification

"@forAll": ":x"

"@forAll": [":x",":y"]

@forSome - Existential Quanitification

"@forAll": ":g"

"@forSome": [":g",":h"]

Examples

{
  "@forAll": ":x",
  "_:g1": {
    "==": {
      "@graph": { ":thermostat": { ":temp": ":x" } }
    }
    "=>": {
      "@graph": { ":cooling": { ":power": ":x" } }
    }
  }
}

@forAll :x.
{ :thermostat :temp :x } => { :cooling :power :x } .
       

{
  "@forAll": "#h",
  "@forSome": "#g",
  "#g": { "#loves": "#h" }
}

@forAll <#h> .
@forSome <#g> .
<#g> <#loves> <#h> .
       

Variables

"?x": {
  "foaf:knows": "http://webr3.org/nathan#me"
}

Rules

Example simple rule

"_:f1": {
  "==": {
    "@graph": { "?x": { ":parent": "?y" } }
  },
  "=>": {
    "@graph": { "?y": { ":child": "?x" } }
  }
}

 { ?x :parent ?y } => { ?y :child ?x } 

Example more complex rule

"_:f1": {
  "==": {
    "@graph": {
      "?x": { ":parent": "?y" },
      "?y": { ":brother": "?z" }
    }
  },
  "=>": {
    "@graph": {
      "?x": { "a": ":Male", ":uncle": "?z" },
      "?z": { "a": ":Male", ":nephew": "?x" }
    }
  }
}

 { ?x :parent ?y . ?y :brother ?z } => { ?x a :Male; :uncle ?z . ?z a :Male, :nephew ?x } 

Named Rules

With JSN3, as with N3, it is possible to name and annotate rules. by naming a graph which contains said rules.

Note: Anybody creating complex / named / annotated rules with either N3 or JSN3 may be wise to consider using AIR

":family": {
  "==": {
    "@graph": {
      "_:f1": {
        "==": {
          "@graph": { "?x": { ":parent": "?y" } }
        },
        "=>": {
          "@graph": { "?y": { ":child": "?x" } }
        }
      }
    }
  },
  "dc:created": { "^^xsd:dateTime": "2010-09-25T21:48:03Z" }
}

:family = { { ?x :parent ?y } => { ?y :child ?x } };
  dc:created "2010-09-25T21:48:03Z"^^xsd:dateTime.