diff --git a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/inherited-invariant-checking-violated-example.png b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/inherited-invariant-checking-violated-example.png index ead1fa5..7278059 100644 Binary files a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/inherited-invariant-checking-violated-example.png and b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/inherited-invariant-checking-violated-example.png differ diff --git a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/invariant-checking-violated-example.png b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/invariant-checking-violated-example.png index bab2aba..5373e59 100644 Binary files a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/invariant-checking-violated-example.png and b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/invariant-checking-violated-example.png differ diff --git a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-checking-example.png b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-checking-example.png index 39985c4..f1bb243 100644 Binary files a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-checking-example.png and b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-checking-example.png differ diff --git a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-equality-evaluation-example.png b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-equality-evaluation-example.png index a038cc0..8675c49 100644 Binary files a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-equality-evaluation-example.png and b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-equality-evaluation-example.png differ diff --git a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-evaluation-example.png b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-evaluation-example.png index a297100..de89930 100644 Binary files a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-evaluation-example.png and b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-evaluation-example.png differ diff --git a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-failed-checking-example.png b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-failed-checking-example.png index 76a25bc..4061184 100644 Binary files a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-failed-checking-example.png and b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-failed-checking-example.png differ diff --git a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-failed-evaluation-example.png b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-failed-evaluation-example.png index 3f59fbb..9a2376b 100644 Binary files a/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-failed-evaluation-example.png and b/examples/scholarly_paper/2021-ITP-PMTI/document/figures/term-context-failed-evaluation-example.png differ diff --git a/examples/scholarly_paper/2021-ITP-PMTI/paper.thy b/examples/scholarly_paper/2021-ITP-PMTI/paper.thy index 902a210..bda2fef 100644 --- a/examples/scholarly_paper/2021-ITP-PMTI/paper.thy +++ b/examples/scholarly_paper/2021-ITP-PMTI/paper.thy @@ -257,7 +257,6 @@ ITP community allowing a deeper structuring of mathematical libraries such as the Archive of Formal Proofs (AFP). \ - (*<*) declare_reference*[casestudy::text_section] (*>*) @@ -343,7 +342,7 @@ doc_class requirement = text_element + (* derived from text_element *) long_name ::"string option" (* an optional string attribute *) is_concerned::"role set" (* roles working with this req. *) \} - This ODL class definition maybe part of one or more Isabelle theory--files capturing the entire + This ODL class definition maybe part of one or more Isabelle theory-files capturing the entire ontology definition. Isabelle's session management allows for pre-compiling them before being imported in the actual target documentation required to be compliant to this ontology. @@ -499,6 +498,14 @@ text*[resultProof::myresult, evidence = "proof", property="[@{thm \HOL.ref text*[resultProof2::myresult, evidence = "proof", property="[@{thm \HOL.sym\}]"]\\ +term*\@{myauthor \church\}\ +(*term*\@{myauthor \churche\}\*) + +value*\email @{myauthor \church\}\ +(*value*\email @{myauthor \churche\}\*) + +(*assert*\@{myresult \resultProof\} = @{myresult \resultProof2\}\*) + (*text*[introduction1::myintroduction, authored_by = "{@{myauthor \church\}}", level = "Some 0"]\\*) (*text*[claimNotion::myclaim, authored_by = "{@{myauthor \church\}}", based_on= "[\Notion1\, \Notion2\]", level = "Some 0"]\\*) @@ -525,7 +532,7 @@ text\ \<^item> Ontological validation of the term: the meta-data of term antiquotations is parsed and checked in the logical context, \<^item> Elaboration of term antiquotations: depending of the antiquotation specific - elaboration function, they antiquotations containing references were replaced, + elaboration function, the antiquotations containing references were replaced, for example, by the object they refer to in the logical context, \<^item> Generation of markup information for the Isabelle/PIDE, and \<^item> Code generation: @@ -537,9 +544,10 @@ text\ and to evaluate a term (the command \<^theory_text>\value\). We provide the equivalent commands, respectively \<^theory_text>\term*\ and \<^theory_text>\value*\, which additionally support a validation and elaboration phase. - + We also provide an \<^theory_text>\assert*\-command which checks + that the evaluation of a term returns \<^const>\True\ and fails in other cases. Note that term antiquotations are admitted in all \<^dof> commands, not just - \<^theory_text>\term*\ and \<^theory_text>\value*\. + \<^theory_text>\term*\, \<^theory_text>\value*\ and \<^theory_text>\assert*\. \ (*<*) @@ -601,7 +609,7 @@ text*[claimNotion::myclaim, authored_by = "{@{myauthor \church\}}", In the instance \<^theory_text>\introduction1\, the term antiquotation \<^theory_text>\@{myauthor \church\}\, or its equivalent notation \<^term>\@{myauthor \church\}\, denotes the instance \<^theory_text>\church\ of the class \<^typ>\myauthor\, - where \<^theory_text>\church\ is an \<^hol>-string. + where \<^theory_text>\church\ is a \<^hol>-string. One can now reference a class instance in a \<^theory_text>\term*\ command. In the command \<^theory_text>\term*\@{myauthor \church\}\\ the term \<^term>\@{myauthor \church\}\ is type-checked, \<^ie>, the command \<^theory_text>\term*\ checks that @@ -670,10 +678,11 @@ declare_reference*["term-context-equality-evaluation"::figure] text\ Since term antiquotations are logically uninterpreted constants, - it is possible to compare class instances logically. \<^figure>\term-context-equality-evaluation\ - shows that the two class instances \<^theory_text>\resultProof\ and \<^theory_text>\resultProof2\ are not equivalent - because their attribute \<^term>\property\ differ. - When \<^theory_text>\value*\ evaluates the term, + it is possible to compare class instances logically. The assertion + in the \<^figure>\term-context-equality-evaluation\ fails: + the two class instances \<^theory_text>\resultProof\ and \<^theory_text>\resultProof2\ are not equivalent + because their attribute \<^term>\property\ differs. + When \<^theory_text>\assert*\ evaluates the term, the term antiquotations \<^term>\@{thm \HOL.refl\}\ and \<^term>\@{thm \HOL.sym\}\ are checked against the global context to validate that the \<^hol>-strings \<^term>\\HOL.refl\\ and \<^term>\\HOL.sym\\ reference existing theorems. @@ -772,8 +781,8 @@ text\ Any class definition generates term antiquotations checking a class instance or the set of instances in a particular logical context; these references were elaborated to objects they refer to. - This paves the way for a new mechanism to query the ``current'' instances presented as a - list of \<^hol> \<^type>\list\. + This paves the way for a new mechanism to query the ``current'' instances presented + as a \<^hol> \<^type>\list\. Arbitrarily complex queries can therefore be defined inside the logical language. Thus, to get the list of the properties of the instances of the class \<^typ>\myresult\, or to get the list of the authors of the instances of the \<^typ>\myintroduction\ class, @@ -1046,7 +1055,7 @@ definition Computer_Hardware_to_Hardware_morphism :: map Product_to_Component_morphism (Computer_Hardware.composed_of \) \" \} -\caption{An extract of a mapping definitions.} +\caption{An extract of a mapping definition.} \label{fig-mapping-example} \end{figure} @@ -1216,7 +1225,7 @@ onto_class Field_of_mathematics = \} defines the class \<^typ>\Field_of_mathematics\ with an attribute \<^theory_text>\Annotations\ which is a \<^type>\list\ of \<^typ>\annotation\s. - We can even constraint the type of allowed \<^typ>\annotation\s with an invariant. + We can even constrain the type of allowed \<^typ>\annotation\s with an invariant. Here the \<^theory_text>\invariant restrict_annotation_F\ forces the \<^typ>\annotation\s to be a \<^const>\label\ or a \<^const>\comment\. Subsumption relation is straightforward. @@ -1276,7 +1285,7 @@ This limits their practical usefulness drastically. Our approach treats invarian first-class citizens, and turns them into an object of formal study in, for example, ontological mappings. Such a technology exists, to our knowledge, for the first time. -Our experiments with adaptions of existing ontologies from engineering and mathematics +Our experiments with adaptations of existing ontologies from engineering and mathematics show that \<^dof>'s ODL has sufficient expressive power to cover all aspects of languages such as OWL (with perhaps the exception of multiple inheritance on classes). However, these ontologies have been developed specifically \<^emph>\in\ OWL and target