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