The Stock Keeping Unit, or SKU is a unique identifier for a product or service from the perspective of a particular supplier, i.e. SKUs are mostly assigned and serialized at the merchant level. Examples of SKUs are the ordering or parts numbers used by a particular Web shop or catalog.
Consequently, the domain of hasStockKeepingUnit is the union of the classes Offering and ProductOrServiceModel.
If attached to an Offering, the SKU will usually reflect a merchant-specificic identifier, i.e. one valid only for that particular retailer or shop. If attached to a ProductOrServiceModel, the SKU should reflect the identifier / part number used by the official manufacturer of that part.
Important:Be careful when assuming two Products or Services instances or Offering instances to be identical based on the SKU. Since SKUs are unique only for the same business entity, this can be assumed only when you are sure that the two SKU values refer to the same BusinessEntity. Such can be done by taking into account the provenance of the data. As long as instances of Offering are concerned, you can also check that the offerings are being offered by the same BusinessEntity.
Usually, the properties hasEAN_UCC-13 and hasGTIN-14 are much more reliable identifiers, because they are globally unique.
See also http://en.wikipedia.org/wiki/Stock_Keeping_Unit
The two properties hasEAN_UCC-13 and hasGTIN-14 used to be subproperties of datatypeProductOrServiceProperty, and thus had the domain gr:ProductOrService.
However, it happens that EAN, UCC, or GTIN-14 codes are assigned to tradeable items including bundles, which means that sometimes Offerings can also have a EAN, UCC, or GTIN-14 codes.
Thus, the rdfs:subpropertyOf relation to datatypeProductOrServiceProperty was removed and the domain redefined to the union of gr:ProductOrService and gr:Offering.
The textual definitions of both elements have been updated accordingly.
It was requested to add a BusinessFunction to express that a BusinessEntity is interested in purchasing or consuming a particular type of good. This is not necessary, since the respective value for BusinessFunction exists already: http://purl.org/goodrelations/v1#Buy
We received a request to add three additional PaymentMethods: Check, WireTransfer, and Discover, in order to be compatible with http://base.google.com/support/bin/answer.py?answer=73932&hl=en
The definition of the class gr:PaymentMethodCreditCard was expanded to include debit cards as well, because a) it is often hard to tell and b) widely irrelevant from a merchant's perspective whether a certain payment card is based on a debit, prepaid, or credit contract. Also, Discover as an important card network in the USA was added to the definition. The new definition of the class is "The subclass of Payment Method represents all variants and brands of credit or debit cards as a standardized procedure for transferring the monetary amount for a purchase. It is mostly used for specifying the types of payment accepted by a Business Entity.
Examples: VISA, MasterCard, American Express, Discover".
The textual definitions of all existing instances was updated to include debit cards, too.
There has been the valuable suggestion to add lightweight support for attaching related REST or SOAP services URIs to the GoodRelations ontology. On one hand, the benefit of this is clear; one can easily link to invocable functionality from an offering, a price specification, or any other element. On the other hand it is also clear that we should not try to reinvent the wheel and replicate all the ongoing works on vocabularies for describing Web Services. We have thus implemented a minimal feature that will allow attaching a related SOAP or REST Web service to any conceptual entity (offering, price specification, business entity, etc.), without duplicating current efforts of modeling Web Services descriptions. We would also be neutral to any such competing efforts.
In detail, we added an owl:AnnotationProperty gr: relatedWebService:"The URI of a SOAP or REST Web service from which additional information about the Business Entity, Offering, PriceSpecification, or ProductOrService instance can be gained. The recommended domain is BusinessEntity, Offering, PriceSpecification, or ProductOrService. The recommended range is rdf:resource, i.e., the URI of a SOAP or REST Web service."
This annotation property allows pointing from any relevant gr:BusinessEntity, gr:Offering, gr:PriceSpecification, or gr:ProductOrService instance to a related SOAP or REST Web service, from which additional information can be gained. Any existing or upcoming vocabulary for Web Services could be used in combination with GoodRelations, because the association between the service description and the GoodRelations description can be made via the Web Service URI value used with the gr:relatedWebService property.
Notes:
Language tags "en" according to RFC3066 have been added to all rdfs:comment fields in the ontology specification.
The wording and spelling of some rdfs:comment elements has been improved.