RE: How to encode a product family?

Hi Alexandre,

I've been mulling this over for a while now for use cases in electronic component industry. 
I'm coming at this not only from an angle of how to publish the data to outside world, but also how to make it easier to manage all this product information in the internal systems.

Here there is a clear case for using schema:ProductModel to indicate some hierarchy of product variants.
For example to indicate that multiple implementations of a design might adhere to the same specification (i.e. datasheet).

For phones this might be that a different BOM of components is used (e.g. for cost down), but from consumer perspective it does the same thing.
For consumer electronics maybe the internals of the phone are not so interesting, but this can be critical in the electronic component world.

There is defnitenly a strong case from marketing to have some level above the product model for a 'series' of products - maybe synonymous with a 'product line'.

The 'series' *could* be thought of as a higher level schema:ProductModel but as Martin indicated reasoning gets very difficult with multiple layers of variants (been there, done that). Furthermore given the usage (<10 domains) I would be very surprised if any consumers of such data implement such non-transitive yet multi-level transfer/inheritance of data.

I've been thinking the opposite way round, whereby a 'series' would instead specify the key characteristics a product must have in order to be a member of the series. Such that a marketeer can define their view of a product that fulfils certain market needs and 'hey presto' it is automatically populated with the actual products based on a query against the product catalog. 
Such a series is below a category or even a brand/family, but above a product model.
For Apple the series might be 'iPhone 6s' (http://www.apple.com/iphone-6s/) which contains two product models the 'iPhone 6s (4.7" screen)' and 'iPhone 6s Plus (5.5" screen)' each of which has multiple variants for colors, memory, carrier, etc. 

Although the two models in the series share much in common (same processor, software etc.), they have some crucial differences (screen size, battery life).
The specs page (http://www.apple.com/iphone-6s/specs/) seems to make a clear split at this level (albeit where common properties are merged - can be just a UI choice).

Does that make sense?

Regards,
John

> -----Original Message-----
> From: bertails@apple.com [mailto:bertails@apple.com]
> Sent: Tuesday, May 03, 2016 8:49 PM
> To: Martin Hepp <mfhepp@gmail.com>
> Cc: Dan Brickley <danbri@google.com>; schema.org Mailing List <public-
> schemaorg@w3.org>
> Subject: Re: How to encode a product family?
> 
> 
> > On May 3, 2016, at 11:43 AM, Martin Hepp <mfhepp@gmail.com> wrote:
> >
> > Hi Alexandre,
> > that looks good!
> 
> I do like the result :-)
> 
> >> On 03 May 2016, at 20:38, Alexandre Bertails <bertails@apple.com>
> wrote:
> >>
> >> Thanks Martin and all for the detailed responses. I think I understand a bit
> better how it could be done now.
> >>
> >> What do you think of the following?
> >>
> >> [[
> >> ## I still feel like we could have schema:ProductFamily as a subclass
> >> of schema:Brand
> >
> >
> > I agree that if we want schema:ProductFamiliy, it should be a subtype of
> schema:Brand and be clearly separate from the
> Product/Service/ProductModel types.
> >
> > The question is whether documenting the use of schema:Brand for this
> purpose is as good as defining a subtype which does not introduce new
> properties.
> >
> > As a compromise, we could add "Product families are also a form of Brand"
> to the description of schema:Brand and schema:brand, and add an example
> for this scenario to schema:Brand, schema:brand, and
> schema:ProductModel.
> 
> schema:Brand does say it's about "labeling a product, product group, or
> similar". I guess "product group" is already very close to "product family". The
> thing is, I would have never found it by myself through the specification :-)
> 
> Alexandre
> 
> 
> 
> >
> > Martin
> >
> >> <http://www.apple.com/iphone/#thing> a schema:Brand ; schema:url
> >> <http://www.apple.com/iphone/> ; schema:name "iPhone" .
> >>
> >> <http://www.apple.com/iphone-5/#thing> a schema:ProductModel ; ##
> >> note /iphone-5/ now redirects to /iphone/ schema:url
> >> <http://www.apple.com/iphone/> ; schema:name "iPhone 5" ;
> >> schema:brand <http://www.apple.com/iphone/#thing> .
> >>
> >> <http://www.apple.com/iphone-6s/#thing> a schema:ProductModel ;
> >> schema:url <http://www.apple.com/iphone-6s/> ; schema:name "iPhone
> >> 6s" ; schema:brand <http://www.apple.com/iphone/#thing> .
> >>
> >> <http://www.apple.com/shop/buy-iphone/iphone6s#gray_64gb> a
> >> schema:ProductModel ; schema:url
> >> <http://www.apple.com/shop/buy-iphone/iphone6s> ; schema:name
> "iPhone
> >> 6s Space-Grey, 64 GB" ; schema:isVariantOf
> <http://www.apple.com/iphone-6s/#thing> .
> >> ]]
> >>
> >> Note that in our case, we need to be precise about the entities we
> manipulate, and where they appear. Our database is www.apple.com.
> >>
> >> Best,
> >> Alexandre
> >>
> >>
> >>> On May 3, 2016, at 8:45 AM, Martin Hepp <mfhepp@gmail.com> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> when "product family" means a mere group of products that serve a
> similar purpose, I would use schema:category for the group (e.g. "iPhone").
> schema:isVariantOf is meant for linking from base models to fully specified
> models.
> >>>
> >>>
> >>> So here is what I would use:
> >>>
> >>> @prefix pto: <http://www.productontology.org/id/> .
> >>>
> >>> foo:iphone1 a schema:ProductModel, pto:Smartphone;
> >>> 	schema:name "iPhone 1";
> >>> 	schema:category "Apple iPhone Family".
> >>>
> >>>
> >>> foo:iphone2 a schema:ProductModel, pto:Smartphone;
> >>> 	schema:name "iPhone 2";
> >>> 	schema:category "Apple iPhone Family".
> >>>
> >>> foo:iphone3 a schema:ProductModel, pto:Smartphone;
> >>> 	schema:name "iPhone 3";
> >>> 	schema:category "Apple iPhone Family".
> >>>
> >>> foo:iphone3gs a schema:ProductModel, pto:Smartphone;
> >>> 	schema:name "iPhone 3 GS";
> >>> 	schema:category "Apple iPhone Family".
> >>>
> >>> foo:iphone4 a schema:ProductModel, pto:Smartphone;
> >>> 	schema:name "iPhone 4";
> >>> 	schema:category "Apple iPhone Family".
> >>>
> >>> foo:iphone5 a schema:ProductModel, pto:Smartphone;
> >>> 	schema:name "iPhone 5";
> >>> 	schema:category "Apple iPhone Family".
> >>>
> >>> foo:iphone5se a schema:ProductModel, pto:Smartphone;
> >>> 	schema:name "iPhone 5 SE";
> >>> 	schema:category "Apple iPhone Family".
> >>>
> >>>
> >>> Then, I would materialize all or the relevant fully specified models, like
> my new iPhone 5 SE in space-grey with 64 GB:
> >>>
> >>>
> >>> foo:iphone5se_gray_64gb a schema:ProductModel, pto:Smartphone;
> >>> 	schema:name "iPhone 5 SE Space-Grey, 64 GB";
> >>> 	schema:category "Apple iPhone Family";
> >>> 	schema:color "space gray";
> >>> 	schema:additionalProperty
> >>> 		[ a schema:PropertyValue;
> >>> 		  schema:name "capacity";
> >>> 		  schema:unitText "GB" ] .
> >>> 	# add more features here, see http://schema.org/PropertyValue for
> >>> examples
> >>>
> >>>
> >>> Then I would state that each fully specified model is a variant of its base
> model:
> >>>
> >>> foo:iphone5se_gray_64gb schema:isVariantOf foo:iphone5se.
> >>>
> >>> You could also also indicate that the newer models are successors of the
> older ones:
> >>>
> >>> foo:iphone5se schema:successorOf foo:iphone5 .
> >>> foo:iphone5 schema:successorOf foo:iphone4 .
> >>> foo:iphone3gs schema:successorOf foo:iphone3 .
> >>> foo:iphone3 schema:successorOf foo:iphone2 .
> >>> foo:iphone2 schema:successorOf foo:iphone1 .
> >>>
> >>>
> >>> Note that successorOf is intended to be transitive (see
> http://www.heppnetz.de/ontologies/goodrelations/v1.html#successorOf),
> but we have not yet made this explicit in schema.org, because meta-
> properties for properties were not supported initially.
> >>>
> >>> schema:isVariant is not transititve, because properties should be passed
> from the generic model to the fully specified ones with a pragmatic
> mechanism for overriding a property (a property will not be passed along if it
> is already locally specified, see http://wiki.goodrelations-
> vocabulary.org/Axioms#Recommended_Default_Rules). For this, the
> ordering of inferences can matter as soon as we have more than one level of
> hierarchy. If you allow complex variant relationships, the reasoning gets very
> difficult.
> >>>
> >>>
> >>> Further references (not all up to date):
> >>>
> >>> http://wiki.goodrelations-vocabulary.org/Documentation/Product_varia
> >>> nts
> >>> https://lists.w3.org/Archives/Public/public-vocabs/2011Oct/0040.html
> >>>
> >>>
> >>> Hope that helps!
> >>>
> >>> Martin
> >>>
> >>>
> >>> -----------------------------------
> >>> martin hepp  http://www.heppnetz.de
> >>> mhepp@computer.org          @mfhepp
> >>>
> >>>
> >>>
> >>>
> >>>> On 03 May 2016, at 17:18, Dan Brickley <danbri@google.com> wrote:
> >>>>
> >>>> +Martin Hepp
> >>>>
> >>>> On 3 May 2016 at 16:01, Alexandre Bertails <bertails@apple.com>
> wrote:
> >>>>> Folks,
> >>>>>
> >>>>> I am trying to encode the following things in Schema.org:
> >>>>>
> >>>>> 1. "iPhone is a Product family."
> >>>>>
> >>>>> 2. "iPhone 6s is part of the iPhone Product family."
> >>>>>
> >>>>> 3. all the Products of a Product family would be related to each other
> (schema:isRelatedTo), and/or similar to each other (schema:isSimilarTo).
> >>>>>
> >>>>> Except for 3., I cannot find something that would capture exactly the
> notion of Product family.
> >>>>
> >>>>
> >>>> You might look at http://schema.org/ProductModel and isVariantOf
> >>>> ("A pointer to a base product from which this product is a variant.
> >>>> It is safe to infer that the variant inherits all product features
> >>>> from the base model, unless defined locally. This is not
> >>>> transitive.") and predecessorOf/successorOf (which I now see should
> >>>> be marked as mutual inverses, issue filed as
> >>>> https://github.com/schemaorg/schemaorg/issues/1142 ).
> >>>>
> >>>> I guess you'd need to figure out the constant "essence of iPhone"
> >>>> and make a generic ProductModel for that, and then relate them. I'm
> >>>> not sure how deep you'd want this to go e.g. I have an (excellent
> >>>> if
> >>>> ageing) iPad Mini, presumably part of an iPad Product family; would
> >>>> se use isSimilarTo vs iSvariantOf to link iPhone and iPad families
> >>>> together?
> >>>>
> >>>> Dan
> >>>>
> >>>>
> >>>>> Any idea?
> >>>>>
> >>>>> Alexandre
> >>>
> >>
> >
>

Received on Tuesday, 3 May 2016 21:09:59 UTC