We describe the design and ongoing update of a knowledge graph and its assorted ontologies which describe beverages and their commercial availability as products. Previous approaches have focused on beverage types or brands with limited support for tracing the product's content or identifying the specific product being consumed by a person. This inability to link the product and source has until now been a hindrance to nutritional studies and food traceability systems.
generic substance rather than an empirical measurement. The separate ontological structures representing substances, containers, commercial products and their individual instances allow the graph to be properly integrate with both empirically and statistically approximated nutritional datasets. As most consumers interact with nutritional substances through products, this ontological bridge will enable better end-user reporting of consumption which will lead to better nutritional analysis and recommendation.
Knowledge Graph, vocabulary, schema, taxonomy and ontology are all terms that have come to be used interchangeably in the literature, causing no small amount of confusion. Beverage Graph is meant to be used as a RDFS/OWL ontologically-based Knowledge Graph capable of integrating with as much of the food supply chain as possible. It currently numbers over 50M triples, growing daily and available as a data dump at https://rdf.ag or through a Sparql endpoint at https://rdf.ag/sparql. All Beverage Graph URIs are de-referenceable and accessible is most data formats through HTTP Content Negotiation.
The core of Beverage Graph relies heavily on the schema.org and GS1 vocabularies. Schema.org[
GS1 Global’s Webvoc[
The largest issue in aligning these two vocabularies was the resolution of what a product is, as represented in Figure 1. We understand that Beer, Porter Beers and that a (hypothetical) Porter Beer brewed by ACME exist as facts, but that pragmatically, ACME Porter Beer can only really exist within a container.
Furthermore, there is more than one size of container (variant) and each physical container is
iflled from beer from a specific lot (beer batch). The specific arrangement of Figure 1 leverages
the strengths of both schema.org and GS1 vocabularies to represent all aspects of a beverage
product. The actual contents of beverages is represented using the Beer[
ACME Porter
rdf:type rdf:type rdfs:subClassOf gs1:package schema:isVariantrOdff:IAtnyCp4rMed7f3E:tmyPploCertaenr rdfs:subClassOf
ACME Porter in 473ml Can Lot 23 rdf:typredf:type beer style. Similarly for fruit juices, we leverage the FoodOn ontology to ontologically reveal ingredients, as in Figure 2.
gs1:Beverage schema:ProductGroup
rdf:type Dole® pineapple juice 7551c5ae-46c5-4d0f-a09dacc9dfffc8bb rdfs:subC lassO f pineapple juice (unsweetened) FOODON_03305240
rom deriRvOe_0d00F1000
Monte Lirio (Uninstanitated)
owl:oneOf pineapple plant
NCBITaxon_4615
The Dole®brand pineapple juice product group is a subclass of the FoodOn pineapple juice class which references its source fruit. It is evident that the structure has enough flexibility to reference the specific cultivar instead of a generic pineapple plant. Figures 1 and 2 are simplifications of the data available within the graph and do not represent properties such as packaging, manufacturer, brand and product description and location information.
The beverage graph uses the W3C Provenance [
Because several commercial sources are used to update the Beverage Graph, Entity resolution
is an important process due to the overlap between commercial data sources. The graph nature
of the data provides a ready made structure for a statistical record linkage[
We note with disappointment that vocabulary reuse seems to be a “do as I say and not as I do” principle and that similar properties are often re-implemented. Concurrently, few graph databases provide the facilities, or are configured, to make use of ontological equivalencies when querying data. For this reason, the Beverage Graph often contains redundant properties in order to make data consumption as simple as possible. A small series of ontological statements3 is also maintained here as a means of aligning temporal statements between PROV-O, Time and schema.org as well as documenting equivalencies between common properties such as gs1:organizationName, schema:name and foaf:name. The data can be consumed with or without these ontological axioms.
The construction of the graph highlighted the complexities of commercial data management, the benefits of ontological backing and the complexities of integrating diferent ontological backed datasets. In acquiring external data, commercial API design reflect the needs and views of their owners which can result in unexpected data representations. A product variant should reference product instances that vary on explicitly defined, specific dimensions. Consumer facing API will often return product variants based on undefined conditions which may include similar packaging type, volume or store location which makes automated integration dificult.
Issue in entity resolutions have highlighted the usefulness of generic terms such as the Geonames 6295630 “planet earth” entity as a generic stand-in for the locality of a brewery as this information is not always available. This avoids the sort of issues that would occur in relational databases with null values, in that the data is always logically consistent and schematically complete even through it is factually imprecise. Operationally, this greatly reduces the complexity of entity resolution queries as fewer exceptions must be handled.
Ontology quality literature focuses on ontological completeness, logical consistency and
structural issues[
3https://rdf.ag/o/BeverageGraph
In this case, the consequence is that there are two mechanisms for defining a fruit juice and some confusion as to whether it derives from the plant or the fruit. Both mechanisms are ontologically consistent, but it makes querying the FoodOn ontology more dificult and potentially duplicates terms. Much has been made of “the code being the documentation” but at scale, ontological integration must be done programmatically and these issues will not be discovered without a high level overview of how specific real world objects are modeled. Too often, “suggestions” are made about the proper use of an ontology when it should be clearly specified. While well intentioned, the cost of flexibility in solving too many problems is a series of poor solutions instead of one good one.
A parallel can be made with the early experiences of the Dublin Core standards which failed
to provide an oficial structure for citing a bibliographic work in RDF while simultaneously
publishing a dcterm:bibliographicCitation term. The only way known to the authors to use
Dublin Core coherently is the Bibo[
Lastly, the actual semantic power of OWL2 ontologies is immense which, in a parallel to software design, can tempt designers to use overly complex technical solutions to simple problems. Ontology end users that wish to solve their own problem will naturally gravitate to the simplest, most documented solutions as it has the lowest cost of implementation.
Beyond its initial focus on supporting beer brewers, the Beverage Graph is flexible in its design to support additional information as to the product, the generic beverage and detailed packaging information, including whether the packaging is recyclable and its composition.
This opens the door to low hanging fruit studies on the prevalence of reusable packaging versus recyclable packaging and their relative volumes within specific markets. As other datasets also report the nutritional / calorimetric content of products, it becomes possible to quickly generate a partial but accurate nutritional profile of a person’s diet simply by scanning the barcode located on their beverage as they consume it. A direct application is in the resolution of the product content on an ontological basis based on its nomenclature. Consider the case of “Cider” which can mean an alcoholic beverage from fermenting apples or unfiltered apple juice or (confusingly), an “Non-alcoholic Cider” sold in the context of alcoholic beverages that contains no or only trace amounts of alcohol. As the Beverage graph reports the commercially mandated alcohol by volume (beer:abvValue / gs1:percentageOfAlcoholByVolume) for beverages an appropriate determination can be made.
The addition of linkages to legislative ontologies may be most interesting from an analytical viewpoint as legislation is heavily dependant on context and local culture. A direct example is the contrast between beer, an alcoholic beverage, and vanilla extract, a baking ingredient. While beer may contain alcohol, it is not mandated to and may actually be non-alcoholic. Vanilla extract is mandated to contain a certain percentage of alcohol in order to be considered an extract but is regulated as a food and not an alcoholic beverage. Legislatively, their intended use dictates the regulatory regime under which they are controlled. From a public health perspective, it is their compositional properties that will dictate their capacity to be abused.
In closing, the Beverage Graph provides a core from which other datasets and ontology can link against or extract a working set. It is freely available, well labeled and aims to be as open as possible.
The Beverage Graph is a maintained collection of instances and ontological classes that document commercially available beverages, their contents and their packaging. It’s construction allows for integrations with other external data sets and lends itself to dietary, commercial and food production analysis. As additional upstream data sources are acquired, the graph will be expanded to more brands and beverage types such as cofee, tea and hard liquors.