Re: REQDOC: ontologies as resources

[sorry this is so long; been meaning to write this up (or down) for some time --dan]

On Thu, 14 Feb 2002, Peter F. Patel-Schneider wrote:

> In a message expressing my concerns with the requirements document, I
> argued that it is premature to require that ontologies be resources, at
> least if by resource, we mean an RDF resource, i.e., elements of the domain
> of discourse that can be used just like any other element of the domain of
> discourse.

I think this is the crux of the WebOnt/RDFS layering dispute. While folk
have often focussed on the "RDF schema says that class is a class" aspect,
this spin on the issue gets us closer.

During the RDF Schema 1.0 discussions, we were painfully aware that there
were many important and meaningful characteristics of classes and
properties which the RDFS WG wasn't going to provide a way of describing.

We hoped that things like DAML+OIL would come along and flesh out some
more of the details later (yes, and help fix the bugs...). Things like
class-contextualised range contraints, transitive properties, cardinality
stuff etc. The RDF (and I believe web architectural) view of this is that
properties such as 'worksFor', 'livesWith' are things in the domain of
discourse, named using URI references, and described using the same
descriptive machinery we use for describing everything else. If someone
deploys a property 'http://example.com/myvocab#livesWith' in the Web, and
that property is symmetrical, RDFS doesn't define any vocabulary for
making that characteristic of the property mechanically evident. But RDF
(not just RDFS) does establish the convention that
'http://example.com/myvocab#livesWith' is in the domain of discourse, and
as such open to further description by arbitrary parties using arbitrary
vocabularies.

This worked quite well for many of us, although Description Logic folk
seem to find it distressing. Having properties and classes in the domain
of discourse meant that the RDFS 1.0 WG didn't have to take upon
themselves the task of enumerating all the useful kinds of things one
might say about classes and properties. Having watched various schema
efforts come and go, I strongly suspect this WG will find this an
attractive feature.

For example, look forward to the day when our WebOnt specs go out for
review by, amongst others, the Internatationalisation and Accessibility
groups at W3C. If we say to them, "classes and properties are special
things, distinct from all the other stuff we describe in the Web. You
can't describe them using ordinary RDF, only by
[some-as-yet-unspec'd-magic]", I predict you'll be in for a bumpy ride.

Instead, we might more plausibly say something like: "classes and
properties are treated as just-more Web identifiable resources. WebOnt/OWL
1.0 provides limited built-in support for describing the
internationalisation and accessibility-related characteristics of these
entities, but suggests RDF/WebOnt be used to add further descriptive
detail where needed.". Taking classes and properties out of the shared
domain makes us their sole guardian; people will come to this WG lobbying
to be allowed to say various things about classes and properties. That
seems problematic, from a practical and organisational point of view as
much as a technical one.


RDF Schema provides vocabulary to say things about classes and properties.

WebOnt/OWL provides fancier vocabulary to say things about classes and properties.

Other languages will do the same. WebOnt/OWL 1.0 will not be the last word!

If we *want* it to be the last word, we should pencil in a substantially
longer schedule for this WG. If not, we need a way for other groups to
describe (in more detail) the things that WebOnt/OWL partially describes.

So we need to plan for this. The approach taken by W3C to date, in RDF and
elsewhere, is that we use URI references to name things, gluing together
the work of our various working groups. If WebOnt decides that it doesn't
believe classes and properties are name-able by URI references, or that
they are members of the domain of discourse alongside everything else
we're busy describing, it buys itself a whole load of work. Having our
descriptive machinery in a non-magical domain of discourse is one way of
partioning the workload across a number of working groups. If someone
describes classes and properties according to WebOnt/OWL, are we telling
them that they can only use WebOnt/OWL 1.0 language features for sharing
information about their ontology? If so, we better make sure v1.0 is
pretty feature rich, for it'll have to serve the needs of the entire Web
community.

In this WG we'll have to find a way of dealing with feature creep. A
common tactic is "hmm, are you sure we *need* that in v1.0? Can't we
postpone that until v2.0?". There is a potentially huge shopping list of
characteristics of classes and properties that people might want to
be able to use to describe RDF/WebOnt ontologies. Understanding their
interactions/dependencies and the associated computational cost for
implementors is as we all know a highly technical business. There will
certainly be things that people want, or think they want, that would
increase the cost of implementing or deploying WebOnt. So we'll find
very likely find ourselves saying "no, not in this version", or "no,
WebOnt/OWL doesn't have any understanding of that construct". We need a
way of saying "lets do this in version 2", or "go define your own convention
for doing that", without forcing people to abandon WebOnt/OWL entirely if
we don't include their favourite features.

One danger we face, in trying to take this stuff mainstream, is that
WebOnt (and to lesser extent RDF) will be seen as being by and for the AI
or knowledge representation world. If we say "you can't do that with Web
Ontologies (because it makes description logic reasoners blow up)", we
risk alienating tens of thousands of mainstream Web developers who expect
to do most of their processing of Web data using tools like Perl, Java and
SQL databases. They may not be very impressed to hear "we omitted the
ability to say *that* about RDF properties because it makes things hard
for inference-oriented systems. More importantly, they will be rather
unimpressed if we then add "...and the language provides no mechanism for
anyone else to define other ways of further describing those self-same
classes and properties". Having classes and properties named by URI reference, and
living in the ordinary, RDF-describable domain of discourse, is our safety
valve. Without it (or some interesting workaround) we lose a rather
practical tool for getting to a widely valued WebOnt/OWL v1.0 spec in
non-glacial timescales.

From an implementors perspective, I have things I want to say about
certain RDF properties that I know DAML+OIL doesn't help me with (namely
that they're static/unchanging UnambiguousProperties). So I went away and
defined a class whose members are the properties I'm interested in. This
is easy, in an environment where properties are just a kind of describable
thing. If WebOnt/OWL makes it hard, I guess I'll have to lobby to get my
beloved language feature included in WebOnt/OWL 1.0 instead... I expect
others will find themselves in a similar situation.

The layering challenge is about fitting in with other WGs and
ontology-description efforts, both past and future, and about finding a
pluralistic extension mechanism without creating total anarchy. A toughie.
I fail to see how removing classes and properties from the domain of
discourse is going to help us make progress in that direction. It feels
uncomfortably close to "language extensibility is a known hard problem;
so... hmm... we'll deal with that in version 2."

Dan

-- 
mailto:danbri@w3.org
http://www.w3.org/People/DanBri/

Received on Thursday, 14 February 2002 15:58:58 UTC