W3C home > Mailing lists > Public > www-webont-wg@w3.org > January 2003

Re: abstract syntax and RDFS

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Tue, 21 Jan 2003 09:27:59 +0000
Message-ID: <3E2D129F.5000106@hpl.hp.com>
To: Guus Schreiber <schreiber@swi.psy.uva.nl>
CC: WebOnt WG <www-webont-wg@w3.org>

> The owl.wol file defines owl:Class as a subclass of rdfs:Class.
> So this seems redundant to me, or are we not assuming owl.owl is always 
> imported? The same holds for the other examples (owl:ObjectProperty is a 
> subclass of rdf:Property, etc.).
> Sorry if I misunderstand.
> Guus

I think it might be helpful if I explain where I am coming from ...

- the syntax of OWL Lite and OWL DL is defined by these mapping rules

- the semantics of OWL Lite and OWL DL are defined in terms of the abstract 

- there is a lot of free choice in the exact mapping rules used (syntactic 
options which do not present semantic difficulties). This choice should be 
made motivated by various concerns.

The principle goals of a syntax are:
1: connection to the semantics - this is primary, the syntax must not 
present unnecessary obstacles to arriving at the meaning of a document
(we are a bit on a loser starting from RDF/XML but that's another story)

2: ease of exposition
    It must be possible to articulate what the syntactic rules are, in a 
way is reasonably clear.

3: clarity of error messages
    A syntax is used in tools like an editor or a syntax checker.
    A syntax is also used in any tool that can read OWL Lite and OWL DL.
    At least some of these tools need to be able to output correct and 
intelligible error messages on ill-formed input.

4: ease of porting, interoperation with other syntaxes
    I see DAML+OIL, RDF and RDFS as the targets here.

This suggests the following syntactic concerns as CR exit criteria:

+ OWL syntax checker:
    at least two independently produced syntax checkers that:
    - can be run in an OWL Lite or OWL DL mode
    - at least one of which, when presented with a document that is
      not OWL Lite can give clear and intellegible indications as to
      why not.
    - at least one of which, when presented with a document that is
      not OWL DL can give clear and intelligible indications as
      to why not.
    - can be run in strict mode, conforming with the exact specification
      (i.e. very unhelpful).

+ OWL editor
     at least two independently produced OWL editing environments that:
     - can be run in OWL Lite or OWL DL mode
     - in OWL Lite/OWL DL mode either prevent the user from creating
       non OWL Lite/OWL DL files, or provide some assistance in fixing
       syntactic problems related to belonging to the correct
       sublanguage. (I personally doubt that a set of emacs macros can
       achieve this satisfactorilly)

+ OWL documents
      The construction of enough OWL sample data,
       e.g. two moderate sized OWL Lite ontologies, two moderate sized
       OWL DL ontologies, two moderate sized OWL Full ontologies

      The porting of at least two moderate sized DAML+OIL ontologies
       into OWL.

      The porting of at least two RDFS schemas into OWL Lite; in such
      a way that interoperation between RDFS and OWL Lite is shown.
      A strong preference that Dublin Core is one of these.

Now, let's get back to the original question. Why do I want the mapping 
rule for owl:Class to optionally redundantly specify that the URIref is 
also an rdfs:Class?
Answer, if it isn't in the mapping rule then any RDFS schema that defines 
or uses an rdfs:Class is not part of OWL DL or OWL Lite. It is semantically 
The current rule that you must not use rdfs:Class or rdf:Property in an OWL 
Lite document seems difficult to explain, and difficult to justify and to 
present unnecessary problems in interoperation between OWL Lite and RDFS.

Therefore it should change; the change I propose is, as you noticed, 
semantically vacuous; which is deliberate. It indicates that there are no 
possible semantic problems in agreeing to it.

Received on Tuesday, 21 January 2003 04:29:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:50 UTC