According to the documentation (http://schema.org/Thing), the item type Thing cannot include a Place.
The users will be asked to add content that does not have a specific type, therefore everything falls back to Thing. So, suppose the following example. This is want I would like to have, but seems to be invalid. Is there a workaround to fix it?
<div itemscope itemtype="http://schema.org/Thing">
<span itemprop="name">Eiffel Tower</span>
<span itemprop="description">Sample description</span>
<div itemscope itemtype="http://schema.org/Place">
<div itemscope itemtype="http://schema.org/PostalAddress">
<span itemprop="streetAddress">Sample address</span>
</div>
</div>
</div>
Your example snippet is valid.
Simply nesting elements with itemscope/itemtype has no effect on the parsed Microdata. You have to use the itemprop attribute if you want to associate/relate the items.
So in your example, you have three items (Thing, Place, PostalAddress) which are not related in any way.
If your question is, "Has Thing a property which allows a value of Place?", the answer is no, there is no such property.
The best solution would be to have the user choose what "type" of thing they are submitting and map those to schema.org types.
E.g. if you had a drop-down list on the form they use to submit listing "CD", "Event", "Place", etc. and use the value from that form field to set the value of the main itemtype.
Related
I'd like to mark my list of acronyms/abbreviations in my glossary of my website with Schema.org (using Microdata).
Which type of Schema.org is the right one for that?
I can't find any related type in the full list on schema.org.
The type DefinedTerm (which is currently in Pending, so it’s subject to change) is suitable for a
word, name, acronym, phrase, etc. with a formal definition
In a glossary, you would use the name property for the term, and the description property for what the term stands for.
<p itemscope itemtype="https://schema.org/DefinedTerm">
<span itemprop="name">SO</span>:
<span itemprop="description">Stack Overflow</span>
</p>
Or with semantic markup:
<dl>
<div itemscope itemtype="https://schema.org/DefinedTerm">
<dt itemprop="name"><dfn><abbr>SO</abbr></dfn></dt>
<dd itemprop="description">Stack Overflow</dd>
</div>
</dl>
(For the whole glossary, you could use the type DefinedTermSet, and add each entry with the property inDefinedTermSet.)
I've found this type on Schema.org: ExerciseGym
It doesn't have any examples with it and I'm confused as to how to use it because it seems to inherit properties from other schemas. This one is more specific to the business so ideally I'd like to use it.
It says "properties from LocalBusiness". I have used LocalBusiness before, and it contains good examples. Should I combine LocalBusiness and ExerciseGym and Person as I would like to list the personal trainers of the gym as employee but it says employee is Person?
So is something like this the right way to do this:
<div class="contact" itemscope itemtype="http://schema.org/ExerciseGym https://schema.org/LocalBusiness https://schema.org/Person" itemprop="employee">
<div class"name" itemprop="name">John Doe Does</div>
...
</div>
A type "includes" all its parent types. An ExerciseGym is also a SportsActivityLocation, a LocalBusiness, an Organization, a Place, and a Thing.
So you don’t have to specify ExerciseGym and LocalBusiness, specifying ExerciseGym is sufficient.
If you specify Person in addition to ExerciseGym, you are conveying: There is something that is a person and a gym. This is of course not want you want to say. To add an employee, you need two separate items: the gym and the person. In Microdata, an item is created with the itemscope attribute.
Example with an ExerciseGym that has two employees:
<div itemscope itemtype="http://schema.org/ExerciseGym">
<div itemprop="employee" itemscope itemtype="http://schema.org/Person">
<span itemprop="name">John</span>
</div>
<div itemprop="employee" itemscope itemtype="http://schema.org/Person">
<span itemprop="name">Alice</span>
</div>
</div>
It's the first time that I use Schema.org and Microdata.
I have several web pages, each giving information about a company.
Let's say I have following short-info:
<div itemsope itemtype="http://schema.org/Organization">
Company Name: <span itemprop="name">MyCompany</span>
Address: <span itemprop="address">Teststrasse 21, CH-8002 Zurich</span>
Telephone: <span itemprop="telephone">+41792565050</span>
Investor Relations: <span ???>John Miller</span>
</div>
where ??? is a placeholder meaning I don't know what to place there.
Investor Relations always displays a name.
I could write:
<span itemprop="Person" itemscope itemytpe="contactPoint">
Is that correct? What if I also wanted to add http://schema.org/contactType to it?
As I am new to this, I am not sure what ca be nested and mixed together.
You must put the property first, properties always start with a lowercase letter and the property you want is contactPoint, so the code if you want to give no other details about John Miller would be:
<span itemprop="contactPoint">John Miller</span>
If you want to give more details about John Miller then you need to nest http://schema.org/Person inside your http://schema.org/Organization - and use itemprop for each property of the person, for example:
<span itemprop="contactPoint" itemscope itemtype=http://schema.org/"Person"><span itemprop="name">John Miller</span><br>
<span itemprop="jobTitle">Marketing Director</span> <span itemprop="telephone">212 5430543</span><br>
Both google's structured data testing tool and the structured data linter are useful if writing structured data and allow a trial-and-error approach.
I've been experimenting with Google Schema and I've looked at a few code generators and they vary in design. The link I'm using for info for these examples: http://schema.org/Book
1) When is it proper to use itemscope itemtype="someSchemeURL.org" or an actual href?
Example:
<div itemprop="author" itemscope itemtype="http://schema.org/Person">
or
<div itemprop="bookFormat" href="http://schema.org/bookFormatType">
The second example isn't even valid HTML since the href attribute isn't accepted on a div.
2) For the example above, is the first column always an itemprop and the second column always the itemscope itemtype?
3) If there is no itemscope itemtype specified, does the itemprop default to the parent itemscope itemtype?
Example:
<div itemscope itemtype="http://schema.org/Book">
<div class="book" itemprop="name"></div>
<div itemprop="author" itemscope itemtype="http://shema.org/Person">
<div class="author" itemprop="name"></div>
</div>
</div>
The .author class will result in the name attributed to "author"
The .book class will result in the name attributed to "book"
So this would mean that although multiple itemprop's have the same name, the itemprop always applies to the parent element, correct?
4) Where is it specified when to use meta, link, span, or div? Or is this left up to preference?
Example:
<div>
<meta itemprop="datePublished" content="2013-07-01">
Some text
</div>
<div>
Some text
<link itemprop="bookFormat" href="http://schema.org/bookFormatType">Ebook
</div>
The second example is invalid, I know, but it's an example from one of the code generators. That specific generator produces invalid code so I know not to use it, but where are they getting their idea to use a link tag (albeit incorrectly)?
These docs can answer almost all of your questions. Maybe you've already seen them but just in case.
Microdata Spec
Getting Started Tutorial at Schema.org
So answers for your questions in order they appear:
1.The first one is correct. The official microdata spec tells us
Microdata is most useful, though, when it is used in contexts where
other authors and readers are able to cooperate to make new uses of
the markup.
For this purpose, it is necessary to give each item a type, such as
"http://example.com/person", or "http://example.org/cat", or
"http://band.example.net/". Types are identified as URLs.
The type for an item is given as the value of an itemtype attribute on
the same element as the itemscope attribute.
Example
<section itemscope itemtype="http://example.org/animals#cat">
<h1 itemprop="name">Hedral</h1>
<p itemprop="desc">Hedral is a male american domestic
shorthair, with a fluffy black fur with white paws and belly.</p>
<img itemprop="img" src="hedral.jpeg" alt="" title="Hedral, age 18 months">
</section>
2.No. Itemprop is used to indicate property of some entity. Itemscope - entity scope. And itemtype - type of the entity. These are different tags with different meaning which can be used separately (at least in theory). What doc says:
At a high level, microdata consists of a group of name-value pairs.
The groups are called items, and each name-value pair is a property.
Items and properties are represented by regular elements.
To create an item, the itemscope attribute is used.
To add a property to an item, the itemprop attribute is used on one of
the item's descendants.
And examples
<div itemscope>
<p>My name is <span itemprop="name">Elizabeth</span>.</p>
</div>
<div itemscope>
<p>My name is <span itemprop="name">Daniel</span>.</p>
</div>
3.Even when itemscope itemtype are specified along with itemprop it is still property of the parent type. In this case this property is entity itself. And you're correct with your example: names will go to different entities. Here is what doc says about processing properties.
The property value of a name-value pair added by an element with an
itemprop attribute is as given for the first matching case in the
following list:
If the element also has an itemscope attribute The value is the item
created by the element.
If the element is a meta element The value is the value of the
element's content attribute, if any, or the empty string if there is
no such attribute.
If the element is an audio, embed, iframe, img, source, track, or
video element The value is the absolute URL that results from
resolving the value of the element's src attribute relative to the
element at the time the attribute is set, or the empty string if there
is no such attribute or if resolving it results in an error.
If the element is an a, area, or link element The value is the
absolute URL that results from resolving the value of the element's
href attribute relative to the element at the time the attribute is
set, or the empty string if there is no such attribute or if resolving
it results in an error.
If the element is an object element The value is the absolute URL that
results from resolving the value of the element's data attribute
relative to the element at the time the attribute is set, or the empty
string if there is no such attribute or if resolving it results in an
error.
If the element is a data element The value is the value of the
element's value attribute, if it has one, or the empty string
otherwise.
If the element is a time element The value is the element's datetime
value.
Otherwise The value is the element's textContent.
The URL property elements are the a, area, audio, embed, iframe, img,
link, object, source, track, and video elements.
4.Left up to preference. There is general advice from search engines - markup consumers
However, as a general rule, you should mark up only the content that
is visible to people who visit the web page and not content in hidden
div's or other hidden page elements.
Schema.org doc gives good overview when usage of hidden elements may make sense.
Many pages can be described using only the itemscope, itemtype, and
itemprop attributes (described in section 1) along with the types and
properties defined on schema.org (described in section 2). However,
sometimes an item property is difficult for a machine to understand
without additional disambiguation. This section describes how you can
provide machine-understandable versions of information when marking up
your pages.
Dates, times, and durations: use the time tag with
datetime
Enumerations and canonical references: use the link tag with
href
Missing/implicit information: use the meta tag with content.
Check this link for details.
While implementing schema.org markup for one of my cusomters online-shops I noticed a little difficulty. I think it's a missing option in the markup. Neighter offer nor aggregateOffer can handle this case correctly - although I think it is quite common.
One page for one product (let's say it's a body-lotion)
The body-lotion comes in 3 sizes, 100, 200 and 250ml
It basically has an internal productId (BL100, BL200 and BL250) for each size as well as a EAN (http://en.wikipedia.org/wiki/International_Article_Number_(EAN)) for each size.
How to buy: Go on the product page, chose your size, the price changes via javascript, click add to chart
Q: How can I markup ONE product with MULTIPLE sizes and MULTIPLE prices correctly?
Problems:
http://schema.org/Product suggests only ONE productID which is wrong for me. If I add three offers (http://schema.org/Offer), search engines might think, the pricing is totally weird because the same product has three different offers.
http://schema.org/AggregateOffer doesn't seem right to me eighter.
Thanks for your help.
I think the correct way to mark up this particular scenario is by nesting several Offers inside of a single Product. To add additional information to each Offer, use an IndividualProduct. I'm not 100% sure, but this seems to work well in the Google Structured Data Testing Tool.
It looks like schema.org is still being updated with new ways to markup your products. The schema.org project pulled in a lot of structure from the Good Relations e-commerce product vocabulary. See E-commerce SEO Using Schema.org Just Got A Lot More Granular for more information about the new vocabulary items.
Say we want to list information about Sumatra coffee beans for sale on a website. We want to sell two different sizes (12 oz. and 16 oz.) with different prices for each. However, both product sizes should have the same images ('tis just a coffee bean) and name. The structure will look something like:
Product (name, description, and image)
aggregateRating
Offer (price and priceCurrency)
IndividualProduct (sku and weight)
Offer (price and priceCurrency)
IndividualProduct (sku and weight)
Copy and paste the following into Google's Structured Data Testing Tool to see how Google will interpret the HTML.
jsFiddle display
<article class="product" itemscope itemtype="http://schema.org/Product">
<div class="images">
<a href="images/product.jpg">
<img alt="Sumatra Coffee Beans" itemprop="image" src="images/product.jpg">
</a>
</div>
<div class="content">
<header>
<h1 itemprop="name">Sumatra Coffee Beans</h1>
</header>
<div class="code">
<span class="label">Item Number:</span>
<span itemprop="productID">sumatra-coffee</span>
</div>
<div itemprop="description">
<p>Error 418</p>
</div>
<div class="reviews" itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating">
<div class="details">
Rated <span itemprop="ratingValue">4.5</span>/5
</div>
<div class="count">
(<span itemprop="reviewCount">9</span> reviews)
</div>
</div>
<div class="offer" itemprop="offers" itemscope itemtype="http://schema.org/Offer">
<div itemprop="itemOffered" itemscope itemtype="http://schema.org/IndividualProduct">
<span class="sku" itemprop="sku">scb-ov1</span>
– (<span itemprop="weight">12 oz.</span>)
</div>
<div class="price">$<span itemprop="price">14.99<span></div>
<meta content="USD" itemprop="priceCurrency">
</div>
<div class="offer" itemprop="offers" itemscope itemtype="http://schema.org/Offer">
<div itemprop="itemOffered" itemscope itemtype="http://schema.org/IndividualProduct">
<span class="sku" itemprop="sku">scb-ov2</span>
– (<span itemprop="weight">16 oz.</span>)
</div>
<div class="price">$<span itemprop="price">20.99</span></div>
<meta content="USD" itemprop="priceCurrency">
</div>
</div>
</article>
I think I would have one Product that contains multiple Offers, one per size. The limitation, of course, is that it doesn't offer a formal means for specifying multiple product IDs, but perhaps you could informally put those in the Offer's Description or URL property. That's not an exact fit, but maybe it's close enough.
Another option is to join the Public Vocabs email list (lists.w3.org/Archives/Public/public-vocabs), which asserts that it is "the place to propose extensions, new types, or feedback from deployment experience with the existing vocabulary" (lists.w3.org/Archives/Public/public-vocabs/2011Oct/0162.html), and propose a solution to your problem.
I think ProductGroup is the key. See https://schema.org/ProductGroup
I have a similar quest and I find it hard to match google suggestions for xml product feeds with schema.org specs. Thing is, that feed should include each sku as single feed item (each shoe size separately), yet wa sell them as one product with different sizes. Our developer uses AggregateOffer to link all the sizes together, but specs does not allow each offer item to differ or even include an sku field. Product seems to suit the case better. Both sku and +size* are valid, properties of Product. Different sizes should be linked by productGroup.
In your case I would look into ProductModel for grouping multiple Product options, as it allows PropertyValue fields. See https://schema.org/ProductModel
I would recommend a slightly different way of thinking about this particular web page. Instead of thinking about this specific webpage as a 'Product' page, think about it as a 'WebPage' type. This 'WebPage' then actually contains three different 'Products', each with their own 'Offer' and their own 'productID'. When you're saying that each size has it's own EAN, that's a big indicator to me that each size's price/size/id should be contained inside if it's own 'Product' div.
This is what Google says to do: Use itemOffered The item being sold. Typically, this includes a nested Product, but it can also contain other item types or free text.
All the different variations should be represented as separate Products with separate Offers. Use Product's isSimilarTo and isRelatedTo properties to link them together.
reference: http://schema.org/Product
Consider using "AggregateOffer" for the product, than within each offer specify each size as a different "itemOffered"
https://schema.org/itemOffered
While several common expected types are listed explicitly in this definition, others can be used. Using a second type, such as Product or a subtype of Product, can clarify the nature of the offer.