Turtle to JSON-LD

Hi, my name is Yulia. 

In this video we'll talk about JSON-LD, which is a common RDF syntax. We'll use an example from the previous two videos, so if you're looking for additional context, check them out by following the links in the description.

We now learned about Turtle syntax and used it to represent two Things, me and myCar, in our set of self-describing interlinked data. Let's translate Turtle into JSON-LD, and add the remaining Things in to complete this example.

JSON-LD stands for JSON-Linked Data, where JSON is JavaScript Object Notation, this is one of the common ways to represent data that is also commonly used by web developers.

Let's start with translating our triples from Turtle to JSON-LD. 

After setting up our JSON document with the open and closing curly braces, we can start on the first set of tiples pertaining to yulia. 

@prefix in Turtle becomes @context in JSON-LD. It can be a single item and then the value is a string, or it could be multiple contexts, in which case an object can list those out. For this example we'll only use one context, and that's https://schema.org/.

 "@context": "http://schema.org/",

There is also a reserved keyword for denoting a subject, and that is "@id". In this key:value pair the value becomes the URL of the Digital Me RDF document,

 "@id": "https://id.inrupt.com/yulia",

Then we have to state that this RDF statement is about a person. We know that in this Turtle expression both "a" and "schema:Person" represent URLs to different vocabularies. In JSON-LD @type is a reserved keyword for the same exact URL as "a" is in Turtle, stating that the subject is of a particular type.

We can then use the full URL for the Schema.org definition of Person. However, we did define https://schema.org/ as a context, so let's use it. 

Since we're only using one context, it's the default place where we'll look up the meaning of keys and values in this JSON-LD object. This means that we can use "Person" as the value, similar to how it works in Turtle, where using the prefix results in the combination of the prefix and the term from that vocabulary.

"@type": "Person",

Next is the first name. We know that Schema.org has a definition for that under the "givenName" entry. This means that we can use "givenName" as the key, making the predicate the combination of the context and the key, just like we did for "Person".

"givenName": "Yulia",

Now we're at the car junction, and we know to use "owns" as it will locate the existing Schema.org definition as predicate for this subject. 

Since we're using JSON, we can nest the car as an object using the "owns" property as our key. 

Since myCar is the subject in this JSON-object it requires @id to denote that it is another node in our data graph. So we use the URL for data pertaining to myCar. The type with @type is Car as defined by Schema.org, and the name Otto, with "name" also defined by Schema.org 

  "owns": {
      "@id": "https://id.inrupt.com/yulia#myCar",
      "@type": "Car",
      "name": "Otto"
  }

Now that Otto is taken care of, let's add another thing to this set of linked data nodes.

I have a friend who's name is Sonali who works for Company A with me. Again, we have a choice to add all of this information about Sonali to this existing RDF resource, or point to Sonali's RDF resource and get her information from there. We'll do a little bit of both. Let's start with the friend part and find a definition for it in Schema.org.

There is a definition of a relationship in Schema.org, called "knows", which means the most generic bi-directional social/work relation. 

Sonali is another node in our graph of data, meaning that she needs to be identified with an @id and a unique URL. We can represent this data by using definitions from Schema.org and stating that yulia knows someone named Sonali, who worksFor company A. Luckily for us "worksFor" is defined by Schema.org as well.

We could end our RDF, Linked Data and JSON-LD exploration here, but in reality we better fix this "Company A" business. There is no need to store this information about Sonali in the Digital Me RDF document, when Sonali should have her own Digital Profile with this same information.

Through her Digital Profile we can find out that she is a person, what her name is, and that she works at "Company A".

We will, however, add to my Digital Me file that I work at "Company A".

  "knows": {
      "@id": "https://id.inrupt.com/sonali",
      "givenName": "Sonali",
}
"worksFor": {"name": "company A"}
}

Similarly to Sonali, and me, "Company A" should have its own RDF resource that has relevant information about it as an organization, in which case its mention in the Digital Me resource should just contain its Digital Profile RDF URL with the @id key, and the rest of the information about that company can be gathered from the set of Linked Data resources pertaining to them.

  "worksFor": {
      "@id": "https://id.companyA.com/companyA"
}

Now we have an RDF document written in JSON-LD that represents this small set of interlinked nodes of data.

In the next set of videos we'll talk about the Web 3.0 technology that will enable us to use Linked Data standards, and do much more in order to help transform the siloed world of data that we live in today into a collaborative distributed web of data. 

For now, let's recap what we learned.

JSON-LD is a syntax to represent an RDF dataset. It blends JSON and RDF to produce data that can be used as plain JSON as well as JSON-LD.

JSON-LD has reserved words, some of which we discussed today.

• @context denotes the vocabularies and any shortcuts that are used in this resource.
• @id denotes the Thing or subject of a set of Triples.
• @type is the key word for denoting an RDF class, or category of something.

We also learned that terms from the chosen vocabulary or context are used just like prefixes are in Turtle. 

To learn more about JSON-LD check out the resources in the description.

Thank you for watching!