Warning: This tool or project is no longer maintained and kept available only for archival purposes. Since GoodRelations and schema.org have evolved significantly in the past years, the current status available on this page is unlikely to function as expected. We take no responsibility for any damage caused by the use of this outdated work, to the extent legally possible.

Due to a lack of resources, we are unable to provide support for this project outside of consulting projects or sponsored research. Please contact us if you can contribute resources to update and enhance these resources.

GoodRelations - The Web Vocabulary for E-Commerce

This is the archive of the goodrelations dicussion list

GoodRelations is a standardized vocabulary for product, price, and company data that can (1) be embedded into existing static and dynamic Web pages and that (2) can be processed by other computers. This increases the visibility of your products and services in the latest generation of search engines, recommender systems, and other novel applications.

[goodrelations] gr:qualitativeProductOrServiceProperty / gr:quantitativeProductOrServiceProperty (was Re: … / gr:datatypeProductOrServiceProperty)

François-Paul Servant fps at semanlink.net
Tue Nov 13 13:51:28 CET 2012


Hi Bene,

thank you for your message.

"A qualitative value is a predefined value for a product characteristic."

I would first note that a predefined value for a product characteristic can very well also be a quantitative value. 

Imagine that you are selling screws. A screw has several characteristics (material, length, threading, …), and the possible values are all standardized, identified by a code (that can be easily transformed to a URI). So, from your database of products, you can easily write triples such as:
:screw1 :material :stainlessSteel ; :length :length_10_mn ; etc.

and you don't really care at this point to assert that :material is a gr:qualitativeProductOrServiceProperty and that :length is a gr:quantitativeProductOrServiceProperty. 

You don't care, and it could be much more difficult to do: you mostly work with your codes and don't care about their actual signification in most of your processes, so the actual description of the values of properties is stored elsewhere. Maybe there you only have text descriptions (that was enough for a printed catalog, after all).

So, if you want to publish your data and you have to decide early between qualitative and quantitive, you must wait to have also worked on the precise definition of each of the types of the values. You cannot begin with just:
:screw1 :material :stainlessSteel ; :length :length_10_mn.
:stainlessSteel rdfs:label "Stainless steel".
:length_10_mn rdfs:label "10 mn".

On the other hand, if it's OK to start with properties definitions such as:
:length owl:subPropertyOf gr:qualitativeProductOrServiceProperty.

you can do it, you can later add to your data (and working from a source different from your product database, that is, without unnecessary coupling):
:length_10_mn a r:QuantativeValue, gr:hasUnitOfMeasurement…

Note that in a linked data perspective, the client discover the rdf:type of the value when dereferencing it, if she wants to: does she really need to know some kind of first approximation of the type of the value before that?

Maybe I just don't see the purpose of having gr:QualitativeValue and gr:QuantitativeValue disjoint. Are there important reasons for that?

> Also, in case you can share, it would be interesting to know the
> modeling problem that you were trying to represent via this

I'm working on the representation of the Renault range as Linked Data, cf.
http://purl.org/configurationontology

We have a few hundreds of properties, all handled in the same way when it comes to configure (customize) a car: the kind (quantitative vs qualitative) of the property (and even its actual meaning, actually) is not relevant in the configuration process: choosing the engine or a level of CO2 emission is the same kind of action. 

Thank you for your time,

Best Regards,

fps


Le 13 nov. 2012 à 10:40, Bene Rodriguez <beroca at gmail.com> a écrit :

> Hi François-Paul,
> 
> In principle, it is NOT OK for a property to be a subproperty of both
> gr:qualitative-, and gr:quantitativeProductOrServiceProperty.
> 
> These two properties, (or rather their expected values, an instance of
> the class gr:Qualitative-, gr:QuantitativeValue respectively) are
> intended to be disjoint or mutually exclusive by definition.
> 
> In case it helps, there is more info about the typical usage of these
> properties and their expected values on the GoodRelations wiki:
> - http://www.heppnetz.de/ontologies/goodrelations/v1.html#qualitativeProductOrServiceProperty
> - http://www.heppnetz.de/ontologies/goodrelations/v1#quantitativeProductOrServiceProperty
> - http://www.heppnetz.de/ontologies/goodrelations/v1#QualitativeValue
> - http://www.heppnetz.de/ontologies/goodrelations/v1#QuantitativeValue
> 
> I could point to many more usage examples of these two properties if needed.
> 
> Also, in case you can share, it would be interesting to know the
> modeling problem that you were trying to represent via this
> hypothetical subproperty of both gr:qualitative-, and
> gr:quantitativeProductOrServiceProperty.
> 
> Best,
> Bene Rodriguez
> -- 
> Research Associate
> E-Business and Web Science Research Group
> Department of General Management and E-Business
> Universitaet der Bundeswehr Munich (Germany)
> phone: +49 89 6004-2849
> email: benedicto.rodriguez at ebusiness-unibw.org
> web:   http://purl.org/beroca
> 
> On Tue, Nov 13, 2012 at 8:32 AM, François-Paul Servant
> <fps at semanlink.net> wrote:
>> Oops,
>> 
>> I messed things up when writing my question. Here is what I wanted to ask:
>> 
>> is it OK for a property used to describe a product to be subProperty of both gr:qualitativeProductOrServiceProperty and gr:quantitativeProductOrServiceProperty?
>> (I hope it is)
>> 
>> fps
>> 
>> Le 13 nov. 2012 à 00:32, François-Paul Servant <fps at semanlink.net> a écrit :
>> 
>>> Hi,
>>> is it OK for a property used to describe a product to be subClass of both gr:qualitativeProductOrServiceProperty and gr:datatypeProductOrServiceProperty?
>>> (I hope it is)
>>> Best,
>>> fps
>> 
>> 
>> _______________________________________________
>> goodrelations mailing list
>> goodrelations at ebusiness-unibw.org
>> http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations





More information about the goodrelations mailing list