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
|
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. |
|
@danbri small quibble, but... could we get the description on https://webschemas.org/ProductGroup to also mention "features" perhaps like:
1 example use case: |
|
@thadguidry what would "features" look like in terms of schema markup here? |
|
@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: and then in ProductModel you have those further feature options of the drive horsepower: 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? |
|
@alex-jansen in the example:
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). |
|
@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. |
|
This issue is being tagged as Stale due to inactivity. |
github-actions
bot
added
the
no-issue-activity
|
I see that schema:ProductGroup is online, so I'm trying it out based on earlier suggestions. A couple of possible inconsistencies that arise:
|
|
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
removed
the
no-issue-activity
|
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. |
|
This issue is being tagged as Stale due to inactivity. |
github-actions
bot
added
the
no-issue-activity
jvandriel commentedNov 14, 2017
•
edited by danbri
(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: