Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the domain and range of isVariantOf to Product #1797

Open
jvandriel opened this issue Nov 14, 2017 · 34 comments
Open

Change the domain and range of isVariantOf to Product #1797

jvandriel opened this issue Nov 14, 2017 · 34 comments
Assignees
Labels
no-issue-activity

Comments

@jvandriel
Copy link

jvandriel commented Nov 14, 2017

(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 the ProductModel than 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.name is '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 isSimilarTo or isRelatedTo properties, which IMHO, don't express the correct relation (and sameAs doesn't do it for me either).

And so I suggest we change the domain and range of isVariantOf from ProductModel to Product.

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 mainEntityOfPage to 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.

@jvandriel jvandriel changed the title Change the domain of isVariantOf to Product Change the domain and range of isVariantOf to Product Nov 15, 2017
@jvandriel
Copy link
Author

jvandriel commented Nov 15, 2017

What I'm hoping to achieve is that, when ProductModel info isn't available, publishers will be able to specify product variant relations as such in a:

Single page environment - base product

[
  {
    "@context":"http://schema.org",
    "@id":"#baseProduct",
    "@type":"Product",
    "name":"Evo Check Case for Galaxy S8 Rose Tint/White",
    "color":"Rose Tint/White",
    "sku":"T21-5664",
    "mainEntityOfPage":"https://www.tech21.com/en_us/evo-check-s8-rose-tint-white",
    "url":"https://www.tech21.com/en_us/evo-check-s8-rose-tint-white"
  },
  {
    "@type":"Product",
    "name":"Evo Check Case for Galaxy S8 Light Blue/White",
    "color":"Light Blue/White",
    "sku":"T21-5586",
    "isVariantOf":
    {
      "@id":"#baseProduct"
    }
  },
  {
    "@type":"Product",
    "name":"Evo Check Case for Galaxy S8 Clear/White",
    "color":"Clear/White",
    "sku":"T21-5584",
    "isVariantOf":
    {
      "@id":"#baseProduct"
    }
  },
  {
    "@type":"Product",
    "name":"Evo Check Case for Galaxy S8 Smokey/Black",
    "color":"Smokey/Black",
    "sku":"T21-5585",
    "isVariantOf":
    {
      "@id":"#baseProduct"
    }
  }
]

Multi page environment - base product

[
  {
    "@context":"http://schema.org",
    "@id":"#baseProduct",
    "@type":"Product",
    "name":"Evo Check Case for Galaxy S8 - Rose Tint/White",
    "color":"Rose Tint/White",
    "sku":"T21-5664",
    "mainEntityOfPage":"https://www.tech21.com/en_us/evo-check-s8-rose-tint-white",
    "url":"https://www.tech21.com/en_us/evo-check-s8-rose-tint-white"
  },
  {
    "@type":"Product",
    "url":"https://www.tech21.com/en_us/evo-check-s8-light-blue-white",
    "isVariantOf":
    {
      "@id":"#baseProduct"
    }
  },
  {
    "@type":"Product",
    "url":"https://www.tech21.com/en_us/evo-check-s8-clear-white",
    "isVariantOf":
    {
      "@id":"#baseProduct"
    }
  },
  {
    "@type":"Product",
    "url":"https://www.tech21.com/en_us/evo-check-s8-smokey-black",
    "isVariantOf":
    {
      "@id":"#baseProduct"
    }
  }
]

Multi page environment - product variant

{
  "@context":"http://schema.org",
  "@type":"Product",
  "name":"Evo Check Case for Galaxy S8 - Smokey/Black",
  "color":"Smokey/Black",
  "sku":"T21-5585",
  "mainEntityOfPage":"https://www.tech21.com/en_us/evo-check-s8-smokey-black",
  "url":"https://www.tech21.com/en_us/evo-check-s8-smokey-black",
  "isVariantOf":"https://www.tech21.com/en_us/evo-check-s8-rose-tint-white"
  }
}

@jvandriel
Copy link
Author

jvandriel commented Nov 15, 2017

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 isVariantOf, namely: hasVariant.

With the following description:

A pointer to a product variant from which this product is the base product. It is safe to infer that the variant inherits all product features from the base model, unless defined locally. This is not transitive.

Making the following possible for a:

Single page environment - base product

{
  "@context":"http://schema.org",
  "@type":"Product",
  "name":"Evo Check Case for Galaxy S8",
  "color":"Rose Tint/White",
  "sku":"T21-5664",
  "mainEntityOfPage":"https://www.tech21.com/en_us/evo-check-s8",
  "url":"https://www.tech21.com/en_us/evo-check-s8",
  "hasVariant":
  [
    {
      "@type":"Product",
      "name":"Evo Check Case for Galaxy S8 Light Blue/White",
      "color":"Light Blue/White",
      "sku":"T21-5586"
    },
    {
      "@type":"Product",
      "name":"Evo Check Case for Galaxy S8 Clear/White",
      "color":"Clear/White",
      "sku":"T21-5584"
    },
    {
      "@type":"Product",
      "name":"Evo Check Case for Galaxy S8 Smoey/Black",
      "color":"Smokey/Black",
      "sku":"T21-5585"
    }
  ]
}

Multi page environment - base product

{
  "@context":"http://schema.org",
  "@type":"Product",
  "name":"Evo Check Case for Galaxy S8 - Rose Tint/White",
  "color":"Rose Tint/White",
  "sku":"T21-5664",
  "mainEntityOfPage":"https://www.tech21.com/en_us/evo-check-s8-rose-tint-white",
  "url":"https://www.tech21.com/en_us/evo-check-s8-rose-tint-white",
  "hasVariant":
  [
    "https://www.tech21.com/en_us/evo-check-s8-light-blue-white",
    "https://www.tech21.com/en_us/evo-check-s8-clear-white",
    "https://www.tech21.com/en_us/evo-check-s8-smokey-black"
  ]
}

@jvandriel
Copy link
Author

jvandriel commented Nov 17, 2017

Done tinkering with the proposals and the code examples - feel free to shoot on 'm now

@vberkel
Copy link

vberkel commented Nov 24, 2017

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:

"A datasheet or vendor specification of a product (in the sense of a prototypical description)".

Yet, today's hierarchy goes from most abstract to concrete then back to abstract.
Thing > Product > ProductModel

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:
Thing > ProductModel > Product
We go from most abstract to concrete. A concrete, sellable product is also implied to based on some ProductModel (and Thing).

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.

@thadguidry
Copy link
Contributor

thadguidry commented Nov 24, 2017

@vberkel Its not ProductORModel ... its actually AProductModel
So the heirarchy is fine the way it is.
What needs to change is our current stupid confusing description. Which I never did agreed to. :) (but love ya @mfhepp ! )

The better description and what I alias in my apps is:
"A particular design or version of a Product."

@jvandriel
Copy link
Author

jvandriel commented Nov 27, 2017

Just to make sure I understand you correctly @thadguidry...

ProductModel = Product variant?

Cause if so, that's not how I understand ProductModel, and I'm pretty sure most publishers don't get it that way either, eg. the example I showed above refers to it as if it's a prototypical/abstract and all sites I checked on their use of ProductModel do so.

And if ProductModel = Product variant, than it might be an idea somebody talks to the major search engines as they sure don't treat it as if it's a "A particular design or version of a Product." given the fact none of 'm generate rich snippets for it (which only makes sense to me if it's an abstract).

@thadguidry
Copy link
Contributor

thadguidry commented Nov 27, 2017

@jvandriel ProductModel = model (which could be a variant of another model)

For clarity, scroll to the bottom and see the reversing properties
http://schema.org/ProductModel

In Good Relations and Schema.org...
Products can have Models.
Models can have variants. (another Model)

  • Product = iPhone (but sure, you can say a Product or you can say it is a Model with the text "Evo Check Case for Samsung 8", up to publishers)
    • ProductModel = iPhone 5
    • ProductModel = iPhone 6
    • ProductModel = iPhone 7
    • ProductModel = iPhone 6 S
      • isVariantOf = iPhone 6
      • predecessorOf = iPhone 7
      • successorOf = iPhone 5
  • IndividualProduct = iPhone 6 S
    • serialNumber = "IMEA # AA-BBBBBB-CCCCCC-D"
  • SomeProducts = iPhone 6
    • inventoryLevel = 2500

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.

@jvandriel
Copy link
Author

jvandriel commented Nov 28, 2017

In Good Relations and Schema.org...
Products can have Models.
Models can have variants. (another Model)

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:

  • ProductModel = iPhone 6s
    • @id = #iPhone6s
    • isVariantOf = iPhone 6
    • predecessorOf = iPhone 7
    • successorOf = iPhone 5
  • Product = iPhone 6s 4.7-inch 128 GB Silver
    • model = #iPhone6s
    • color = silver
    • memory = 128 GB
    • hasVariant = ???
    • isVariantOf = ???
  • Product = iPhone 6s 4.7-inch 32GB Gold
    • model = #iPhone6s
    • color = gold
    • memory = 32 GB
    • hasVariant = ???
    • isVariantOf = ???

Something I feel isSimilarTo & isRelatedTo don't cover as these can refer to completely different products (of a different brand) with similar properties as well - reason why I'd like to see the domain and range of isVariantOf be changed to Product as well as adding a reverse property (hasVariant).

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.

Don't know if I agree with you on this one though. Reason being that it's not very often a ProductModel is up for sale - eg, Apple isn't very likely to sell it's iPhone 8 ProductModel though they do sell products. Heck, they even annotate their iPhone 8 as a Product as opposed to a ProductModel.

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 ProductModel itself)

And at the same time, if a ProductModel could be considered a Product than why isn't this reflected by the major search engines by allowing them to generate 'rich snippets'* as well? To me this is an indication they see a substantial difference between the two types as well

* no, I don't want to get into a 'rich snippet' discussion over this, the example is just illustrative

@jvandriel
Copy link
Author

jvandriel commented Dec 22, 2017

@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).

@jaw111
Copy link
Contributor

jaw111 commented Apr 23, 2020

For the use cases I'm commonly dealing with (electronic components) I'd propose to tighten the definition of isVariantOf based around idea of form, fit and function, such that the (manufacturing) variants of a product model must have the same form, fit and function.

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.

@danbri
Copy link
Contributor

danbri commented Jun 5, 2020

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.

  • Although the idea is similar to /ProductModel data sheets, the "product model" construct addresses a slightly different situation (c.f. @jvandriel's point above, "there are far more products out there of which publishers don't have info about / a resource for the /ProductModel than there are publishers that do have such info.").
  • noting that @jvandriel and others have advocated to extend /isVariantOf so that it doesn't just relate /ProductModels to /ProductModels, but also relates specific product variants to general products that stand for a group of predictably-varying products.
  • and that @mfhepp's example markup instead uses an indirection through an Offer to implicitly link a general product to a specific one, i.e. a /Product ("The Hepp Smart Watch is a unique wristwatch.") would have /offers, one for each variant offered, such as "Hepp Smart Watch in Silver with 16 GB RAM", "Hepp Smart Watch in Gold with 64 GB RAM". This is fine when you have such offers to publish, but there seems be a shared desire to model the underlying product situation independently.
  • we see value in introducing a new type, analogous to /ProductModel, to more explicitly represent a group or cluster of varying products. We suggest /ProductCluster for this (or /ProductGroup). It could be used in the styles advocated by either @jvandriel or @mfhepp. This would make it easier for consuming applications to understand when a Product-description was intended as a general vs specific variant, rather than leaving it ambiguous (since sparse descriptions of the variants are otherwise indistinguishable from the general descriptions).
  • we also propose using /ProductCluster to describe common characteristics of the specific product variants in that group or cluster, as well as the nature of the variations (i.e. color, pattern etc.). We expect to propose a mechanism similar to that used in /StatisticalPopulation and /ProductModel for this, where properties applicable to the varying instances can be ascribed to the prototypical "item representing the whole group". 
  • Suggest rewording definition of /isVariantOf to something along these lines, with the details moved out into a dedicated doc: "Indicates a base or parent product that this product is a variant of. Properties of the referenced product are generally also applicable to the variant products, i.e. the convention is to describe a ProductModel or ProductCluster as the shared prototype of all its variants. See [doc] for details."There are reasonable reasons to debate whether extending /isVariantOf is better than a new property, or for that matter whether there's a case to have /ProductModel and the proposed /ProductGroup be a sibling type to /Product rather than a subtype.  Before we spin off into discussion of those details it would be good to re-affirm the value of doing something in this broad direction.

@jvandriel
Copy link
Author

jvandriel commented Jun 5, 2020

Sounds good to me. Personally I'd prefer the name ProductGroup as it's closest to what it's called in other namespaces/specs for marketplaces, which often speak about a 'group' of products.

Any thoughts about the possibility of adding a hasVariant property so there's no dependency on the existence of offers or the need for referencing by fragment identifiers?

@danbri
Copy link
Contributor

danbri commented Jun 5, 2020

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.

@thadguidry
Copy link
Contributor

thadguidry commented Jun 5, 2020

@jaw111
Copy link
Contributor

jaw111 commented Jun 5, 2020

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?

@danbri
Copy link
Contributor

danbri commented Jun 5, 2020

@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.

@jaw111
Copy link
Contributor

jaw111 commented Jun 8, 2020

@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?

@alex-jansen
Copy link
Contributor

alex-jansen commented Jun 8, 2020

@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.

@danbri
Copy link
Contributor

danbri commented Jun 9, 2020

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#

@jaw111
Copy link
Contributor

jaw111 commented Jun 9, 2020

@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?

@alex-jansen
Copy link
Contributor

alex-jansen commented Jun 10, 2020

@jaw111 It makes sense, you are modeling a 3-level hierarchy: series->types->orderable parts, where:

  • types belonging to a series vary based on "packaging"
  • orderable parts belonging to a type vary based on their "packing" (and possibly "quantity")
  • series and types are virtual
  • orderable parts are the tangible (buyable) items

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> .

@jaw111
Copy link
Contributor

jaw111 commented Jun 10, 2020

@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.

@alex-jansen
Copy link
Contributor

alex-jansen commented Jun 11, 2020

@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.

danbri added a commit that referenced this issue Jun 16, 2020
including minimal linking into core via isVariantOf
danbri added a commit that referenced this issue Jun 16, 2020
Needed to pass sanity checks that there are even number of inverseOf claims.
/cc #1797
danbri added a commit that referenced this issue Jun 19, 2020
Hyperlinked 'size' in ProductGroup definition.
Removed accidental quote chars.
/cc #1797
@danbri
Copy link
Contributor

danbri commented Jun 22, 2020

For this issue and #2587 -

This is a work in progress, but I expect to include it in the 9.0 release as a Pending change.

@thadguidry
Copy link
Contributor

thadguidry commented Jun 22, 2020

@danbri small quibble, but... could we get the description on https://webschemas.org/ProductGroup to also mention "features" perhaps like:

A ProductGroup represents a group of Products that vary only in certain well-described ways, such as by, size, color, material etc., and sometimes optionally by features.

{
 "ROTO-GRIND",
 "DUAL-SHAFT",
 "QUAD-SHAFT",
}

1 example use case:
image

@danbri
Copy link
Contributor

danbri commented Jun 22, 2020

@thadguidry what would "features" look like in terms of schema markup here?

@thadguidry
Copy link
Contributor

thadguidry commented Jun 22, 2020

@danbri There's a lot, depending on the ProductGroup and industrial manufacturer. I only gave this one example to illustrate a real world scenario with 2 ProductGroup levels (actually 3 if you count the below drive option which some publishers might further group up and how their catalogs are realized). Anyways, the next ProductGroup feature would be 2 such options:

{
  "Electric drive",
  "Hydraulic drive"
}

and then in ProductModel you have those further feature options of the drive horsepower:

{
  "100hp",
  "125hp",
  etc.
}

and other Model features.

So, many times in industrial manufacturing, as some folks are saying above, like in silicon chip fab, the ProductGroups are sometimes heavily nested with Grouping levels by features, before even reaching the ProductModels that also have features and then finally IndividualProduct's.

I think as a good doc clue to publishers, we should inform them somehow more that they can do feature grouping by ProductGroup or ProductModel, depending on aggregate features in a Product series (line) and that Schema.org can handle that for them. Right now, the descriptions and docs are not really telling of that.

(of course there's the good old Product::category that some publishers do use currently for some Product Grouping but tedious and that's on a Product, which sits under ProductGroup and above ProductModel)

Does that help understand more?

@jaw111
Copy link
Contributor

jaw111 commented Jun 23, 2020

@alex-jansen in the example:

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.

Then is it fair to say the 3-pack and 6-pack would each be a /ProductModel as they are not an /IndividualProduct no /SomeProducts (at least until they are put into a basket or picked off the shelf).

To put it another way, is there any case where one should ever use /Product as it should always be possible to be more specific and use the appropriate subclass instead, otherwise just make everything a /Thing and leave it at that (just to take things to the extreme).

@thadguidry
Copy link
Contributor

thadguidry commented Jun 23, 2020

@alex-jansen "Packages" often do have a SKU (and in the USA, a single UPC label) and treated as a sellable item (fit for sale). A Package offered can be an /IndividualProduct, if it has a serial number (for example, to allow a user to register the individual product to their individual self)

3-pack item and 6-pack item are items being offered, so they are a /Product (fit for sale) or a subtype of /Product.

Also, Schema.org doesn't have much to offer for the supply chain side of things, since it covers only some sides of Trade and Commerce.

@github-actions
Copy link

github-actions bot commented Aug 23, 2020

This issue is being tagged as Stale due to inactivity.

@github-actions github-actions bot added the no-issue-activity label Aug 23, 2020
@jaw111
Copy link
Contributor

jaw111 commented Aug 25, 2020

I see that schema:ProductGroup is online, so I'm trying it out based on earlier suggestions.

A couple of possible inconsistencies that arise:

  1. It's stated above that /ProductGroup would never have a /sku whilst being a subclass of /Product would imply that it may have a /sku
  2. Given that /ProductGroup is a subclass of /Product then would it be appropriate to relate a /ProductGroup to another /ProductGroup using /isVariantOf or /hasVariant

@danbri
Copy link
Contributor

danbri commented Aug 25, 2020

@jaw111

on (1.) - the type hierarchy suggests that /sku might be applicable to all and any Products. But in this case, it isn't. This is similar to openingHours applying to places, and Country being a Place; or faxNumber applying to Volcano. The vocabulary structure only sets out the possibilities, it does not guarantee that there is a sensible value for a property in every instance of every type, even when the property is in general reasonable for that type.

In this case we looked at moving /ProductGroup out to sit in parallel to /Product but the benefits seemed minor enough that we didn't take that direction.

(2.) I'm not sure, I believe this possibility came up. @alex-jansen - ping

@danbri danbri removed the no-issue-activity label Aug 25, 2020
@alex-jansen
Copy link
Contributor

alex-jansen commented Aug 25, 2020

Re.2: Yes, a multi-level hierarchy as discussed earlier in this thread is explicitly supported, so a ProductGroup can have variants that are ProductGroups themselves.

@github-actions
Copy link

github-actions bot commented Oct 25, 2020

This issue is being tagged as Stale due to inactivity.

@github-actions github-actions bot added the no-issue-activity label Oct 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-issue-activity
Projects
None yet
Development

No branches or pull requests

6 participants