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

RE: DTTF: darkest africa

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Thu, 30 May 2002 11:35:58 -0400
To: jjc@hplb.hpl.hp.com
Cc: www-webont-wg@w3.org
Message-Id: <20020530113558P.pfps@research.bell-labs.com>

From: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Subject: RE: DTTF: darkest africa
Date: Thu, 30 May 2002 16:25:43 +0100

> 
> >
> > Huh?  You are now saying that the behaviour of OWL graphs that include
> >
> > 	ex:person owl:sameClassAs owl:ABCDEF
> >
> > is undefined?  Why?  What is wrong with this?
> 
> The most obvious thing wrong with that is there is no such owl property
> as owl:ABCDEF. We control the namespace and we haven't made such a
> property.

But how does that prevent some other agent from using that URIref?  Why is
owl:ABCDEF not (a QName that expands into) a valid URI that can be used in
OWL?  I don't see any hint that the working group is going to ``control''
the owl namespace to this extent. 

> For the names we do define, the only thing wrong with it (IMO) is that
> it gives a misleading impression of what an OWL implementation will or
> will not do. If I say
>  ex:Rest owl:sameClassAs owl:Restriction .
> 
> and then try and use ex:Rest just like owl:Restriction then it won't
> work because:
> i) the OWL model theory
> and
> ii) OWL implementations
>   are looking for syntactic structures with a triple like
> 
> _:foo rdf:type owl:Restriction .
> 
> rather than doing a least fixed point or something like that on the
> interpretation of owl:Restriction.

> (I don't particularly like doing it syntactically. However I believe we
> are not wanting to support two steps in semantic inference. I think it
> is straight forward to simply ban some triples to block off any
> misapprehension that it may be possible to have indirect  impact on the
> user level ontology using entailments over OWL concepts. Moreover I
> believe that such a banning can be done in a way that postpones the
> research issues, rather than prematurely closing them in the negative).

Well, my point was precisely that owl:ABCDEF is *not* part of the
``built-in'' OWL machinery, so why should it matter what users do with it?
I agree that messing with the OWL built-ins is a dangerous thing to do.


> > > I suspect my list is incomplete, the rules for
> > > completing it are:
> > > - when in doubt add the triple
> > > - the only reason for not adding the triple is
> > >   + it seems genuinely useful
> > > and
> > >   + it expresses something that can be expressed
> > >     in mainstream description logic.
> > > I am assuming that the List vocabulary is in the
> > > owl namespace. Otherwise it would need to be
> > > explicitly treated in the black list.
> >
> > I don't understand this rationale for making triples dark.  I don't
> > understand the rationale for identifying triples as dark in
> > this way.  I
> > don't understand the implications here of making triples dark.
> 
> I am trying to build a fence. The classes and properties and
> restrictions still end up as in the domain of discourse, like in RDFS;
> but all the abilities of OWL and RDFS to say anything about them at a
> meta level is switched off (other than appropriate use of
> rdfs:subClassOf between user level classes etc).

> > > Of course, we could address the RDFS layering issue
> > > simply by deciding that all the dark graphs identified
> > > above are contradictions. Then we would respect all
> > > their RDFS entailments (trivially). I wouldn't like
> > > that much but could live with it, and would prefer it
> > > to making RDF Model Theory non-normative.
> >
> > Huh?
> 
> The suggestion that OWL treat some triples as not having their RDFS
> meaning is a suggestion that the RDFS Model Theory is in essence
> optional.

But why make them contradictions?

> > > If we wanted to stress conformance with RDFS then
> > > we would have slightly different text
> > >
> > > [[[
> > > implementation may treat a dark graph as
> > > having its RDFS entailments and any others
> > > of the implementation's chosing. The simplest
> > > implementation is to treat a dark graph as
> > > self-contradictory.
> > >
> > > ]]]
> > >
> > > (I doubt there would be group consensus for that).
> > >
> > > If we wished to stress the dangers of paradox we
> > > would have text
> > >
> > > [[[
> > > implementors should note that at least some
> > > dark graphs appear self-contradictory in
> > > interesting ways e.g.
> > >   testA, testB, testC
> > > ]]]
> >
> > > Jeremy
> >
> > I don't think that this proposal can lead to a solution of
> > the layering
> > paradoxes.  I certainly don't see any such solution above.
> 
> No. It doesn't intend to.

Then what is it trying to do?

> It tries to indicate that we may be able to agree on what we agree on,
> and identify the areas where we disagree. The areas where we disagree
> are less important than the areas where we agree. There may be practical
> ways of avoiding paradox by substantially reducing the apparant power of
> the language for describing itself. I don't think there are any
> implementations yet that would allow us to use this power.
> We have no use cases for exploiting that power. Personally I don't want
> to rule that power out for ever, but I believe that I agree with you on
> the meaning of all RDF graphs that do not contain any of the triples I
> identified.

Well, we disagree on the meaning of just about everything in an ontology,
including things like

  John a [intersectionOf A B] .

so I don't see how ruling out misuses of OWL vocabularly will help the
situation too much. 

> Also, areas where we disagree can be labelled as such. It is not a three
> valued logic but simple practical expediency. I am sorry I was less than
> precise about interpretations and truth, I got the impression that you
> had understood what I was getting at though.

If you don't want to consider triples that misuse the OWL vocabularly, then
why not just make them syntactically invalid?  I would view that as very
much clearer and cleaner.

> Jeremy


peter
Received on Thursday, 30 May 2002 11:36:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:50 GMT