Re: update to the compliance document

Jeff,

I am not convinced that counting features provides the right metric 
to assess the distance between OWL-level-1 and Full-OWL.  Even 
assuming that only UnionOf, IntersectionOf and ComplementOf are left 
out of OWL-level-1 (I agree with your point that hasValue could also 
be in level 1), Full-OWL wold still remain far more powerful and 
complex than OWL-level-1.  In particular it is a lot harder to 
implement a system that can reason with arbitrary combinations of 
unionOf and ComplementOf, than one where you can only say that class 
A is subclassOf or sameClassAs class B. Vice versa, there are certain 
features that are trivial to add and would not radically change the 
nature of a reasoning system for OWL-level-1, such as hasValue.

Enrico


At 4:55 pm -0400 31/5/02, Jeff Heflin wrote:
>Jim Hendler wrote:
>>
>>  Jeff - two points
>>
>>    1) As I said in my report from WWW, it appears there is a large and
>>  growing group of users of DAML who are using what might be called
>>  "thesaurus" systems -- they publish a vocabulary, but the vocabulary
>>  was created in a different (usualyy proprietary) system.  These users
>>  use something similar to what was in SHOE or RDFS, but they also need
>>  to express some property restrictions - in particular, it is RDFS +
>>  unambiguous/unique + sometimes real cardinality.  I would venture
>>  that this is far and away the largest group of current users, and a
>>  group who OWL Core should support.  These are not group 2
>>  (description logic) users, and these are people publishing a lot of
>>  DAML (example, US National Cancer Institute will publish a 40,000
>>  term thesaurus updated monthly in D+O subset of this kind) - any
>>  attempts we make to guess what people will do should certainly
>>  include this group.
>
>I was not aware of this group (unfortunately I had to miss WWW), but
>agree that we should add it to the list. Without knowing the specifics
>of these thesaurus systems, I can't say how for how sure it fits into
>the picture, but I imagine that they would not be able to claim level-1
>compatability (as currently defined). In particular, I doubt their
>systems can reason with existential local range restrictions and I would
>bet that if they use universal local range and local cardinality
>restrictions, that they use them as constraints, as opposed to axioms
>for drawing inferences (as implied by the semantics of DAML+OIL). This
>could be a case to further reduce level-1, or maybe we throw thesaurus
>systems in with the "database crowd."
>
>>     2) I'm not sure what you mean by "almost back at full language" so
>>  I decided to do the experiment we ran at the f2f -- I took all the
>>  D+O language features and mapped them against Deb's level 1, and then
>>  look at the remaining.  I believe the following are NOT in level 1:
>>
>>  complementOf
>>  disjointUnionOf
>>  disjointWith
>>  hasValue
>>  intersectionOf
>>  oneOf
>>  onProperty
>>  unionOf
>>
>>  (which is a significant group).
>
>I don't believe disjointUnionOf is in consideration for the full
>language, and onProperty is just an artifact the RDF serialization of
>DAML (it is required for all restrictions). Still, that leaves us with:
>
>complementOf
>intersectionOf
>unionOf
>disjointWith
>hasValue
>oneOf
>
>The first three (complementOf, interectionOf and unionOf) are what I
>meant by boolean combinations. Still, that leaves three other features I
>didn't realize were left out. I would argue that hasValue and oneOf are
>likely to be as widely or more widely used than existential local range
>restrictions (hasClass). That certainly appears to be the current case
>for DAML+OIL ontologies (see http://www.daml.org/ontologies/features).
>So, I would argue if you add local range restrictions, then you should
>also add these two as well. Once you do that, then you are getting
>pretty close to the full language again.
>
>>  I also suspect that not all of these would go in core - or might be
>>  otherwise simplified, depending on how our issue re: datatypes
>  > finally works out:
>>
>>  Datatype
>>  DatatypeProperty
>>  DatatypeRestriction
>>  Datatype value
>
>If datatypes are done in a similar way, then I expect all of these (or
>equivalents) would be in the core.
>
>>  In addition, we haven't discussed whether the "extralogical" things
>>  we want would also go in core.  I expect they would, so I do not
>>  include:
>>  imports
>>  versionInfo
>
>I would have a major objection if these did not go into the core.
>
>>  I believe the big difference between Core as expressed by Deb and
>>  Core as proposed at f2f if that at the f2f, we assumed that those 8
>>  things not currently in core would be in core for "named" classes.
>>  Deb's document takes them out of core completely.  That seems to me
>>  to be a very big difference.
>>
>>    -JH
>>
>>  --
>>  Professor James Hendler                           hendler@cs.umd.edu
>>  Director, Semantic Web and Agent Technologies     301-405-2696
>>  Maryland Information and Network Dynamics Lab.    301-405-6707 (Fax)
>>  Univ of Maryland, College Park, MD 20742          240-731-3822 (Cell)
>>  http://www.cs.umd.edu/users/hendler