research whether or not there is an XMI to (E)BNF transformation service out there somewhere.

[ontochatbot]

[lonniev]

See related paper on BNF to EMF http://mdebe2013.big.tuwien.ac.at/wp-content/uploads/2013/09/mdebe2013_submission_4.pdf

[lonniev]

The paper is interesting and describes the addition of annotations to an EBNF (much like identifiers on rules in a PEG) to improve the ability of an XText parser of EBNF statements to yield a better Ecore metamodel for that EBNF. It also describes the use of a corpus of language statements to train a parser in producing better outputs than is possible from just the grammar specification.

[lonniev]

@rmbell2, I suspect you meant that the EBNF of Annex L of ad-15-10-01.pdf (the OMG DOL specification) is apparently hand-crafted and may be inconsistent with the actual ontology. Is that the EBNF of which you spoke?

[lonniev]

My Sodius XMI translation gurus tell me that they are not aware of any practical tool that can go from EBNF to Ecore to XMI. The probability of the existence of the reverse transformation (XMI to BNF) is higher than that for BNF to XMI due to the higher expressivity of XMI over BNF.

[lonniev]

See also http://edoc.hu-berlin.de/oa/conferences/reJMvCw1y4TMs/PDF/21NkCImNXEzsM.pdf (Section 3) where is discussed several challenges in using BNF as the source for metamodel production.

[lonniev]

This is an interesting site related to grammar translations. http://slebok.github.io/zoo/index.html#ontoware

[lonniev]

@rmbell2, are OMG specifications required to provide an (E)BNF specification of any formal language that they specify? I suspect not because none of the requirements in the DOL OMG document call for one and Annex L is marked as (informative) and not normative. (See ID 6.5.3(a)) If this annex simply is provided for audiences that are more familiar with BNF than with RDF in one of its dialects then perhaps its inclusion needlessly creates opportunities for errors because the EBNF isn’t a generated transformation of the definitive ontology.

[lonniev]

In “Clause 4” where the DOL Ontology is specified through the use of natural language, the authors could inform the readers that the text of the section is, in fact, generated from the actual ontology to which the specification is versioned. (If that is not the case, it should be: I’m fairly sure that VOM could serialize the ontology this way, I personally have coded MagicDraw Velocity script to serialize VOM ontologies this way, and the new Cameo Concept Modeler™ can serialize an ontology this way.) There’s no reason to leave readers unaware of the sound foundation of the text they are reading.