Of beer and upper ontologies and how they affect modelling

(Warning: this is a chatty, imprecise description written on a plane in a daze!)

Lukas Koster (@lukask) from the University of Amsterdam and I were discussing some of the issues in using upper ontologies with linked data. One of the major issues can be seen in this real-life (or perhaps, lack of a life) discussion that we had regarding modelling beer.

In my beer ontology, I have modelled beer as a thing that has a property hasCap, which takes an argument of that is an instance of the class “Cap”. Thus we model a beer “NearWater”:

:nearWater33 a beer:Beer ;
rdfs:label "NearWater" ;
beer:volume "33 cl" ;
beer:hasCap beer:CrownCap .

beer:CrownCap a beer:Cap ;
rdfs:label "Crown Cap" .

This modelling states that “NearWater” is a beer and it has a crown cap; from this we can rapidly find out what kind of opener we need in order to open this beer, because the beer hasCap property is “crown cap”.

Lukas, however opines that hasCap is not a property of Beer, but of Bottle; thus he models his tripel ontology:

:nearWater a tripel:Beer ;
rdfs:label "NearWater" ;
tripel:hasBottle :bottle123 .

:bottle123 a tripel:Bottle ;
tripel:volume “33 cl” ;
tripel:contains :nearWater ;
tripel:hasCap :crownCap ;
tripel:hasLabel :nearWater33Label .

:nearWaterCrownCap a tripel:Cap ;
tripel:capLabel :nearWaterCapLabel .

:nearWater33Label a triple:Label ;
triple:labelText “NearWater 33cl, like sex in a canoe” .

Lukas’ detailed modelling allows him to express many details of the bottle, the cap, etc. Contrasted with the model I provided, we see that 1) Lukas is interested in a generic concept of the particular beer, I model a specific instance of the beer — a merchantable item (a 33 cl bottle of NearWater) (I could model a generic concept of “Beer”). 2) Lukas’ model allows extensive variations in the delivery method and can reflect facts that are not easy to reflect upon in my model. 3) Lukas’ model is a strangely bottle-oriented because each new merchantable item is actually a new tripel:Bottle, rather than a beer:Beer.

Given that there are few arguments against a generic modelling of the beer, I add the class :nearWater and amend :nearWater33:

:nearWater a beer:Beer ;
rdfs:label "NearWater" .

:nearWater33 a beer:Beer ;
rdfs:subClassOf :nearWater ;
beer:volume "33 cl" ;
beer:hasCap beer:CrownCap .

Here, I state that nearWater33 is a subclass of :nearWater, which means that it inherits its properties.

In my first model, I would need the following SPARQL query to retrieve all the relevant information for a merchant site:

prefix beer: <http://folk.ntnu.no/greenall/beer#&gt;
prefix rdfs: <rdfs>

SELECT ?label ?volume ?cap WHERE {

?beer a beer:Beer ;
rdfs:label "NearWater" ;
beer:volume ?volume ;
beer:hasCap ?capType .

?capType rdfs:label ?cap .
}

In Lukas’ model, I would use a query such as:

prefix tripel: <http://example.com/tripel/&gt;
prefix rdfs: <rdfs>

SELECT ?label ?volume ?cap WHERE {

?beer a tripel:Beer ;
rdfs:label "NearWater" ;
tripel:hasBottle ?bottle .

?bottle tripel:volume ?volume ;
tripel:hasCap ?capType .

?capType rdfs:label ?cap .
}

In my extended model, I would use:

SELECT ?label ?volume ?cap WHERE {

?beer a beer:Beer ;
rdfs:label "NearWater" .

?instance rdfs:subClassof ?beer ;
beer:volume ?volume ;
beer:hasCap ?capType .

?capType rdfs:label ?cap .
}

From a modelling perspective, my revised model places focus clearly on the beer, whereas Lukas’ model focuses on the bottle. The insight that cap is a property of a bottle is correct, but it is nevertheless desirable to present an easy-to-understand interface to users, so the original insight from my original model that the merchantable item (that it is a 33 cl bottle of NearWater that is on sale) is preferable. The revised model takes into account that Lukas’ distinction between the beer itself and a specific bottling for this beer, but rather models :nearWater33 as a subclass of :nearWater.

There are many ways of modelling beer, however, dependent on the purpose of the ontology, we model in different ways. Given an upper ontology designed for representing bottled beer as a commodity, my original model would probably be acceptable; given an upper ontology based on epistemological principles, and particularly one that was founded in cognitive theory and/or industrial modelling, Lukas’ model would be preferable; my final model provides a middle ground that provides better support for a generic concept of a beer and mirrors closely the real-world mercantile ontologies. Of these approaches, the latter is also probably the most “linked data” approach as it uses generic subclassing to provide support for the concept of the beer in a bottle.

A looser approach leads to more flexibility about what you can say, so that a “merchantable item” can be easily defined. If one uses an upper ontology that defines liquid, and beer is a subclass of liquid, then the restrictions placed upon the liquid concept are inherited by beer. If liquid is defined as a physical state, then beer cannot be defined as having a cap, or a volume. This would co-erce Lukas’ modelling upon any modeller. Further, such a model would likely have a concept of volume, which can be applied to containers. This would likely preclude a modelling of hasVolume with a value “33 cl”, but rather something like:

:container a ex:Container ;
ex:hasVolume :volume .

:volume a ex:Volume ;
ex:quantity :quantity .

:quantity a ex:Quantity ;
ex:value "33" ;
ex:unit ex:Centilitre .

In order, then to find out the physical volume of the bottle, we then look up the container, it’s volume, the quantity of the volume and the unit used to measure the volume, and the rdfs:label of that volume. Furthermore, the relationship between the bottle, the label and cap becomes one that is largely problematic because the container is actually a composite; thus:

:beerBottle a ex:Composite ;
ex:hasPart :container ;
ex:hasPart :cap ;
ex:hasPart :label .

Thus we have a proxy to represent the bottle. If we understand that it is this composite that is also the merchantable item, we add a triple to the effect that :nearWater is contained by the container.

This leads to a situation where, in order to produce our desired result, we need the following SPARQL query.

SELECT ?label ?volume ?cap WHERE {

?bottle ex:hasPart ?container ;
ex:hasPart ?capProxy .

?capProxy tripel:hasCap ?capType .

?capType rdfs:label ?cap .

?container ex:hasVolume ?volumeProxy ;
ex:contains ?beer.

?beer rdfs:label "NearWater" .

?volumeProxy ex:quantity ?quantity .

?quantity ex:value ?value ;
ex:unit ?unitProxy .

?unitProxy rdfs:label ?unit .

BIND (CONCAT(?value,CONCAT(" ",?unit)) AS ?cases)

}

Because the chosen upper ontology coerces a world view where everything is defined in terms of strictly defined classes, the modelling becomes an exercise of representing information in the ontology, rather than representing information usefully and appropriately for the application. There are indeed cases where the level of finesse that we see here is appropriate, however, the added baggage of all of the proxy classes means that getting the data becomes a task that is not directly simple for humans. It also means that large portions of domain specific knowledge become modelled in a potentially counterintuitive way because the upper ontology views the world in terms of composite parts and relations between these, whereas a merchantable item is ideally modelled as an instance that has a purchase and a sale value.

I don’t believe that modelling to be steered in this way is compatible with the wider goal of linked data: understandable provision of data using HTTP. Given the proxy-driven model, the response to the request for http://example.com/beerBottle is:

<http://example.com/beerBottle&gt; a ex:Composite ;
ex:hasPart :container ;
ex:hasPart :cap ;
ex:hasPart :label .

Which is in no way appropriate. Requesting the top-level instance :nearWater gives the response:

<http://example.com/nearWater&gt; a tripel:Beer ;
rdfs:label "NearWater" ;
tripel:hasBottle :bottle123 .

Which isn’t good either (especially as the only transition is to <http://example.com/beerBottle&gt;) and shows that working with this data becomes difficult for a person not au fait with the modelling defined in the upper ontology, and nor is this useful outside the context of reasoning, which has only spurious value when the required result is not only difficult to get (a merchantable item) and the same can be better represented without the artificial context of the upper ontology.

Advertisements
Tagged with: ,
Posted in Uncategorized

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s