- From: Michael Schneider <schneid@fzi.de>
- Date: Wed, 19 Dec 2007 22:59:45 +0100
- To: "Pat Hayes" <phayes@ihmc.us>
- Cc: "Owl Dev" <public-owl-dev@w3.org>
Hi Pat!
Pat Hayes wrote:
>>>OK, let me modify the proposal slightly. It is
>>>structurally the same but the terminology has been altered, according
>>>the following table:
>>>
>>>old proposal new proposal
>>>
>>>owl:UQRestriction owl:Restriction
>>>owl:QRestriction owl:QRestriction
>>>owl:Restriction owl:Restriction1.1
>>>
>>>with isomorphic relationships between them.
>>
>>This means that the additional axioms, you mentioned in your
>previous mail,
>>will become:
>>
>> owl:Restriction rdfs:subClassOf owl:Restriction1.1 .
>> owl:QRestriction rdfs:subClassOf owl:Restriction1.1 .
>> owl:QRestriction owl:disjointWith owl:Restriction .
>
>Yes, though I'm using owl11:Restriction rather
>than owl:Restriction1.1 below, following your
>lead.
>
>>
>>>This introduces a new
>>>name for the class of restrictions in 1.1, which is a proper
>>>superclass of the restrictions in 1.0, thereby maintaining
>>>consistence of terminology between 1.0 and 1.1. The RDF
>>>representation for an unqualified restriction in 1.1 is now exactly
>>>the same as it was in 1.0, and has isomorphic conditions imposed upon
>>>it. OWL 1.1 will therefore use the exact same RDF encoding for its
>>>1.0 subset as 1.0 does, and will support the exact same entailments
>>>within that subset.
>>>
>>>OK?
>>
>>I'm afraid there is still a problem. :-( It will at least not
>be possible to
>>simply extend the current RDF compatible semantics of OWL-1.0
>with your
>>proposal.
>
>Well no, but that isn't necessary, and is
>probably not going to be possible in any case for
>other reasons, I would guess. OWL 1.1 can
>(should? must?) be given its own semantic
>specification, especially for the RDF embedding,
>which should support the same entailments as 1.0
>for the 1.0 fragment, but can (should? must?) be
>phrased somewhat differently. It is easy to see
>how to do it, Im sure you could write it out, but
>I hereby volunteer to do so if you feel it is
>necessary.
Erm, step by step, please! For the moment, I would still prefer to keep
focussing on the very specific (Q)CR aspect of OWL-Full! :)
I have to admit that I didn't feel very well when I challenged your proposal
with this "rougue"-kind of argument presented below (but I couldn't resist,
of course ;-)): That the semantic condition for cardinality restrictions
already fires on (onProperty,cardinality) triple pairs, without taking the
"_:x rdf:type owl:Restriction" typing triple into accout. My estimation at
the moment is that the structure of the semantic conditions for
restrictions, as given in the OWL-1.0 semantics spec, should really be
reconsidered when it comes to constructing the RDF compatible semantics for
OWL-1.1. However, I also think that such a reconsideration should be done
independently from the "QCR-RDF-encoding" question, which we discuss in this
thread. Anyway, I promise to not using this argument again in this
discussion. :)
>The chief advantage to this compared to Peter's
>suggestion is that it keeps the actual language
>simpler, which is a huge advantage compared to
>making it easier to write the semantic spec.
I disagree with this claim! I believe that Peter's suggestion would be more
coherent (from a usage perspective, not talking about semantics here) w.r.t.
the way how OWL deals with restrictions today.
OWL-1.0 has several different restrictions (allValuesFrom, existsValue,
hasValue, (min|max)?cardinality), all of them represented in a common class
owl:Restriction. Now, QCRs enter the field, and suddenly there would be a
separate (even disjoint) class owl11:QRestriction for QCRs alone, and a
second class owl11:Restriction to contain both the QCRs and the "rest" of
the restrictions. If I wasn't aware of our discussion here, this "special
handling" of QCRs would look pretty strange to me. I would certainly ask
myself what was so special about QCRs that they need to have their strictly
separated own part of the OWL universe, while all the other restrictions do
not need any further explicit distinction. I would regard it to be even more
strange, if I was aware of the fact that there actually /are/ special kinds
of QCRs in OWL-1.0, which are, of course, members of the old class
owl:Restriction:
* ordinary cardinality restrictions are QCRs on class owl:Thing
* existsValue restrictions are ">=1"-QCRs
Having these special QCRs in a different class from general QCRs is, of
course, not a bug in a technical sense (because from only knowing that the
class extensions of two given QCRs are equal, it can *not* be entailed that
the respective class /resources/ are also the same). But, I claim, this
would at least /"feel"/ like a bug, and I would try to avoid sources of
getting such feelings, esp. w.r.t. OWL newbies.
I want to note that this problem would, of course, /not/ exist, if in
OWL-1.0 the distinction between different restriction types would be made by
/class/. So if there were already classes
* owl:ExistsValueRestriction
* owl:AllValueRestriction
* owl:(Min|Max)?CardinalityRestriction
* owl:HasValueRestriction
all of them being subclasses of
owl:Restriction
then having additional classes
owl11:(Min|Max)?QualifiedCardinalityRestriction
would look natural to me, and I would really prefer your proposal (but only
if these QCR classes would also be instances of owl:Restriction, not
owl11:Restriction).
But, actually, the distinction between the different restriction types is
made by using specific /properties/, not by classes, i.e. we have
* owl:existsValue
* owl:allValuesFrom
* owl:(min|max)?cardinality
* owl:hasValue
So it just looks consequent to me to get new properties
* owl11:(min|max)?qualifiedCardinality
for specifying QCRs in RDF. And this is actually what Peter suggests.
(Of course, the third possibility you mention below, to have new
'onProperty'-like vocabulary, is not more than just a "technical solution"
in this regard. I don't think that it is worthwhile to discuss this approach
any further. :))
>I don't think Peter's suggestion is feasible.
>
>Jim
>is not alone in absolutely detesting the old DAML
>vocabulary, and if it is brought back simply to
>avoid a routine piece of spec-writing, there will
>be hell to pay (and quite rightly, IMO). It might
>even prevent the spec reaching REC status. I for
>one would strongly lobby against any attempt to
>bring back the bad points of DAML syntax.
For me, coming relatively late to the SemWeb world (quite some time after
OWL-1.0 has been released, let alone DAML), this is something I don't
understand. I can see that DAML had QCR vocabulary, while OWL-1.0 had not.
And I can see that the "QCR in OWL?" question had been *postponed* (not
closed!) according to
<http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I3.2-Qualified-Restrict
ions>
So I would expect that the old WG left open the door for QCRs to enter OWL
for the case that the problems of that time are solved in the future. And
when I read the list of problems in the link above, then all I can say is,
yes, it's time for the WG to open the door!
Well, I notice from the discussion in this thread that neither you nor Jim
do actually oppose the introduction of QCRs as a feature. But what is then
the problem with the vocabulary? What are the "bad points of DAML syntax",
as you call them? I simply do not understand this.
>BTW, you say that Peter's suggestion is 'robust',
>but the central problem of it is that it uses the
>same term for the class of 1.0 restrictions as
>for 1.1 restrictions, yet these are different
>sets. This is not a robust technique! It is
>likely to cause other problems, since the meaning
>of a central part of the semantic spec shifts
>incompatibly between the 1.0 and 1.1 specs. Its
>relatively easy to change the words: what makes
>things robust is not changing the mathematics.
This seems to be a semantical aspect which I did not consider yet: When I
correctly understand you, you say that the new class names
'owl11:QRestriction' and 'owl11:Restriction' should be introduced, because
the old class name 'owl:Restriction' exists for the old OWL-1.0
restrictions, and it should be prevented to accidentaly re-interpret this
class name in OWL-1.1. So if this is really a danger, then introducing the
new class names would be the save way, I agree.
But I think this can be checked. The current OWL-1.0 semantic conditions
dealing with restrictions should have the potential to bring trouble when a
new restriction type, or the set of QCRs specifically, are additionally put
into the class owl:Restriction. But from looking into §5.2 of the OWL-1.0
semantics spec, I cannot find anything which really looks dangerous.
The first semantic condition dealing with restrictions is in table
"Conditions concerning the parts of the OWL universe and syntactic
categories", and it in essence says:
owl:Restriction rdfs:subClassOf owl:Class (or rdfs:Class)
This is harmless, and would also be true for your proposed additional
classes, of course.
Second, there are the specific semantic restriction conditions in table
"Conditions on OWL restrictions". But they only determine the extensions of
the respective restriction classes. This, again, looks rather harmless to
me, because from this information about restriction class extensions I
cannot draw any conclusions about the properties or the extension of class
owl:Restriction.
Finally, restrictions appear in the table about "Comprehension conditions",
so let me see whether I actually comprehend them. :) For example, one of
these comprehension conditions say that for each property p and for each
number n there is some cardinality restriction r with
r rdf:type owl:Restriction ;
owl:onProperty p ;
owl:cardinality n .
And for each restriction type in OWL-1.0 there exists some analog
comprehesion condition in this table. Ok, this tells me something about what
I can expect to find within class owl:Restriction. *But* it does not tell me
that these are *all* the restrictions I will find in owl:Restriction. I
cannot even see that these comprehension conditions put any kind of
constraint on what things owl:Restriction can additionally contain and what
not. So, again, this looks reasonably harmless to me.
All in all, I believe that the RDF compatible semantics for OWL-1.0 will not
bring us into trouble, when we consider to also add QCRs in class
rdf:Resource. There would then be an additional entry in the "Conditions on
OWL restrictions" table, and also an additional "comprehension condition"
for QCRs, but I do not see how this can become a problem. Instead of
regarding owl:Restriction as the class of all OWL-1.0 restrictions, I would
rather like to regard class owl:Restriction to be the class of *all
thinkable* restrictions, even if they will first enter the game in OWL-6.0
or whatever. I believe that with my checks performed above, this stance is
pretty save.
So, until you show me an error in my argumentation above, or some hidden
additional information which I did not take into account (quite possible,
certainly, this was just a quick check), I do not see any need for action
here to introduce new classes in order to cope with the new QCRs. Otherwise,
next time, in OWL-2.0, there will be again a new type of restrictions, and
then it will be necessary to introduce another pair of new restriction
classes, and so on. I don't believe that that any OWL user will want to bye
this hack. :)
To summarize, apart from the "DAML" question, which I do not understand, and
which makes me a bit scary ("It might even prevent the spec reaching REC
status."), I am now even more convinced that I should prefer Peter's
suggestion to your's. Both from usage aspects and semantical aspects.
Cheers,
Michael
>
><snip>
>>
>>The natural solution seems to be to change the semantic cardinality
>>condition into:
>>
>> IF
>> x rdf:type owl:Restriction .
>> x owl:onProperty p .
>> x owl:cardinality n .
>> THEN
>> ...
>>
>>But if this "bugfix" would be applied in the OWL-1.1
>semantics, OWL-1.1-Full
>>would not really be perfectly backwards compatible with
>OWL-1.0-Full. Fact
>>is that according to OWL-1.0-Full semantics the following RDF
>graph already
>>completely specifies a cardinality restriction:
>>
>> (R21) _:x owl:onProperty <hasBodyPart> .
>> (R22) _:x owl:cardinality 2 .
>>
>>Because both, that the additional information that '_:x' denotes an
>>owl:Restriction, and that the extension of this class equals
>a cardinality
>>restriction, is entailed from {(R2*)} through the OWL-1.0 semantic
>>cardinality restriction. But with the "fixed" semantic
>cardinality condition
>>in OWL-1.1, this graph would not match any semantical
>condition anymore, so
>>it would *not* specify a cardinality restriction.
>
>True, well spotted.
>
>>The question is, whether this new loss of backwards
>compatibility may be
>>regarded to be a minor problem. Well, this is certainly hard
>to answer, and
>>I am neither able nor willing to answer this question.
>
>Well, I am :-) It is minor. I bet there isn't a
>single deployed 1.0 ontology which omits the
>owl:Restriction triple in this way. IMO this very
>small change is well worth the cost of an ugly
>extension to the language. But for compatibility
>purists, read on.
>
>> Instead, I prefer to
>>go the easy way, by voting for Peter's solution to introduce
>a new property
>>
>> owl11:qualifiedCardinality
>>
>>With this, the above problems will not occur, because
>OWL-1.0-Full simply
>>does not have any semantic condition which matches parts of
>the RDF graph
>>
>> (R31) _:x rdf:type owl:Restriction .
>> (R32) _:x owl:onProperty <hasBodyPart> .
>> (R33) _:x owl:qualifiedCardinality 2 .
>> (R34) _:x owl11:onClass <Leg> .
>>
>>besides one condition which entails from (R31) that _:x is an
>owl:Class, but
>>this is ok, of course.
>
>One gets a similar fix by modifying the
>onProperty, which has the advantage that it does
>not alter the 'core' vocabulary, only the
>vocabulary that is introduced to handle the RDF
>embedding:
>
>(R31') _:x rdf:type owl:Restriction .
>(R32') _:x owl11:onPropertyQ <hasBodyPart> .
>(R33') _:x owl:cardinality 2 .
>(R34') _:x owl11:onClass <Leg> .
>And this could be given an analogous semantics
>where the first triple is redundant.
Of course, but this is now really a purly /technical/ solution.
>But I am
>still leery of calling this an owl:Restriction.
>The fact is, its not an OWL1.0 restriction. It
>just takes one 'iff' in the spec to foul things
>up. I'd rather use
>
>(R31'') _:x rdf:type owl11:Restriction .
>
>>So Peter's solution seems to work in a robust way, and it
>will also allow
>>(or I should better say: it won't prevent) to construct an
>OWL-1.1-Full
>>semantics, which is backwards compatible with OWL-1.0-Full by simply
>>extending the current set of semantic conditions in OWL-1.0.
>
>As said above, I think this is a misguided
>ambition, one likely to create more problems than
>it solves, and in any case not semantically or
>mathematically necessary. This kind of situation,
>where adding some new vocabulary requires one to
>rephrase the older semantic conditions to
>preserve their intended meaning in a larger
>language, is not at all uncommon.
>
>Pat
>
>> (Whether there
>>will still have to be fixes to certain OWL-1.0 semantic
>conditions will then
>>be a different story).
>>
>>
>>Cheers,
>>Michael
>>
>>--
>>Dipl.-Inform. Michael Schneider
>>FZI Forschungszentrum Informatik Karlsruhe
>>Abtl. Information Process Engineering (IPE)
>>Tel : +49-721-9654-726
>>Fax : +49-721-9654-727
>>Email: Michael.Schneider@fzi.de
>>Web : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555
>>
>>FZI Forschungszentrum Informatik an der Universität Karlsruhe
>>Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
>>Tel.: +49-721-9654-0, Fax: +49-721-9654-959
>>Stiftung des bürgerlichen Rechts
>>Az: 14-0563.1 Regierungspräsidium Karlsruhe
>>Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova,
>Rudi Studer
>>Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
>
>
>--
>---------------------------------------------------------------------
>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
>
>
--
Dipl.-Inform. Michael Schneider
FZI Forschungszentrum Informatik Karlsruhe
Abtl. Information Process Engineering (IPE)
Tel : +49-721-9654-726
Fax : +49-721-9654-727
Email: Michael.Schneider@fzi.de
Web : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
Received on Wednesday, 19 December 2007 22:00:02 UTC