RE: [OEP] OWL restrictions

Great Idea Guus. I have not read it through, just skimmed the overall,
and read bits. Very good overall.
I will try and read it more thoroughly later. 

There is one key thing missing from this and all other write-ups that I
have seen explaining restrictions. It caused me no end of confusion and
frustration when I had to learn them myself so I could teach them at the
first Madrid summer school tutorial. I also harp on people [not unlike
Natasha] for not including them in our notes.

Namely: there needs to be direct transliterations of the OWL into
[awkward sounding, but semantically accurate and understandable]
English.  Then have a few intermediate steps which clearly are
equivalent, ending up with a sensible way to say something whose meaning
is immediately obvious.

For example:
:RedWine
  a owl:Class ;
  rdfs:subClassOf
    [ a owl:Restriction ;
      owl:onProperty :color ;
      owl:hasValue red^^<http://www.w3.org/2001/XMLSchema#string>
    ] .

Translates literally to:

RedWine is a class.
RedWine is a subclass of
	The class of all things that have the value red for their color
property.

Which sounds better like this:

RedWine is a class.
RedWine is a subclass of
	The class of all red things.

Which sound better still like this:

RedWine is a class.
All instances of RedWine are red things.

-- an alternative re-phrasing at the first step might be:--

RedWine is a class.
Every instance of the class RedWine has the value red for its color
property.

Etc etc...

It may not be so important in our notes, but it but for a note
specifically devoted explaining restrictions, I think it is essential.
IMHO, it is just about impossible for a beginner to make that leap in
one step. I find it hard myself.

Minor thing, this sentence needs fixed: 
"The key difference is not the language [but rather,] the intended use."

I agree wholeheartedly. If you wish to include more information on
comparing data schema with ontologies, you might wish to look at the
following which is a section from a paper published last year in the Sig
Mod special issue on semantic integration.
2.3	Ontologies vs.  Database Schema
There are many interesting relationships between database schema and
formal ontologies. We will consider the following issues: language
expressivity, systems that implement the languages and usage scenarios.

There is much overlap in expressivity, including: objects, properties,
aggregation, generalization, set-valued properties, and constraints. For
example, entities in an ER model correspond to concepts or classes in
ontologies, and attributes and relations in an ER model correspond to
relations or properties in most ontology languages.  For both, there is
a vocabulary of terms with natural language definitions. Such
definitions are in separate data dictionaries for DB schema, and are
inline comments in ontologies. Arguably, there is little or no obvious
essential difference between a language used for building DB schema and
one for building ontologies. They are similar beasts. There are many
specific differences in expressivity, which vary in importance. Many of
the differences are attributable to the historically different ways that
DB schema and ontologies have been used.  
Ontologies have a range of purposes including interoperability, search,
and software specification (see section 3).  One or more parties commit
to using the terms from the ontology with their declared meaning. The
primary use of most DB schema is to structure a set of instances for
querying a single database. This difference impacts heavily on the role
of constraints.
For ontologies, constraints are called axioms. Their main purpose is to
express machine-readable meaning to support accurate automated
reasoning. This reasoning can also be used to ensure integrity of
instances in a knowledge base. For databases, the primary purpose of
constraints is to ensure the integrity of the data (i.e. instances).
These 'integrity constraints' can also be used to optimize queries and
help humans infer the meaning of the terms. Cardinality and delete
constraints are important kinds of integrity constraints which have
highly DB-specific uses that are outside the scope of most or all
ontology systems. For example, cardinality constraints are used for
getting the foreign key in the right direction and to ensure that extra
tables are built for many to many relationships. Such constraints do
express meaning, but this may be of secondary importance. The main roles
for cardinality constraints in ontologies is to express meaning, and
ensure consistency (either of the ontology, or of instances).
There are some key similarities and differences in systems that
implement DB schema languages vs. ontology languages. For both, there
are processing engines that can be used to perform reasoning. SQL
engines are highly specialized and tuned for answering queries,
reasoning with views and ensuring data integrity. They can handle rich
and expressive logical expressions, as can ontology engines. An
important difference is that reasoning over ontologies normally is done
by general logic-based theorem provers, specific to the language.
Although ontology inference may be used for queries and to ensure
integrity of instances, these are optional. The fundamental role of a
reasoning engine is to derive new information via automated inference.
Inference can also be used to ensure the logical consistency of the
ontology itself. Note that deriving new information and checking
consistency can take place with or without instances. Classically, such
mixing of types with instances does not take place with DB schema and
data. This is mainly due to much greater scale and performance
requirements for database systems. Another key difference is support for
taxonomic reasoning: it is fundamental for nearly all ontology
applications, but it is not supported by most DBMS. 
The different roles of DB schema and ontologies also affect design and
other pragmatic issues.  For example, there is much effort on
normalization for DB schema, with no similarly pervasive analogous step
for ontologies. 
Enforcement of DB integrity constraints is expensive; therefore many
constraints identified during modeling are left unstated, resulting in
loss of captured meaning. This makes semantic integration difficult-if
you don't know what things mean, how can you relate them to anything
else?  Capturing as much data meaning as possible in machine readable
format is important for interoperability (e.g., for schema/ontology
matching). Hence, a good step toward designing database schemas for
interoperability would be more widespread decoupling of constraint
definition from constraint enforcement (as is done in the ontology
community).

============================================
Mike Uschold
Tel: 425 865-3605              Fax: 425 865-2965
============================================



>  -----Original Message-----
>  From: Guus Schreiber [mailto:schreiber@cs.vu.nl] 
>  Sent: Thursday, June 02, 2005 11:40 PM
>  To: SWBPD list
>  Subject: [OEP] OWL restrictions
>  
>  
>  
>  
>  For a course that I'm teaching this month I have written a 
>  short note 
>  about OWL restrictions, as this is something that students who start 
>  working with OWL find difficult to understand. It is not a 
>  pattern note, 
>  but maybe it could be useful as an add-on to the 101 paper 
>  of Natasha.
>  
>  You can find the note at:
>  
>     http://www.cs.vu.nl/~guus/public/owl-restrictions/
>  
>  It still needs a careful read-through.
>  
>  Guus
>  
>  -- 
>  Free University Amsterdam, Computer Science
>  De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
>  Tel: +31 20 598 7739/7718; e-mail: schreiber@cs.vu.nl
>  Home page: http://www.cs.vu.nl/~guus/
>  
>

Received on Saturday, 4 June 2005 01:16:36 UTC