Re: on owl:imports

>Hi Alan
>
>following up from our chat yesterday, (but note public list), you 
>mentioned how some of the possible constructs in OWL Full seemed 
>totally useless and just plain confusing.
>
>Two you mentioned were:
>
>what would
>
>rdf:type rdf:type rdfs:Class .
>
>mean?

Well, that is rather odd, but it is clear what it MEANS. It says that 
rdf:type is an RDFS Class. It would go along with writing

ex:a rdf:type rdf:type .

to say that something is in that class. In RDFS and in OWL-Full (and 
Common Logic) it is fine to have one thing be both a class and a 
property. So rdf:type being a class does not interfere with its 
normal property meaning. One possible reason for treating a property 
as a class (which we used in the RDF datatype syntax) is to use the 
same name for the things of a certain type and the typing property 
itself, but in this case we already have a name for the things of 
that type: they are the rdfs:Classes. So that kind of usage, which I 
confess is the only kind Ive seen, isn't much use here.

OK, I can't think of any sensible use for this. Nevertheless, it 
isn't semantically insane: it does make a kind of sense. And its 
simpler to allow it than to prohibit it.

There is a general point to be considered here. Even if you cannot 
imagine why you would ever want to say something, there still might 
be someone who, for some reason in some circumstances, might want to 
be able to say it. So its usually a bad idea (in an open situation 
like the Web) to actually forbid it, unless you need to forbid it for 
some practical reason. I'll give you an example from a related area, 
designing Common Logic. We were trying to make the syntax as 
'forgiving' as possible, to allow virtually anything. Someone pointed 
out at one point that our draft syntax allowed one to use a quoted 
string as though it were a predicate or a function name, which is 
like using "34"^xsd:string as an RDFS class or property. We all 
agreed that this was silly, that no sane person could possibly want 
to do this, and we wrote it out of the syntax. But then, later, we 
reconsidered this decision: the syntax was simpler without the 
artificial restriction, and simply as a matter of principle we wanted 
to eliminate as many restrictions as possible. I forgot all about 
this until several years later, when trying to set up an 
interoperability mapping between a variety of formalisms, I wanted to 
use 'contextual names', which are quoted strings joined together with 
a context (indicating what the string denotes when understood as a 
name in that context: the use was to allow the same name to mean 
different things in different places), and I realized that the 
natural way to write this in CL is to make the string into a function 
name applied to the context name. This turns out to give a very 
natural, powerful and uniform way of treating contextually sensitive 
naming strategies: so useful, in fact, that we wrote the 'null case' 
of it into the logical semantics of IKL, our CL successor. So here I 
was, using - and doing something like standardizing - the very 
technique that I, along with everyone else in the working group, had 
decided was insane only a couple of years earlier.

>And what would:
>
>restriction( owl:imports, minCardinality(4) )
>
>mean?
>
>The general OWL Full mentality, is to allow people to say things, 
>including unhelpful things, and then to take a garbage-in 
>garbage-out type approach.
>
>For instance, earlier today I have been answering a question on the 
>jena support list concerning an intersection of a class and a 
>datatype property: unsurprisingly not what was intended.
>
>But, it has occurred to me that the restriction on owl:imports is, 
>in fact, plausibly useful in some cases.
>
>Here goes:
>
>I have been investigating improving Jena's performance.
>A possible area of investigation is how well does Jena perform when 
>a large number of imports have been made.
>As long as each ontology is a semantically distinct thing then
>
>restriction( owl:imports, minCardinality(4) )
>
>is the class of ontologies that have imported at least 4 ontologies.
>
>This may be a useful class of ontologies to concentrate my 
>performance tests on.

I agree. But I don't follow why you need this:

>To make that work within a reasoner, I would have to augment the 
>formal OWL Semantics, perhaps, to make
>
>uri1 rdf:type owl:Ontology
>uri2 rdf:type owl:Ontology
>uri1 owl:sameAs uri2
>
>into a contradiction (when uri1 and uri2 differ). This would reflect 
>some sense of the meaning of the uri of an ontology being its 
>(unique?) name. I believe that would be a compliant extension to the 
>semantics (although not one that I would propose for 
>standardization).
>
>Probably to answer the most useful question in this case I would 
>want a transitive superproperty of owl:imports, and then ask the 
>minCardinality question: this would give me a class of ontologies 
>whose import closure is large.
>
>=====
>
>I am not trying to claim that this is an important use case, that 
>must be addressed - I am more trying to articulate a mentality: we 
>have a powerful tool for describing resources on the web and their 
>relationships - it can be used to help with a number of tasks.
>
>The limitations of OWL DL guarantee certain computational 
>properties, but at the cost of syntactically prohibiting certain 
>constructs, most of which do not address the main tasks of 
>traditional ontologies.
>
>It doesn't mean that such constructs are useless.

Absolutely. One should not prohibit something just because one cannot 
think of a use for it. Others may have a broader imagination.

Pat

>
>
>Jeremy
>
>
>
>
>
>--
>Hewlett-Packard Limited
>registered Office: Cain Road, Bracknell, Berks RG12 1HN
>Registered No: 690597 England


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

Received on Thursday, 14 June 2007 16:05:32 UTC