From: Frank van Harmelen (email@example.com)
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