Re: How to encode a product family?

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

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?

<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"
    }
  },
  "brand":
  {
    "@type": "Brand",
    "@id": "#Brand",
    "name": "iPhone 5 SE"
  }
}
</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.

--

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>


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