Re: ISSUES: DAML+OIL issues/experience/changes

In response to [1], this note summarizes some of my personal
experiences and recommendations in using DAML+OIL for
various applications and tools.

1) I've come to firmly believe in the value of associating
range and other restrictions with property/Class pairs
rather than just properties.  I've got several proposals in
this area:

  a) We should more officially extend this to
  DatatypeProperties as well as ObjectProperties (the spec
  suggests use of rdfs:range for DatatypeProperties).  In
  particular, I've been using code like

    <rdfs:subClassOf>
      <daml:Restriction>
        <daml:onProperty rdf:resource="#foo"/>
        <daml:toClass rdf:resource="&xsd;integer"/> <!-- look here -->
      </daml:Restriction>
    </rdfs:subClassOf>

  and would like to ensure that this is officially
  sanctioned.

  b) We should drop UniqueProperty in favor of using
  daml:cardinality="1" on a property/Class pair.

  c) We should replace UnambiguousProperty with a
  unambiguouslyIdentifies property on a property/Class pair,
  probably

    <rdf:Property rdf:ID="unambiguouslyIdentifies">
      <rdfs:domain rdf:resource="#Property"/>
      <rdfs:range rdf:resource="#Class"/>
    </rdf:Property>

2) We should provide some equivalent to UnambiguousProperty
for DatatypeProperties (currently UnambiguousProperty can
only apply to ObjectProperties), even if only as a
validation/reasoner hint.  This is equivalent to specifying
a single primary key in a database schema.

3) I believe that daml:TransitiveProperty is very valuable
in supporting reasoners.

  a) We should add daml:SymmetricProperty and
  daml:ReflexiveProperty as additional advice to reasoners.

  b) For consistency, we might want to investigate whether
  these properties can be associated with property/Class
  pairs rather than just properties, although that probably
  over-complicates use with reasoners.

4) I'd like to see daml:restrictedBy brought back (even if
just as a synonym for rdfs:subClassOf) to assist tool
developers in identifying defined class relationships.

5) I think we made the right choice in leveraging XML Schema
datatypes (rather than recoding the information into DAML),
and have found adequate Java tool support for processing
them in the Oracle XML Development Kit and Castor [2].  In
particular, I've found the use of ISO 8601 date/time types
extremely beneficial and adequate.  I also expect many
applications to benefit from the ability to specify pattern
datatypes for formatted identifiers (e.g. social security
numbers, ISBNs, etc.).

6) We need some simple mechanism for restricting a property
to a List of some specific type, e.g. an ordered list of
strings or Persons, that still allows use of the
daml:collection syntax.

7) There are some applications that required ordered
properties.  2 concrete examples are meeting agendas [3] and
results [4].

8) daml:equivalentTo and its subproperties hold significant
potential, as yet unrealized as far as I know.

  a) We've run into 2 cases where different identifiers
  refer to the same object:  airports with 3-character IATA
  and 4-character ICAO codes, and countries with different
  2-character ISO and 2-character FIPS codes.
  daml:sameInstanceAs could address this problem, but some
  mechanism like daml:renamesInstance would be a more direct
  match.

  b) We need more experience in really using these
  properties (e.g. is it reasonable to unify graph nodes or
  rename arcs based on these properties?)

  c) equivalence is just the beginning.  We'd ideally like
  to have a DAML-based language for specifying ontology
  mappings/translations/articulations.  This should probably
  be done above the language level (like DAML-Services).

9) We should drop daml:imports.

10) A standardized means for making "statements about
statements" (to capture provenance/pedigree, uncertainty,
timestamps, security classifications, etc.) should be a
major positive differentiator for a Web Ontology language
over current database and other approaches.  Many RDF/DAML
tools already support this (see [4]).  When serializing a
model, supplying statement IDs and using those IDs as the
subject of other statements (as done by Jena) works well and
shouldn't require the triple explosion of full reification.
We also need some equivalent mechanism for making statements
about statements in other models that weren't assigned
statement IDs when they were serialized.

	Mike

[1] http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0138.html

[2] http://castor.exolab.org

[3] http://www.daml.org/2001/10/agenda/

[4] http://www.daml.org/2001/07/breakout/

[5] http://www.daml.org/2001/04/reification/

Received on Tuesday, 8 January 2002 01:08:30 UTC