Re: SEM: Light review of semantics document

On November 7, Peter F. Patel-Schneider writes:
> 
> [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.

In absolute terms it doesn't make any difference because, as I
mentioned in an earlier email, the question can be formulated in terms
of satisfiability - e.g., P is transitive just in case for some new
individual i (intersectionOf (P someValuesFrom (P hasValue i))
(complementOf (P hasValue i))) is not satisfiable. The if/iff question
only relates to the RDF syntax - i.e., P is transitive if/iff the
triple P rdf:type owl:TransitiveProperty is in the ontology.

Ian

> 
> > >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 15:20:02 UTC