Re: Could owl:sameAs reference non-OWL resources

Dear Bernard

This is in response to your comment/query
http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0059.htm

The short answer is 'yes'; that is, OWL can, in principle, 
interoperate with 'non-OWL resources'. In fact there is not really a 
well-defined notion of an "OWL resource" and hence not of a non-OWL 
resource: like RDF, OWL simply uses URIrefs to denote things; and 
'things' here can literally be *any* thing at all; so the use of 
owl:sameAs to indicate that two things are the same (more exactly, 
that two different URIrefs refer to the same thing) is not restricted 
in any way: in particular, it is not restricted to "OWL resources". 
(There is a restriction in OWL DL in that owl:sameAs cannot be used 
there to refer to identity of OWL classes or properties: this is to 
keep the OWL DL inference process within manageable complexity 
bounds. But this restriction is private to OWL, as it were: it 
doesn't prevent OWL from spreading its referential net widely across 
the universe of Web resources.)

In the example you cite, the URIref "http//sports.org/US#SoccerTeam" 
is supposed to indicate a class, probably the class of members of the 
team; so this is indeed an externally defined resource. The OWL text 
asserts that this is being regarded as an OWL class, which is merely 
OWL's way of saying that it claims the right, as it were, to perform 
class reasoning about it, eg think about the number of things in it, 
use it to help define other classes, and so on.  But OWL is a 
general-purpose class reasoner, and it can reason about virtually any 
class of virtually any kind of membership. It is not restricted to a 
special category of "OWL classes" distinct from other kinds of class 
or groupings. (OWL DL is somewhat restricted, eg it cannot deal with 
classes containing other OWL classes, or classes of OWL properties. 
Again, this is deliberate design decision which trades some 
expressive power for a gain in processing speed in a reasoning 
engine.  But any class that fits the OWL DL standards - which will be 
many of the cases one meets with in practice - will be a suitable 
OWL-DL class.)

I am not sufficiently familiar with XTM subject indicators to answer 
that part of your question definitively, but certainly the OWL use of 
URIrefs does not restrict them to those that retrieve a document 
which use any particular format. Note however that your useage of the 
phrase 'the resource at "http//sports.org/US#SoccerTeam" ' suggests 
that you think of this URI as indicating the document 'at' the URL. 
OWL does *not* make his assumption: it uses URIrefs simply as names, 
and assumes that they refer to something.  Exactly how these entities 
- the referents of the URIrefs - are defined is not discussed by the 
OWL semantics. To this extent, OWL (and RDF and DAML) are somewhat 
disconnected from the RFC 2396 picture of the use of URIrefs within 
the REST architecture of an idealized Web. They do not deny this 
architecture, of course, but (with a few exceptions, most notably the 
use of owl:imports and the associated terminology) they largely 
ignore it. Thus, there is nothing in the OWL spec that says how, if 
at all, one can *determine* what class 
"http//sports.org/US#SoccerTeam" actually denotes: the OWL stance on 
that question might be summed up as 'whatever class it is, the 
following conclusions must be true of it, given what I know about 
it...'; and OWL's task is simply to ensure that the process of 
drawing those conclusions is error-free and as complete as possible. 
The same observation applies to RDF and DAML; to this extent, these 
languages are similar in the way they approach the meanings of 
URIrefs.

Please let me know (with a cc: public-webont-comments@w3.org) whether 
this reply adequately responds to your comment.

Pat

-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes