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

Re: ACTION: task force unasserted triples

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Wed, 24 Apr 2002 10:50:59 -0500
Message-Id: <p0510152eb8ec82bf94ff@[]>
To: "Jos De_Roo" <jos.deroo.jd@belgium.agfa.com>
Cc: www-webont-wg@w3.org
>>The situation can be summed up as follows. The WebOnt language is
>>obliged by the layering requirements to treat its own syntactic
>>constructions as assertions of the existence of a class corresponding
>>to the syntactic construct(and in fact of a great deal else as well,
>>eg lists). This is because the RDF meaning of the RDF encoding of
>>every piece of the WebOnt language amounts to an assertion of the
>>existence of that class. And, as Peter has shown, such a requirement
>>is very dangerous, since it can rapidly lead to paradoxes or
>>contradictions of various well-known kinds when the language is
>>reasonably expressive. (It may be worth emphasizing that the kind of
>>problems that Peter is talking about have been well-known now for
>>close to a century, are widely studied, and that there is no easy or
>>cute way to hack around them. Some very smart people (Hilbert,
>>Russell, Church, Turing, Goedel, Quine, Kripke, Montague) have
>>wrestled with these problems, and the consensus seems to be that
>>there isn't any way to avoid them. Certainly they cannot be avoided
>>by appeals to other kinds of logic, such as multi-valued logics or
>>abandoning the law of excluded middle. They have the same kind of
>>status in foundations of mathematics as, say, the conservation of
>>energy has in physics. A blithe confidence that some way will be
>>found to hack around them should be treated rather like a patent
>>application for a perpetual-motion machine: its really not worth
>>getting into the details of what is wrong with it.)
>[i really more than hate the idea of perpetual-motion machines]
>Some further thoughts...
>Suppose we want to say
>   :John a [ owl:intersectionOf ( :Student :Employee ) ] .
>which is in triples
>   :John a _:a0 .
>   _:a0 owl:intersectionOf _:a1 .
>   _:a1 owl:first :Student .
>   _:a1 owl:rest _:a2 .
>   _:a2 owl:first :Employee .
>   _:a2 owl:rest owl:nil .
>Now suppose I'm so clumsy to create http://www.agfa.com/w3c/n3/ta.n3
>   :John rdf:type _:a0 .
>   _:a0 owl:intersectionOf <http://www.agfa.com/w3c/n3/ti.n3> .
>and http://www.agfa.com/w3c/n3/ti.n3
>   _:a1 owl:first :Student .
>   _:a1 owl:rest _:a2 .
>   _:a2 owl:first :Employee .
>   _:a2 owl:rest owl:nil .
>This is not to say that we should do it in that way,
>just to say that it could be thought in that way.
>I'm now asserting ta.n3 but what happens while
>asserting the owl:intersectionOf statement?
>Because we have to have a list of classes it's
>quite obvious that we have to dereference our uri
>to get that (functional) term in our engines.
>Does that mean that we also have to *assert* the
>statements in ti.n3? Not at all I think.
>We are not ``talking'' about _:a1, but ``using'' it.

Right, I like this idea. It is simple, straightforward, practical, 
and it requires no change to RDF (though it does come close to 
violating Dan C's notion of what it means to publish an RDF graph). 
OWL needs to add some extra meaning to RDF, but  that is what one 
would expect, and the extra meaning involved is very 'webbish' and 
natural-seeming, involving using URIs as, well, URIs.

But I had the distinct impression that this option was ruled out at 
the Amsterdam F2F on the grounds that any solution that involved 
"lots of little files" wasn't acceptable. That was late on the second 
day, and things were a little chaotic, but since then I have been 
working on the assumption that we have to find some other way to do 
it. If that assumption is wrong, maybe someone else who was at the 
meeting can correct my memory.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Wednesday, 24 April 2002 11:50:58 UTC

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