Re: SEM: Light review of semantics document

[I'm adding my comments to Pat's, so as not to split the discussion.]

From: pat hayes <phayes@ai.uwf.edu>
Subject: Re: SEM: Light review of semantics document
Date: Wed, 6 Nov 2002 23:08:47 -0600

> >Here's some initial comments on the Semantics document dated Nov. 3:
> >
> >1) Sect. 2.2. [2.1?] The syntax needs the ability to represent documents that
> >consist soley of facts (that is, something other than ontologies).
> 
> Can you explain what you mean by "other than ontologies" ?Do you 
> mean, not in OWL?

> >Perhaps a top-level <content> or <data> production could be added. The
> >most import reason for this is that content documents (which are not
> >ontologies), will also need to be represented. Assuming imports is not
> >postponed, such documents will also need to contain imports directives.

I also find this request confusing, particularly for the abstract syntax.
An ontology in the abstract syntax is a sequence of axioms, facts,
annotations, and imports.  In particular a sequence of facts is a perfectly
good ontology.  Perhaps it would be better to explicitly state that an
ontology does not need to have any axioms, or facts, or annotations, or
imports, but I believe that, as the grammar is quite clear about this, that
the natural-language gloss does not need to be so explicit.

> >2) In the abstract syntax we have EquivalentClasses,
> >EquivalentProperties but SameIndividual. We should change them all to
> >the same basic form. Since sameXXXas is what is used in the exchange
> >syntax, I suggest: SameClass, SameProperty, and SameIndividual.

If the WG so decides, this change can be easily done.

> >3) Section 3.4: The discussion of imports does not take into account
> >documents that are not ontologies. I had a proposal (that I thought you
> >agreed to), that fixed this and other problems. Is this an oversight, or
> >are you waiting for the group to resolve the issue before making a
> >change.

My view is that as far as OWL is concerned, everything *is* an ontology.
That is, OWL ontology is just another name for OWL knowledge base.  Here,
again, we are talking about the abstract syntax, so matters of concrete
syntax are not really germane.  (I agree that it is a bit risque to talk
about going from a URI to an ontology in the abstract syntax, but that is
the only syntax that is available here.)  

In section 5.3.1 there is a treatment of imports in the n-triples syntax.
Here the imports closure is just a collection of n-triples, which is, I
believe, as in your proposal.

> >4) Sect. 4.1: The conditino for n-triple form seem overly restrictive.
> >Is this just meant for OWL/DL?

The current version of the document is explicit that this is OWL/DL.  (I
think that an early version didn't have this.)  In fact, one of the biggest
changes between the 3 Nov version of the document and the current version
is that there is a cleaner distinction in sections 2, 3, and 4 between
OWL/DL (a.k.a., the abstract syntax) and OWL/Full.

> >5) Same section: The list of URI references that should not be mentioned
> >should include owl:imports (assuming it is not postponed)

Good point.  I think that this is the only place where I listed the
forbidden URI references.  Elsewhere I forbid all elements of the owl:
namespace.  I have just now changed to this latter method in 4.1.

> >6) Sect. 5.2: I'm hesitant about all of the iff definitions. For
> >example, isn't iff for TransitiveProperty putting an undue burden on
> >reasoners? I understand that you can only infer something is an
> >owl:TransitiveProperty if it is transitive in all models, but it seems
> >that you might be able uses cardinalities to restrict a property to a
> >certain number of tuples and then list all of these tuples. In such a
> >case, wouldn't complete reasoners always have to run through at the
> >tuples to determine if the property was transitive? Seems like an
> >expensive operation to me and I don't really see the utility of it.

I agree somewhat, but making the definitions only-if introduces its own
complications.  We could consider discussing this further.

> >Also, as I was reading the following thing occured to me, which is not
> >specific to the semantics document:
> >
> >The notion of complementOf in an open-world like the Semantic Web
> >worries me.
> 
> RIGHT!! I have been complaining about this ever since it was first 
> put into DAML. We should have a relative complement construction as 
> basic, rather than an absolute one, since we never know when one 
> ontology's universe is the same as another's.

> >We can never compute the complement because we can never
> >know the entire set of resources. I guess this will be used in rules in
> >such a way that we never actually need to know the extension of the
> >complement of a class, but are we sure there are no problems lurking
> >here? Is this something that should be a new issue, or have people given
> >this enough thought and decided its okay?
> 
> No, they havn't, and its not OK, and it needs some thought.

Absolute complement has been part of description logics for at least a
decade.  It doesn't cause any problem there, so why should it cause a
problem here?

Also, to make OWL safe in the database sense would require that all
restrictions were restrictions of some named class.  Even that would not be
sufficient, as owl:Thing could be used.  

In fact, this whole issue is completely pointless as rdfs:Resource is the
entire domain of discource, and thus absolute complement can easily be
reduced to relative complement.  You may as well complain that you can
never compute the extension of rdfs:Resource!

> Pat

peter

Received on Thursday, 7 November 2002 08:29:18 UTC