JSON-LD RDF API describes access methods for transforming and abstract RDF represention into JSON-LD and back..
This document is an experimental work in progress.
This document is a detailed specification for Linked Data in JSON. The document is primarily intended for the following audiences:
To understand the basics in this specification you must first be familiar with JSON, which is detailed in [[!RFC4627]]. You must also understand the JSON-LD Syntax [[!JSON-LD]], which is the base syntax used by all of the algorithms in this document, and the JSON-LD API [[!JSON-LD-API]]. To understand the API and how it is intended to operate in a programming environment, it is useful to have working knowledge of the JavaScript programming language [[ECMA-262]] and WebIDL [[!WEBIDL]]. To understand how JSON-LD maps to RDF, it is helpful to be familiar with the basic RDF concepts [[!RDF-CONCEPTS]].
The intent of the Working Group and the Editors of this specification is to eventually align terminology used in this document with the terminology used in the RDF Concepts document to the extent to which it makes sense to do so. In general, if there is an analogue to terminology used in this document in the RDF Concepts document, the preference is to use the terminology in the RDF Concepts document.
The following is an explanation of the general terminology used in this document:
@value
, @list
,
or @set
keywords, or@graph
keyword and is
the top-most _:
.There are a number of ways that one may participate in the development of this specification:
This API extends the API defined in [[!JSON-LD-API]]. It is inprovides a clean mechanism that enables developers to convert JSON-LD data to various RDF formats to allow greater interoperability with Linked Data applications. If a JSON-LD API with the RDF extension is provided in a programming environment, the entirety of the following API MUST be implemented.
The JSON-LD processor interface is the high-level programming structure that developers use to access the JSON-LD transformation methods.
The JSON-LD API signatures are the same across all programming languages. Due
to the fact that asynchronous programming is uncommon in certain languages, developers MAY
implement a processor with a synchronous interface instead. In that case, the callback
parameter MUST NOT be included and the result MUST be returned as a return value instead.
input
.notType
,
which if set to rdf:type
as a property, instead of @type
.input
according to the
Convert to RDF Algorithm
defined in [[!JSON-LD-API]], calling
the provided callback
for each input
has been converted
to @context
.
For example, if a @type
key maps to anything other than
@id
or an Developers should note that the details of error handling and conformance handling are being actively debated.
JSON-LD processors utilize a variety of callbacks in order to return information in an asynchronous manner to calling applications. This section details the parameters sent to those callbacks as well as the desired operation of the callbacks.
The QuadCallback is called whenever the processor generates a quad during processing.
null
, then no error occurred. If
the value is non-null
, a processing error occurred
and the details will be contained within the error
object.
The following data structures are used for representing data about RDF quads. They are used for normalization, and RDF conversion.
The IRI datatype represents an
The Quad interface represents an RDF Quad. An RDF Quad is an
RDF triple
[[!RDF-CONCEPTS]] with an optional fourth element, the graph name, being a
A
A _:
and an implementation dependent,
auto-generated suffix that is unique to all information associated with the
particular
identifier
MUST NOT be relied upon in any way between two
separate processing runs of the same document or with a different document.Developers and authors must not assume that the
value of a
Implementers MUST ensure that BlankNode values are unique
within the current environment, two
Literals represent values such as numbers, dates and strings in
RDF data. A
value
language
tagdatatype
specified by an Literals representing plain text in a natural language may have a
language
tag specified by a string token, as specified in
[[!BCP47]], normalized to lowercase
(e.g., 'en'
, 'fr'
, 'en-gb'
).
They also have a datatype attribute such as xsd:string
.
If unspecified, the datatype
defaults to xsd:string
.
Literals representing values with a specific datatype, such as
the integer 72, may have a datatype
attribute specified in the form
of a IRI (e.g.,
xsd:integer
).
See[[!RDF-CONCEPTS]] definition for literal.