The goal of this article is to show a part of what JSON-LD structured data to build a foundation for learning all of it. The focus is to introduce two parts of structured data called the structured data Type and the Property.
Structured data code is a language with logical structure. By understanding the different parts you can begin to understand that language. It’s easier than it looks!
Once you finish this article you will have a better understanding of structured data and can begin to understand the code.
You will also be better able to take advantage of the ranking opportunities that structured data offers.
In my previous article (What is Structured Data) I outlined the basics of structured data that explains what structured data is.
If you haven’t read that article yet, I encourage you to read it to get an understanding of what structured data is, who is responsible for it and how Google uses it for your benefit.
About JSON-LD Structured Data
There are others ways to communicate structured data but JSON-LD is Google’s preferred version. It’s easier to understand, too.
How Structured Data is Organized
Structured data is basically information (data) that is presented in an organized manner (structured).
When you think about structured data, just remember that it’s nothing more complicated than information that is presented in an organized way.
Two Structured Data Terms You Need to Know
There are many technical terms used in Schema.org structured data. But there are two that are important to understand first because they are the basic building blocks of structured data.
Two fundamental terms to know are:
A Schema structured data is about a (data) Type and can contain more than one Type within the JSON-LD structured data script.
Each Type has Properties that are associated with each Type.
The Type can be thought of as a thing and the Property can be thought of as attributes of that thing that describe what that thing is.
As an analogy, let’s think of a Type as being a person.
That person may have attributes associated with them like their educational level, address, their job status, etc.
The person in the above analogy is the Type. The attributes of that person (education level, etc.) are the Properties associated with that Type.
So when you see the phrase Structured Data Type, you can know that it’s the main topic or thing of what the structured data is about.
Structured Data Type and Case
Taking a look at the above examples of structured data types, it’s evident that there is a capitalization structure to it.
The first letter of each word in a structured data type is capitalized.
That’s called PascalCase.
PascalCase is a way of naming things by using compound words (where two words are joined together) and capitalizing the first letter of each word.
So when you’re looking at a JSON-LD structured data script and you see something spelled in PascalCase (like NewsArticle), you can know that it is a structured data Type.
Examples of structured data types showing the PascalCase:
What is a Structured Data Property?
The definition of a structured data Property, according to Schema.org is:
“A property, used to indicate attributes and relationships of some Thing…”
When we talk about Type we are generally talking about a thing. That said, a service can be a type.
The way we describe a Type is by it’s attributes and relationships, which is called a Property.
Going back to the analogy of a person as a Type, we can describe a person by their attributes like the person’s educational status, job, address and so on.
In structured data, those “attributes” are called a structured data Property.
A property describes an attribute of a Type or a relationship of the Type with something else. The Property describes or gives information about the Type.
Structured Data Property and Case
Structured data Types are spelled with PascalCase. A structured data Property is spelled differently.
When the Property is a compound word (two words joined together) the first letter in the first word is lower case and the first letter in the second word is upper case.
This way of spelling compound words is called camelCase.
When the structured data Property is just one word, then the first letter of the word is still spelled in lower case.
Illustration showing PascalCase and camelCase in Structured Data
Here’s an example of a two-word compound Property:
This is an example of a single-word Property:
Example of a JSON-LD Structured Data Script
Let’s take a look at an example of a News Article structured data script.
In the example below we see two items are types, using the code, “@type”:
The colon : is a part of the code and it means that everything that follows is what that Type is.
In the example, the first type is written like this:
That script is saying, the following is a type, indicated by the code @type and the colon which indicates that what follows is the type. In this case, the type is NewsArticle.
Here’s the script:
In the above script you will see that there is a comma. That means that there is more data coming. It’s like a list where you say that there is this, this, this and that.
We’ll get into the commas and brackets in the next article. I just wanted to point that out to explain what it is.
A few lines down you’ll see that there’s another type that is labeled, Organization. The interesting thing about this Type is that it is a single word.
Even though it’s a single word and not a compound word (two words joined together), the first letter is still capitalized.
Beneath the declaration that this is an object (“@type”:”Organization”,) you’ll see that there is a property.
That property is a single word and the first letter of that word is spelled in lower case, like this: “name“:”BBC News”,
Let’s take a look at the script again, focusing on the section for the publisher property.
Here’s the section:
Publisher (publisher) is a property of the NewsArticle type. So it’s spelled in lower case like this: publisher.
But the type of publisher is a Type, which is an Organization.
The Organization Type has a name and it’s the BBC News. The Organization also has a logo.
Understanding Structured Data Type and Property
If you have gotten this far you now know two important parts of a JSON-LD structured data and a little bit of how they are organized within the structured data script.
If you’d like to explore and learn more about structured data, you may be ready to review the different Schema.org types.
Here is a partial list of ten generic types called Parent Types. Each generic parent type can be clicked through to more specific types.
At this time there are a total 841 Types, 1,369 Properties.
For example, the hierarchical order for the WebSite type is:
That means you can start at the Schema.org page for Thing here: https://schema.org/Thing
Then click through to the WebSite Type page here: https://schema.org/WebSite
On that page you can find examples of what that structured data can look like.
Additionally, you can download a Chrome extension called Schema Builder from Schema.dev and use that to build structured data by filling out a form.
By reviewing the Schema.org structured data and using the Schema Builder Chrome plugin you will be able to get a feel for the different kinds of structured data there are and begin understanding JSON-LD structured data.
The next article will good deeper into discussing the code used for structured data. After that you should have a significantly better understanding of structured data code.