This is the archive of the goodrelations dicussion list

Dear all:

We are about to release a service update for the GoodRelations ontology 
(http://purl.org/goodrelations).

This will incorporate several improvements based on very valuable 
feedback from many members of the GoodRelations community.

All but three changes are proper extensions of the current version. All 
changes are documented at [1]. The general change log documenting all 
past and future changes is at [2].

The changes that will imply a minimal change in the formal semantics of 
the ontology are as follows:

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

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

Since the implications will, however, be without major practical impact, 
the new version will be published in the old namespace.

Also, with this Service Update, we will move from client-side rendering 
to content negotiation. That will avoid a Jena warning that may have 
been irritating for some users of the ontology.

The Service Update 2008-11-27 will replace the previously published 
version later today. Please update all local copies and caches.

Best wishes

Martin Hepp
-----------------

[1] 
http://www.ebusiness-unibw.org/wiki/GoodRelationsChangeLog#November_27.2C_2008:_Minor_extensions_and_improvements.2C_part_II

[2] http://www.ebusiness-unibw.org/wiki/GoodRelationsChangeLog


Version 1, http://purl.org/goodrelations/v1,  November 27, 2008: Minor 
extensions and improvements
=======================================================================

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

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

3. 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&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:
          o 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.
          o gr:Discover: Payment by credit or debit cards issued by the 
Discover network.

4. Meaning of PaymentMethodCreditCard 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.

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

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

7. The wording and spelling of some rdfs:comment elements has been 
improved.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_hepp.vcf
Type: text/x-vcard
Size: 308 bytes
Desc: not available
URL: <http://ebusiness-unibw.org/pipermail/goodrelations/attachments/20081201/b3a23361/attachment.vcf>