Usability/quality issues with Offer (price, gtin, ...)

[danbri]

http://schema.org/Offer http://schema.org/price

(originally relayed from a colleague, Matthias)

Fixed already:

• [x] price field, can we say something clearer about localization (use of €, $ symbols, '.', ',' for decimal vs 1000s, @content?). e.g. $ is ambiguous
• [x] we could point out '.' vs ',' are ambiguous (http://en.wikipedia.org/wiki/Decimal_mark#Hindu.E2.80.93Arabic_numeral_system).
• [x] Maybe we should we just say "without using '.' or ',' for 1000s", and using '.' for decimals? We can also note that both Microdata and RDFa allow localised human-facing markup to say one thing, but an equivalent decimal value can be written in the @content="..." attribute.
• [x] gtin. we should link to http://www.gs1us.org/about-gs1-us/media-center/press-releases/gtin-validation-guide.
• [x] a way of indicating the main offer in a page ('mainEntity' use case?) would be useful. Fixed in #301"

  Open...

• [ ] can we say something about whether tax is included in price?
• [ ] also consider adding examples or shortcut properties that show how to describe related products via their gtin.
• [ ] show a product example for mainEntityOfPage - the problem is that a merchant's web-site contains multiple offers, the "main" one and typically related product/offers, but also offers for the same product by different sub-sellers." e.g. http://www.walmart.com/ip/Teenage-Mutant-Ninja-Turtles-2014-Blu-ray-Gift-Set-With-Figurines-Walmart-Exclusive-Widescreen/38234327
• [ ] see also notes below...

[danbri]

http://schema.org/productID is vague too; what should it contain?

"What are the allowed prefixes? isbn? gtin? ean? jan? upc? sku? mpn? is the colon mandatory? Is the prefix case sensitive?" (Matthias)

[danbri]

"From the parsing point of view, the best would be to have price without any grouping or cosmetic characters, in latin letters and the decimal point. And no currency mark, and currency being populated. i.e. 12345678.90" "the ascii requirement is important, the current spec allows (does not disallow) １２３４５ or 一二三四五六"

(from Matthias, the aforementioned colleague who raised this).

[danbri]

More detailed feedback around Offer from Matthias. These should be broken out into separate issues by logical group (availability, Actions, etc.), but for now just to record them in public:

• "There is an implicit relationship between availability and availableAtOrFrom, the second only makes sense if availability is InStock, InStoreOnly, LimitedAvailability, PreOrder maybe make that relationship explicit, i.e. say that populating availableAtOrFrom when availability is OnlineOnly is absurd.
• The definitions for availability are pretty fuzzy, what does in stock mean? These days, no merchant has any warehouse, or stock. What does limited availability mean? As of this year, Google shopping only has three values: "preorder" (orders are taken, but the item is not available yet), "in stock" you can order the item and it will ship, "out of stock" you cannot buy the item.
• Maybe mention that either price + priceCurrency should be populated OR priceSpecification, not both…
• It is strange to have an MPN (Manufacturer Part Number) field, but no Manufacturer field.
• validFrom and validThrough refer to the item, what does this mean? Should this not be the offer? If the fields really relate to the item, should they not be on the item itself?
• Some clarification / recommendation between an Offer and its child potentialAction/BuyAction, should this be the buy button?
• Why does TradeAction have a price field, and not an Offer? In turn BuyAction, reproduces more fields from Offer: seller, warrantyPromise…"

[danbri]

I've left this overly general, semi-meta issue open for sdo-gozer. What specifics can we easily address for this current looming release? Other aspects need breaking out into their own issues and filing against Q2.

I'm aware also that a related question about area pricing - see https://github.com/schemaorg/schemaorg/wiki/PricingByArea - was only partially answered.

/cc @mfhepp

[mfhepp]

@danbri Thanks for CCing me. I admit I did not see this issue so far. Will try to address this for the post-gozer release. Martin

[danbri]

Yes, I don't see anything leaping forward to be included in the next release

[github-actions[bot]]

This issue is being tagged as Stale due to inactivity.

[gmackenz]

@danbri Should we close this issue as obsolete?

[danbri]

Yes

On Thu, 24 Oct 2024 at 17:22, Gordon Mackenzie @.***> wrote:

@danbri https://github.com/danbri Should we close this issue as obsolete?

— Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/99#issuecomment-2435728462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGIHWSFKMPBTQ7ZBA7DZ5ENEPAVCNFSM6AAAAABQRO4ST6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZVG4ZDQNBWGI . You are receiving this because you were mentioned.Message ID: @.***>

[gmackenz]

Thanks for the quick response Dan, I am slowly checking all the long outstanding issues with the originators. Apologies but I lack the admin rights to be able close this issue myself.

[MatthiasWiesmann]

Closing this issue then.