From Wiki of the E-Business and Web Science Research Group

Change Log GoodRelations

This page summarizes changes on the GoodRelations ontology.

Version 1, http://purl.org/goodrelations/v1

Version 1 and the base URI http://purl.org/goodrelations/v1# are meant to be stable. We will only carry out small bugfixes and extensions that are fully backward compatible.

October 25, 2009: Minor Bugfix

The range and domain of gr:variantOf has been set to gr:ProductOrServiceModel.

July 18, 2009: Service Update - Minor extensions and improvements, part III

The most significant change in this update is the introduction of the gr:seeks property. This allows representing both the sales and the buy side with no additional changes to the vocabulary.

1. Changed the domain of gr:hasStockKeepingUnit from the union of gr:ProductOrServiceModel and gr:Offering to the union of gr:ProductOrService and Offering, since also products or services that have no Product Or Service Model may have this property.

Also slightly updated the text.

2. Changed the comment field for gr:priceType to indicate that the absence of this property indicates the actual sales price.

"The absence of this property marks the actual sales price."

3. Changed the domain of gr:hasManufacturer from gr:ProductOrServiceModel to gr:ProductOrService, since also products or services that have no Product Or Service Model may have this property.

Also slightly updated the text:

"This object property links a Product Or Service to the Business Entity that produces it. Mostly used with gr:ProductOrServiceModel."

4. Added a new gr:PaymentMethod http://purl.org/goodrelations/v1#DirectDebit

"Payment by direct debit, i.e., the buying party will inform the offering Business Entity about its bank account details and authorizes the Business Entity to collect the agreed amount directly from that account."

5. Added a new gr:PaymentMethod http://purl.org/goodrelations/v1#COD

"Collect on delivery / Cash on delivery - A payment method where the recipient of goods pays at the time of delivery. Usually, the amount of money is collected by the transportation company handling the goods."

6. Added a gr:includes property as shortcut with the following semantics:

#rule for new includes property
PREFIX gr: <http://purl.org/goodrelations/v1#>

CONSTRUCT {
_:n rdf:type gr:TypeAndQuantityNode.
_:n gr:AmountOfThisGood "1.0"^^xsd:float.
_:n gr:hasUnitOfMeasurement "C62"^^xsd:string.
?a gr:includesObject _:n .
_:n gr:typeOfGood ?b.}

WHERE

{?a rdf:type gr:Offering.
?b rdf:type gr:ProductOrService.
?a gr:includes ?b}

Note: The usage of this property requires either additional queries or non-standard reasoning e.g. in the form of the SPARQL CONSTRUCT shown above.

7. Changed the range of http://purl.org/goodrelations/v1#typeOfGood from

gr:ProductOrService

to the union of

gr:ActualProductOrServiceInstance and
gr:ProductOrServiceSomeInstancesPlaceholder

8. Changed the rdfs:comment for gr:offers to

"This links a Business Entity to the Offerings it is offering (i.e., the sales side). If you want to express interest in receiving offers, use gr:seeks instead."

This is necessary because the new gr:seeks property requires such a clarification.

9. Added a new object property http://purl.org/goodrelations/v1#seeks

This allows expressing interest in offers by others. It replaces the former Business Function gr:Buy.

"This links a Business Entity to the Offerings that describe what the Business Entity is interested in (i.e., the buy side). If you want to express interest in actually offering something, use gr:offers instead. Note that this substitutes the former Business Function gr:Buy, which is now deprecated."

10. Updated the rdfs:comment text for all gr:BusinessFunctions to be compatible with the new gr:seeks property.

11. Deleted the two obsolete classes

12. Added an object property http://purl.org/goodrelations/v1#hasInventoryLevel

"This property specifies the current approximate inventory level of the Product Or Service Some Instance Placeholder. The unit of measurement and the point value or interval are indicated using the attached gr:QuantitativeValueFloat instance."

13. Added mutual disjointsWith axioms between all siblings.

14. Added isDefinedBy to all new elements manually:

15. Since individuals cannot be set deprecated, http://purl.org/goodrelations/v1#Buy can only be marked deprecated by means of rdfs:label and rdfs:comment. --> DONE

16. Removed range xsd:float at gr:hasMinValue
Note that this property is a shortcut only!

17. Added domain and range to hasValueFloat and hasValueInteger
This was formerly implicit via the subpropertyOf relationship, but since some annotation tools don't do reasoning, we added them in here explicitly.
Note that these properties are shortcuts only!
a) hasValueFloat
-->
# rdfs:domain -- #QuantitativeValueFloat
# rdfs:range -- http://www.w3.org/2001/XMLSchema#float

b) hasValueInteger
-->
# rdfs:domain -- #QuantitativeValueInteger
# rdfs:range -- http://www.w3.org/2001/XMLSchema#int

May 5, 2009: Service Update - Minor extensions and improvements, part II

- Removed p1 namespace prefix (unused)
- Added rdfs:label properties for all elements. For reasons of consistency, they are identical with the element identifiers (e.g. "BusinessEntity"). Ontologically significant individuals (e.g. days of the week) also contain the name of their superclass in parentheses (e.g. "Friday (DayOfWeek)").
- Removed unused protege namespace prefix
- Expanded the descriptions of hasMaxValue and hasMinValue to indicate that hasMaxValueFloat/hasMaxValueInteger, haxMinValueFloat/hasMinValueInteger, or hasValueFloat/hasValueInteger should be used when specifying values.
- Set description to deprecated; use rdfs:comment now instead. This provides better tooling support.
- Added PayPal as a PaymentMethod.
- Added DeliveryModePickUp as a DeliveryMethod
- Added DeliveryModeFreight as a DeliveryMethod
- Added DeliveryModeOwnFleet as a DeliveryMethod
- Added PublicHolidays as a DayOfWeek; This is a placeholder for all official public holidays at the LocationOfSalesOrServiceProvisioning. It allows specifying the opening hours on public holidays. If a given day is a public holiday, this specification supersedes the opening hours for the respective day of the week.
- Added hasPOS ObjectProperty. This property states that the respective LocationOfSalesOrServiceProvisioning is a point of sale for the respective BusinessEntity. It allows linking those two types of entities without the need for a particular Offering.
- Added VersionInfo property
- Added terms:license statement http://creativecommons.org/licenses/by/3.0/
- Added rdfs:isDefinedBy statements to all elements
<rdfs:isDefinedBy rdf:datatype="&xsd;anyURI">http://purl.org/goodrelations/v1</rdfs:isDefinedBy>
- Added LINK tag to XHTML document header,
<link rel="meta" type="application/rdf+xml" title="RDF/XML definition for the GoodRelations ontology" href="http://purl.org/goodrelations/v1.owl" />
- Added note that the return format of the ontology specification is determined by content negotiation - in order to get a particular format, append .owl or .html to the ontology URI.
- Added hasNAICS datatype property for attaching NAICS codes to BusinessEntities
- Addes hasISICv4 datatype property for attaching ISIC Rev. 4 codes to BusinessEntities.
- Added cardinality recommendations (constraints) to datatype and object properties by extending the rdfs:label elements.
- Added isVariantOf object property for modeling product model variants. This states that a particular ProductOrServiceModel instance is a variant of another ProductOrServiceModel. It is pretty safe to infer that the variant inherits all quantitativeProductOrServiceProperties, qualitativeProductOrServiceProperties, and datatypeProductOrServiceProperties that are defined for the first ProductOrServiceModel.
(Example: foo:Red_Ford_T_Model gr:isVariantOf foo:Ford_T_Model)
- Set isListPrice to DEPRECATED. Use the new gr:priceType property instead. This boolean attribute indicated whether a UnitPriceSpecification is a list price (usually a vendor recommendation) or not. TRUE indicates it is a list price, FALSE indicates it is not. It is safe to assume by default that a UnitPriceSpecification that lacks this attributes is not list price.
- Added new datatype property priceType: This attribute can be used to distinguish multiple different PriceSpecifications for the same Product or Service. It supersedes the former isListPrice property. The following values are recommended: SRP: "suggested retail price" - applicable for all sorts of a non-binding retail price recommendations, e.g. such published by the manufacturer or the distributor. This value replaces the former gr:isListPrice property. INVOICE: The invoice price, mostly used in the car industry - this is the price a dealer pays to the manufacturer, excluding rebates and charges.
- Added explicit namespace prefix "gr" in addition to the default (xmlns:gr="http://purl.org/goodrelations/v1#). This may make life easier for ontologies that import GoodRelations.
- Added business function ConstructionInstallation. This Business Function indicates that the Business Entity offers to construct and/or install the specified Product at the customers location.
- Changed cardinality constraints (recommendation) for gr:hasOpeningHoursDayOfWeek from 1..1 to 1..*. This allows using a single OpeningHoursSpecification instance for multiple Days of Week, as long as the opening hours are the same. This is an important simplification for RDFa markup.
- Fixed several spelling mistakes and inconsistencies in capitalization and usage of camel word (BusinessEntity etc.). Now, identifiers for classes and instances are camel words with a starting capital letter (BusinessEntity). Properties use camel words with an initial lower caps (hasPOS). In rdfs:comment fields etc., the camel words of classes and instances are split up into multiple words by inserting white space, but the capitalization remains (Type And Quantity Node); this indicates that we are talking about an entity defined in the ontology. For properties, the camel words as used as identifiers are also used in rdfs:comment fields ("We recommend the hasPOS property to link a Business Entity to a Location of Sales").
- Improved the XHTML rendering - now, the ontologically significant instances (e.g. values) are indicated as links under the respective class definition.
- Changed cardinality constraints (recommendation) for gr:hasBusinessFunction from 1..1 to 1..*. This allows using a single Offering instance for multiple business functions, as long as there are no price specifications. For incomplete / lightweight descriptions, this simplifies RDFa markup. Note 1: This shortcut can only be used if the terms and conditions and all details of the offering are the same for different business functions. This is highly unlikely as soon as prices are given (the price for leasing out and selling a boat is unlikely to be the same).
- Added list of predefined individuals to class definitions in XHTML file.
- Added list of suitable predefined individuals for the range of object properties in the XHTML file.

November 27, 2008: Minor extensions and improvements, part II

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

August 14, 2008: Minor extensions

We have added a new attribute hasManufacturer to GoodRelations, which allows a better modeling of product models.

gr:hasManufacturer

<owl:ObjectProperty rdf:ID="hasManufacturer">
  <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
      This object property links a ProductOrServiceModel to the BusinessEntity that produces it.
  </rdfs:comment>
  <rdfs:domain rdf:resource="#ProductOrServiceModel"/>
  <rdfs:range rdf:resource="#BusinessEntity"/>
</owl:ObjectProperty>

Also, there is now a special how-to document that explains how you can use GoodRelations for publishing products and services model data.

This is particularly relevant for manufacturers of commodities who want to make features of their product models available on the Semantic Web.

The document is available at

http://www.ebusiness-unibw.org/wiki/Modeling_Product_Models

Changes between the Technical Report and the Official Release Version 1, http://purl.org/goodrelations/v1#

1.Base URI
We moved the whole ontology to purl.org. The new authoritative base URI is http://purl.org/goodrelations/v1#.

2. Project Home Page
We moved the project home to purl.org. The new authoritative project URI is http://purl.org/goodrelations/.

3. Price Ranges for Unit Price, Shipping Charge, Payment Charge
We added support for price ranges by creating two new properties that can be attached to any PriceSpecification, i.e., any instance of
!UnitPriceSpecification, DeliveryChargeSpecification, and PaymentChargeSpecification:
a. hasCurrencyValueMin
b. hasCurrencyValueMax

The initial property hasCurrencyValue is a subproperty of both, applying the same pattern for ranges as explained in section 3.3.4 of
the Technical Report.

Old data using hasCurrencyValue requires no changes, and hasCurrencyValue keeps on being supported as a shortcut. The only
modification is that querying for the price requires now to search for hasCurrencyValueMax or hasCurrencyValueMin explicitly (since hasCurrencyValue y
implies hasCurrencyValueMax y and hasCurrencyValueMin y, but naturally, nothing is inferred about hasCurrencyValue if a range is declared).

4. List Prices
We added support for list prices by providing the datatype property isListPrice, with the domain of UnitPriceSpecification and the range of
boolean. By that, you can indicate that a given UnitPriceSpecification is a list price.

5. Properties for EAN/UPC, ISBN, ISSN, and other identifiers

a) We added support for the EAN/UPC/UCC by adding the datatype property hasEAN_UCC-13.
Note that UPC, EAN-13, and ISBN number have now all been consolidated into EAN-UCC-13.
This code is now officially called GTIN-13 (Global Trade Identifier Number) or EAN·UCC-13. Former 12-digit UPC codes can be converted into EAN·UCC-13 code by simply adding a preceeding zero.

Note: When using this property for searching by 12-digit UPC codes, you must add a preceeding zero digit.

There is no need for a separate ISBN attribute, because the ten digit ISBN is deprecated now (as of 2007). Instead, old ISBNs are to be imported into the EAN-UCC-13 scheme by prefixing 978 or 979. As far as we know, the whole book sales business has already updated all systems and data.

b) We also added support for the more comprehensive GTIN-14 code by providing the datatype property hasGTIN-14. This can hold the Global
Trade Item Number (GTIN-14) of the given ProductOrService.

Both are subproperties of gr:datatypeProductOrServiceProperty.

6. Properties identifying businesses
We added support for two other common identifiers, which are often used for business entities or locations, GLN/ILN and DUNS.

a. hasGlobalLocationNumber for BusinessEntity and LocationOfSalesOrServiceProvisioning
b. hasDUNS for BusinessEntity only

7. We added time-zone support for validFrom and validThrough by explaining the use of the "Z" suffix for datetime.

For a time in GMT/UTC, simply add a "Z" following the time:
2008-05-30T09:30:10Z
Alternatively, you can specify an offset from the UTC time by adding a positive or negative time following the time:
2008-05-30T09:30:10-09:00
or
2008-05-30T09:30:10+09:00

8. We added time-zone support for "opens" and "closes"and updated the definition:

- If no time-zone suffix is included, the time is given in the local time valid at the Location.
- For a time in GMT/UTC, simply add a "Z" following the time
- Alternatively, you can specify an offset from the UTC time by adding a positive or negative time following the time:
09:30:10-09:00
or
09:30:10+09:00

9. The missing property "hasOpeningHourSpecification" was added to the ontology and documentation.

10. A property gr:hasManufacturer hat been added. This should be used to link a ProductOrServiceModel to the BusinessEntity that produces it.

GoodRelationsChangeLog