GoodRelationsValidator
The GoodRelations Validator is a tool that helps you check your product and company meta-data.
http://www.ebusiness-unibw.org/tools/goodrelations-validator/
On this page, we provide information on the check steps and error / warning messages.
Implemented
Errors
=== E1: For all intervals: Check that Max<=Min (for quantitative properties and for currencyValue) ===
Validator Tool: Step # 1
Error Message: All maximun values must be greater than minimun values, including currencies.
Potential Problem: Prices and quantitative product properties can be specified as intervals using the gr:hasMinValueFloat - gr:hasMaxValueFloat, gr:hasMinValueInteger - gr:hasMaxValueInteger and gr:hasMinCurrencyValue - gr:hasMaxCurrencyValue properties. Care must be taken that the "min" values are lower or equal to the "max" values.
E2: If range specified, no explicit value specified (for quantitative properties and for currencyValue)
Validator Tool: Step # 2
Error Message: A specific value (hasValue) cannot be defined when a range is present (hasMinValue or hasMaxValue) for both numeric and currencies values.
Potential Problem: Prices and quantitative product properties can be specified as intervals using the gr:hasMinValueFloat - gr:hasMaxValueFloat, gr:hasMinValueInteger - gr:hasMaxValueInteger and gr:hasMinCurrencyValue - gr:hasMaxCurrencyValue properties. Care must be taken that if a range is present, no specif value should be included (hasFloatValue, hasIntegerValue, and hasCurrencyValue.
E3: Check that priceSpecifications are non-overlapping in terms of quantity. i.e. None ranges min-max values in price specifications are include in others
Validator Tool: Step # 3
Note: This validation must be done before E4
Error Message: None ranges min-max values in price specifications are include in other.
Potential Problem: One offering (gr:Offering) can include more than one price specification. Prices specifications can include price intervals using the gr:hasMinCurrencyValue - gr:hasMaxCurrencyValue properties. Care must be taken that price ranges in price specifications for the same offering do not overlapp to each other.
E4: Check that there is at most one ListPrice for the same quantity.
Validator Tool: Step # 4
Note: This validation must be done after E3
Note: This property is currently DEPRECATED. Use the gr:priceType property instead.
Error Message: Only one ListPrice (true) can be specified per each Offering.
Potential Problem: Offerings can include more than one Unit Price Specification. A unit price specification helps to describe price type, valid dates (from - throught), and unit of measurements. Care must be taken that list price in unit price specifications for the same offering is defined as true only once.
E5: Check that the UnitOfMeasurement for Price specifications is C62 for all bundles (i.e. offerings including more than one type of product)
Validator Tool: Step # 5
Error Message: The UnitOfMeasurement must be C62 when more than one type of product is offer (more than one includesObject is specified).
Potential Problem: Offerings can include more than one Unit Price Specification. A unit price specification helps to describe price type, valid dates (from - throught), and unit of measurements. Care must be taken that hasUnitOfMeasurement value must be C62 when more than unit price specification is present.
E6: Check that EAN-UCC has 13 digits and only numbers.
Validator Tool: Step # 7
Error Message: Global Trade Identifier Number (GTIN, before known as EAN·UCC-13) must have exactly 13 digits.
Potential Problem: The EAN·UCC-13 is the code of the given Product Or Service or Offering (hasEAN_UCC-13 datatype property). 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. Care must be taken that EAN·UCC-13 has exactly 13 digits.
E7: Check that GLN has the correct number of digits and contains only numbers.
Validator Tool: Step # 8
Error Message: Global Location Number (GLN) must have exactly 13 digits.
Potential Problem: The Global Location Number (GLN, hasGlobalLocationNumber datatype property, sometimes also referred to as International Location Number or ILN) is a thirteen-digit number used to identify parties and physical locations of the respective Business Entity or Location Of Sales Or Service Provisioning. Care must be taken that GLN has exactly 13 digits.
E8: Check that all opening hour specs are non-overlapping for the same day of week, and that they make sense.
Validator Tool: Step # 10
Error Message: None ranges opens-closes values in opening hours specifications are include in others.
Potential Problem: One business entity (gr:BusinessEntity) can include provision locations with more than one opening hour specification. Opening hour specifications can include open-close intervals using the gr:opens - gr:closes properties. Care must be taken that open-close ranges in opening hour specifications for the same location do not overlapp to each other.
E9: Check that the opening hour is earlier than the closing hour.
Validator Tool: Step # 11
Error Message: Invalid validity interval for opening hours (gr:opens and gr:closes make no sense).
Potential Problem: One business entity (gr:BusinessEntity) can include provision locations with more than one opening hour specification. Opening hour specifications can include open-close intervals using the gr:opens - gr:closes properties. Care must be taken that for all open-close ranges in opening hour specifications gr:opens is less or equal than gr:closes.
E10: Check that both validThrough and hasValidFrom exist in offerings.
Validator Tool: Step # 17
Note: This validation must be done before E11
Error Message: Both validFrom and validThrough must be specified.
Potential Problem: One offering can specify valid dates by means of gr:validFrom and gr:validThrough. Care must be taken that both values exist because one has no sense without the other.
E11: Check that validThrough hasValidFrom and viceversa in offerings.
Validator Tool: Step # 18
Note: This validation must be done after E10
Error Message: When validFrom is specified, validThrough must be also specified and viceversa.
Potential Problem: One offering can specify valid dates by means of gr:validFrom and gr:validThrough. Care must be taken that both values exist because one has no sense without the other.
E12: Check that validThrough is later than validFrom.
Validator Tool: Step # 19
Error Message: validFrom must be strictly smaller than validThrough.
Potential Problem: One offering can specify valid dates by means of gr:validFrom and gr:validThrough. Care must be taken that for all open-close ranges in opening hour specifications gr:validFrom is less than gr:validThrough.
E13: Check that if a price specification is attached, not more than one BusinessFunction is used.
Validator Tool: Step # 20
Error Message: When price specifications exist, only one Business Function is allowed.
Potential Problem: One offering can specify more than one price specification. Care must be taken that only one gr:hasBusinessFunction is specified when there are more than one price specification for the same offer because very likely, the price asked for two business functions is not the same.
E14: Check that all PriceSpecifications have a currency value or currency interval attached.
Validator Tool: Step # 23
Error Message: All price specifications must specify a currency value, a minimun currency value or a macimun currency value.
Potential Problem: One offering can specify more than one price specification. Care must be taken that all price specifications inlcude a currency value, it can be a fix value by means of gr:hasCurrencyValue or a range by means of gr:hasMinCurrencyValue and/or gr:hasMaxCurrencyValue, otherwise offer will have no price attached.
E15: Check that each ProductOrService is also either Actual, Model, or InstancePlaceholder.
Validator Tool: Step # 25
Error Message: No direct instances of ProductOrService are allowed, only instances of ActualProductoOrServiceInstance, ProductOrServiceModel, or ProductOrServicesSomeInstancesPlaceHolder.
Potential Problem: Care must be taken that only instances of ActualProductoOrServiceInstance, ProductOrServiceModel, or ProductOrServicesSomeInstancesPlaceHolder exist in the model. ProductOrService is a generic absctrat class that must not be instanciated.
E16: Check that certain properties should be used only once for the same object (i.e. the max. cardinality is 1). However, this is not formally specified in the ontology --> Object properties.
Validator Tool: Step # 28
Error Message: Cardinalities must follow the specification of GoodRelations Ontoology.
Potential Problem: Care must be taken that cardinalities in object properties (from a class to a class) follow the prime suggestions.
E17: Check that gr:opens and gr:closes use following format: hh:mm:ss (ISO 8601).
Validator Tool: Step # 29
Error Message: Open and close hours must be in 24 hours format and must follow one of the next conventions: hh:mm:ss, hh:mm:ssZ, hh:mm:ss+hh:mm, hh:mm:ss-hh:mm.
Potential Problem: Care must be taken that open a close hours follow the given format, otherwise it is not possible to know whether or not an hour is correct.
E18: Check that all hours specification includes at least one day.
Validator Tool: Step # 30
Error Message: Open and close hours specifications must include at least one day of the week.
Potential Problem: Care must be taken that all hour specifications include at least one day, otherwise it is not possible to really know when a location is open.
E19: Check that certain properties should be used only once for the same object (i.e. the max. cardinality is 1). However, this is not formally specified in the ontology --> Datatype properties.
Validator Tool: Step # 31
Error Message: Cardinalities must follow the specification of GoodRelations Ontoology.
Specific examples:
- Check for lacking UnitsOfMeasurement everywhere, exactly one. (Validator Tool: Step # 13)
- Check for quantity spec in the bundle. (amountOfThisGood is mandatory), exactly one. (Validator Tool: Step # 15)
- Check that all PriceSpecifications have exactly one hasCurrency Attribute. (Validator Tool: Step # 22)
Potential Problem: Care must be taken that cardinalities in object properties (from a class to a class) follow the prime suggestions.
E20: Check that all xsd:float values (in particular those attachedto gr:QuantitativeValueFloat and all price info) is compliant with the xsd:float spec.
Validator Tool: Step # 32
Error Message: Float values must be compliant with the xsd:float spec. Particulary, float values should contain only digits (no currency characters etc.) and not thousand separators (comma) and at max one dot. So "$2,019.60" is incorrect. e or E for exponents would be allowed if preceded and followed by digits. So "1234.4E07" is valid.
Potential Problem: Care must be taken that all xsd:float acomplish to the xsd specification. In particular that it contains only digits (no currencycharacters etc.) and not thousand separators (comma) and at max one dot.So ""$2,019.60"" is incorrect. e or E for exponents would be allowed ifpreceded and followed by digits "1234.4E07" is valid.
E21: Check whether eligibleRegions values are valid two-character version of ISO 3166-1 (ISO 3166-1 alpha-2) for regions or ISO 3166-2, which breaks down the countries from ISO 3166-1 into administrative subdivision and NOT use 3-letter ISO 3166-1 codes!
Validator Tool: Step # 16
Error Message: Eligible regions must follow the standards given in ISO-3166-1 (ISO 3166-1 alpha-2) or ISO 3166-2.
Potential Problem: The property eligibleRegions specifies the geo-political region or regions for which the offer is valid. Care must be taken that all regions follow the two-character version of ISO 3166-1 (ISO 3166-1 alpha-2) for regions or ISO 3166-2 , which breaks down the countries from ISO 3166-1 into administrative subdivisions. Important: Do NOT use 3-letter ISO 3166-1 codes.
Examples: "AT", "DE", "US", etc. are valid ISO 3166-1 codes. "AT-7" (Tyrol), "DE-BY" (Bavaria), etc. are valid ISO 3166-2 codes.
E22: Check for lacking UnitsOfMeasurement everywhere, exactly one.
Validator Tool: Step # 13
Error Message: The property gr:hasUnitsOfMeasurement must be used exactly ones for every instance of gr:QuantitativeValue, gr:TypeAndQuantityNode and every gr:UnitPriceSpecification.
E23: Check that hasCurrency has a valid value.
Validator Tool: Step # 21
Error Message: Currencies must follow the ISO 4217 standard (3 characters).
Potential Problem: The hasCurrency property represents the currency for all prices in the Price Specification given. Care must be taken that all currencies are using the ISO 4217 standard (3 characters).
E24: Check that within the PURL namespace, only elements defined in V1 are used (i.e. no spelling mistakes or elements from other ontologies).
Validator Tool: Step # 6
Error Message: There are some elements not defined in V1 of GoodRelations.
Potential Problem: Care must be taken that all concepts and properties of GR are used properly and elements from other ontologies are properly related to GR.
E25: Check that the validity of the offer covers the validity of all price specifications.
Validator Tool: Step # 26
Error Message: At least one price specification is not covered by the validity of the related offer.
Warnings
W1: Warn if list price is lower than non-list price.
Validator Tool: Step # 14
Error Message: If the type price is SRP, all currency values in other unit price specifications with the same currency must be greater or equal, i.e the one which is SRP must be the lowest.
Potential Problem: Offerings can include more than one Unit Price Specification. A unit price specification helps to describe price type, valid dates (from - through), and unit of measurements. Care must be taken when one type price is SRP since it means that all currency values in all other unit price specifications with the same currency must be greater or equal, i.e the one which is SRP must be the lowest.
Future
Errors
FE1:: Check that all ranges and domain are met (interpreted as constraining, not inferring, but taking into account the subsumption hierarchy and unionOf definitions)
- Error Message: Domain and range must follow the specification of GoodRelations Ontology
- Potential Problem: Care must be taken that domain and range specifications in properties follow the prime suggestions.
FE2: Check that all OpeningHourSpecifications make sense; have time-zone spec and that there is exactly one DayOfWeek and one closes and one opens attribute.
- Error Message: Opening hours specifications should make sense, check time-zone specification, only one DayOfWeek, and only one closes and one opens attribute.
- Potential Problem: OpeningHourSpecification holds together all aspects related to the opening hours for a given DayOfWeek for a given LocationOfSalesOrServiceProvisioning. Care must taken that time-zone is present, and there is exactly one DayOfWeek and one closes and one opens attribute.
FE3: Check that includesitems in each bundle are either actual instances or placeholders, but not models. (For the correct modeling of product models, see the dedicated recipe)
Warnings
FW1: Warning if opening hour specs include time-zone spec: Make sure this is the proper time-zone at the location.
- Error Message: The time-zone specification does not match the location or is not valid.
- Potential Problem: OpeningHourSpecification holds together all aspects related to the opening hours for a given DayOfWeek for a given LocationOfSalesOrServiceProvisioning. Care must taken that time-zone is present and is valid, it also should match the related location.
FW2: Check for expired offers or price specifications (and other nodes)
- Error Message: No statement in the Offering is valid and no validThrough is in the future.
- Potential Problem: The properties gr:validFrom and gr:validThrough should be used to specify the validity of instances of gr:Offering and gr:PriceSpecification (including subclasses). At least the gr:Offering should contain a validity statement and the validThrough property should be in the future.