>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