Schema.org 'mpn' for product variations - schema.org

I have an ecommerce site and I am trying to make sure everything is structured correctly and am not sure what to do for the mpn value.
I have different variations of products that each have their own MPN, however, they exist on my site in one product page, with a drop down to select the variation that the user wants.
Should I be adding all MPNs to the structured data? Or how should the information be structured in this case?

Each variant should be its own Product (or ProductModel). Then each Product/ProductModel would have one mpn value.
If one Product is used for all variants, it wouldn’t be possible to convey how the products differ (or that there are variants in the first place), and others couldn’t make statements about a specific variant.
For example, if one ProductModel is used for a shirt that gets offered in two variations, there is no way to convey which name/color/mpn belong together (it’s one product model with two names, two colors, and two MPNs):
{
"#context": "http://schema.org",
"#type": "ProductModel",
"name": ["Blue shirt", "Red shirt"],
"color": ["Red", "Blue"],
"mpn": ["23", "24"]
}
So, there should be two ProductModel items instead:
{
"#context": "http://schema.org",
"#type": "ProductModel",
"#id": "#p24",
"name": "Blue shirt",
"color": "Blue",
"mpn": "24",
"isSimilarTo": {"#id": "#p23", "#type": "ProductModel"}
}
{
"#context": "http://schema.org",
"#type": "ProductModel",
"#id": "#p23",
"name": "Red shirt",
"color": "Red",
"mpn": "23",
"isSimilarTo": {"#id": "#p24", "#type": "ProductModel"}
}

Related

How best to describe material of parts of a schema.org/Product in JSON-LD?

The schema.org/Product type has a material property for “[the] material that something is made from.” I'd like to describe the materials that each part of a product is made from.
For example, suppose I have a carbon fiber bike with wood handles and an aluminium fork (putting aside whether or not such a beast makes any sense!). I can describe the base material of the bike like so.
{
"#context": "http://schema.org/",
"#type": "Product",
"name": "A Bike",
"material": "Carbon Fiber"
}
But, how should I describe the material of the handles and fork? The material property expects Product or Text or URL as values, so I don't think I can say that the bike in general is carbon fiber, but the fork is aluminum. Right now, I'm placing the extra data under additionalProperty.
{
"#context": "http://schema.org/",
"#type": "Product",
"name": "A Bike",
"material": "Carbon Fiber",
"additionalProperty": [
{
"#type": "PropertyValue",
"name": "fork-material",
"value": "Aluminum"
},
{
"#type": "PropertyValue",
"name": "handle-material",
"value": "Wood"
}
]
}
Is there a better way to describe the materials of parts of a product?

schema.org structure for more than one ebook

I want sell more than one ebook on my site. But all ebooks are in one package for a specific price. I dont know, how i must setup the schema.org. My first creation look like this:
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "WebPage",
"mainEntity":{
"#type": "Book",
"author": "www.example.com",
"bookFormat": "https://schema.org/EBook",
"fileFormat": "application/pdf"
"image": "example.jpg",
"inLanguage": "English",
"name": "Example",
"numberOfPages": "20",
"genre": "Example",
"description": "Description example",
"keywords": "Keyword example",
"offers": {
"#type": "Offer",
"price": "1.00",
"priceCurrency": "USD",
"category": "",
"availability": "https://schema.org/OnlineOnly",
"availableDeliveryMethod": "http://purl.org/goodrelations/v1#DeliveryModeDirectDownload"
},
"publisher": "www.example.com",
}
}
</script>
Thanks for your help!
Your product seems a grouped product of downloadable products, which are enlisted eBooks.
There are two ways to implement a list format for your structured data:
Summary page + multiple full details pages
A single, all-in-one-page list
If the page has full details of each eBook in the list prefer A single, all-in-one-page list else if the page has short description of each eBook in the list use Summary page + multiple full details pages as described in here.
Regards,
Vivek

Structured data (schema.org) for Price lists / service lists

I'm building a website for a local beauty salon. They offer services such as massages and various beauty treatments. It's all visible on 1 overview page (price list)
I found out https://schema.org/Product can be used for services:
Any offered product or service. For example: a pair of shoes; a concert ticket; the rental of a car; a haircut
Fist question, can I ignore fields like availability and condition?
Second, should I list this products as ItemOffered inside Offer? Or is this not the correct way?
Example:
{
"#context": "http://schema.org",
"#type": "WebPageElement",
"offers": {
"#type": "Offer",
"itemOffered": [
{
"#type": "Product",
"#id": "/beauty-treatment-a",
"description": "Short description with details",
"name": "Beauty Treatment A",
"offers": {
"#type": "Offer",
"price": "18.28",
"priceCurrency": "EUR",
"description": "Same description",
"name": "Same name",
"image": {
"#context": "http://schema.org",
"#type": "ImageObject",
"contentUrl": "image-a.jpg",
"description": "Same name",
"width": 640,
"height": 640
}
}
},
{
"#type": "Product",
"#id": "/beauty-treatment-b",
"description": "Short description with details",
"name": "Beauty Treatment B",
"offers": {
"#type": "Offer",
"price": "18.28",
"priceCurrency": "EUR",
"description": "Same description",
"name": "Same name",
"image": {
"#context": "http://schema.org",
"#type": "ImageObject",
"contentUrl": "image-b.jpg",
"description": "Same name",
"width": 640,
"height": 640
}
}
]
}
}
Fist question, can I ignore fields like availability and condition?
Schema.org never requires a property. A consumer, like Google, might require properties for one of their features.
For Google’s Product feature,
availability is recommended for the rich result in Google Search, and required for the "Related Items" in Google Images, and
itemCondition is neither recommended nor required.
However, their feature is only for pages about a single product. So your page is not eligible for Google’s Product rich result.
Second, should I list this products as ItemOffered inside Offer? Or is this not the correct way?
You can either have Product as top-level item (with offers Offer), or Offer as top-level item (with itemOffered Product).
About your example:
There is no need to use WebPageElement; it’s typically not relevant information that a certain HTML element on a page contains an offer, it’s only relevant that there is an offer.
You have one offer that consists of two products, and two offers that consist of one product each (the same like in the first offer). You probably don’t want to have the first offer (unless there really is an offer that combines the two products).
I would recommend the following:
Use OfferCatalog for the list of offers.
Each list item is an Offer.
Each Offer points to its Product/Service with itemOffered.

Is the Event type suitable for running races?

I have inline Schema.org code via itemprop attributes, on all event pages on a website.
Search Console is flagging up recommendations that I use performer and various other properties, however due to the nature of the events (they are races), there are no performers.
Does this imply that event is the wrong type of Schema.org here, or can the warnings be safely ignored?
The tags used are:
type
image
name
location
type
address
type
streetaddress
addresslocality
address country
type
name
aggregaterating
type
reviewcount
ratingvalue
The Event type is perfectly suitable for races. But you should use the more specific SportsEvent.
Schema.org never requires any property, but consumers (who offer features based on Schema.org structured data) have their own requirements. If you want to get the feature, you would have to comply; if you don’t want the feature (or you can’t get it because you can’t provide all the required data), you can simply ignore any kind of errors/warnings from this consumer.
The consumer Google Search offers the event rich result feature, which has required and recommended properties. The performer property is just recommended, so it should be possible to get the event rich result without providing a performer.
Note that the guide of Google for Event requires the use of the following property that are not in the markup scheme you specified: startDate.
There are also many recommended properties out there that you are missing and these lower the value of the rich results of Google in the SERP:
description
endDate
location.name
offers
Note that the property executor can have the embedded type PerformingGroup, e.g.:
"performer": {
"#type": "PerformingGroup",
"name": "McLaren"
}
This way you can create markup for the team but not for each rider.
More detailed markup with structured data enriches the SERP of your web pages.
Beeing a webdeveloper and racedirector, I have been looking into this for some time now. If you take a look at the races website (no, this is no advertising for the best race on the planet), you can see that I have an event (SportsEvent) and six different competitions on that very day: 100km ultramarathon
What you see here is what I assembled so far to make my race as machine readable as possible. I have the adress, the different competitions, the place, the entry fees and the offers, the dooring time and all the stuff I might need google to know.
The only thing that is missing is the list of the competitors, the runners of each race. I am doing research about how to do this right now, but "sports" in microformats seems to be a team based thing. If I found out how to do it right, I'll post an update here. And you'll see it in the websites source code of course.
I have copied the LD-JSON here for future reference in case I'd edit the code of the website.
FYI: I am getting the participants data as XML feed directly from the raceresult registration website.
<script type='application/ld+json'>
{
"#context": "http://schema.org",
"#type": "SportsEvent",
"#id": "https://whew100.de/wettbewerbe/whew100.html",
"name": "WHEW100 Ultramarathon",
"image": "https://whew100.de/assets/images/WHEW100_transparent.png",
"url": "https://whew100.de/wettbewerbe/whew100.html",
"description": "WHEW100 Ultramarathon in Wuppertal über Wülfrath, Velbert, Heiligenhaus, Essen, Hattingen und Sprockhövel. Auf alten Bahntrassen zwischen Wuppert und Ruhr.",
"startDate": "2019-05-04T07:00:00",
"endDate": "2019-05-04T22:00:00",
"doorTime": "2019-05-04T06:00:00",
"maximumAttendeeCapacity": "200",
"aggregateRating": {
"#type": "AggregateRating",
"ratingValue": "4.9",
"reviewCount": "84"
},
"location": {
"#type": "Place",
"name": "Utopiastadt",
"sameAs": "https://www.clownfisch.eu/utopia-stadt/bahnhof-mirke/",
"address": {
"#type": "PostalAddress",
"streetAddress": "Mirker Straße 48",
"addressLocality": "Wuppertal",
"postalCode": "42105",
"addressCountry": "Germany"
}
},
"competitor": [
],
"offers": {
"#type": "Offer",
"description": "Anmeldung zum WHEW100",
"url": "http://my.raceresult.com/105067/",
"price": "75",
"priceCurrency": "EUR",
"availability": "200",
"validFrom": "2018-09-01T00:00:00"
},
"superEvent": {
"#id": "https://whew100.de",
"name": "WHEW100",
"startDate": "2019-05-04T07:00:00",
"endDate": "2019-05-04T22:00:00",
"location": {
"#type": "Place",
"name": "Utopiastadt",
"sameAs": "https://www.clownfisch.eu/utopia-stadt/bahnhof-mirke/",
"address": {
"#type": "PostalAddress",
"streetAddress": "Mirker Straße 48",
"addressLocality": "Wuppertal",
"postalCode": "42105",
"addressCountry": "Germany"
}
}
}
}
</script>

Connecting multiple organizations and websites via JSON-LD schema.org

I'm trying to accomplish machine-understandable relationship descriptions for companies/subsidiaries and their websites. Let's suppose there is one parent company with two subsidiaries, all of which have their own websites. I deploy one Organization script, and one WebSite script per home page.
The parent organization's JSON-LD reads:
<script type="application/ld+json">
{
"#context": "http://www.schema.org",
"#type": "Organization",
"#id": "https://www.parentorg.com/#organization",
"name": "Parent Org",
"legalName": "Parent Org Inc.",
"description": "Description of company",
"foundingDate": "1978",
"logo": "https://www.parentorg.com/images/logo.png",
"image": "https://www.parentorg.com/de/images/outside.jpg",
"url": "https://www.parentorg.com/",
"address": {
"#type": "PostalAddress",
"streetAddress": "Street 110",
"addressLocality": "City",
"postalCode": "XX XXX",
"addressCountry": "XX"
},
"contactPoint": {
"#type": "ContactPoint",
"contactType": "customer support",
"telephone": "+12-345-678-91011",
"email": "contact#parentorg.com"
},
"sameAs": [
"https://twitter.com/parentorg/",
"https://www.instagram.com/parentorg/",
"https://www.youtube.com/user/parentorg/",
"https://plus.google.com/parentorg"
],
"subOrganization": [
{
"#type": "Organization",
"#id": "https://www.subsidiary-one.de/#organization",
"name": "Subsidiary One"
},
{
"#type": "Organization",
"#id": "https://www.subsidiary-two.de/#organization",
"name": "Subsidiary Two"
}
]
}
</script>
The parent's website JSON-LD is:
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "WebSite",
"#id": "https://www.parentorg.com/#website",
"url": "https://www.parentorg.com/",
"author": {
"#type": "Organization",
"#id": "https://www.parentorg.com/#organization",
"name": "Parent Org"
}
}
</script>
And now the subsidiaries' organization JSON-LD contain a parentOrganization property:
"parentOrganization": {
"#type": "Organization",
"#id": "https://www.parentorg.com/#organization",
"name": "Parent Org"
}
Would this be a good way to cross-reference those entities? And do I even need to write out the name properties inside subOrganization, parentOrganization, and author, when there are URIs referenced?
Yes, you follow the best practice how to cross-reference entities (by giving each entity an #id that is different from the url).
You don’t have to provide additional properties when referencing entities, so this is fine:
"author": {"#id": "https://www.parentorg.com/#organization"}
"subOrganization": [
{"#id": "https://www.subsidiary-one.de/#organization"},
{"#id": "https://www.subsidiary-two.de/#organization"}
]
"parentOrganization": {"#id": "https://www.parentorg.com/#organization"}
However, this of course requires that consumers fetch the referenced documents. But not all do (probably). So if you want to provide data for those consumers, too, you could add properties in addition to the #id. It could be just one, a few, or even all properties. I think the two from your example are the most important ones:
Providing #type can also be useful for consumers that are capable of fetching documents, as it may allow them to decide whether the referenced resource is of interest to them before fetching it. For example, a consumer might only care about works authored by an Organization, not by a Person.
Providing the name property can be useful for consumers that display the included structured data in some way that benefits from a name/label.