The Distributed Ontology, Modeling and Specification Language (DOL) - an answer to the OMG RFP OntoIOp. * View the latest version here: https://github.com/tillmo/DOL/raw/master/Standard/dol.pdf. * Convenience version with diff to version of August 24: https://github.com/tillmo/DOL/raw/master/Standard/dol-diff.pdf * Homepage of OntoIOp is
Page 44, first sentence of subclause: “While in most cases the translation from concrete to abstract syntax is obvious (the structure is largely the same)...” I found several cases (identified in following comments), beyond the few bullet points given, in which the relationship of the concrete to abstract syntax seemed to me not to be so obvious. It would be much better to have a more explicit specification of how the abstract syntax is synthesized from the parsing of the concrete syntax. This will be even more important as the metamodel is revised to be a better MOF model, rather than being derived as just an abstraction of the concrete syntax.
Page 45, ConservitivityStrength, ExtConservitivityStrength, Conservative: These concrete syntax productions make it clear that there are certain conservativity strengths that can only be used in certain contexts. It would be best if these restrictions were also recorded as constraints in the abstract syntax metamodel.
Page 45, OMSRef: Presumably this maps to the abstract syntax class OMSReference, so it should be called OMSReference in the concrete syntax, not OMSRef.
The structure of the BNF for OMS mappings seems to be more divergent from the structure of the corresponding abstract syntax than in other areas.
Page 51, production for InterpretationDefinition:
a. The first two clauses could be combined into a single clause (with “’=’ LanguageInterpretation* [SymbolMap] ‘end’” being optional).
b. It would be clearer if the third clause were separated into its own “RefinementDefinition” production (particularly in light of the comment bleow on InterpretationKeyword).
Page 51, InterpretationKeyword: It is not clear how the use of this keyword in the concrete syntax maps to the abstract syntax. Only the first two clauses of the InterpretationDefinition production (as given) would seem mappable to InterpretationDefinition in the abstract syntax, and should thus always use the “interpretation” keyword, while only the third clause would be mappable to RefinementDefinition and should thus always use the “refinement” keyword. And what is a “view”?
Page 51, RefMap: This production should be divided into separate productions for OMSRefinementMap (first two clauses) and NetworkRefinementMap (last clause), since the former applies only to SimpleOMSRefinements, while the later applies only to SimpleNetworkRefinements.
Page 52, Correspondence: How does “*” map? To DefaultCorrespondence?
Page 52, Relation: There should be an explicit specification of the mapping of the symbols given in the production for Relation to literals in the StandardRelationValues enumeration, and from an IRI to RelationReference.
Ed: