GoodRelations Technical Report Errata
Errata / Bugs / Inconsistencies in the Goodrelations Technical Report
1. Broken link " http://www.ietf.org/internet-drafts/draft-mealling-epc-urn-02.txt " on page 59. Apparently the internet draft has been removed from the ietf.org site.
(Thanks to Alex Cozzi for spotting this).
2. On page 43, it should be
IF datatype = NR2* or NR3* THEN ..
(instead of IF datatype = NR2* or NE3* THEN ..).
3. After publishing the technical report, the ontology has been slightly improved and the base URI of the ontology and the project have been changed. The official ontology release and the HTML version of the documentation supersede the Technical Report.
Ontology: The new authoritative base URI is http://purl.org/goodrelations/v1#.
Project Home Page: The new authoritative project URI is http://purl.org/goodrelations/.
4. What is called PriceSpecification in the domain capture, is now called UnitPriceSpecification in the ontology. PriceSpecification is now the superclass of UnitPriceSpecification, DeliveryChargeSpecification, and PaymentChargeSpecification. This may cause some inconsistencies between the domain capture and the authoritative ontology file and documentation as on the Web. The ontology and documentation published at http://purl.org/goodrelations/ supersedes the Technical Report.
5. The property gr:hasOpeningHoursSpecification was missing in the ontology and technical report. This property links a LocationOfSalesOrServicesProvisioning with an OpeningHoursSpecification.
6. The example on pages 47 and 48 says the cell phone had a talk time of 120 hours, but the code says 120 minutes. The correct unit of measurement code for hour is "HUR", not "MIN".
Changes between the Technical Report and the Official Release
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:
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:
Alternatively, you can specify an offset from the UTC time by adding a positive or negative time following the time:
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:
9. The missing property "hasOpeningHourSpecification" was added to the ontology and documentation.
<xml xml="xml"><owl:ObjectProperty rdf:ID="hasOpeningHoursSpecification">
<rdfs:domain rdf:resource="#LocationOfSalesOrServiceProvisioning"/> <rdfs:range rdf:resource="#OpeningHoursSpecification"/> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" xml:lang="en"> This property links a LocationOfSalesOrServicesProvisioning with an OpeningHoursSpecification </rdfs:comment>
10. A property gr:hasManufacturer hat been added. This should be used to link a ProductOrServiceModel to the BusinessEntity that produces it.