Re: How to encode a product family?

Hi Jarno:

> On 03 May 2016, at 19:55, Jarno van Driel <jarnovandriel@gmail.com> wrote:
> 
> foo:iphone5se_gray_64gb a schema:ProductModel, pto:Smartphone;
>         schema:name "iPhone 5 SE Space-Grey, 64 GB";
>         schema:category "Apple iPhone Family";
> 
> Looks nice but there are a couple of practical issues I got with this.
> 
> 1] "pto:Smartphone"
> 
> Even though this sounds nice in theory in all the years I've been doing this I still have to encounter an employer/client that's willing to map 1000+ categories to external enumerations simply because they don't see the added value in comparison to the costs of setting this up and maintaining it (unless it's for advertisement feeds). In the end, if manufacturers/data companies don't provide to such data to e-commerce sites the costs of adding this type of data manually simply is too high for most.

This was just for the Apple case - for a manufacturer with a moderate number of types of products, this seems realistic.
For a retailer with 100k product from thousands of categories, this isn't.

> 
> 2] "schema:category "Apple iPhone Family";"
> 
> On many sites I've worked on things are categorized as: mobile > smartphone > iphone > iphone 5 SE. A type of categorization where each layer of categories is a product listing page. How do you imagine handling that, maybe something like this?

First, note that you can have multiple values for schema:category, so you can keep both product family and shop hierarchy in two separate values. But I share Vicki's argument for schema:brand.


> 
> <script type="application/ld+json">
> {
>   "@context": "http://schema.org",
>   "@type": "Product",
>   "name": "iPhone 5 SE Space-Grey, 64 GB",
>   "url": "http://www.example.com/product/iphone-5se-space-grey-64-gb",
>   "category": 
>   {
>     "@type": "CollectionPage",
>     "name": "iPhone 5 SE",
>     "url": "http://www.example.com/mobile/smartphone/iphone/iphone5se",
>     "about": 
>     {
>       "@id": "#Brand"
>     }

While formally okay, I would not use a CollectionPage entity as the value for schema:category.

>   },
>   "brand":
>   {
>     "@type": "Brand",
>     "@id": "#Brand",
>     "name": "iPhone 5 SE"
>   } 
> }
That looks reasonable.

> </script>
> 
> "If the backend database does not contain a product family relation, rather use schema:category with a text value and let the big search engines do the entity consolidation. After all, they have more data and processing power than a single site ;-)"
> 
> +1 
> 
> "i.e. we just have to encourage them to *expose* better data"
> 
> Well, that's my aim here, not to add something new to the schema perse. However, I've read plenty questions about how to express product families, while running into these sorts of situations myself as well. Unfortunately there's little to find in regards to marking up product listing pages, categorization and product 'families'.
> 
> Maybe we could do something about the unclarity by providing some schema.org examples that show how one could express the notions product listing pages, categorization and product 'families'? 
> 
> I have no problem spending some time on this but to do so will require a better notion of what is considered a best practice for this sort of situation.

It would definitely good to improve the set of examples in schema.org here. But there are many ends to work at and only a few hands around, so this takes time.


> 
> --
> 
> Note: Adding a 'topicOf' property to schema.org/Tthing might help here as well as we then could express (and avoid the use of fragment identifiers):
> 
> <script type="application/ld+json">
> {
>   "@context": "http://schema.org",
>   "@type": "Product",
>   "name": "iPhone 5 SE Space-Grey, 64 GB",
>   "url": "http://www.example.com/product/iphone-5se-space-grey-64-gb",
>   "category": 
>   {
>     "@type": "Brand",
>     "name": "iPhone 5 SE", 
>     "topicOf":
>     {
>       "@id": "http://www.example.com/mobile/smartphone/iphone/iphone5se"
>     }
>   }
> }
> </script>
> 

Doable, but I am not very optimistic that clients will actually use this information.

Martin


> 
> 2016-05-03 17:57 GMT+02:00 Jarno van Driel <jarnovandriel@gmail.com>:
> "Could you not refer to the manufacturer's page for asserting  such a relationship?:"
> 
> Oh, one could definitely do so but the problem I keep running into on large scale e-commerce sites is that the product data they receive/have in 99% of the cases doesn't contain any 'product family' nor any 'manufacturer's page' information. Which is a serious issue for sites containing more than 100k products as on that scale it isn't feasible to manually find/add such information.
> 
> What happens in these cases is that such parties write algo's that compare products based on the information they do have ('name', 'brand' and some string information) to 'sort of' deduct what the product family is. But since the outcome of such algo's often contain a certain error rate it's nearly impossible to state these fall under the same product model. 
> 
> The end result more often than not is an approximated grouping these businesses internally call product families and which most of the time differ from the product manufacturers state are part of a product model line.
> 
> Something that makes me wonder for a long time already whether we should have ProductFamily type to accommodate this type of grouping.
> 
> 2016-05-03 17:37 GMT+02:00 Hans Polak <info@polak.es>:
> Hi Alexandre,
> 
> Could you play around with it here https://generator-1260.appspot.com/ProductModel ?
> 
> I'd love to get more feedback.
> 
> Cheers,
> Hans
> 
> 
> 
>

Received on Tuesday, 3 May 2016 18:39:53 UTC