RE: some x has only y

> -----Original Message-----
> From: public-owl-dev-request@w3.org [mailto:public-owl-dev-
> request@w3.org] On Behalf Of Matthew Pocock 
> 
> Hi,
> 
> 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.
> 
> [snip]
> 
> 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.
> 

I think this can be done without creating an ABox, but I will need the OWL gurus on the list to double-check my logic (see below).

Let's start with the following set of base axioms:

OWLClass(:BeerDrinkingExperience)
OWLClass(:KaraokeExperience)
ObjectProperty(:causes)


>
> 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
> experience
> 

In order to capture the logic you're looking for here, "beer drinking that leads to karaoke" would have to be an intersection class, not a subclass of "beer drinking experience". As written, ANYTHING that causes karaoke is beer drinking, which I don't think is what you were trying to say.

So let's postulate the following assertions:

OWLClass(:BeerDrinkingThatLeadsToKaraoke)
EquivalentClasses(:BeerDrinkingThatLeadsToKaraoke 
                  ObjectIntersectionOf(:BeerDrinkingExperience 
                                       ObjectSomeValuesFrom(:causes :KaraokeExperience)))

# Redundant...implied by intersection semantics
SubClassOf(:BeerDrinkingThatLeadsToKaraoke :BeerDrinkingExperience)


>
> However, while this gets arround the problems with the a-box approach,
>

I'm not sure it does. In this case, all you have done is created a class describing beer experiences that lead to karaoke. You have not said that this class necessarily contains any members. 

To elaborate, if you said something like

# Beer drinking does NOT cause karaoke
EquivalentClasses(:BeerDrinkingExperience
                  ObjectAllValuesFrom(:causes 
                                      ObjectComplementOf(:KaraokeSinging))
                                   

you would not be creating an inconsistency. Instead, you would be implying that :BeerDrinkingThatLeadsToKaraoke is an empty class (i.e. equivalent to owl:Nothing). At this point, we haven't actually REQUIRED that the members of the class exist.


>
> 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. 
>

I think the following sentence is key:

>
> This would require this (anonymous) concept to be satisfiable,
>

So how do we require that a class be satisfiable? While I'm on fairly sure footing with everything I've said so far, here's where I begin to wonder. Can we declare that a class is satisfiable by declaring the following?

# someClass has at least one member
DisjointClasses(:someClass owl:Nothing)


If that were the case, then your problem could be addressed like this:

# Sometimes, beer drinking causes karaoke
# Or, there is at least one beer drinking experience that causes a karaoke experience
DisjointClasses(owl:Nothing 
                ObjectIntersectionOf(:BeerDrinkingExperience
                                     ObjectSomeValuesFrom(:causes :KaraokeExperience)))


Does this work? Does declaring a class disjoint with owl:Nothing mean that it PROVABLY has members? My gut says that this doesn't work, but I can't figure out why. I'd love to hear the list's opinions on this.


Thanks,

Tim Swanson
Semantic Arts, Inc.
Fort Collins, Colorado




>
> 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?
> 
> Thanks,
> 
> Matthew
>

Received on Wednesday, 12 March 2008 16:11:05 UTC