Alignment to e-commerce ontologies

[pipauwel]

Georg: about the definitions for the bot:Element and product:Product, we should consider looking at the GoodRelations definition at ([http://wiki.goodrelations-vocabulary.org/Documentation/Product_or_Service]). GoodRelations distinguishes between three kinds of products:

1. A real product like my laptop, my car with this VIN and mileage, a particular item on an eBay auction - gr:Individual.
2. A product model, i.e. a datasheet, like "Nikon T90", "iPod Nano 16 GB", or similar. - gr:ProductOrServiceModel.
3. Then we have a third case, in which the entities exposed on the Web are neither products nor product models, but instead "black boxes" of products. - gr:SomeItems.

These three subtypes are powerful, but it is of course also allowed to use the common abstraction gr:ProductOrService.

Pieter: In that case, we should probably opt to align bot:Element and product:Product to a number of these subClasses. Likely, bot:Element should then align with gr:Individual, while product:Product should align with gr:ProductOrServiceModel. => To be checked with Prof. Martin Hepp [call 5th October]

[GeorgFerdinandSchneider]

From the presentation today by Martin Hepp I think this needs to be revised

• gr:Individual would relate to an owl:NamedIndividual of a bot:Element

• gr:ProductOrServiceModel would relate to bot:Element

From the discussion of Martin and Mads

Mads: You make a distinction between the product and the product model. What I find is that we build a requirements document for a product model to begin.
Martin: Product model may be too narrow a term. When you are talking about specifications, you model a prototype that has certain characteristics, you can use goodrelations to model an abstract product or service model. You could say “I need a lawnmower than needs less than 2 amperes” or “I need a certain oven with certain energy usage” and with the product feature relation, you can model intervals. So we can model an “ideal” of a product in goodrelations.
Mads: Yes, and we do this as designers. Stakeholders specify their requirements for a particular
component.
Martin: Once this has an identity via its URI, and different requirements (cost, safety, energy efficiency, etc.) can be associated to this. May be done in a quad space with contradicting graphs.

• gr:SomeItems to several owl:NamedIndividuals of bot:Element

[GeorgFerdinandSchneider]

Providing a top level alignment with GR ontology should be doable and might be added as a LDAC 2017 Action item

[GeorgFerdinandSchneider]

As schema.org is fully swallowing GR schema.org might be better to use.

please find some idea for alignment with schema.org below

[GeorgFerdinandSchneider]

See a revised version of modelling product data using the producttypesontology.org derived from wikipedia and schema.org

EDIT: The use of PTO ontology to model properties is NOT recommended!

It might makes sense to think about the semantic relationships between

bot:Element and schema:ProductModel, schema:Product, schema:IndividualProduct

[GeorgFerdinandSchneider]

Please note, the PTO ontology reuses identifiers from the real wikipedia - hence if they use under scores in the URI it will also be in the PTO URI.

Taking the coefficient of performance example:

The wikipedia URI is:

https://en.wikipedia.org/wiki/Coefficient_of_performance

The corresponding PTO URI is hence

http://www.productontology.org/id/Coefficient_of_performance

Depending on the HTTP request type different content is return by the PTO web service (RDF, TTL; HTML).

See also the documentation on

http://www.productontology.org/

PTO also provides multilingual labels which are human readable rather then the URI itself.

Best

Georg

[MadsHolten]

Using PTO will infer the following:

<http://www.productontology.org/id/Coefficient_of_performance> a owl:Class ;
	rdfs:subClassOf gr:ProductOrService, schema:Product .

It is not true that it is a product, so maybe we should just copy the service for properties and infer:

<http://www.propertyontology.org/id/Coefficient_of_performance> a owl:Class ;
	rdfs:subClassOf props:Property, schema:Property .

[GeorgFerdinandSchneider]

Hmm this could be problematic.

However in http://meta.schema.org/Property the schema:additionalType is suggested to use also with schema:Property.

[MadsHolten]

I made this visualization from where we can start sketching.

It is based on this json-file, and if you add a new item to the array it will automatically create a new tab.

[GeorgFerdinandSchneider]

Correct! As indicated by Mads and also confirmed by the PTO authors it is NOT recommended to use PTO ontology to describe properties.

[RichardPinka]

Hello there,
just one comment to add to the example of heat pump property "Coefficient of performance" :
I see that this property has only one number. I consider it as wrong, or better to say - not exact.
This value is useless for exact engineering, as far I did use these data during my work. In this property, much more values according the refrigerant cycle charasteristics has to be prepared to be stored in the product model. COP (or EER ) as one number value, is only kind of marketing purpose, or fast orientation. It has nothing to do with proper design.
That means, proper data from manufacurer stored in this product data model shall be curve/polyline or more/less detailed 3D surface. These are chosen according the Designer´s HP control preferences (eg. fixed or variable condensing temperature) or by possibilities of manufacturer´s ability to ofere such technical data.
You can define these values either in analytic forms : polynomials, or in exact in table(or cube) made by lab measurements.
That means, in each property shall be the amount of spaces/dimensions exactly defined and it is not impossible to think that some properties may have more than 3 dimensions.
for example : valueSpace: Integer ; valueSpace: 2Dimensional; valueSpace: 4Dimensional etc..

For now, I still do not know how to model ontologies and graphical relationships, I hope i improve myself, but this is wery important to mention this property of properties :))
If you want to let industrial data be understood by another functionalities/applications via ontologies, this is important for implementing.

[GeorgFerdinandSchneider]

Thanks Richard for pointing this out. I tried to fill your complaint into a requirement defition presented here: LINK