- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 14 Jun 2007 11:05:14 -0500
- To: Jeremy Carroll <jjc@hpl.hp.com>
- Cc: Alan Ruttenberg <alanruttenberg@gmail.com>, Owl Dev <public-owl-dev@w3.org>
>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