If applied to algebraic signatures (sorts + operation symbols), minimize can be used to express reachability (i.e. term-generatedness) of first-order models. This should be clarified in the standard.

*Added footnote to explain use of minimize *

We added a footnote mentioning the use use minimize for expressing term-generatedness, and provided some datatype example (and corrected some other datatype example).

change the copyright information on page i (directly after title page) from
Copyright ©2014-15
to
Copyright ©2014-17

copyright information is updated

All occurrences of "Copyright ©2014-15" are replaced by "Copyright ©2014-17"

Cite the versionless reference and URL of standards. This will always refer to the lastest released version. Only in cases where we definitely rely on a specific version, we should cite that one.

Citation have been updated

We have changed several references from "versioned" to "unversioned".
We left the following normative references versioned because we are referring to a specific section of the standard document: RDF, RDFa, XMLns, OWL2RDF.

We have
OMS = ... | OMS OMSTranslation | ...
OMSTranslation = ... | ’with’ LanguageTranslation+

Assuming our OMS language contains an opitonal syntax element 'with' IRI, we could have something like

ontology foo =
...
with <www.example.com>

this would be ambiguous, since it would not be clear whether the "with <www.example.com>" would be part of the basic OMS or not.

*Curly Braces for Basic OMS within DOL documents *

We have added the restriction that inside DOL documents, a Basic OMS must not use any DOL keywords, unless it is enclosed in curly braces.

Because of an error in a Latex declaration, some parentheses aren't visible in the abstract grammar. These omissions change the grammar in unintended ways. This bug affects EBNF grammar expression across chapter 9 and in annex K.

*parenthesis now visible *

We fixed the bug in the latex that was responsible for hiding some of the parenthesis in EBNF code. While we were making these changes we also harmonized the use of whitespace in the EBNF grammars (this is a purely cosmetic change).

This affected the EBNF code on page 48, 52, 53, 57, 60, 138, 142.

Across the DOL spec "model" is used both for models in the UML sense and models in the mathematical model theory sense. This can lead to confusion. Better replace "model" in the mathematical sense by "realisation"

*terminological clarification of "model", introduction of "realization" *

we have changed the term "model" into "realization" and the term "MDE model" into "model", because in the OMG community, the term "model" will be unterstood in the sense of MDE and not in the sense of logical model theory. This makes certain sentences much clearer, e.g. on p. 119, "models (in the sense of the term defined in clause 4) of UML class models" now becomes "realisations of UML class models".

C.2 refers to “the metaclass OWL Ontology” and “the metaclass OWL Universe”. Presumably these refer to the classes OWLOntology and OWLUniverse from ODM; if so they should be spelt correctly (no space) and there should be a reference to NR24.

D.2 refers to the metaclasses Text and Sentence. It is not clear where these come from. Are they from an existing standard? – if so it should be referenced. Or if they are from a hypothetical metamodel inferred from the Common Logic definition, this should be made explicit.

E.2 refers to the metaclasses Document and Triple. Are these from ODM? If so there should be a reference fo NR24.

F.2 refers to the metaclasses OWL Model and OWL PackageableElement. Presumably the reference to OWL is an error, and the metaclasses are actually Model and PackageableElement from the UML metamodel – reference NR8. Also it would be more flexible to make Package rather than Model a subclass of NativeDocument: it’s valid for a UML document to contain a top-level Package which is not a Model and it seems a shame to exclude such a thing from the world of DOL.

G.2 refers to the metaclasses TPTP_file and annotated_formula. It is not clear where these come from. Are they from an existing standard? – if so it should be referenced. Or if they are from a hypothetical metamodel inferred from the TPTP definition, this should be made explicit.

H.2 refers to the metaclasses LIBRARY and BASIC-SPEC. It is not clear where these come from. Are they from an existing standard? – if so it should be referenced. Or if they are from a hypothetical metamodel inferred from the CASL definition, this should be made explicit.

all proposals were implemented

we implemented all proposed changes (see diff document)

P11: shard -> shared

P25: “Annex M provides of DOL texts, which provide examples for all DOL constructs,” clumsy. Reword “Annex M provides textual examples for all DOL constructs,”

P25: The bibliography contains Q references -> delete Q

P31: “Often is useful” -> “Often it is useful”

P35: “in this context are ask” -> “in this context ask”

P62: Table 2 should be positioned in 9.8.1.2, not in the middle of 9.8.1.1.

P125: “many-sorted first has been formalized” -> “many-sorted first-order logic has been formalized”

all corrections were made

all corrections were made

It says “a transformation tool is DOL-conformant if it implements one (or more) language translations, logic translations, language projections and/or logic projections.” There must surely also be some DOL-related requirement here, e.g. that the tool consumes and produces DOL-conforming documents.

Conformance condition for transformation tools clarified

We have added that a transformation tool has to operate on the DOL (abstract) syntax.

(1) when possible rephrase definitions in order to improve ISO 704 compliance,
(2) replace rdf:comment with skos:definition where appropriate,
(3) when appropriate spit definitions into a definition and related explanatory note,
(4) revise some comments as more specifically usage notes
(5) change the label “model” to “realization” in order to avoid potential confusion of “model” in the logic sense and “model” in the engineering sense
(6) address formatting issues

adressed all issues

We addressed all issues.

For example
"AnnotationAssertion(rdfs:comment <http://www.omg.org/spec/DOL/DOL-terms/propagatesToAdjoint> "The subject class denotes a kind of mapping that, if it holds for a translation, also holds for the adjoint reduction."@en)"
was replaced by
"AnnotationAssertion(<http://www.w3.org/2004/02/skos/core#definition> <http://www.omg.org/spec/DOL/DOL-terms/propagatesToAdjoint> "subject class denotes a kind of mapping that, if it holds for a translation, also holds for the adjoint reduction"^^xsd:string)"

Another example:
"ObjectPropertyDomain(<http://www.omg.org/spec/DOL/DOL-terms/satisfies> <http://www.omg.org/spec/DOL/DOL-terms/Realization>)"
was replaced by
"ObjectPropertyDomain(<http://www.omg.org/spec/DOL/DOL-terms/satisfies> <http://www.omg.org/spec/DOL/DOL-terms/Model>)"

All of these changes improved the readability of the ontology, but did not change the content of the ontology. The terminological change from "model" to "realization" was necessary in order to synchronise the terminology in the ontology with the terminology in the specification.

Because of its original source, many of the definitions and comments contain Latex markup and symbols that are not properly encoded. This needs to be cleaned up.

Encoding corrected, latex annotations removed

non-UTF 8 symbols were replaced by UTF 8 symbols (e.g., non-UTF quotation marks).
Latex markup was replaced by equivalent text. Citations were removed, since they are available in the specification text.

For example the following text:

AnnotationAssertion(<http://www.w3.org/2004/02/skos/core#note> <http://www.omg.org/spec/DOL/DOL-terms/LinkedData> " The linked data principles (adapted from
cite

and its paraphrase at
cite

) are the following:
begin

"@en)

was replaced by

AnnotationAssertion(<http://www.w3.org/2004/02/skos/core#note> <http://www.omg.org/spec/DOL/DOL-terms/LinkedData> "Linked data principles, as interpreted herein, are as follows: (a) Use IRIs as names for things; (b) Use HTTP IRIs so that these things can be referred to and looked up (dereferenced) by people and user agents; i.e., the IRI is treated as a URL (uniform resource locator); (c) Provide useful machine-processable (plus optionally human-readable) information about the thing when its IRI is dereferenced, using standard formats; (d) Include links to other, related IRIs in the exposed data to improve discovery of other related information on the Web."^^xsd:string)

Note that change from language tagged strings to xsd:string is the result of the resolution of ticket DOL-102

The OWL file is attached to the resolution of DOL-102. The resolution does not affect the specification.

The label for supportsLogic in the ontology is duplicated.

*The duplication has been deleted. *

we have deleted the duplication.

I.5.7.2 Translation of sentences: $\top$ and $\bot$ are missing!
I.5.7.3 Translation of models:

$M'_\Thing$ does not make sense, because this is unsorted first-order logic.
$\I$ has not been introduced. Sometimes, $I$ is used.
Typo: By Induction (should be: by induction).
As last item, add: The other cases are similar.
The satisfaction condition holds as well. --> The satisfaction condition now follows easily.

Minor technical corrections to OWL -> FOL translation

We have made minor technical corrections in the mathematical definition of the translation of OWL to first-order logic. For details see diff file.

Footnote 35 says "there does not seem to be default in UML 2.5". This is incorrect. UML 2.5 specifies the defaults in the Classifier description of MultiplicityElement thus:

isOrdered : Boolean [1..1] = false

isUnique : Boolean [1..1] = true

*changed footnote *

We removed the sentence ""there does not seem to be default in UML 2.5"

P28. The textual example illustrating section 7.2 contains two inconsistent language lang:CommonLogic terms, one of which is followed by a colon while the other is not.

*change of example *

there was no inconsistency, because the two lang:CommonLogic terms were used in different syntactic roles (global versus local language qualification). Nevertheless, we have revised the example, such that this is avoided now.

typo on page 53
satifsiable -> satisfiable

trivial spelling error corrected

see summary

Replace "view" by "refinement" in example 7.11 on page 37

"view" replaced by "refinement"

Simple replacement of one term by another.

Original text:
view cd2stm = cd refined to

end
view cd2psm = cd refined to

end

In the DOL ontology, dol:Union is defined in terms of the combination of all ..., and then refers to a sequence of OMS. Is the sequence order actually relevant? If not, would it be better to define this through a set of OMS rather than a sequence?

No change

Sequence is used here in the sense of syntactic sequence. Since a union is a syntactic entity, we would prefer to stay with sequence here.

Generally, there seem to be a number of concepts where the definition in the ontology diverges from the one given in the specification document. Some concepts defined in the document do not appear in the ontology, e.g. infrastructure axiom (which is referred to e.g. in the natural language definition of SimpleTheoroidalMapping). Ideally, and especially for use in other OMG specifications such as API4KP, the ontology should be able to stand alone.

infrastructureAxiom was added to the ontology

We have added InfrastructureAxiom to the DOL ontology. Otherwise, we believe that we have taken all concepts from the glossary (section 4) into account when designing the DOL ontology.

SimpleTheoroidalMapping: The definition seems to suggest that this is not a LogicMapping (the natural language definition says it maps signatures to logical theories, while a LogicMapping maps logics to logics). The definition in the document of simple theoroidal logic translation is much clearer. There is a disconnect because only simple theoroidal logic translation is defined in the document, while SimpleTheoroidalMapping as defined in the ontology is more general.

clarification of definition of LogicMapping and SimpleTheoroidalMapping

We have clarified that a LogicMapping is "a mapping (translation or reduction) between two logics consisting of mappings for signatures, sentences and models".

We further clarified that a SimpleTheoridalMapping is a "logic mapping that maps signatures of the source logic to theories of the target logic"

These changes should make transparent that a SimpleTheoroidalMapping is a LogicMapping.

In the ontology, classes for Reduction and Translation (as subclasses of Mapping) would be useful (and then define logic and language reduction and translation using them).

• we have added classes Reduction, Translation and OMSLanguageReduction.*

we have added classes Reduction, Translation and OMSLanguageReduction. The definition of OMSLanguageTranslation was clarified.

In the DOL ontology for LogicalTheory: The natural language definition is kind of awkward: "a signature together with a set of sentences" would be more appropriate.

definition of LogicalTheory improved

We have changed the wording as suggested, but kept the addition "(over that signature)

Logic: the definition seems to be appropriate for monotonic logic only. That is, the satisfaction relation is defined for sentences, and then it appears to be assumed that satisfaction of a theory is based on satisfaction of all sentences in the theory. This would not be enough for, e.g. defeasible logic. So perhaps the name of this concept should be changed to MonotonicLogic, so if can be reused in external ontologies that also cover nonmonotonic logics.

We distinguish between Logic and MonotonicLogic

The former class Logic has been renamed to MonotonicLogic, and a class
Logic has been added as a superclass of MonotonicLogic.
Most object properties still have domain/range Logic. Only the
formalises object properties has range MonotonicLogic:
an Institution always formalises a MonotonicLogic.

The definition of dol:Language as "collection of expressions" where dol:Expression is "a finite combination of symbols that are well-formed according to applicable rules (depending on the language)" suggests that this class does not include natural languages, only formal languages. This is supported by its usage in the definition of dol:FormalSemantics? To avoid confusion, could this concept be renamed to dol:FormalLanguage (if that is the intent)?

(API4KB team)

We now distinguish class Language and class FormalLanguage.

We now distinguish class Language and class FormalLanguage.

LogicReduction has a note "mapping between logics forgetting parts of the structure, projection to a smaller logic, in contrast to reduction". Should be "mapping between logics forgetting parts of the structure, projection to a smaller logic, in contrast to translation"

(API4KB team)

*see http://issues.omg.org/browse/DOL-53*

This has been covered by the proposal
http://issues.omg.org/browse/DOL-53

The definition of Logic Mapping suggests that it can be any kind of mapping between logics, but the comment says it should be either a translation or reduction, which seems to be more specific. Should LogicMapping be the disjoint union of LogicTranslation and LogicReduction?

(API4KB team)

translations or reductions are kinds of LogicMapping, but there could be more

LogicTranslation and LogicReduction are not disjoint. The extreme case of a LogicMapping that leaves everything unchanged (the identity mapping) is both a LogicTranslation and a LogicReduction.
Moreover, in the future, there could be LogicMappings that are neither LogicTranslations nor LogicReductions (although it is presently not clear how they would look).
Hence, we prefer to leave the ontology unchanged here.

Add a note (if it is true) that an dol:OMSLanguageTranslation could also be called an dol:OMSLanguageMapping, since the formalization simply requires that the mapping be from and to OMS Languages.

(API4KB team)

*see proposal http://issues.omg.org/browse/DOL-53*

this is covered by http://issues.omg.org/browse/DOL-53

In the DOL ontology, dol:SequenceOfCorrespondences doesn't appear to be used for anything. Consider deleting.

(Note that any deletions must be done prior to moving into RTF – at that stage in the specification one cannot delete or rename concepts or properties - you would need to deprecate them instead, so that your user community is not negatively impacted.)

*added new class Sequence *

SequenceOfCorrespondences is actually used in Alignment, we have corrected this and also introduced a class Sequence serving as domain/range of object properties hasSequenceMember and isSequenceMemberOf.

DOLLibrary is formalized as "semanticallyDenotes some GlobalEnvironment", but this doesn't seem to arise from the natural language definition.

*axioms are added to reflect the textual definition *

A DOLLibrary is now (additionally) formalised as having OMS, OMSMappings and OMSNetworks as parts.

On page 4 of the specification document, it states that " DOL is capable of assigning identifiers to entities (symbols, axioms, modules, etc.)." Based on this, we expect to find classes for symbol, axiom and module in the ontology. Is AxiomSentence the same as "axiom"? Definitions for some of these concepts appear to be missing from the ontology, in other words.

*Renaming of AxiomSentence into Axiom *

We have changed AxiomSentence into Axiom (and TheoremSentence into Theorem). Symbol occurs as NonLogicalSymbol in the ontology, in accordance to section 4.2 of the DOL document. On page 4, they are (for conciseness) mentioned as "symbols". Module is a class in the ontology.

Currently in the DOL ontology, DefaultMapping is defined as a subclass of LogicMapping. There might be a need for DefaultLanguageMappings, so it would be better to rename this class to DefaultLogicMapping and have a superclass named DefaultMapping (especially the fact that the document speaks of default language translations hints to the existence of a default language mapping).

*Introduction of DefaultLogicMapping and DefaultLanguageMapping *

We introduced DefaultLogicMapping and DefaultLanguageMapping. DefaultMapping is a superclass of both.

In the DOL ontology, the natural language (text) definition for the Institution class is incomplete, and should incorporate the definition provided by the defining axioms of the class.

*Definition of institution changed. *

We have extended the definition of institution in order to incorporate the definition provided by the defining axioms of the class.

HeterogeneousEnvironment: the notes from the document should also be added to the ontology class.

• We have added the notes to the class HeterogeneousEnvironment of the DOL ontology.*

We have added the notes to the class HeterogeneousEnvironment of the DOL ontology.

In the DOL ontology, LanguageGraph and LogicGraph: Explicitly state what the nodes and what the edges are

we have now explicitly stated what nodes and edges are.

We have now explicitly stated what nodes and edges are by changing the definitions of LanguageGraph and LogicGraph.

In the DOL ontology, LanguageGraph: edges seem to be limited to language translations - why not e.g. language reductions?

The definition of OMSLanguageTranslation suggests that a language mapping can be either a translation or a reduction.

We have added language reductions to the definition of LanguageGraph.

We have added language reductions to the definition of LanguageGraph.

In the DOL ontology, IRIs seem to be restricted to document identifiers, networks and mappings, and the meaning of global knowledge remains unexplained.

*definition of global knowledge rephrased *

We have changed the wording concerning global knowledge. However, we did not change anything concerning IRIs. Note that a GlobalEnvironment uses IRIs in a specific and restricted way. But this does not mean at all that IRIs (which are not defined in the DOL ontology, because there are other places to do so) are restricted.
This change affects both the glossary in the specification as well as the ontology.

There is no concept of Symbol but it is used in the definition of Language, and there is a concept of NonLogicalSymbol.

(API4KB team)

We have added classes Symbol and LogicalSymbol.

We have added classes Symbol and LogicalSymbol.

There appears to not be an intermediate concept between dol:OMSLanguage and dol:Profile for a dol:OMSLanguage with a particular logic (e.g. OWL2 with Direct Semantics).
While this is not an error of the DOL ontology, this is a concept that would be useful for API4KB.

We are surprised that this concept is not needed in DOL, because e.g. this concept enables the distinction between OWL 2 (in general) and OWL DL or OWL Full, It would also potentially be needed to distinguish between OWL 2 profiles.

(API4KB team)

no intermediate concept between dol:OMSLanguage and dol:Profile needed

There appears to not be an intermediate concept between dol:OMSLanguage and dol:Profile for a dol:OMSLanguage with a particular logic (e.g. OWL2 with Direct Semantics).
While this is not an error of the DOL ontology, this is a concept that would be useful for API4KB.

We are surprised that this concept is not needed in DOL, because e.g. this concept enables the distinction between OWL 2 (in general) and OWL DL or OWL Full, It would also potentially be needed to distinguish between OWL 2 profiles.

The philosophy of DOL is different here: an OMSLanguage can support (via the object property supportsLogic) different Logics. What you are after is a pair of an OMSLanguage and a Logic (such that the supportsLogic relation holds). We do not have such a thing in DOL as a concept of its own, although implicitly it is there: a user can select an OMSLanguage and a Logic, for example OWL2 EL with RDF logic (i.e. RDF semantics, aka OWL full).

Each of "dol:Ontology", "dol:Specification" and "dol:MDEModel" are defined as "logical theories", but they are not subclasses of dol:LogicalTheory. Further, their definition suggests they are roles (i.e. non-rigid properties) of dol:LogicalTheory. If this is the intended meaning, then the definition should say this explicitly.

(API4KB team)

*revised definitions of OMS, ontology, MDE model and specification *

Indeed, the use of "logical theory" for the definitions is misleading here. We improved the definitions of OMS, ontology, MDE model, and specification both in the DOL spec and the ontology.

There is a typo in definition of ontology "shard" =>"shared".

(API4KB team)

typo corrected

typo corrected

The definition of dol:AbstractSyntax says it is a (term) language that ... . Therefore It should be a subclass of dol:Language.

Also, the definition dol:AbstractSyntax does not capture the common notion of abstract syntax in OMG. Perhaps "platform-independent metamodel for a language"?

(API4KB team)

definition of AbstractSyntax revised

AbstractSyntax is now a subclass of Language. The notion of metamodel occurs in a note; we have kept the definition more general.

The class, dol:LanguageGraph has a label of "OMS language graph", which is more explicit. If that is the intent of the class from a usage perspective, the name should be revised to dol:OMSLanguageGraph.

(API4KB team input)

• we have implemented the suggested change.*

The class, dol:LanguageGraph has a label of "OMS language graph", which is more explicit. If that is the intent of the class from a usage perspective, the name should be revised to dol:OMSLanguageGraph.

we have implemented the suggested change.

dol:OMSLanguageTranslation has two definitions with slightly different wording. One says "a mapping (translation or reduction) between two OMS languages", which seems like it would be more appropriate for dol:OMSLanguageMapping, a concept that is not explicitly defined. The second says "mapping from constructs in the source OMS language to their equivalents in the target OMS language". It is not clear in what sense "equivalent" is meant here.

(API4KB team)

Clarification of OMSLanguageTranslation

dol:OMSLanguageTranslation has two definitions with slightly different wording. One says "a mapping (translation or reduction) between two OMS languages", which seems like it would be more appropriate for dol:OMSLanguageMapping, a concept that is not explicitly defined. The second says "mapping from constructs in the source OMS language to their equivalents in the target OMS language". It is not clear in what sense "equivalent" is meant here.

The first wording has been adressed already by proposal
http://issues.omg.org/browse/DOL-53. We have deleted the second wording, because it is imprecise and mostly inherited from Mapping already.

In dol:OMSLanguageTranslation the use of "text" in the note suggests that a translation is always between texts (presumably, a coarse-grained syntactic category like Common Logic texts?), rather than between the more fine-grained syntactic "constructs". It would be more clear to either define "dol:Text" and "dol:Construct" or re-use terms that are formally defined, such as dol:Term or dol:Expression.

(API4KB team)

*Clarification of dol:OMSLanguageTranslation *

The syntactic category of the result of a translation entirely depends on the syntax of the target language. Thus, we have removed the term "text" in order to avoid possible confusion. It is required that the result must be well-formed in the target language, the syntactic nature of the result is not longer mentioned.

The natural language definition of Term "syntactic expression either consisting of a single non-logical symbol or recursively composed of other terms (a.k.a. its subterms)" is a little unclear, as it leaves some question as to the role of logical symbols. The intent is made more clear by the existence of the subclass Sentence, which presumably includes sentences with logical connectives, but as a stand-alone definition it is vague. Perhaps an explanatory note could be added, because in some standards the "term" class does not include sentences.

definition of Term is clarified

We have clarified that logical symbols can be part of terms. Hopefully, this makes it more transparent.
There is an axiom that states that Sentence is as subclass of Term. We are not sure what the note should say in addition to that.

The term "construct" is used in several annotations (:isLanguageAspectOf definition, :LanguageAspect, ...). Is this a synonym for dol:Term or dol:Expression or something different? To make this more clear, either a term dol:Construct could be defined, or an existing concept could be used instead.

(API4KB team)

"Construct" added to ontology

We have now defined construct as "syntactic pattern that is part of a language".

The natural language definition of dol:Mapping does not agree with the formalization, in that logic mappings are not set-theoretic mappings, but are families of set-theoretic mappings. The natural language definition could be generalized to "set-theoretic mapping or family of set-theoretic mappings" (as suggested by Till), so that it would be correct to say that dol:LogicMapping is a subclass of dol:Mapping. This would still exclude dol:SignatureMorphism.

change of definition of Mapping

We have generalized the definition of Mapping to "set-theoretic mapping or family of set-theoretic mappings".

There is no definition of a dol:OMSLanguageReduction, but reduction is mentioned in the definition of dol:OMSLanguageTranslation.

(API4KB team)

*see proposal http://issues.omg.org/browse/DOL-53*

this has been covered by http://issues.omg.org/browse/DOL-53

There is a similar group of redundant axioms for subclasses of LogicTranslation and LogicReduction, that explicitly state they are subclasses of LogicMapping. It should be okay to delete these redundant declarations.

(API4KB team)

redundant axioms were removed

We have removed the redundant axiom for Embedding, which is a subclass of LogicTranslation. There is no subclass of LogicReduction.

There is a redundant declaration of dol:OMSLanguageTranslation as a subclass of dol:Mapping, in addition to it being a subclass of dol:LanguageMapping, which could be deleted.

*See proposal http://issues.omg.org/browse/DOL-53*

The redundant declaration has been taken care of as part of the rewrite in proposal
http://issues.omg.org/browse/DOL-53.

The definition of dol:OMS suggests it should be a disjoint union of dol:Ontology, dol:Specification and dol:MDEModel, while formally they are subclasses. It is not clear if dol:OMS should be considered a role, or a subclass of logical theory. Based on the note attached to OMS, which says "an OMS is a collection of expressions, like ...", I would expect that OMS is a subclass of logical theory, not a role. Therefore, dol:Ontology, dol:Specification and dol:MDEModel would not be subclasses of OMS, but roles that an OMS can play.

(API4KB team)

*already covered by http://issues.omg.org/browse/DOL-83*

This issue is already covered by proposal http://issues.omg.org/browse/DOL-83

While aspects of the ontology are incorporated in definitions in the body of the specification, the ontology itself should be documented via ODM-compliant diagrams, and both ODM/UML XMI and ODM XMI forms for the ontology should be included as deliverables with the specification.

The DOL ontology should be documented properly in the specification

The resolution to this issue requires (1) production of the ODM UML XMI according to the latest version of the ontology, (2) production of the ODM XMI according to the latest version of the ontology, and (3) documentation of the ontology in an informative annex, including all header metadata describing the ontology as well as its contents in DL notation (see the LCC and FIBO specifications for examples).

This issue is being deferred to the DOL 1.1 RTF due to the fact that the modifications required to the ontology by other issues documented in this report were completed close to the delivery deadline, and the process of documenting the ontology, which is informative, will take more than the available time remaining.

Because the ontology is available in RDF/XML serialized OWL, adopters of this specification can use it as is, and leverage tools to automate the transformations to UML XMI or ODM XMI as required for other work. The definitions used in the ontology for the various concepts defined therein are also provided as normative terms and definitions in the body of the specification. The other artifacts should be provided for the sake of completeness by the DOL 1.1 RTF, however, as other emerging specifications at OMG, such as the API4KBs specification, will depend on them.