Remove product properties from schema:Offer

[mfhepp]

For historic reasons, a few product properties were also allowed on schema:Offer.These are now more confusing than useful, and I recommend to remove them from schema:Offer.

gtin12
gtin13
gtin14
gtin8
mpn
serialNumber

In some cases, we also have to polish the textual description of the properties, as in the case of serialNumbe (currently: "The serial number or any alphanumeric identifier of a particular product. When attached to an offer, it is a shortcut for the serial number of the product included in the offer.")

If there is agreement, I am happy to craft a pull request for that.

PS: This change might break a little bit of data that is out there, but I think the pain is worth it.

[jvandriel]

+1

[ekgs1]

I was curious why the product identifiers were in both the product and the offer in the original design. Was this for ease of use?

[mfhepp]

I need a bit of history to explain that:

1. From its very beginning, GoodRelations had a clear distinction between products and offers, so gr:Offering (now schema:Offer) had only commercial properties (price, business function, ...) and gr:ProductOrService (now schema:Product) held only properties for the actual thing and not its use in offers or transactions.
2. When we worked with Google in 2010 on Google support for GoodRelations in RDFa, simplicity of markup was a key concern. RDFa 1.0 was difficult, Microdata not yet known (afaik), JSON-LD absent. People had to weave in RDFa markup directly into visible content, and RDFa skills were rare among developers.
3. We found that in many sites, the data about a product was limited to a name, description, and maybe image, plus commercial aspects.
4. After considering back and worth, I agreed to add a few properties from products to gr:Offering so that in these very simple cases, one could collate the markup to one entity.

Note that this was well before schema.org.

Now, when schema.org was released, it reused the distinction between products and offers from GoodRelations with an initially very small e-commerce model.

From 2011 through 2012, I worked with the sponsors of schema.org on a comprehensive integration of GoodRelations into schema.org. In that step, we added various properties to schema:Offer that are actually properties of the products mentioned in an offer.

Now, with the thrust of so many consumers of schema.org and better syntaxes, tooling, and a generally better skill level in the community, we are in a position to remove a few anomalies in schema.org, even if that means that a bit of older markup becomes invalid.

We already removed width, weight, height, etc. in an earlier step.

My proposal now is also to remove these product identifiers and rather foster the proper modeling of products inside offers.

"And now you know the rest of the story." (Paul Harvey)

[ekgs1]

Thank you for the history. +1

[vholland]

+1

[dbs]

I have a concern about the removal of schema:serialNumber from Offer. While gtin* and mpn are generic properties of products (that is, a run of a given product will all have the same gtin* / mpn), serial numbers are unique identifiers that differentiate one instance of a Product from another... and thus, it is a useful differentiator to apply to the Offer, in a scenario where you have multiple instances of a single product.

I recognize that the GoodRelations alternative would be to use IndividualProduct, which is also where serialNumber lives. It appears that that would entail duplicating all of the other Product property values on each of the IndividualProduct, just to differentiate the serial number; there doesn't currently seem to be a good way to say "this IndividualProduct is an instance of this Product". The data for the usage of IndividualProduct vs. serialNumber seems to bear this out for schema.org publishers; IndividualProduct currently has 10 - 100 domains of usage, while serialNumber has 1,000 - 10,000 domains of usage, which strongly suggests that most sites are using serialNumber on Offer as a useful pattern of differentiating the instances of the product that are on offer.

I do have a particular, practical use case in mind: in February 2014, the W3C SchemaBibex community dubbed http://www.w3.org/community/schemabibex/wiki/Holdings_via_Offer a "recommended best practice" for reflecting library holdings in schema.org, and a core part of that is using serialNumber on Offer.

So, I am -1 to removing serialNumber from Offer, but +1 on removing the other more generic properties from Offer.

[inetbiz]

I would say that serial numbers should be an action status such as checking the status of an order from gmail structured markup / order status pages.

[RLRichardson]

Identifiers are not actions, but can be used to enable or trigger actions

[mfhepp]

Hi @dbs: I think there is a cleaner way to model what you seem to want to achieve. But given the fact that you are using serialNumber in existing best practices, I think we should simply keep serialNumber and deprecate the others.

[radusi]

Hi, if for some reasons, gtin remains, could't it be URI ?

[danbri]

I believe the GS1 plan is to converge gtin* properties to a single property, which I totally support.

[ekgs1]

Hi Dan, in GS1 vocabulary we have consolidated the various GTINs into a single gtin property.

[danbri]

#1244

maybe we can add text discouraging use on Offer, at least?

[github-actions]

This issue is being tagged as Stale due to inactivity.

[lukebrowell]

Appreciate that this issue has gone stale. If indeed this issue has yet to be formerly resolved, May I propose that the legacy GTINs be marked as deprecated so that we can close this issue?

[danbri]

We now do have http://schema.org/gtin as @lukebrowell points out.

ping @alex-jansen - it would be good to know that data-consuming platforms (e.g. Google) are using the new consolidated property, before deprecating the others in favour of it.