JSON-LD for software discovery, reuse and credit by Afron Smith.
From the post:
JSON-LD is a way of describing data with additional context (or semantics if you like) so that for a JSON record like this:
{ "name" : "Arfon" }when there’s an entity called name you know that it means the name of a person and not a place.
If you haven’t heard of JSON-LD then there are some great resources here and an excellent short screencast on YouTube here.
One of the reasons JSON-LD is particularly exciting is that it’s a lightweight way of organising JSON-formatted data and giving semantic meaning without having to care about things like RDF data models, XML and the (note the capitals) Semantic Web. Being much more succinct than XML and JavaScript native, JSON has over the past few years become the way to expose data through a web-based API. JSON-LD offers a way for API provides (and consumers) to share data more easily with little or no ambiguity about what the data they’re describing.
The YouTube video “What is JSON-LD?” by Manu Sporny makes an interesting point about the “ambiguity problem,” that is do you mean by “name” what I mean by “name” as a property?
At about time mark 5:36, Manu addresses the “ambiguity problem.”
The resolution of the ambiguity is to use a hyperlink as an identifier, the implication being that if we use the same identifier, we are talking about the same thing. (That isn’t true in real life, cf. the many meanings of owl:sameAS, but for simplicity sake, let’s leave that to one side.)
OK, what is the difference in both of us using the string “name” and both of us using the string “http://ex.com/name”? Both of them are opaque strings that either match or don’t. This just kicks the semantic can a little bit further down the road.
Let me use a better example from json-ld.org:
{
"@context": "http://json-ld.org/contexts/person.jsonld",
"@id": "http://dbpedia.org/resource/John_Lennon",
"name": "John Lennon",
"born": "1940-10-09",
"spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
If you follow http://json-ld.org/contexts/person.jsonld you will obtain a 2.4k JSON-LD file that contains (in part):
“Person”: “http://xmlns.com/foaf/0.1/Person“
Following that link results in a webpage that reads in part:
The Person class represents people. Something is a Person if it is a person. We don’t nitpic about whether they’re alive, dead, real, or imaginary. The Person class is a sub-class of the Agent class, since all people are considered ‘agents’ in FOAF.
and it is said to be:
Disjoint With: Project Organization
Ambiguity jumps back to the fore with: Something is a Person if it is a person.
What is that solipsism? Tautology?
There is no opportunity to say what properties are necessary to qualify as a “person” in the sense defined FOAF.
You may think that is nit-picking but without the ability to designate properties required to be a “person,” it isn’t possible to talk about U.S.C Title 42: 1983 civil rights actions where municipalities are held to be “persons” within the meaning of this law. That’s just one example. There are numerous variations on “person” for legal purposes.
You could argue that JSON-LD is for superficial or bubble-gum semantics but it is too useful a syntax for that fate.
Rather I would like to see JSON-LD to make ambiguity “manageable” by its users. True, you could define a “you know what I mean” document like FOAF, if that suits your purposes. On the other hand, you should be able to define required key/value pairs for any subject and for any key or value to extend an existing definition.
How far you need to go is on a case by case basis. For apps that display “AI” by tracking you and pushing more ads your way, FOAF may well be sufficient. For those of us with non-advertising driven interests, other diversions may await.
“You could argue that JSON-LD is for superficial or bubble-gum semantics but it is too useful a syntax for that fate. ”
It seems like a very useful syntax, but at the same time, having recently gotten up to speed on it myself, I’m finding it frustratingly limited. From what I can tell, it seems to expect a 1:1 mapping between keys in a document and nodes in a model. I’ve encountered plenty of models, particularly those based on the Basic Formal Ontology, that break down even very basic concepts into small networks of nodes, and I haven’t figured out how to write a context for that yet. (I posted a question at answers.semanticweb.com on this subject just this afternoon, in fact.)
“On the other hand, you should be able to define required key/value pairs for any subject and for any key or value to extend an existing definition.”
I may be wrong, but I’m under the impression that defining required key/value pairs is part of what JSON Schema is for.
Comment by marijane — June 17, 2014 @ 12:59 am
marijane, sorry for the delayed posting!
What sort of answer did you get from answers.semanticweb.com?
Your right and what is more, the JSON-LD schema defines primitives. OK, but not if you need to map between primitives from another system.
Comment by Patrick Durusau — July 8, 2014 @ 7:06 am
No answer so far. 100 views, though. I am thinking I might need to raise it on the json-ld mailing list, or perhaps even their IRC channel.
Also, I’m not sure I was clear in the last sentence in my last comment, I was referring to http://json-schema.org, which is different from JSON-LD.
Comment by marijane — July 8, 2014 @ 12:55 pm