Interpretation as RDF

1. Export vs Interpretation

The JSON document can be exported as RDF. This resembles simply mapping the JSON tree document to a corresponding tree (RDF graph) of RDF resources. However, to actually export the knowledge encoded in a Connected JSON graph, is often more interesting. This specification does not define an RDF Export, just an RDF Interpretation.

2. Base URI

The graph/baseUri is used to map nodes and edges to RDF. The baseUri is defined like in HTML as "the absolute base URL of the document containing the node." The default value is the local file path using the file:// scheme, with URL-encoding, where required.

3. Node URI

Each node id is URL-escaped and then appended to the base URI to form a unique, valid node uri. Similarly, the edge id is appended to the base URI to form a unique edge uri. Ports are ignored in RDF.

4. Edge Types

The type of an edge can be stated at the edge level and/or at the endpoint level. For bi-edges the edge level works fine and has a clear interpretation, even as RDF. However, an n-ary edge cannot always be interpreted as RDF. I.e., the hyper-edge itself is not mapped to triples, but the induced bi-edges are.

The edge type (edge.type, edge.typeNode, edge.typeUri) defines a value for each endpoint. It can be overwritten in each endpoint (endpoint.type, endpoint.typeNode, endpoint.typeUri).

Algorithm for Interpreting a (Hyper-)Edge as RDF Triples

Compute the effective endpoint type by
- Compute the edge type (resolve edge.type, edge.typeNode and edge.typeUri into a single type using precedence rules.
- Compute the endpoint type (is any of endpoint.type, endpoint.typeNode, endpoint.typeUri given?).
- Combine into a single, effective endpoint type.
Process each pair of endpoints (A,B):
- Sort pair into first and second, by
- If typeUri is empty and typeNode is given, then set typeUri to the node URI of the node, referenced in typeNode.
- For each typeUri in the pair generate an RDF triple from in to out:
  
  If in.typeUri is present, generate
  (in.node, in.typeUri, out.node).
  
  If out.typeUri is present, generate
  (in.node, out.typeUri, out.node).

Table 1. Mapping of Endpoint Pair
Input		Resulting RDF Order
A	B	Subject	Object
`in`	`in`	Skip
`in`	`out`	A	B
`in`	`undir`	A	B
`out`	`in`	B	A
`out`	`out`	Skip
`out`	`undir`	B	A
`undir`	`in`	B	A
`undir`	`out`	A	B
`undir`	`undir`	A	B

5. Examples

Example: Bi-Edge with One Type

{
  "source": "n12",
  "target": "n17",
  "endpoints": [
    { "node": "n12",
      "direction": "in"  },
    { "node": "n17",
      "direction": "out",
      "typeUri": "https://example.org/worksAt" }
  ]
}

interpretation as RDF (Turtle Syntax)

@prefix ex: <https://example.org/> .
ex:n12 ex:worksAt ex:n17 .

The following example uses source/target and endpoints, which is allowed but uncommon. The endpoints stated using source/target have no endpoint types defined.

Example: Hyper-Edge

{
  "id": "sale123",
  "source": ["n12","n3","n123"],
  "target": ["n17","n100"],
  "endpoints": [
    { "node": "n100", "direction": "in",
      "typeUri": "https://example.org/sells" },
    { "node": "n12",  "direction": "in",
      "typeUri": "https://example.org/buys" },
    { "node": "n3",   "direction": "undir"  },
    { "node": "item-1",  "direction": "out" }
  ]
}

interpretation as RDF (Turtle Syntax)

@prefix ex: <https://example.org/> .
ex:n100 ex:sells ex:item-1 .
ex:n12  ex:buys  ex:item-1 .