Sporny pours napalm on my previous sources during this research.
Many W3C specifications are so cryptic that they require the sacrifice of your sanity and a secret W3C decoder ring to read. I never understood why these documents were so difficult to read, and after years of study on the matter, I think I found the answer. It turns out that most specification editors are just crap at writing.
… this Linked Data stuff didn’t have to seem so damn complicated.
RDF is a shitty data model. It doesn’t have native support for lists. LISTS for fuck’s sake! The key data structure that’s used by almost every programmer on this planet and RDF starts out by giving developers a big fat middle finger in that area.
When you chair standards groups that kick out “Semantic Web” standards, but even your company can’t stomach the technologies involved, something is wrong.
Wow. Shots fired.
I’m a Sporny fan at this point.
Manu links to:
Reading the JSON-LD Specification
Sporny wasn’t blowing smoke, this is the most implementation-oriented W3C / RFC / ANSI standard document I’ve ever read. I didn’t even know it could be like this. I’ve never read something so lucidly written, I’d always just assumed that this is how standards docs look.
- “Linked Data [LINKED-DATA] is a way to create a network of standards-based machine interpretable data across different documents and Web sites. It allows an application to start at one piece of Linked Data, and follow embedded links to other pieces of Linked Data that are hosted on different sites across the Web.”
- JSON-LD is a lightweight syntax to serialize Linked Data in JSON
- Since JSON-LD is 100% compatible with JSON, the large number of JSON parsers and libraries available today can be reused
- JSON-LD is designed to be usable directly as JSON, with no knowledge of RDF RDF11-CONCEPTS
- Developers only need to know JSON and two keywords (
@id)to use the basic functionality in JSON-LD.
The Really Important Things:
@context: Used to define the short-hand names that are used throughout a JSON-LD document. These short-hand names are called terms and help developers to express specific identifiers in a compact manner. The
@contextkeyword is described in detail in section 5.1 The Context.
@id: Used to uniquely identify things that are being described in the document with IRIs or blank node identifiers. This keyword is described in section 5.3 Node
- A context is used to map terms to IRIs. Terms are case sensitive and any valid string that is not a reserved JSON-LD keyword can be used as a term identifiers.
- Thus, to an existing JSON Object, we add a key called “
@context”. It provides the mapping to turn convenient keys typical to JSON into FQ IRIs typical of LD. Good idea! …OR you can refer to the context somewhere else on the internet by giving it an IRI.
- @id =~ “There’s a unique IRI in this somewhere”
@type: @id: Expect an IRI for the value, and it’s unique
- When a JSON object is associated with a term, it is called an expanded term definition.
- IRIs can be referenced relatively or absolutely
- An IRI is generated for the string value specified using @id or @type.
- In JSON-LD, a node is identified using the @id keyword…
- The type of a particular node can be specified using the @type keyword.
- In Linked Data, types are uniquely identified with an IRI. Multiple types can be expressed as well.
- Other features: (Section 6)
- Base IRI
- Default Vocabulary
- Compact URLs (
- Typed values may be expressed in JSON-LD in three ways:
- By utilizing the
@typekeyword when defining a term within an
- By utilizing a value object.
- By using a native JSON type such as number, true, or false.
- Types can be coerced
- ** OK this is phat: ** Ordinary JSON documents can be interpreted as JSON-LD by referencing a JSON-LD context document in an HTTP Link Header.
- Possible to combine external and local contexts
- Can also embed in script with type
Relationship to RDF
Algorithmic work can happen to create and serialize to classical formats e.g. TURTLE