From W3C Wiki
Jump to: navigation, search

This is a WebSchemas proposal additionalTypeProposal for schema.org. See Proposals listing for more. Status: Published

This WebSchemas page discusses a proposal to add an 'additionalType' (or 'type') property to schema.org. This goes back to an earlier proposal made in October 2011 on the public-html-data-tf@w3.org mailing list.

The 'additionalType' property was added to the Thing type on 2012-07-17 (schema version 0.96). The remainder of this page is retained as background notes.


  • This page proposes the addition of a property 'additionalType' to schema.org.
  • it means the same thing as 'rdf:type', and is used in syntaxes like Microdata where built-in typing syntax does not allow extra types to be listed.

public-vocabs discussion

Discussion of additionalType proposal

This is not representative or a complete summary, but should give some quick overview of people's positions.

  • R.V.Guha - "My personal preference is to just add an attribute called type (or additionalType) which is samePropertyAs rdfs:type and be done with it."
  • Ivan Herman - "As a a consequence, I think that having that additionalType stuff be part of schema makes sense, but this also means that schema-aware tools that use RDF vocabularies should know that this is a synonym to rdf:type. Which is not a nice design but, that being said, this may be to only way ahead for microdata users.
  • Gregg Kellogg - could add some rules to the microdata/rdf mapping about multiple types, 'Not that I would recommend that anyone do this against the requirements of Microdata.'
  • Martin Hepp - "So adding "type" or "additionalType" property to http://schema.org/Thing seems like a quick, pragmatic yet future-prone approach to me.
  • Peter Mika - "My main concern is that schema.org is and should be about the schema, not the syntax. The reason of adding this property is to patch microdata, but if schema.org defines this term, it will be available for all syntaxes (microdata, RDFa, possibly soon OData). In both microdata and RDFa, we would end up with two ways of defining types (using typeof/itemtype vs. additionalType). Standard parsers however will only see one type (the one expressed using the standard mechanism).
  • Egor Antonov - "Agreed with Peter. "additionalType" is not a part of the (ontology) schema, but a hack for microdata.", "It's just a superset of microdata features, and it can be implemented in a prettier way than "additionalType" property IMHO"
  • Adrian Giurca - "Indeed, it would be enough to allow a list of URLs as value of Microdata @itemtype"
  • Jason Douglas - "That's not just a token list... it's an ordered token list. You're privileging the first token as the "frame" as Martin calls it."
  • Evan Sandhaus - "ideal solution would be to extend Microdata Syntax to allow for multiple types, ... the need for web publishers to associate multiple types with their metadata is sufficiently urgent that the sponsors of schema.org would be completely justified in introducing an 'additionalType' property."
  • Dan Brickley - [ after Microdata DOM investigations], "I just don't think it's feasible, so let's try to do the best we can with 'additionalType'."
  • Alexander Botero-Lowry - (on Dan's proposal), "I think this is OK but we need to be explicit that for this to work the primary type (itemtype) needs to be a part of schema.org or the additionalType predicate needs to be fully qualified."
  • Stephane Corlosquet - "I'd like to see some markup example of what this discussion would lead to."
  • James M Snell - "Activity Streams (AS) has it's own basic type model (and "objectType" property whose value is either a simple label representing known types or an absolute IRI to identify types from other vocabularies. Having a "type" property in the schema.org vocabulary would help us tremendously in bridging the AS model into the schema.org realm. I'd certainly be in favor of introducing it. ("additionalType" works too)."


The core of the discussion is whether we use Microdata's 'itemtype' attribute and add space-separated values to it. Microdata already allows this to be a list of types from the same vocabulary, but does not permit them to be from multiple vocabularies. It also exposes this information in the Microdata DOM API.

Using 'additionalType' property:

  1. <div itemscope itemtype="http://schema.org/Product">
  2.    <link itemprop="additionalType" href="http://www.productontology.org/id/Fire_extinguisher" />
  3.    <span itemprop="name">.. a short name for the object ...</span>
  4.    Product description:
  5.    <span itemprop="description">... a longer description ...</span>
  6.    <div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
  7.        <span itemprop="price">$19.99</span>
  8.        <link itemprop="availability" href="http://schema.org/InStock"/>In stock
  9.    </div>
  10. </div>

Using Microdata itemtype attribute as a list:

(note that this is not good syntax, but only shows a potential design that was under discussion; do not copy this markup!)

  1. <div itemscope itemtype="http://schema.org/Product http://www.productontology.org/id/Fire_extinguisher">
  2.    <span itemprop="name">.. a short name for the object ...</span>
  3.    Product description:
  4.    <span itemprop="description">... a longer description ...</span>
  5.    <div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
  6.        <span itemprop="price">$19.99</span>
  7.        <link itemprop="availability" href="http://schema.org/InStock"/>In stock
  8.    </div>
  9. </div>


Changes to http://schema.org/Thing

The proposal is to add a new property named 'additionalType to http://schema.org/Thing. The description of the property should be

  • additionalType: The URL of an additional type for the item, typically used for adding more specific types from external vocabularies in microdata syntax. In RDFa syntax, it is better to use the native RDFa syntax for multiple types. Schema.org tools may have only weaker understanding of extra types, in particular those defined externally.

Changes to http://schema.org/docs/datamodel.html

Insert a section: Handling of Multiple Types

schema.org provides the property additionalType for all http://schema.org/Thing and all subtypes. From an RDF perspective, this property is equivalent to rdf:type. When consuming schema.org markup in microdata syntax, one should include the following mapping axiom:

# Prefixes
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix schema: <http://schema.org/> .

# Mapping of schema:additionalType to rdf:type
schema:additionalType rdfs:subPropertyOf rdf:type .

# One could also use the stronger owl:equivalentProperty predicate, but that has unintended side-effects raised by Ivan Herman
# @prefix owl: <http://www.w3.org/2002/07/owl#> .
# schema:additionalType owl:equivalentProperty rdf:type .

Changes to the RDFa and OWL/RDF+XML Versions

The two versions of schema.org at


should include the triple

schema:additionalType rdfs:subPropertyOf rdf:type .

Original Materials

Proposal is...

  • Property: additionalType
  • samePropertyAs: rdf:type
  • description: "An alias for the rdf:type relationship between something

and a class that the thing is in. It is generally preferable to use syntax-native typing mechanisms. The additionalType construct can be useful in constrained syntaxes - e.g. microdata - where multiple types from independent vocabularies cannot be easily expressed. In such situations, care should be taken to assign the most relevant schema.org type using the primary (e.g. 'itemtype') typing syntax. Schema.org tools may have only weaker understanding of extra types, in particular those defined externally."


  • we need to be explicit that for this to work the primary type (itemtype) needs to be a part of schema.org or the additionalType predicate needs to be fully qualified.
  • unlike the itemtype attribute which can contain multiple types, only one type can be defined at a time in each additionalType element. When specifying multiple additionalTypes for a data item, add an element for each additional type.