Changelog/20081127

= Changelog: Service Update November 27, 2008

New datatype property hasStockKeepingUnit added
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

Slight changes of hasEAN_UCC-13 and hasGTIN-14
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.

Business Function "Consume, Buy, Purchase"/ OfferToConsume
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

AcceptedPaymentMethods: Check, WireTransfer, Discover
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&amp;hl=en


 * As for WireTransfer, this is already covered by gr:ByBankTransferInAdvance. We added "This is equivalent to payment by wire transfer." to the textual definition of the element.
 * Check and Discover have been added as instances of PaymentMethod:
 * gr:CheckInAdvance: Payment by sending a check in advance, i.e., the offering Business Entity will ideliver the goods upon receipt of a check over the due amount. Note that there are variations in handling payment by check - sometimes, shipment will be upon receipt of the check as a document, sometimes the shipment will take place only upon successful crediting of the check.
 * gr:Discover: Payment by credit or debit cards issued by the Discover network.

Meaning ofPaymentMethodCreditCard expanded to include debit cards
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.

New annotation property gr:relatedWebService for pointing to SOAP or REST Web Services
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:


 * Practically, gr:relatedWebService is a rdfs:subpropertyOf of rdfs:seeAlso. However, expressing this in the GoodRelations vocabulary would move GoodRelations from OWL DLP to OWL Full, which is sometimes undesirable.
 * For the same reason, the intended range (rdf:resource) cannot be specified. If this does not hurt in your local model (e.g. because you are in OWL Full anyway), you can safely add the statement  gr:relatedWebService rdfs:subpropertyOf rdfs:seeAlso  to your data.
 * There could be further specializations of this gr:relatedWebService property, based on functional or business-wise distinctions, but we have no plans to define those in the generic GoodRelations vocabulary.

Language tags "en" added to all elements
Language tags "en" according to RFC3066 have been added to all rdfs:comment fields in the ontology specification.

Proof-reading and wording
The wording and spelling of some rdfs:comment elements has been improved.