W3C home > Mailing lists > Public > public-owl-dev@w3.org > January to March 2008

some x has only y

From: Matthew Pocock <matthew.pocock@ncl.ac.uk>
Date: Wed, 12 Mar 2008 09:23:11 +0000
To: public-owl-dev@w3.org
Message-Id: <200803120923.11516.matthew.pocock@ncl.ac.uk>


I'd like to convert something like "beer causes karaoke" into OWL that a) is 
semantically accurate and b) is represented with the minimum of artifice.

The noob error would be to make statements like:

  beer < causes some karaoke
  beer < causes only karaoke

But, of course, this is placing the quantifier in the wrong place. It says in 
the first case that every beer [drinking experience] causes a karaoke 
[singing experience], and in the second case, that beer causes exclusively 
kraoke. We know, of course, possibly from personal experience that beer leads 
to many things other than embarasing public displays of singing and also that 
we don't burst into tune each and every time we down a beer.

So, we could in our a-box create a 'whitness' model. This would need beer, 
causes and karaoke in the t-box, but no t-box assertions between them. 
Instead, we would add this to the a-box:

  b1 causes k1 ; b1 instanceof beer ; k1 instanceof karaoke

Now, when the ontology is fully classified and all individuals placed, we will 
get an inconsistency if somehow we have made it impossible that beer causes 
karaoke in at least one possible case. However, this seems like an ugly way 
forward. Firstly, we are using these 'whitness models' in a schematic way, 
rather than to represente real examples of things. Secondly, we get the wrong 
kind of error. It will tell us that this a-box is wrong because it clashes 
with the t-box, when in fact it is the t-box which is wrong.

Another way to do this would be to introduce a sub-class of beer [drinking 
experience] called something like "beer drinking that leads to karaoke".

"beer drinking that leads to karaoke" < "beer drinking experience"
"beer drinking that leads to karaoke" = causes some "karaoke singing 

However, while this gets arround the problems with the a-box approach, this 
has introduced a new named class with a necesarily ugly name. It feels like 
we now need extra documentation to allow a user or editor to know that we are 
using subsumption assertion to represent "some" in "some beer leads to 
karaoke" and therefore to tell us more about beer, rather than as a mechanism 
to say something about a specific sub-type of beer. I guess what I'm groping 
towards is 'anonymous sub-classes' so that I could say something like:

subclassof(_ intersection(beer, causes some karaoke))

where _ is a new class identifier, globally unique, each and every time it is 
used. This would require this (anonymous) concept to be satisfiable, but 
removes the need to make the ugly names. Fairly trivial tooling could flip 
this into 'some x ...' statements, for user interaction.

I hope that made sense. So is there a standard way to handle 'some' placed at 
this point in an assertion? A design pattern? An idiom? Or should I go with 
ugly whitness instances or with these 'some' named subclasses and just 
document things very carefully?


Received on Wednesday, 12 March 2008 09:23:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:16 UTC