I have a situation where I can put 99% of my structured data into JSON-LD in the of my product pages. But the only way I can get the UPC is to place it inline as microdata.
Will Google aggregate the product data from the JSON-LD and the inline microdata?
Most likely yes.
Google’s Structured Data Testing Tool works fine if you are using JSON-LD and Microdata (and RDFa).
Google does not say otherwise (they did in the past), see their Structured Data Policies:
The data may be embedded in your webpage using any of three supported formats: JSON-LD, RDFa, and microdata.
Some of Google’s structured data features are (currently) only documenting JSON-LD (for example, TV and Movie Watch Actions); for others, Google recommends using RDFa/Microdata, see for example their "About schema.org":
[…] Google recommends the use of JSON-LD for those features. For the remaining Rich Snippets types and breadcrumbs, Google recommends the use of microdata or RDFa.
It wouldn’t make sense for Google to restrict authors so that can’t make use of all the features (using different syntaxes) in the same document.
That said, you can never know for sure (their documentation is not always up-to-date, and their rules might change each day.)
One can use both in same page. But may not divide the info of one type of entity into parts ..example: some info about the product in JSON-LD format and some in microdata format does not work.
Also two separate things would mean two entities. Although one may use #id in JSON-LD and itemid in microdata to specify them as same entity but the Google’s Structured Data Testing Tool still shows them as two entities.
You can combine all three formats in a single page but Google gives more priority to JSON-LD and will take data from JSON-LD format shall the other one (or two) have different values than the former.
Related
I'm working on a site optimizing their structured data and noticed they use YotPo to pull in ratings and reviews. YotPo is defining the Product and only has a couple of values for AggregateRating that are being injected via JavaScript.
I have all of the other product data coming from the CMS, so I defined all the other information there, but when I run Google's testing tool on the page, it sees it as 2 products and says it's missing fields for the YotPo markup that are already defined in my markup.
Is there some way to let Google know that they're both chunks of data for the same product so it only sees it as a single product with the combined data?
You need to make sure both Yotpo and your CMS use the same format. e.g. json-ld or microdata.
You can then indicate that they relate to the same product by setting both up to use the same id.
I have added structured data to the product pages of my website. Would it also be beneficial to also add the structured data to the category pages? i.e. the pages that show all products within a certain product category group?
My thought is yes, as I'm describing what that page is displaying. The only doubt I have is that I'm only displaying a subset of the information that's on the full product page. E.g. I don't have a itemprop='description' entry on the category page. But I would assume/hope that because I have itemprop="url" for each product on the category page, that the search engines will be smart enough to tie the two together …?
Yes.
It can be beneficial to have the structured data also on category pages, in sidebars, on search result pages, etc., for various reasons. The more the merrier.
It’s no problem to specify only a subset of the content. Neither Microdata nor Schema.org require any properties.
And yes, by using Schema.org’s url property, you give consumers the chance to learn
that the two items are about the same thing, and
that they might find more properties about the item by following the URL.
(If, or which, consumers actually do this is another topic.)
We have been using schema.org to markup our products on the web with metadata.
We have a system where we have alternate part numbers for products and customers want to be able to search for any of the alternate part numbers.
Using schema.org or GoodRelations how should we mark up alternate part numbers? We think we should have one page on the web per part on not one page per alternate part number but we do want Google and Bing to be able to find and understand our alternate part number semantically?
Any ideas?
A "product part" concept can be represented in GoodRelations by an object property isAccessoryOrSparePartFor (http://purl.org/goodrelations/v1#isAccessoryOrSparePartFor) that is allowed on a class ProductOrServiceModel (http://purl.org/goodrelations/v1#ProductOrServiceModel)
I don't have an answer on whether Google or Bing take this property into account in their current implementation. This is a moving target and perhaps your best option is to give it a try.
I have been looking around on Schema.org but I don't understand one thing.
Can a single HTML page be made up of multiple schemas? If so do they need to be nested?
We have a one page landing / selling page we are working on.
I would like to have the following Schemas in place on it:
Organization
Product
Product Reviews
I am guessing the product reviews need to be nested within a product? Or can they be in a totally different part of the page?
Looked over what little docs there are.
You can have multiple schemas as well as mix on other markup types.
Some schema types naturally nest other types, like a product may contain product reviews. It is possible to markup the reviews outside the product but you may find less systems pick up the association correctly.
In an altruistic manner I would like to expose as much structured data about my website.
I also wouldn't mind SEO boost but its secondary.
Seems there are a couple of options:
Full on RDF (kill me now XML)
Atom with your own custom tags (liking that)
RDFa in your webpage (might help SEO)
Dublin Core Meta tags
Dublin Core using RDFa
Atom with RDFa
I'm just trying to make it easy for people to get data off my site.
The nice thing about standards is that there are so many of them to choose from.
Which one do you think I should use?
RDF is not just XML; RDF is a data model that relies on sets of triples (subject, predicate, object) and URIs to unambiguously refer to things. Actually, people working with RDF tend to run away from RDF/XML and we prefer RDF/Turtle or RDF/Ntriples, even RDF in JSON format. These serializations are more readable, easier to construct and easier to parse. Moreover, there are many tools that allow you to transform between all the range of RDF flavors (i.e: rapper or Jena).
When it comes to publishing information in RDF. You generally have three different choices:
To provide RDF dumps of your data.
To publish RDF following the Linked Data rules.
To add metadata to your existing Web pages with RDFa.
... these are not exclusive. You can go for any combination of them, the most important thing is choosing the correct structure of URIs (see Cool URIs don't change).
Following your SO profile I see that you're working on a social taste recommendation website (http://evocatus.com/). I assume that you might want to expose information about those reviews. So for a review like http://evocatus.com/sauce/cholula-chipolte-hot-sauce/272645/ you can provide different serializations and give back not just HTML but also:
.../holula-chipolte-hot-sauce/272645/rdf-turtle
.../holula-chipolte-hot-sauce/272645/rdf-xml
.../holula-chipolte-hot-sauce/272645/rdf-json
and one for any other type of format you want to expose.
In addition, the HTML version could be enhanced with RDFa. Depending on the type of client that consumes your data, following content negotiation rules, you'll redirect the HTTP request to whichever format is accepted by the client. This is established by the HTTP header Accept. So a request like the one below with curl would be redirected by your application giving back the RDF/XML version:
curl -H 'Accept: application/rdf+xml' .../holula-chipolte-hot-sauce/272645/
In the future, people would be able to say things about existing reviews in your site by just reusing your URIs in their RDF data. That's the power of RDF and Linked Data.
About Dublin Core, you could use Dublin Core with either RDF or RDFa. But, in your case there are some other interesting ontologies to consider and the right thing would be to use a mix of all of them:
FOAF: Friend Of A Friend, to express user personal information and relations between users.
Tag Ontology: A very simple ontology to express tag information.
RDF Review Vocabulary: Vocabulary for expressing reviews and ratings using RDF.
GoodRelations: An ontology to express product information and eCommerce.
Vcard/RDF: for addresses, normally used in combination with FOAF.
There is one site called http://revyu.com/ that uses all these ontologies (except GoodRelations), so you could use it as a guideline. See for instance:
http://revyu.com/reviews/342b55e79f64d5ca37f633b93c246c6ad6e14b04/about/html
http://revyu.com/reviews/342b55e79f64d5ca37f633b93c246c6ad6e14b04/about/rdf
... these are HTML and RDF versions of the same review.
Unlike with ATOM, as you can see, with RDF you would be able to reuse existing ontologies and since RDF is based on URIs everything would be interlinked.
Linked Data Added Value
What would happen if you invest sometime linking your products and reviews to other data sources ? (i.e: dbpedia.org or freebase.com). Let's imagine that you start linking all your Beer reviews (http://evocatus.com/beer/) to whatever brewery is manufacturing the product from (http://dbpedia.org/page/Alcoholic_beverage), by following the links you would be able to know for instance where the preferable beers are manufactured. Dbpedia holds that information.
Also see that in Freebase, that also provides RDF versions, you could link to manufacturers. For instance see, http://rdf.freebase.com/rdf/en.budweiser in RDF or http://www.freebase.com/view/en/budweiser in HTML.
The Dublin Core Schema is a small set of vocabulary terms that can be used to describe web resources (video, images, web pages, etc.).
Example of Dublin Core code
<meta name="DC.Format" content="video/mpeg; 10 minutes">
<meta name="DC.Language" content="en" >
<meta name="DC.Publisher" content="publisher-name" >
Link to Generate DC.Meta tags : http://www.dublincoregenerator.com/generator_nq.html
DC in meta-tags for SEO purposes - they are obsolete.
It was found that using Dublin Core elements did not improve the retrieval rank of the web pages" and that "Dublin Core metadata, as a well-known metadata schema, is not widely accepted and used by search engine designers and the spiders do not consider its elements while ranking the web pages.
Google are NOT using that in their indexing, and there is no mention of Dublin core on Google or search engine's site for indexing.
In the UK, government organisations use DC to provide standardised access to tags.
That's not to say Google, Bing, Yahoo, etc will never implement them. Google is using more metadata and rich snippets these days.