Change the domain and range of isVariantOf to Product #1797
Comments
jvandriel
changed the title
|
What I'm hoping to achieve is that, when Single page environment - base product Multi page environment - base product Multi page environment - product variant |
|
And if we want to be helpful to publishers, in regards to ease of implementation, than we help them avoid the needed use of fragment identifiers, as shown in the examples above, by introducing an inverse property for With the following description:
Making the following possible for a: Single page environment - base product Multi page environment - base product |
|
Done tinkering with the proposals and the code examples - feel free to shoot on 'm now |
|
I would like to propose a different way of solving this issue. Could we swap the rdfs:subClassOf hierarchy of Product and ProductModel? As we have it today, the ProductModel is described as prototypical, as in something that is more abstract than the Product itself:
Yet, today's hierarchy goes from most abstract to concrete then back to abstract. In concrete terms, we can say today that all ProductModel data items are also implied to be a Product and a Thing. A Product conversely cannot be inferred to be a ProductModel even though all products are based on some conceptualization. I don't think it is correct that a prototype, abstract, template-able sort of thing is also through inheritance a kind of concrete thing. If we flipped the hierarchy: If we agree to the above, we might want to discuss which properties should be reassigned to a domain of ProductModel from Product. I would start with the assumption that all properties of Product get reassigned to ProductModel. This would solve @jvandriel issue of changing isVariantOf through inheritance. I'm curious what @mfhepp would have to say about this. |
|
@vberkel Its not ProductORModel ... its actually AProductModel The better description and what I alias in my apps is: |
|
Just to make sure I understand you correctly @thadguidry...
Cause if so, that's not how I understand And if |
|
@jvandriel ProductModel = model (which could be a variant of another model) For clarity, scroll to the bottom and see the reversing properties In Good Relations and Schema.org...
Some will argue that iPhone is ONLY a brand... well yeah, it "can be" a brand, but its not necessary to say ONLY. Its certainly allowable to say that iPhone can be a Product, and nothing in Good Relations or Schema.org prevents that. :) Thank goodness. |
Great, at least we're talking about the same thing. But for all intends and purposes, what I'm missing in this list is that products can have variants as well, eg:
Something I feel
Don't know if I agree with you on this one though. Reason being that it's not very often a What's the rationale behind: "Its certainly allowable to say that iPhone can be a Product"? (after all, one buys a certain configuration of a product and not the And at the same time, if a * no, I don't want to get into a 'rich snippet' discussion over this, the example is just illustrative |
|
@unor's answer to the question: "How to avoid repeating values that are the same for the differently sized products?" on StackExchange illustrates perfectly one of the issues I hope to resolve with this proposal - it would eliminate the need for repeating the same properties over and over again. Something @mfhepp's publication about markup for product variants with different prices doesn't take into account either (plus it depends on the existence of offers). |
|
For the use cases I'm commonly dealing with (electronic components) I'd propose to tighten the definition of In that view the iPhone 6s is not a variant of the iPhone 6, but a separate model (perhaps in the same series or family). However I can imagine consumer goods has it's own world view, same for other domains. |
|
hi folks! As alluded to in #2587, @alex-jansen @rvguha and I have been discussing this with Google colleagues too. We think there is scope to clarify how to treat variants.- In line with @mfhepp in his old blog post (which seems offline but via archive.org) we would agree that the "abstract model of the product" (omitting /size, /color etc concrete details) is worth describing separately as a distinct entity. We think this can be done more explicitly with some modest tweaks, including a new (sub)type.
|
|
Sounds good to me. Personally I'd prefer the name Any thoughts about the possibility of adding a |
|
Having an inverse of /isVariantOf sounds useful to me. As for names, the terminology of "parent" also seems popular in e-commerce circles, but we have already used it in schema.org metaphorically in other places. |
|
This is valuable.
Agree with /ProductGroup name.
Will /ProductGroup have properties for parent/sibling relationships like
/ProductModel has with pre/succ ?
Do we expand pre/succ to also expect a type of /ProductGroup in addition to
the expected /ProductModel?
I am worried about mixing Types and Multi-Typed entities playing within all
this...so...
It might be better to have new properties for the parent/sibling
relationships just for /ProductGroup to alleviate ambiguity with
/ProductModel at the predicate level?
I.E. /parentProductGroup
/childProductGroup
Thad
https://www.linkedin.com/in/thadguidry/
…On Fri, Jun 5, 2020 at 10:50 AM Dan Brickley ***@***.***> wrote:
Having an inverse of /isVariantOf sounds useful to me. As for names, the
terminology of "parent" also seems popular in e-commerce circles, but we
have already used it in schema.org metaphorically in other places.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1797 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHQ2RQZI6JHENQPQ4GMRYLRVEH23ANCNFSM4EDYRGAQ>
.
|
|
To me /ProductGroup is still quite vague and perhaps might just be a arbitrary group of products that share some similar feature or characteristic. How does it differ from a /category of products? Perhaps something like /ProductLine, /ProductSeries or /ProductFamily might fit better? Without wanting to muddy the waters further, isn't it the case that an /Offer is (logically) related to either an /IndividualProduct or /SomeProducts i.e. you (generally) do not offer the /ProductModel for sale. Isn't the use of the more generic /Product class just ambiguous in those cases? |
|
@jaw111 /ProductGroup (or cluster or whatever) would be products which differed only along explicitly declared lines, e.g. w.r.t. sizes, colors. Line/Series/Family seem closer to the "model" construct. The observation that the abstract product model, or product group, isn't itself offered for sale is one of the points made in favour of having them be under /Intangible. At which point it becomes a technical debt / workflow etc management issue to keep the type/property associations properly in sync. The original Good Relations design had services and products in the same type, for example; in Schema.org we ended up treating them separately, and so have to maintain by hand various places in which either could appear. It's one of the costs of trying to avoid an over-deep type hierarchy with lots of abstractions. As to @thadguidry 's point, yes - interactions with multi-typed entities could complicate things. I was talking recently with @alex-jansen also on how this would interact with subtypes of Product, if we (hypothetically) were to go in that direction and distinguish eg WearableProduct from others. |
|
@danbri the naming of the classes seems something that'll be hard to find something to please all parties. I struggle a bit with when something would be more of a /ProductGroup or a /ProductModel. In most cases I deal with the Series is a group of products that differ along explicitly declared lines, whilst also appearing in the same data sheet. Would it help to have some concrete uses cases to clarify when it would be more appropriate to use which and how that might be interpreted by an application that consumes that data? |
|
@jaw111 One key distinguishing characteristic of a /ProductGroup could be that it is always virtual (non-tangible). Which means that 1 or more defined attributes (the canonical examples of which are /size and /color for apparel) are needed to turn it into a real tangible product (aka a "variant"). A /ProductGroup will therefore not have the typical identifiers such as a /sku or a /gtin that a tangible item has. In this example size and color are the variant attributes, while for example material and product details are common. A /ProductModel on the contrary appears to represent a "complete" and tangible item in a series of related items (see also the comment of @thadguidry). The main reason to make the concept of /ProductGroup explicit was nicely phrased by @JvDriel, namely to introduce an explicit and unambiguous way of representing and grouping product variants and their variant attributes. This would make it easier for consuming applications since those would not have to reconstruct (or guess) variant groupings. |
|
Some notes towards draft schemas and examples (join #1797 and #2587), although not addressing all of the goals in the other issue around SizeDetails: https://docs.google.com/document/d/19DpcLStce-n1iF1rsIyS3Pz9_h-xSaQ1J_Nu7m24Wjo/edit# |
|
@alex-jansen ok, so using an example at hand for microchips (B2B), we might have the series 74ABT125 which would be a /ProductGroup containing the /ProductModel instances (with some variant hierarchy):
Where the lowest level represent different packing methods for 'the same' product, like you might get 'the same' 330ml can of coke as a single item, or a 6-pack or 24-pack. As we're still not describing a specific box of chips, or 'some' anonymous boxes of chips, nor offering something for sale, then it's still appropriate to us /ProductModel for that. Example: @prefix schema: <http://schema.org/>
<74ABT125> a schema:ProductGroup ;
schema:name "74ABT125" ;
schema:description "Quad buffer; 3-state" ;
schema:hasVariants <74ABT125BQ>, <74ABT125D>, <74ABT125DB>, <74ABT125PW> .
<74ABT125PW> a schema:ProductModel ;
schema:name "74ABT125PW" ;
schema:description "Quad buffer; 3-state in SOT402-1" ;
schema:hasVariants <74ABT125PW,118>, <74ABT125PW,112> .
<74ABT125PW,118> a schema:ProductModel ;
schema:name "74ABT125PW,118";
schema:mpn "74ABT125PW,118" ;
schema:description "Quad buffer; 3-state in SOT402-1 on Reel 13\" Q1/T1 2500 pieces" ;
schema:isVariantOf <74ABT125PW> .
<74ABT125PW,112> a schema:ProductModel ;
schema:name "74ABT125PW,112";
schema:mpn "74ABT125PW,112" ;
schema:description "Quad buffer; 3-state in SOT402-1 Bulk pack 2400 pieces" ;
schema:isVariantOf <74ABT125PW> .Does that make sense? |
|
@jaw111 It makes sense, you are modeling a 3-level hierarchy: series->types->orderable parts, where:
The question then is whether the 2nd level (type) is a ProductGroup or a ProductModel? It appears orderable parts differ along explicitly declared properties ("packaging", "packing"), quite similar to the examples of apparel (t-shirts), cola, and chips. If we define ProductGroups as virtual (non-buyable) then would it make sense to model all but the leafs as ProductGroups? For example (bear with me, this is only conceptual since Schema.Org does not define "package" , "packing", "quantity", or "variesBy" properties): @prefix schema: <http://schema.org/>
<74ABT125> a schema:ProductGroup ;
schema:name "74ABT125" ;
schema:description "Quad buffer; 3-state" ;
schema:variesBy "package" ;
schema:hasVariants <74ABT125BQ>, <74ABT125D>, <74ABT125DB>, <74ABT125PW> .
<74ABT125PW> a schema:ProductGroup ;
schema:name "74ABT125PW" ;
schema:description "Quad buffer; 3-state in SOT402-1" ;
schema:package "TSSOP14" ;
schema:variesBy "packing", "quantity" ;
schema:isVariantOf <74ABT125>
schema:hasVariants <74ABT125PW,118>, <74ABT125PW,112> .
<74ABT125PW,112> a schema:ProductModel ;
schema:name "74ABT125PW,112";
schema:mpn "74ABT125PW,112" ;
schema:description "Quad buffer; 3-state in SOT402-1 Bulk pack 2400 pieces" ;
schema:packing "Bulk pack" ;
schema:quantity "2400" ;
schema:isVariantOf <74ABT125PW> . |
|
@alex-jansen that's where I struggle with the distinction between /ProductModel and /ProductGroup types. In this case the second level already specifies the complete form, fit, function of the product, such that all manufacturing variants (produced in different locations or whatever) must conform to that specification. There may be some internal variance in how they are produced, but that should not affect how the product is used e.g. as a customer I know I can safely buy any variant of the 74ABT125PW and it'll still work in my design/application. Whereas the different product in a group are generally not drop-in replacements for each other. I don't know if this is a specific concern for electronic components, or something more generically applicable. I guess something similar, but a bit further down the supply chain might be a product model like "iPhone 6s 4.7-inch 128 GB Silver". In a way all of those phones should be equal, but in practice there might be internal differences like the screen or battery might come from another supplier, but all should conform to the specification of that model. Perhaps there is something to be said for tightening up the semantics of /isVariantOf such that a variant can only extend the specification of the parent model, but should never overrule an inherited value? In case of components, the packing (i.e. box, reel, tray) is a secondary concern and more about the logistics. A distributor might resell the products in smaller quantities than are available direct from the manufacturer. I assume the same applies in other industries too. I'm not sure if it'd be of interest to try and capture that in Schema.org, or if it is already covered by something like the GS1 Web Vocabulary. |
|
@jaw111 How about this to differentiate /ProductGroup and /ProductModel: A /ProductGroup (1) never has a SKU and (2) contains a set of Products that vary on explicitly defined specific dimensions only (so it defines both the set of variants and which values must be added by those variants). A /ProductModel (1) might have a SKU and (2) is more flexible in terms of the variations between related ProductModels (even if we disallow overruling inherited values). A /ProductGroup is thus more restricted compared to a /ProductModel. For example, in the world of eCommerce, the quantity is often an identifying dimension of a variant. One can buy the same roll of Scotch Tape in 3-packs or 6-packs. Each of the packs has a separate SKU, the /ProductGroup would be "Scotch Tape" and the /Products would be the 3-pack and the 6-pack. |
including minimal linking into core via isVariantOf
Needed to pass sanity checks that there are even number of inverseOf claims. /cc #1797
Hyperlinked 'size' in ProductGroup definition. Removed accidental quote chars. /cc #1797
|
This issue is being tagged as Stale due to inactivity. |
github-actions
bot
added
the
no-issue-activity
|
I was wondering if any of you had any thoughts on how one should actually go about to exactly specify along which schema.org properties products vary? (I couldn't find any issue discussing this other than some mentions about the use of string values for When playing around with it I came to something like this (which I consider quite convoluted): Which, in an attempt to shorten it, led to : And then I realized that even though it's not mentioned explicitly, providing a url should probably suffice as well (which definitely is the most publisher friendly annotation): Thoughts? Note: related to #2587 |
|
@jvandriel fair question and just a url should indeed be sufficient. We were considering adding URL to the range of variesBy. An even better alternative could be Property. Thoughts? |
|
Well, I'm right in the middle of 3 experimental projects involving One of which a is a basic webshop, for which I had to act quite pragmatic so to prevent them from losing their Rich Results in Google search; Which currently still happens when a page contains multiple products that are eligible for Rich Results. Meaning that Though the other 2 involve SaaS products with subscriptions. Which is something we never really spoke about during the discussions around the new In 1 of the SaaS cases the variances lie with subscriptions offering different combinations of sub-applications that make up a software suite. The main entity being a whopping: In this case though, In the last SaaS case however I'm describing eSim Data Plans ( A scenario which definitely wasn't discussed during the conversations thus far as we've mostly been talking about variances which are a direct derivative of a Now the above markup does illustrate I am able to express this with the current setup (so it seems robust) though I have my doubts about how 'consumable' this really is without introducing additional triple statements (not that I have any better ideas at the moment as I'm still elbows deep in writing markup. More reflections at a later moment, first I need to have actual urls I can share). All this to say, I'm not sure - taking the final example into account - what to do with situations where the properties describing the variances are found at a deeper level of nesting, which as I now discovered, doesn't appear to be all that uncommon when expressing SaaS products (and likely other types of products I don't yet foresee as well). Thoughts? As for your question about adding The latter seems like a really good idea to me because together with Plus I'd also like to have the |
|
Hello Dear experts, Thank you very much for your insights. I am a start up online shop and really struggle to accomplish google requirements. Would you mind please helping? The advocates for "hasVariantOf" does not comply with the google demands, since Google insists that each variant must have a ProductID that refers to the original ProductID. please read this google link: https://support.google.com/merchants/answer/6324507?hl=en&ref_topic=6324338#zippy=%2Cgeneral-examples here is there citation: "Submit a unique ID for each different product. Use the same value for item group ID [item_group_id] attribute for all variants of the same product. For example, a T-shirt comes in 9 variants: 3 sizes (small, medium, large) and 3 colors (red, blue, green). Submit each variant as a separate product (for a total of 9 separate products), and submit the same value for the item group ID attribute for each to indicate that these are variants of the same product." In addition to this, there is no [item_group_id] attribute on schema.org, so what are they referring to? |
There is, though the properties used for this are called differently: |
Dear Jvandriel, do you know whether I am allowed to use separate schema code for each of the product variant, Or I must use a single code? For example if I have 3 colors and 3 sizes this is in total 9 products, hence 9 different schemas. I am failing to put everything in a single code. |
|
All product variants that are part of the same Part of you confusion might be caused by the fact that feeds for GMC only contain product data but don't contain any actual Which you can express as such by using the schema.org vocabulary, though we're trying to come up with a solution that allows one to model the same info in multiple directions. Let me give you 3 code examples to illustrate what I'm trying to get across... Multiple A A |
|
dear jvandriel, thank you very much for your comprehensive response, while I am testing the code, would you mind helping with answering a very simply question: what if I just ignore the complicated Schema and simply override everything in the Google Merchant Center manually, Since they have the manual option for that which I just noticed. Do you believe it will work? |
|
Part of what we're trying doing here is to create an alternative for having to use XML feeds, so that you can either use structured data OR GMC XML feeds. The most luxurious option for consumers of such data is if you do both. In which case you should try to make sure both methods end up offering exactly the same info. I wouldn't count on either one of them being able to overrule the other. |
|
dear jvandriel, the problem that I already have the automatic crawling feed which I tried to solve the same way as you - creating the Schema that answers all the questions. But I am failing to do it. It is too complicated for me. I still have the automatic crawling feed and try to override everything manually. However, I faced with another problem. Because the feed is automatic and the changes are manual I am failing to add the sizes. Because google insists for every size and color to have a separate product. But I cannot do it since its automatic feed. so shall I delete the automatic feed and do everything manually? |
|
I'm sorry @Prlme1 but I fear I can't help you out with that as I'm not qualified to make any such statements, nor is this the right platform to be discussing that. Here we try to work on the development of schema.org itself. If you've got any questions about how to resolve your situation I suggest you ask them over at the GMC's help center. |
|
thank you very much for you help. I will keep following your Schema inventions. |
|
dear jvandriel, I understood my mistake confusing the Schema.org and the Structural Data with the internal schema of google within the Merchant Center. I promise to stick with the topic discussed here. Would you mind helping with another confusion please about the schema: How to make the Structural Data in a such way so that Google Merchant Center reads off each variant as an individual product. Lets say I have 3 colors and 3 sizes which is in total 9 products. Shall I just add 9 different schemas to the web page so that next time google crawl it sees 9 products and adds them all to the Merchant Center? Or it should be a single code with let's say VariantOf attributes? will it be able to read off a single code as a 9 different products and adding all 9 to the merchant center? Recall the google requirement: here is there citation: "Submit a unique ID for each different product. Use the same value for item group ID [item_group_id] attribute for all variants of the same product. For example, a T-shirt comes in 9 variants: 3 sizes (small, medium, large) and 3 colors (red, blue, green). Submit each variant as a separate product (for a total of 9 separate products), and submit the same value for the item group ID attribute for each to indicate that these are variants of the same product." Please, help me to solve this difficult puzzle. I am really struggling. |
|
Just a bit of historic context: isVariantOf was initially designed so that
It was initially not meant to represent rules that define possible product variants, but instead assuming that product models are materialized (i.e. one entity per each product variant). The original axioms are documented in here: http://wiki.goodrelations-vocabulary.org/Axioms Namely: http://wiki.goodrelations-vocabulary.org/Axioms#product_variants I now tend to agree that we likely need a mechanism to specify the range of possible product variants in a rules-based fashion (like "the shirt is available in three colors and six sizes each"), although that creates problems of its own, namely
One essential question is whether we want the rules of product variant composition to be a) under the command of the publisher (e.g. a server-side Python script that simply materializes all possible variants, or a RESTful API based on a URL pattern), or Now, as for product model vs. product: There are subtle yet practically relevant differences between product characteristics defined at the level of a product model vs. those of an actual product. The original way of representing product characteristics in GoodRelations was organized in a hierarchical fashion, like so Base Model properties -> Variant -> Actual Product The exact semantics is specified here: https://wiki.goodrelations-vocabulary.org/Axioms#product_models Bottom-line: I think it is possible to define a simple, much constrained mechanism so that product variants for commodities like clothing can be represented by rules in markup rather than materialized, but it is slippery ground - because for availability information and ordering, you will need a unique identifier for each variant anyway. Outlook: As search engines are increasingly able to process JSON-LD that is created by active content (e.g. JS) on the client side, it may be both more feasible and more flexible to develop a best-practice guide on how to generate the schema.org markup for product variants by Javascript components. |
Is that enough though, shouldn't this be able to be achieved for non-physical products like SaaS products as well? (e.g. to be able to express the differences between different types of subscriptions) Although I do feel that for these it would have been nice if schema.org had chosen for Whichever it is, we wouldn't be able to achieve much these days without SaaS yet it's not a type of product/service which tends to have any (need for a) globally recognized identifier. At best the companies behind them sometimes sort of 'cheat' in their markup by providing an Oh, and what about mobile phone network, data plan and vpn providers (and such). Wouldn't it be of value if their product/service/subscription variants would be able to be expressed (and supported) as well? (good luck finding a |
|
@Prlme1, Google has very specific guidelines which describe how they would like you to handle product variants (at this moment in time). I suggest you read these and ask any questions you might have about them on Google's support forum. |
|
I re-read the relevant Google docs for Google Search and Google Merchant Centre. TL;DR; I think the closest you can get to comply with both sets of requirements is to mark up a single product with inProductGroupWithID and have an offer per variant that includes the variant SKU or GTIN. Unfortunately, I see no way of describing the variants, and multiple offers may break the rich results, which state the variant should be on its own URL that is canonicalized out, so of no use. At this time, I only add structured data at the product level. We’ve had several cases where structured data alone can add products to the Merchant Centre. Merchant centre: https://support.google.com/merchants/answer/6386198 A product page has a single product identified by inProductGroupWithID, which maps to item_group_id in the feed. ProductModel and ProductGroup do not seem to be mentioned anymore. https://support.google.com/merchants/answer/7331077 It can have multiple offers that are identified by SKU or GTIN that map to the feeds id. However, I see no way to define what the variant is in the offer. So offers can be variants. On to Google rich snippets… https://developers.google.com/search/docs/appearance/structured-data/product#technical-guidelines Also mentions support for inProductGroupWithID. Only mark up one product on a product page. So using things like Product Group will probably break it. I’ve experimented with Product markup on category pages and saw that rich snippets only happened if the category only had one product. The document implies only one offer, but does not specifically say so. It would make sense to allow variants on the product page, where they specify the url for their true location. This could even be just a #green to trigger the page to show variant info. It references this about giving variants their own URL: eCommerce URL recommendations It suggests that the canonical tag should be used to have the main product page as the canonical for all the variant pages. This would tell Google not to index the variant pages and not to use their structured data. However, as they would be near duplicates, Google would probably canonicalise them out anyhow. So it seems there is no value in marking up variants on variant pages for Google search. Maybe the merchant centre will still check them. |
|
To respond in particular to what @Tiggerito described about Google's documented desire for canonicalizing product variants to that of a single variant vs real-life situations where web sites offer a product page without having any of the variables set yet (so, variant to be determined still, pretty much like the GMC ad modal for variants identified as having the same It's this where I feel
This way all the variant pages can have their canonical url refer to that of the Which becomes really painful when such a product is out of stock, because than the canonical has to automatically shift in a cascading manner until there's a variant that is in stock, and than has to get up the waterfall again as products are again in stock. A seriously stupid and wasteful system which I don't want to know how many billions have been spent on globally already and will be spent more of we don't make it easier for the world by simply letting them provide a The first example of my recent post in this thread is actually a result of what @Tiggerito described. That site has a clean canonical url which sort of resembled what this GMC page illustrates, but due to Google Organic Search's best practices 'suggestion' for a canonicalized product variant, that business opted to spend dozens and dozens of development hours to accommodate the implementation those 'best practices'. Yet they already had the perfect system in place - nearly out of the box - to be able to generate a page of which the @Tiggerito unfortunately still is very correct in saying: "So it seems there is no value in marking up variants on variant pages for Google search." While also being right in saying: "So using things like Product Group will probably break it". I've extensively tested this over the last couple of months and so far the outcome of At this moment the only sort of practical use case I've been able to find are SaaS subscription overview pages, which due to the nature of such content already aren't eligible for Google's Rich Results. But beyond that I can NOT find any candidates that are willing to take a chance with publishing |
|
I went to the nike shop and read off the schema they have. This is how the major shops do. they put everything in "AggragateOffer" section. However, they ignore the sizes for some reason. and I still cannot understand how this appears in the Google Merchant Center, since all variants have to be a separate product: </script> <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Product", "name": "Nike Spark Women's Shoes", "image": "https://static.nike.com/a/images/t_default/b438f82a-62a3-49a8-9ded-fd1d281761a9/spark-shoes-zPVQHZ.png", "description": "Find the Nike Spark at Nike.com.", "brand": { "@type": "Brand", "name": "Nike", "logo": "https://www.nike.com/Nike_Swoosh_Logo_Black_original.jpg" }, "offers": { "@type": "AggregateOffer", "lowPrice": "8957", "highPrice": "12795", "priceCurrency": "INR", "availability": "https://schema.org/InStock", "offerCount": 5, "offers": [ { "@type": "Offer", "url": "https://www.nike.com/in/t/spark-shoes-zPVQHZ", "price": 8957, "priceCurrency": "INR", "itemOffered": { "@type": "Product", "name": "Nike Spark Women's Shoes", "model": "14084002", "releaseDate": "2022-10-06T16:00:00.000Z", "color": "Barely Rose/Pink Oxford/Light Soft Pink/Dark Smoke Grey" }, "seller": { "@type": "Organization", "name": "Nike" }, "availability": "https://schema.org/OutOfStock" }, { "@type": "Offer", "url": "https://www.nike.com/in/t/spark-shoes-zPVQHZ", "price": 8957, "priceCurrency": "INR", "itemOffered": { "@type": "Product", "name": "Nike Spark Women's Shoes", "model": "1003839125", "releaseDate": "2023-01-30T16:00:00.000Z", "color": "Summit White/Rush Fuchsia/Ocean Bliss/Metallic Silver" }, "seller": { "@type": "Organization", "name": "Nike" }, "availability": "https://schema.org/InStock" }, { "@type": "Offer", "url": "https://www.nike.com/in/t/spark-shoes-zPVQHZ", "price": 12795, "priceCurrency": "INR", "itemOffered": { "@type": "Product", "name": "Nike Spark Women's Shoes", "model": "14018627", "releaseDate": "2022-11-22T16:00:00.000Z", "color": "Phantom/Sand Drift/White/Dark Smoke Grey" }, "seller": { "@type": "Organization", "name": "Nike" }, "availability": "https://schema.org/InStock" }, { "@type": "Offer", "url": "https://www.nike.com/in/t/spark-shoes-zPVQHZ", "price": 12795, "priceCurrency": "INR", "itemOffered": { "@type": "Product", "name": "Nike Spark Women's Shoes", "model": "14141745", "releaseDate": "2022-10-06T16:00:00.000Z", "color": "Black/Pure Platinum/White/Metallic Silver" }, "seller": { "@type": "Organization", "name": "Nike" }, "availability": "https://schema.org/InStock" }, { "@type": "Offer", "url": "https://www.nike.com/in/t/spark-shoes-zPVQHZ", "price": 12795, "priceCurrency": "INR", "itemOffered": { "@type": "Product", "name": "Nike Spark Women's Shoes", "model": "1010134718", "releaseDate": "2023-03-26T16:00:00.000Z", "color": "White/Game Royal/Picante Red/Black" }, "seller": { "@type": "Organization", "name": "Nike" }, "availability": "https://schema.org/InStock" } ] }, "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.9", "reviewCount": 9, "bestRating": "5", "worstRating": "1" } } </script> |
|
@Prlme1 using AggregateOffer means the page is not eligible for the merchant centre: They assume that means you are an affiliate. Could you provide an example URL where your example structured data is causing rich snippets. They have a strange nested offer structure which might end up being acceptable. |
|
Thank you for sharing this information! Regarding your question about Nike shoes on Google, the products are displayed as goods in the image tab. However, it's uncertain how comprehensive these rich results are. |
|
Hello, It is great to see that this issue is being addressed after having made an educated guess for aggregating products with duplicate content back in 2019. I have spent countless hours trying to figure out how this simple, and very common circumstance should be treated in the eyes of google. If anyone can help in lehman terms that would be much appreciated. It is quite difficult to drill down to a source of truth. For simplification, i will separate variation tiers by (A, B, C) and will address each tier as defined below. -Product Category ( A )
Topics of Confusion
Thank you for your help, the more i read the more contradictions i find from different parts of the thread, or different information online.. hoping to get something firm to stand on. |
|
hello dear @jvandriel . i would be grateful if you would take the time to review my suggestion about "varianttype" and if you provide me with your feedback. thank you for your time and consideration. Rationale for "VariantType" after conducting a thorough analysis of the entire conversation and the provided texts, the introduction of the VariantType stems from a need for a more robust and standardized way to represent variable features within a group of products. The primary motivations for this proposal are: Semantic Enhancement: User Experience Improvement: Data Modeling Flexibility: Categorization and Recommendation: Consistency Across Products: By addressing these considerations, the VariantType proposal aims to provide a solution that not only fills the current gap in data representation but also anticipates future needs and changes in the landscape of product information. The objective is to enhance both the backend structuring of data and the frontend user experience, creating a more comprehensive and user-friendly system for handling variable product features. Proposal Explanation: Using VariantType: This proposal allows you to enhance semantic structure, improve product information based on variable features, and assist users in quickly finding the products they need. First Example: VariantType is a variable used to model types of variable features within a group of products. This variable adds meaning to product information and helps systems and users quickly understand the differences and various features of products. VariantType Features: Name: Variant Values: Associated Products: Categorization: Extendable Information: Example: VariantType: Color Using VariantType allows for easy and improved modeling of variable product information, enabling users to quickly find the products they need. Second Example: VariantType is a variable used to model types of variable features within a group of products. This variable adds meaning to product information and helps systems and users quickly understand the differences and various features of products. VariantType Features: Name: Variant Values: Associated Products: Categorization: example: using VariantType allows for easy and improved modeling of variable product information, enabling users to quickly find the products they need. this code illustrates the structure of VariantType, its features, and an example for a product with variable colors. thank you |
|
@Alireza-Naji, could you please open a new issue for your request? You're asking for something that is out of scope for this thread. |
|
@briansackett, you seem to have all kinds of questions about how you should do things for Google. I suggest you take your questions to their forum. We do not handle that here. |
github-actions
bot
removed
the
no-issue-activity
and others
(edit by @danbri June 2020; see also: #2587)
One of the things I keep running into over and over again is that there currently is no way to express a 'variant' relation between products without the use of
ProductModel. Which IMO is an serious issue as there are far more products out there of which publishers don't have info about / a resource for theProductModelthan there are publishers that do have such info.For example, cell phone cases - a type of product that often is available in several colors yet for which, more often than not, doesn't exist a resource containing product model information, eg:
4 variants (color) of the same product of which the
ProductModel.nameis 'Evo Check' according to their own structured data, but that's all the info there is.Currently such products can only be sort-of chained together by using either the
isSimilarToorisRelatedToproperties, which IMHO, don't express the correct relation (andsameAsdoesn't do it for me either).And so I suggest we change the domain and range of
isVariantOffromProductModeltoProduct.Interesting note:
This topic became top of mind for me again when I was studying Google's Merchant Center documentation, which contains an example of an array of unchained products that implies a group of product variants on a single page (try adding a
mainEntityOfPageto that example, which is important if there are also other top-level entities on a page, besides the product variants).So the way I see it is that even Google isn't sure how to handle the relation between product variants and uses an array as a poor man's solution to come to some sort of implied semantics where explicit semantics are needed.
The text was updated successfully, but these errors were encountered: