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
).
-
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 andtypeNode
is given, then settypeUri
to the node URI of the node, referenced intypeNode
. -
For each
typeUri
in the pair generate an RDF triple fromin
toout
:If in.typeUri is present, generate
(in.node, in.typeUri, out.node).If out.typeUri is present, generate
(in.node, out.typeUri, out.node).
-
Input |
Resulting RDF Order |
||
---|---|---|---|
A |
B |
Subject |
Object |
|
|
Skip |
|
|
|
A |
B |
|
|
A |
B |
|
|
B |
A |
|
|
Skip |
|
|
|
B |
A |
|
|
B |
A |
|
|
A |
B |
|
|
A |
B |
5. Examples
{
"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.
|
{
"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 .