GoodRelationsOptionalAxiomsAndLinks
From Wiki of the E-Business and Web Science Research Group
Contents |
Useful Rules, Axioms, and Links for the GoodRelations Ontology
On this page, we are collecting optional rules and axioms and linksets for GoodRelations that are not part of the main ontology specification but can be helpful in many cases.
They can be imported in your model when they don't hurt. Some have side-effects that are unwanted in some scenarios.
Such rules are not part of the core GoodRelations ontology for two reasons:
- For semantic aligments with other vocabularies ("ontology mappings"), the problem is that the candidate vocabularies are often defined in different ontology languages or language fragments, e.g. RDF-S, OWL DL, and OWL Full. Including such alignments in GoodRelations directly will turn GoodRelations into OWL Full, which is something we want to avoid as much as we can. The reason is that there are applications for GoodRelations both
- in the "open, wild Web", where OWL Full will anyway be the likely language fragment, and incomplete, lightweight reasoning be suffcient, and
- in controlled, corporate settings, where staying withing OWL DL is an important feature for consistent DL reasoning.
Also, those alignments that are useful in practice are often broader than correct. While they are good in 90% of the cases, they will have unwanted side-effects in 10% of the cases. Thus, including them must be optional
- in the "open, wild Web", where OWL Full will anyway be the likely language fragment, and incomplete, lightweight reasoning be suffcient, and
- For additional rules and axioms, the problem is that they raise the bar for computing the full entailment, which may slow down reasoner performance. Also, they are very promising topics for further research and fine-tuning, so the examples given in here will be initial sketches only. Practitioners will be able to improve them a lot in terms of computational efficiency and quality. If you are working on business applications that consume GoodRelations data, this is what you should dedicate resources to.
Recommended Default Rules
The following rules should be used by default for any GoodRelations data. They require just a simple rule reasoner.
Product Models
In GoodRelations, you can link a product or service (both gr:ActualProductOrServiceInstance and gr:ProductOrServicesSomeInstancesPlaceholder) to a make and model (gr:ProductOrServiceModel), i.e. the "datasheet" that specifies technical features for all those individual objects.
Now, our intuition tells us that an actual product inherits all technical features from its make and model, unless specified at for that particular individual specifically.
Example: If the Nikon camera model T80 has a weight of 400 g, then a camera instance of which is known that it is of this make and model can be inferred to weight 400 g, too.
SPARQL CONSTRUCT Rule:
# Products inherit all product features from their product models unless they are defined for the products individually
CONSTRUCT {?product ?property ?valueModel.}
WHERE
{
{
{?product a gr:ActualProductOrServiceInstance.}
UNION
{?product a gr:ProductOrServicesSomeInstancesPlaceholder.}
}
?model a gr:ProductOrServiceModel.
?product gr:hasMakeAndModel ?model.
?model ?property ?valueModel.
{
{?property rdfs:subPropertyOf gr:qualitativeProductOrServiceProperty.}
UNION
{?property rdfs:subPropertyOf gr:quantitativeProductOrServiceProperty.}
UNION
{?property rdfs:subPropertyOf gr:datatypeProductOrServiceProperty.}
}
OPTIONAL {?product ?property ?valueProduct.}
FILTER (!bound(?valueProduct))
}
Possible extensions: Additional rules for gr:isSparePart, gr:isConsumableFor, gr:isSimilarTo, and gr:isAccessoryOrSparePartFor.
(Previous page: Ruleset for Product Model Properties, now redirects to this section.)
Expand gr:includes
The gr:includes property is a shortcut for the many cases in which the product includes just one item. By that you spare the effort for an additional gr:TypeAndQuantityNode.
However, when querying, you must search for the full pattern, or both. In order to expand all usages of gr:includes to the full pattern, activate the following SPARQL CONSTRUCT rule:
SPARQL CONSTRUCT Rule:
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.}
Product Variants
The gr:isVariantOf object property allows 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 gr:quantitativeProductOrServiceProperties, gr:qualitativeProductOrServiceProperties, and gr:datatypeProductOrServiceProperties that are defined for the first gr:ProductOrServiceModel, except for those defined for the variant individually.
Exception: gr:hasEAN_UCC-13 and gr:hasStockKeepingUnit should not be inferred for the variant.
Example: foo:Red_Ford_T_Model gr:isVariantOf foo:Ford_T_Model
Note 1: gr:isVariantOf is NOT a transitive property in GoodRelations, because the semantics of defaults is a bit more complicated. In particular, the order of reasoning steps matters. If A is a variant of B and C a variant of B, then B should first inherit properties from A and C from B, before C would inherit properties from A. Otherwise, properties defined at thelevel of B could be overwritten by properties defined at the level of A. This problem is relevant only if model data overwrites product features at intermediate levels AND if there is more than one level of variantOf relationships. A pragmatic solution is to execute the construct rule a few times sequentially.
Note 2: There is a problem with quantitative values held in blank nodes in the current rule, because such may not be properly replicated. Avoid blank nodes for quantitative values, if possible.
SPARQL CONSTRUCT Rule:
# Rule for product variants
CONSTRUCT {?model2 ?property ?valueModel1.}
WHERE
{
?model1 a gr:ProductOrServiceModel.
?model2 a gr:ProductOrServiceModel.
?model2 gr:isVariantOf ?model1.
?model1 ?property ?valueModel1.
{
{?property rdfs:subPropertyOf gr:qualitativeProductOrServiceProperty.}
UNION
{?property rdfs:subPropertyOf gr:quantitativeProductOrServiceProperty.}
UNION
{?property rdfs:subPropertyOf gr:datatypeProductOrServiceProperty.}
FILTER (?property!=<http://purl.org/goodrelations/v1#hasEAN_UCC-13> && ?property!=<http://purl.org/goodrelations/v1#hasStockKeepingUnit>)
}
OPTIONAL {?model2 ?property ?valueModel2.}
FILTER (!bound(?valueModel2) && ?model1!=?model2)
}
Data Cleansing: Entity Consolidation Etc.
The distributed character of the Web makes it very likely that the exact same entity is being defined in multiple graphs. In particular, there will be significant redundancy in the definition of
- Business Entities and
- Product Models.
The main cause is that providers of data may define entities locally rather than searching for an authoritative URI on the Web. For example, someone exporting a catalog may want to refer to the manufacturer of a gr:ProductOrServiceModel or gr:ProductOrServicesSomeInstancesPlaceholder without searching for the authoritative URI of that manufacturer. This is not a major technical problem, since providers of commerce dataspaces will very likely offer entity consolidation as one important feature.
For your own projects, you can start with the following simple SPARQL CONSTRUCT rules to create owl:sameAs statements so that multiple definition of the very same entities will be treated as one.
Add links between Product Models and Products if they share the same gr:hasEAN_UCC-13
# Add gr:hasMakeOrModel links between models and products on the basis of identical EAN_UCC codes
CONSTRUCT {?product gr:hasMakeAndModel ?model}
WHERE
{
?model a gr:ProductOrServiceModel.
{
{?product a gr:ProductOrServicesSomeInstancesPlaceholder.}
UNION
{?product a gr:ActualProductOrServiceInstance.}
}
?model gr:hasEAN_UCC-13 ?ean.
?product gr:hasEAN_UCC-13 ?ean.
OPTIONAL {?product gr:hasMakeAndModel ?model2}
FILTER (?ean!="" && ?model != ?model2)
}
Consolidate Business Entities that have the exact same gr:legalName
CONSTRUCT {?u2 owl:sameAs ?u1.}
WHERE {?u1 a gr:BusinessEntity.
?u2 a gr:BusinessEntity.
?u1 gr:legalName ?name1.
?u2 gr:legalName ?name2.
FILTER (?u1!=?u2 && ?name1=?name2)}
Consolidate Product Models that have the exact same gr:hasEAN_UCC-13
CONSTRUCT {?u2 owl:sameAs ?u1.}
WHERE {?u1 a gr:ProductOrServiceModel.
?u2 a gr:ProductOrServiceModel.
?u1 gr:hasEAN_UCC-13 ?ean1.
?u2 gr:hasEAN_UCC-13 ?ean2.
FILTER (?u1!=?u2 && ?ean1=?ean2 && ?ean1!="")}
On Openlink Virtuoso, you can use
! bif:isnull (?ean1)
instead of
?ean1 != ""
which will be faster.
Note that the current rules assume perfect equivalence of the legal names resp. the EAN/UPC code. You could use more sophisticated filters for expanding the scope of the consolidation, e.g. ignoring capitalization and special characters (e.g. "Miller Ltd." vs. "miller ltd").
Important:
1. Make sure you consolidate only nodes of the same type. For example, two gr:Offerings may have the same gr:hasEAN_UCC-13 property, but are of course not the same.
2. For local sets of such statements, you have any degree of freedom and I encourage you to experiment with different ones. Before publishing such sameAs statements, however, run thorough quality checks first. Reckless usage of sameAs can spam the Web of Linked Data, and dataspaces will consequently ignore all your graphs.
Links to FOAF, iCal, and other Vocabularies
The following schema mappings are often useful in practice. While they are good in 90% of the cases, they will have unwanted side-effects in 10% of the cases. Thus, including them must be optional. In particular, they may turn your model into OWL Full.
Acknowledgements: A big thanks to Andreas Harth (ahaATaifb.uni-karlsruhe.de) for several suggestions!
@prefix ical: <http://www.w3.org/2002/12/cal/ical#> gr:BusinessEntity rdfs:subClassOf foaf:Organization . gr:legalName rdfs:subPropertyOf foaf:name . gr:validFrom rdfs:subPropertyOf ical:DTSTART . gr:validThrough rdfs:subPropertyOf ical:DTEND .
Candidates:
- Locations: maybe foaf:based_near und geo:Point
- Yahoo / foaf: Match foaf:depiction and media:image
