FYI
-------- Original Message --------
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.
|
martin_hepp.vcf
Description: Vcard
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (01)
|