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

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?

Related

Schema.org 'specialty' property failing with Q&A type: "The property specialty is not recognised by Google for an object of type Question."

I'm trying to add the specialty property, following the Schema.org docs using JSON-LD. According to the QAPage docs, specialty is indeed a valid value for this schema type.
The problem is when I validate with Google's Structured Data Testing Tool, it spits out this error:
(The property specialty is not recognised by Google for an object of type Question.)
Now, Schema.org is partly ran by Google, so I don't feel it's an error on their end. Pretty sure it may be JSON-LD syntax but I've been trying different things all morning. Could anybody shed any light on the issue?
{
"#context": "https://schema.org",
"#type": "QAPage",
"mainEntity": {
"#type": "Question",
"name": "How many ounces are there in a pound?",
"text": "I have taken up a new interest in baking and keep running across directions in ounces and pounds. I have to translate between them and was wondering how many ounces are in a pound?",
"specialty": "SEO", //ISSUE LINE
"answerCount": 3,
"upvoteCount": 26,
"dateCreated": "2016-07-23T21:11Z",
"author": {
"#type": "Person",
"name": "New Baking User"
},
"acceptedAnswer": {
"#type": "Answer",
"text": "1 pound (lb) is equal to 16 ounces (oz).",
"dateCreated": "2016-11-02T21:11Z",
"upvoteCount": 1337,
"url": "https://example.com/question1#acceptedAnswer",
"author": {
"#type": "Person",
"name": "SomeUser"
}
},
"suggestedAnswer": [
{
"#type": "Answer",
"text": "Are you looking for ounces or fluid ounces? If you are looking for fluid ounces there are 15.34 fluid ounces in a pound of water.",
"dateCreated": "2016-11-02T21:11Z",
"upvoteCount": 42,
"url": "https://example.com/question1#suggestedAnswer1",
"author": {
"#type": "Person",
"name": "AnotherUser"
}
}, {
"#type": "Answer",
"text": " I can't remember exactly, but I think 18 ounces in a lb. You might want to double check that.",
"dateCreated": "2016-11-06T21:11Z",
"upvoteCount": 0,
"url": "https://example.com/question1#suggestedAnswer2",
"author": {
"#type": "Person",
"name": "ConfusedUser"
}
}
]
}
}
The specialty property needs to be added to WebPage (or one of its sub-types, like QAPage).
You added it to Question (where it’s not listed).

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.

Defining Schema.org JSON-LD for my Multi-language Web application

I am building a web application for product comparison. The website has a structure like so:
http://example.com
http://example.com/fr/compare/
http://example.com/es/compare/
etc..
The main page is in English.
I want to insert Schema.org for each of the pages and I've construed this schema. Written in square brackets are what I intend to put as value later on.
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#id": "[canonical-url-for-specific-language]#webapp",
"#type": "WebApplication",
"name": "[Product Comparison Title in specific language]",
"url": "[canonica url for specific language]",
"applicationCategory": "Utility",
"applicationSubCategory": "Product Comparison",
"about": "[page-description]",
"browserRequirements": "Requires JavaScript. Requires HTML5.",
"softwareVersion": "1.0.0",
"screenshot": "[image-url]",
"inLanguage": "[language-code]",
"softwareHelp": {
"#type": "CreativeWork",
"url": "[link-to-how-to-page-for-specific-language]"
},
"operatingSystem": "All"
}
</script>
How can I construct this JSON-LD well to work for my specific website.
If you use structured data for a home page that has a language selector, then the markup can be similar to the following:
{
"#context": "https://schema.org",
"#id": "[canonical-url-for-specific-language]#webapp",
"#type": "WebApplication",
"name": "[Product Comparison Title in specific language]",
"url": "[canonica url for specific language]",
"applicationCategory": "Utility",
"applicationSubCategory": "Product Comparison",
"about": "[page-description]",
"browserRequirements": "Requires JavaScript. Requires HTML5.",
"softwareVersion": "1.0.0",
"screenshot": "[image-url]",
"inLanguage":[{
"#type": "Language",
"name": "English",
"alternateName": "en",
"additionalType":"https://www.loc.gov/standards/iso639-2/php/code_list.php",
"sameAs":"https://en.wikipedia.org/wiki/English_language"
},
{
"#type": "Language",
"name": "Spanish",
"alternateName": "es",
"additionalType":"https://www.loc.gov/standards/iso639-2/php/code_list.php",
"sameAs":"https://en.wikipedia.org/wiki/Spanish_language"
}],
"softwareHelp": {
"#type": "CreativeWork",
"name":"Customer Service and Support",
"url": [
"https://examples.com/en/help.html",
"https://examples.com/es/help.html"
]
},
"operatingSystem": "All"
}
Note that I have here used for each language two identifiers with the properties sameAs and additionalType.
If the web page is with one particular language, then just delete the part of the markup for the unnecessary language and the square brackets.
Check out this markup on the Google testing tool and note that there are two warnings that are useful to fix.

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.

Errors in Google SDTT for Schema.org Product, Offer, and PriceSpecification

I'm new with Schema.org markup, so I've actually come up with the following codes for my real estate markup, and Google testing keep saying I shouldn't use offer for priceSpecification. I'm so lost now.
{
"#context": "http://schema.org/",
"#type": "Product",
"name": "Nodorus - Precinct 17",
"image": "http://www.setiaalam.com.my/images/products/p17/nodorus-c.jpg",
"description": "A distinct modern link residence set amidst award-winning green spans, wetland wonders and multiple amenities. Come home to articulately crafted spaces where architecture and nature's beauty infuse home with fresh chic. Rejoice in this cosy new addition to Setia Alam North.",
"additionalType": "Product",
"Offer": {
"#type": "PriceSpecification",
"priceCurrency": "RM",
"priceSpecification": {
"minPrice": "593000",
"maxPrice": "890000"
},
"availability": "http://schema.org/InStock",
"seller": {
"#type": "Organization",
"name": "S P Setia"
}
}
}
If you want to add an Offer for a Product, you have to use the offers property.
So instead of this (which doesn’t make sense, because Offer is not a property):
{
"#context": "http://schema.org/",
"#type": "Product",
"Offer": {}
}
You have to use this:
{
"#context": "http://schema.org/",
"#type": "Product",
"offers": {}
}
The type of the offers value should be Offer, not PriceSpecification.
The PriceSpecification can be added to the Offer via the priceSpecification property.
So the structure could look like:
{
"#context": "http://schema.org/",
"#type": "Product",
"offers": {
"#type": "Offer",
"priceSpecification": {
"#type": "PriceSpecification"
}
}
}