Re: comments on OWL Last Call drafts

Ken-
  Thanks for your comments, and for spending the time discussing them 
with me at the World Wide Web Conference.  As we discussed, while the 
issues you bring up (need to be able to have uncertainties attached 
to statements, need to be able to say things like "usually" and other 
non-monotonic features for specifying defaults) are certainly 
important, they were beyond what the working group was chartered to 
do for this, the first generation of OWL technology.  In addition, 
there is much debate in the research and applications community as to 
the best way to achieve the features you discuss, and thus there is 
no easy way to design them into the language until more consensus has 
been derived among researchers, implementors, and potential users.
  The design of OWL, and particularly the semantics of what we have 
called OWL Full, does allow for users to add features beyond those we 
have defined and to explore their use and implementation, thus those 
communities wishing to try different solutions will be guaranteed 
some interoperability (when using the current OWL vocabulary) as they 
explore new extensions.
  You and I also discussed adding a "what OWL doesnt' do" section, but 
the Working Group felt that the Requirements document [1] did a good 
job of explaining the coverage intended for OWL and the issues that 
we did tackle.  The list of things OWL doesn't do is arbitrarily 
long, and other than saying "the owl:complementOf what is in that 
document" it would be hard to be more specific.

Several of the things you brought up are, indeed, already in this 
document.  These are:

1 - You bring up the need to have multiple ontologies that have 
different world views.  This was a major design goal for us, stated 
as:

3.3 Ontology interoperability Different ontologies may model the same 
concepts in different ways. The language should provide primitives 
for relating different representations, thus allowing data to be 
converted to different ontologies and enabling a "web of ontologies." 
Supported Tasks: Any use case in which data from different providers 
with different terminologies must be integrated. Justification: 
Although shared ontologies and ontology extension allow a certain 
degree of interoperability between different organizations and 
domains, there are often cases where there are multiple ways to model 
the same information. This may be due to differences in the 
perspectives of different organizations, different professions, 
different nationalities, etc. In order for machines to be able to 
integrate information that commits to heterogeneous ontologies, there 
need to be primitives that allow ontologies to map concepts to their 
equivalents in other ontologies. RDF(S) Support: RDF provides minimal 
support for interoperability by means of the rdfs:subClassOf and 
rdfs:subPropertyOf properties.

and OWL provides a number of vocabulary elements that can be used for 
expressing the relationships between, as well as within, ontologies.


2 - you asked for the ability to state defaults.  We included this as 
an objective (i.e. something we would like to see in the language, 
but had no solution for at this time):

O2. Default property values     The language should support the 
specification of default values for properties. Such values are 
useful in making inferences about typical members of classes. 
However, true default values are non-monotonic, which can be 
problematic on the Web where new information is constantly being 
discovered or added. Furthermore, there is no commonly accepted 
method for dealing with defaults. An alternative is for the language 
specification to recommend to users how they can create their own 
default mechanisms.     Motivation: Balance of expressivity and 
scalability


3 - you asked about extending OWL to use separate programs or other 
mechanisms to deal with uncertainty.  This is often handled by the 
use of procedural attachments, which were also an objective we hope 
the langauge will eventually contain:

O13. Procedural attachment     The language should support the use of 
executable code to evaluate complex criteria. Procedural attachments 
greatly extend the expressivity of the language, but are not 
well-suited to formal semantics. A procedural attachment mechanism 
for web ontologies should specify how to locate and execute the 
procedure. One potential candidate language would be Java, which is 
already well-suited to intra-platform sharing on the Web. 
Motivation: Ontology interoperability

We hope the discussion summarized above, and the sections of the 
requirements document as described here, adequately address your 
misgivings and will let you support this, the version 1.0 design for 
the OWL language, and will encourage you to support future 
development so that some later version can, indeed, handle the 
important issues you bring up.
   Jim Hendler
   coChair, Web Ontology Working Group


p.s. Please let us know if this answers your questions, or whether 
you have further issues to bring up.
-- 
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

Received on Monday, 9 June 2003 20:33:17 UTC