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] Modeling the type of product / offer

Martin Hepp martin.hepp at ebusiness-unibw.org
Fri Mar 11 12:29:59 CET 2011


Dear all:

Attached, please find my private reply to someone who was asking for how to model the type of products in an offer, e.g. how to indicate what types of products you are selling. I think it is of generic relevance.

Begin forwarded message:
------------------------

The precise way of classifying offerings by what they include is to use *a taxonomy on the products* included. So since gr:Offerings may include very different objects (1 beer + 2 laptop computers), it is not very scalable to classify offers by content. Rather, classify the objects included.

There are three ways for doing so:

1. Use an external GoodRelations specialization for a vertical (see list: http://www.ebusiness-unibw.org/wiki/GoodRelations#Compatible_Vocabularies_for_Products_and_Services) and make the gr:ActualProductOrServiceInstance or the gr:ProductOrServicesSomeInstancesPlaceholder an instance of the matching class:

Example for a Hammer and using the class from www.productontology.org:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix pto: <http://www.productontology.org/id/> .
@prefix gr: <http://purl.org/goodrelations/v1#> .
@prefix foo: <http://example.com/> .

# The object
foo:myObject a <http://www.productontology.org/id/Hammer> ;
    a gr:ProductOrServicesSomeInstancesPlaceholder ;
    gr:name "... a short name for the object ..."@en ;
    gr:description "... a longer description ..."@en .

So you make it an instance of both pro:Hammer and gr:ProductOrServicesSomeInstancesPlaceholder.

Then you need to model the offer and the company, as usual:

# The agent (person or company) who is offering it
foo:ACMECorp a gr:BusinessEntity ;
    gr:legalName "ACME Corp" ;
    gr:offers foo:Offer .
        
# The offer to sell it
foo:Offer a gr:Offering ;
    gr:includes foo:myObject;
    foaf:page <http://URI_of_the_page_containing_the_offer.com>;
    gr:hasBusinessFunction gr:Sell ;
    gr:validFrom "2011-01-24T00:00:00+01:00"^^xsd:dateTime ;
    gr:validThrough "2011-12-24T00:00:00+01:00"^^xsd:dateTime ;
    gr:hasPriceSpecification
        [ a gr:UnitPriceSpecification ;
          gr:hasCurrency "USD"^^xsd:string ;
          gr:hasCurrencyValue "19.99"^^xsd:float ;
          gr:validThrough "2011-12-24T00:00:00+01:00"^^xsd:dateTime ] .

2. As 1, but you define a proprietary ontology for your types of goods, as described in
http://www.ebusiness-unibw.org/wiki/GoodRelations#Creating_New_Vocabularies_for_Products_and_Services

So you would define classes and maybe properties that match your internal data structures:

foo:Hammer a owl:Class;
    rdfs:subClass of gr:ProductOrService .

The you do the same as in option 1:

# The object
foo:myObject a foo:Hammer, a gr:ProductOrServicesSomeInstancesPlaceholder ;
    gr:name "... a short name for the object ..."@en ;
    gr:description "... a longer description ..."@en .


3. If you just have a label for the category and don't want to create an ontology, you can also use gr:category with a literal.

Advantage: Much simpler
Disadvantage: Harder to process by clients, thus lower visibility (but future engines can still try to build links based on string similarity).

The you do the same as in option 1:

# The object
foo:myObject a a gr:ProductOrServicesSomeInstancesPlaceholder ;
    gr:category "Hammer"@en ;
    gr:name "... a short name for the object ..."@en ;
    gr:description "... a longer description ..."@en .

If you absolutely want to attach the information to the offer, you could use foaf:topic or create your own subclasses of gr:Offering, but I would discourage that because

- it won't scale
- most clients will ignore that
- it's much harder to model alignments.


Best

Martin Hepp






More information about the goodrelations mailing list