Part V: The Next Web
Chapter 15
#The Web as data: things should have addresses too
Portability is not interoperability.
Portability means that data can leave one application. Interoperability means that another application can understand and use it without a special translator written for those exact two systems.
JSON is never just JSON. It is portable and can carry almost any kind of data, but it does not tell another program what the names inside it mean.
That is not an accidental omission. JSON is infrastructure, and almost aggressively small. It has objects, arrays, strings, numbers, booleans and null. That is nearly the whole spell.
Its smallness helped it spread. It also made JSON difficult to extend. When people need identity, dates, references, types or shared vocabularies, they make another format or hide another language inside the familiar one.
A contacts app, calendar app and photo app may all know something about the same person. Unless their names line up, the data still lives in separate little rooms.
#The private-name problem
Imagine two systems store the same fact.
The contacts app says:
person-17 | city | ManchesterThe calendar app says:
attendee-4 | addressLocality | ManchesterBoth records have the same rough shape. Something has a property with a value, but the names are private.
person-17 only means something inside the contacts app. attendee-4 only means something inside the calendar app. They may both refer to Hilda, but nothing in either identifier says so.
The properties have the same problem. One application says city. Another says town. Another says addressLocality. Another says municipality, because someone had a meeting.
Inside one application, private names are fine. You control the dictionary. But when you cross a border, a boundary, each private name needs a translator. Every import script has to learn both sides. When either side changes, the bridge changes too.
What if names inside the data could cross the same boundaries as documents?
#Names that can travel
The Web already gave documents addresses.
https://solid.muze.nl/example/data/people/hilda.htmlhttps://www.w3.org/DesignIssues/LinkedData.html Linked data extends that trick: https://www.w3.org/DesignIssues/LinkedData.html
Things can have Web addresses too.
Hilda can have an identifier:
https://solid.muze.nl/example/data/hilda-ogdenManchester can have one:
https://solid.muze.nl/example/data/manchester
The relationship lives in can have one:
https://solid.muze.nl/example/ns/livesInNow the fact can be written as three pieces:
subject predicate object
Hilda lives in ManchesterOr with Web names:
https://solid.muze.nl/example/data/hilda-ogden
https://solid.muze.nl/example/ns/livesIn
https://solid.muze.nl/example/data/manchesterThis is not pretty. It is meant to be unambiguous and able to cross boundaries.
https://www.w3.org/TR/rdf11-concepts/ The Resource Description Framework, RDF, gives this shape a formal name: a subject-predicate-object triple. Many triples together form a graph. https://www.w3.org/TR/rdf11-concepts/
In less specification-shaped language: RDF lets you write small facts that can join other small facts.
https://www.w3.org/TR/turtle/ Here is the same data in a friendlier syntax, Turtle: https://www.w3.org/TR/turtle/
@prefix data: <https://solid.muze.nl/example/data/> .
@prefix ns: <https://solid.muze.nl/example/ns/> .
data:hilda-ogden
ns:firstName "Hilda" ;
ns:lastName "Ogden" ;
ns:livesIn data:manchester ;
ns:knows data:stan-ogden .https://www.w3.org/TR/json-ld11/ RDF is a model for the data, not one particular spelling. Turtle is one spelling. JSON-LD is another. https://www.w3.org/TR/json-ld11/
JSON-LD takes a slightly strange route. It keeps the familiar JSON shape, then gives names such as @id and @context an extra job. They say which values identify things and where the meanings of other names come from. JSON remains unchanged underneath. A more expressive language stands on top of it.
Breaking knowledge into small statements is not new. Databases and logic languages have done versions of it for a long time.
The Web contribution is that the names inside those statements can be Web names.
#A graph without a centre
A table usually has a home. It lives in a database, under one schema, inside one system.
Together, triples form a different shape: a graph. A graph can be assembled from facts written in different places.
I can say something about Hilda in an address book. You can say something about Hilda in a calendar invitation. A photo archive can say that Hilda appears in a picture.
None of us has to own the complete record.
# In a contacts document
data:hilda-ogden ns:phoneNumber "+44 ..." .
# In a calendar document
data:meeting-123 ns:attendee data:hilda-ogden .
# In a photo document
data:photo-7 ns:depicts data:hilda-ogden .If the names line up, software can follow them.
This is where linked data gets its name. The data is not only structured. It points. A fact can point to a thing, which can lead to more facts somewhere else.
Tim Berners-Lee described linked data with deliberately simple rules: use URIs as names for things, use HTTP URIs so they can be looked up, provide useful information when they are looked up, and include links to other URIs.
This is the URL chapter returning in another costume.
A URL lets one document point outside itself. Linked data lets one fact point outside itself.
#Meaning needs names too
Giving Hilda an identifier is not enough. The properties need identities too.
If I write:
data:hilda-ogden ns:knows data:stan-ogden .
what does knows mean?
Met once? Friends with? Can recognise in a police lineup? Has a phone number for? Once shared a tram in Manchester?
A word that looks obvious to a human may be vague to software. It may even be obvious in two different ways to two different humans.
This is where your eyes may start to gloss over. Vocabularies, ontologies, IRIs. This all sounds abstract and academic, and it is. It's also necessary and powerful.
When independent tools recognise the same names for the same kinds of facts, they can work on those facts independently. But the only way to get there is for people to agree, enough, about what each name means. The problem is that shared meaning is social work pretending to be technical work.
Linked data is not fairy dust. You can make a knitted castle out of triples. You can invent private vocabularies nobody else understands. You can create a vocabulary so elaborate that a simple fact needs an expedition.
A format will not solve all these problems. What matters is that names and meanings can survive the application that first used them.
#What linked data does not solve
Linked data lets applications work with the same meanings, but the data can still be trapped behind a locked gate. It does not decide where data lives, who owns the storage, or who may read or change it.
A company can keep RDF in a private database. A locked service can offer a Turtle export button.
We need both boundaries, but they are not the same.
#The boundary moves again
Back in the knitted castle, the useful question was not whether something could be reused, but in what direction. A file format can be reused by programs that do not share code. A protocol lets different systems meet and then go their separate ways again.
Linked data moves that boundary further.
Two applications do not need to share code if they can recognise the same things, use the same names and work with the same data. A contacts application can describe a person. A calendar can invite that person. A photo tool can say that the person appears in a picture.
The shared part is not hidden inside either program. It is in the names and data they agree to use.
Linked data gives names somewhere to meet. It lets work done by one application become useful to another that was written independently.
If the meaning can live outside the application, why should the application own the only copy of the data?
Where should a person’s data live?