W3C home > Mailing lists > Public > www-webont-wg@w3.org > August 2002

Re: OWL semantics

From: Jeff Heflin <heflin@cse.lehigh.edu>
Date: Fri, 09 Aug 2002 14:23:32 -0400
Message-ID: <3D5408A4.23AA4E2C@cse.lehigh.edu>
To: Ian Horrocks <horrocks@cs.man.ac.uk>
CC: www-webont-wg@w3.org


I absolutely agree with you that it is of utmost importance that we
resolve the OWL semantic issues now. That said, I'd like to discuss your
arguments for your position.

Although there may be good reasons for being against "classes as
instances," your argument below is not one of them. Sure, unary
predicates are a common way to model classes in first order logic (FOL),
but another just as common way is to define binary relations such as
isa(x,y) (which says x isa a subclass of y) and instanceOf(x,y) (which
says that x is an instance of class y). Only a few simple axioms are
needed to give these relations their correct semantics. With this idiom,
classes are no longer predicates but are instead objects in the domain
of discourse. Furthermore, the isa and instanceOf relations have a nice
correspondence with rdfs:subClassOf and rdf:type, making it likely that
people translating RDF into FOL might choose this method over the unary
predicate approach.

However, that said, this approach does not address the problem of
properties as instances. Note, in the RDF model, properties are simply
special kinds resources, and which suggests that they should be treated
as instances as well. To do so, would require you to embed HOL in FOL.
Perhaps your argument should focus on this matter first, before talking
about classes as instances.

I strongly agree with your point 1b. The use of OWL/RDF to change the
meaning of OWL or RDF itself could open up a Pandora's Box of trouble.
However, I'm afraid that this might be a consequence of choosing to
layer OWL on RDF. After all, RDF let's you say anything about anything,
and everything is just a resource. In order to describe a class or
property in RDF, you have to treat it as a resource, because all you
have are classes, properties and resources. If a class isn't a resource,
then you can't state that it is the subclass of another class. And what
is a resource, but an instance? But with this model, how can we prevent
statements that redefine RDF or OWL properties? Perhaps we can darken
the entire RDF, RDFS and OWL vocabularies, but this seems to go against
the zeitgeist of RDF. After all, if an RDF reasoner is supposed to
conclude A subClassOf C, when it sees A foo B, B foo C, and foo
subpropertyOf subClassOf, why shouldn't an OWL reasoner? [1] To do
otherwise, would be a non-monotonic layering (by this I mean, a language
that is layered on another language does not have all the entailments of

This is a crucial problem. It seems that RDF's ability to say anything
about anything presents a great big unknown when you begin adding more
expressiveness to the language.  In essence, I think this feature alone
turns our work from a standardization effort into a difficult research
problem. Although dark triples may help us sweep the problem under the
rug, I believe that approach undermines the few good reasons for
layering on RDF in the first place, and that if we take that approach,
we would have been better off just creating a (non-RDF) XML ontology

Unfortunately, I don't have any solutions at this time.


[1] I suspect that most RDF tools do not handle this inference correctly
anyway, but that is a different issue

Ian Horrocks wrote:
> Dear All,
> Having made a plea for the resolution of the semantics issue, I would
> now like to enter into the argument of what form these semantics should
> take.
> I have tried to summarise below the arguments in favour of what has
> become known as the "Patel-Schneider" semantics. I have tried to couch
> this summary in terms that should be accessible to all members of the
> WG, and I would appreciate the more technically inclined members
> cutting me a little slack w.r.t. any minor imprecisions that may have
> crept in as a result.
> Point 1:
> I would like to argue that we should KEEP THE LANGUAGE (and the
> semantics) SIMPLE. In particular, we should make sure that it is (a
> subset of) first order logic (FOL). I.e., when we talk about classes
> we mean 1 place predicates, and when we talk about properties we mean
> 2 place predicates: Jane is a Person just in case our ontology entails
> Person(Jane), and Jane is the mother of John just in case our ontology
> entails isMotherOf(Jane,John). If the logic is first order, then the
> arguments of a predicate must always be either a variable or a
> constant (such as Jane).
> Another way to look at this is that a model of our ontology consists
> of a set of objects and a mapping function that maps individual names
> (constants) to single objects, class names to sets of objects and
> relation names to sets of pairs of objects. Jane is a Person just in
> case that, in all models of our ontology, the object that Jane maps to
> is a member of the set that Person maps to, and Jane is the mother of
> John just in case that, in all models of our ontology, the pair of
> objects that Jane and John map to is a member of the set that
> isMotherOf maps to.
> That is really all there is to it: you can explain it to pretty much
> anyone. Moreover, it is part of the core curriculum of most
> undergraduate computer science and maths courses, and many of the
> people who will be involved in implementing the semantic web will
> already be very familiar with it. Can we say the same thing about
> solipsistic logic? How many of us had ever heard of it before joining
> the WG, or even now have the slightest idea as to what it is all about?
> Point 1a:
> While it is clear that, in some cases, it is useful to be able to talk
> about classes as instances, we should be clear that this means going
> outside first order logic into higher order logic (HOL), because we
> can now have predicates as the arguments of other predicates. If we
> accept classes as instances, then even OWL Lite (which is supposed to
> be "viewed by tool builders to be easy enough and useful enough to
> support") will be a HOL. Some people will argue that it isn't really
> higher order, but what they mean is that it may be possible (depending
> on the assumed semantics of the HOL syntax) to embed the HOL in FOL by
> axiomatising the HOL itself and the HOL ontology in FOL. Imagine this
> conversation with a potential OWL tool builder:
> Tool builder: OWL (Lite) is a higher order logic, so I will need a HOL
> reasoner, right?
> OWL guru: No, no. All you have to do is take a FOL reasoner, an
> axiomatisation of OWL in FOL, and feed the axiomatisation, plus your
> axiomatised ontology, into the FOL prover. Piece of cake really.
> It is worth noting that real HOL systems, e.g., Isabelle [1] and HOL
> [2], don't work via FOL axiomatisation as it is well known that, in
> practice, you wont be able to prove anything this way.
> It is also worth pointing out that such axiomatisations are invariably
> large and complex, and that it is difficult/impossible to be sure that
> they are correct. E.g., take a look at the axiomatisation of
> DAML+OIL/RDF in [3], which contains around 140 axioms. FOL reasoners
> can be used to detect "obvious" inconsistencies (as happened with
> earlier versions of [3]), but simply ironing these out is a LONG way
> from proving that the axiomatisation correctly captures the meaning of
> the language.
> Point 1b:
> It should NOT be possible to use OWL/RDF statements to constrain the
> meaning of OWL/RDF syntax. E.g., if myTransitive is a sub-class of
> transitiveProperty, then instances of myTransitive should NOT be
> treated by OWL as transitive properties. If we go down this road, then
> we need a (HOL) reasoner even to parse the syntax of an OWL ontology,
> to determine what is being said, and to check that it is valid OWL.
> For example, when we parse an OWL ontology we may find that instead of
> using the familiar subClassOf property, it contains lots of statements
> like "Person foo Animal". If we allow statements in the ontology to
> constrain the meaning of the syntax, then we may be able do deduce
> that foo is equivalent to subClassOf, and that this is therefore a
> meaningful OWL statement. The reasoning required for this deduction
> may be extremely complex. It may even be IMPOSSIBLE to be sure that we
> have derived the complete syntactic meaning of an OWL ontology
> (because the language is undecidable).
> Another example. In OWL, transitive properties cannot be used in
> cardinality restrictions. If we allow inference to be used to deduce
> that a property is a transitive property, then when we parse an OWL
> ontology we can't be sure that it is valid until we have checked that
> none of the properties used in cardinality constraints can be deduced
> to be transitive. Again, the required reasoning may be very complex,
> and it may even be IMPOSSIBLE to be sure that the ontology is
> syntactically valid. One can easily imagine situations where the
> inference that a property is transitive depends on a cardinality
> restriction involving the property itself, which then becomes a
> syntactically invalid statement, so the inference is no longer valid
> (a paradox).
> To return again to our poor benighted tool builder, can you imagine
> the reaction we will get when we try to explain that it is impossible
> to parse an OWL ontology and check it for syntactic validity without
> employing the services of a (possibly higher order) reasoner?
> Point 2:
> If we decide to go with some form of higher order logic and/or allow
> reasoning about syntax, then all our efforts to design OWL so as to be
> relatively simple, and hopefully even implementable, are a (bad)
> joke. Even the so called Lite version of OWL would be impossibly
> complex to deal with, as I hope I showed in some of the above
> examples.
> I guess that is enough to be going on with.
> Regards, Ian
> [1] http://www.cl.cam.ac.uk/Research/HVG/Isabelle/index.html
> [2] http://www.cl.cam.ac.uk/Research/HVG/FTP/FTP.html
> [3] http://www.w3.org/TR/daml+oil-axioms
Received on Friday, 9 August 2002 14:23:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:33 UTC