Re: (Part 2) Where did these syntax constraints come from?

From: Frank van Harmelen (frankh@cs.vu.nl)
Date: 01/07/01


Dear Joint Everybody,

This is the second part of our reply to all your comments.
We deal with all the smaller points (in fact, we take action on most
of them). 

DC> why 1 <ontology> element?

Fixed. Now 0 or more.

DC> Empty ontologies are fine?

Yes.

DC> Why in daml+oil.daml:
DC>  <rdfs:Class rdf:ID="Thing">
DC>  but later...
DC>  <subPropertyOf resource="#equivalentTo"/>

Bug.Fixed.

JH> Why need at least 1 <imports> element?

Fixed. Now 0 or more.

DC> "why this specific syntax" and "isn't other RDF allowed"

Hopefully dealt with in our first reply message.
(through introductory text in the reference document)

TBL> Is DAML+OIL a subset of RDF?

Yes. Hopefully dealt with in our first reply message.
(through introductory text in the reference document)

TBL> I know some folks have wanted to make separate lanuages and force
TBL> separate documents for defining classes and instances.
TBL> I feel that that would be a very backward step.

See our first reply message. 
Don't worry, such a separation is definitely not the case. 

TBL> the reference led me to believe that you don't need a full RDF
TBL> parser to parse DAML - you only need to parse elements, not
TBL> attributes.

Apologies for making you believe this. As our first reply message
hopefully made clear, the believe was false, and the new text of the
reference doc. should now no longer make anybody believe this. 

DC> I'm not aware of any decision to get rid of daml:equivalentTo.

We've put it back in, with a remark that it is less useful than the
more specific daml:samePropertyAs or daml:sameClassAs, because its
semantics are less clear to RDFS-only agents (as explained in Dan's email).
For this reason, we would not like to put it back in the walkthrough
(bad modelling style). 

TBL> restrictedBy and subClassOf seem to be synonyms.  Why both with both?

This was discussed and decided in Washington. Mostly backward
compatability with earlier version, as explained by Dan.

TBL> <restrictedBy>
TBL>   <Restriction>
TBL>      <hasValue>
TBL> I hoped that the english would improve.  It is still really
TBL> non-evident from the markup what the restriction is. Also, it is a
TBL> wasteful use of markup. It is an example of excessive reification.
TBL> But I can't think of a better alternative.

Yes, it's not pretty. If you have a better idea, say it NOW, or it will
be frozen. (Actually, if you read
     <subClassOf>
       <Restriction>
          <hasValue>
It already sounds a lot better!)

TBL> It is not clear from the spec, when one has multiple restriction
TBL> elements defining different sets, that the restriction is the
TBL> intersection (I assume) of those sets.

Conjoining multiple elements without an explicit connective means
conjunction everywhere, but we've added text to emphasise.

TBL> The explanation of toClass is really diffciult to read.

Attempted a new formulation.

TBL> (under "hasClass" element definition, the "belongs to other
TBL> Classes" should be "do not belong to the class".)

actually, should read "do not belong to the class expression". Fixed.


This archive was generated by hypermail 2.1.4 : 04/02/02 EST