Do you have a list of terms relevant to your data?
Things such as subjects, topics, job titles, a glossary or dictionary of terms, blog post categories, ‘official names’ for things/people/organisations, material types, forms of technology, etc., etc.
Until now these have been difficult to describe in Schema.org. You either had to mark them up as a Thing with a name property, or as a well known Text value.
The latest release of Schema.org (3.4) includes two new Types – DefinedTerm and DefinedTermSet – to make life easier in this area.
The best way to describe potential applications of these very useful types is with an example:
Imagine you are an organisation that promotes and provides solid fuel technology….
In product descriptions and articles you endlessly reference solid fuel types such as “Coal”, “Biomass”, “Peat”, “Coke”, etc. For the structured of your data, in product descriptions or article subjects, these terms have important semantic value, so you want to pick them out in your structured data descriptions that you give the search engines.
Using the new Schema.org types, it could look something like this:
"@context": "http://schema.org",
"@graph": [
{
"@type": "DefinedTerm",
"@id": "http://hotexample.com/terms/sf1",
"name": "Coal",
"inDefinedTermSet": "http://hotexample.com/terms"
},
{
"@type": "DefinedTerm",
"@id": "http://hotexample.com/terms/sf2",
"name": "Coke",
"inDefinedTermSet": "http://hotexample.com/terms"
},
{
"@type": "DefinedTerm",
"@id": "http://hotexample.com/terms/sf3",
"name": "Biomass",
"inDefinedTermSet": "http://hotexample.com/terms"
},
{
"@type": "DefinedTerm",
"@id": "http://hotexample.com/terms/sf4",
"name": "Peat",
"inDefinedTermSet": "http://hotexample.com/terms"
},
{
"@type": "DefinedTermSet",
"@id": "http://hotexample.com/terms",
"name": "Solid Fuel Terms"
}
]
}
As DefinedTermSet is a subtype of CreativeWork, it therefore provides many properties to describe the creator, datePublished, license, etc. of the set of terms.
Adding other standard properties could enhance individual term definitions with fuller descriptions, links to other representations of the same thing, and short codes.
For example:
{
"@type": "DefinedTerm",
"@id": "http://hotexample.com/terms/sf1",
"name": "Coal",
"description": "A combustible black or brownish-black sedimentary rock",
"termCode": "SFT1",
"sameAs": "https://en.wikipedia.org/wiki/Coal",
"inDefinedTermSet": "http://hotexample.com/terms"
}
There are several other examples to be found on the type definition pages in Schema.org.
For those looking for ways to categorise things, with category codes and the like, take a look at the subtypes of these new Types – CategoryCode and CategoryCodeSet.
The potential uses of this are endless, it will be great to see how it gets adopted.
Two issues. 1) there’s an error in you JSON-LD (a trailing comma). 2) GSDTT does not yet process @DefinedTerm. Any idea when it will be recognized by Google SDTT?
Thanks for spotting the trailing comma – now fixed.
The 3.4 release of Schema.org is only currently a few days old. I cannot speak for Google, or any of the other major consumers of Schema.org. However, it is usually a few weeks before they start to recognise updates in the vocabulary, either in their interpretation of data or in their public testing tools.
This is interesting, but why did they not provide support for skos in schema.org? Now we have a another vocabulary standard.
An excellent question Henk!
Since the early days of Schema.org there have been several “why don’t you support / integrate this or that ontology / vocabulary” debates on the lists.
Two well, and often, one debated have been FRBR and SKOS.
The style depth and associated baggage that such full adoption would bring to the Schema.org vocabulary, and the potential unintended consequences in complexity etc, for the target adopters, I believe were the main reasons for these debates to die out without concrete action.
There was another attempt in 2013 to introduce a miniSKOS by introducing a Topic type which would have been an equivalent Class to skos:Concept, but that also went nowhere – there is an understandable reticence to tie Schema types to classes in other vocabularies.
The introduction of DefinedTerm and the associated CategoryCode was an initiative from myself to satisfy the needs of those that have lists of terms/concepts/etc. that they want to share on the web (without having to share all the management stuff that often comes with SKOS – or get their head around SKOS in the first place).
The presumption being that if you need SKOS to organise all your knowledge, you will already have it, and adding a very thin layer of Schema.org on top will make it widely sharable.
This is the same pattern as for all domains – manage your data with the ontology/vocabulary most appropriate for your domain, then add some Schema.org to make it generically consumable across all domains via a web presence.
That’s the short answer, I’m more than pleased we got DefinedTerm into the vocabulary to at least satisfy a need. I am interested to see the many and varied ways it will be adopted.
~Richard
What would be the best use of “DefinedTerm”? For example in an “article”?
In a sense are you creating your own vocabulary for that post? How does that differ than using “about” and including wikipedia URL’s to the term definitions.
The best description I can find is in the the type description:
“A word, name, acronym, phrase, etc. with a formal definition. Often used in the context of category or subject… ”
So I would see it used in the context of an article for instance, as the value of a subject:
“about”: {
“@type”: “DefinedTerm:,
“@id”: “http://example.org/Sub/1”,
“name”: “The Subject”,
“sameAs”: “http://wikidata.org/….”,
}
Yes you are correct that you are creating and/or referencing your/another vocabulary. This really comes into play when you/others start reusing these terms across pages/sites.
A good example of this would be to define the categories/tags on a blog as DefinedTerms (on the category page(s)), referencing them to global equivalents, such as wikidata etc, and from each post.