An Open Markup Format for Mathematical Documents (Version 1.1)

Total Page:16

File Type:pdf, Size:1020Kb

An Open Markup Format for Mathematical Documents (Version 1.1) OMDoc: An Open Markup Format for Mathematical Documents (Version 1.1) Michael Kohlhase Computer Science, Carnegie Mellon University Pittsburgh, Pa 15213, USA http://www.cs.cmu.edu/∼kohlhase October 5, 2005 Abstract In this report we present a content markup scheme for (collections of) math- ematical documents including articles, textbooks, interactive books, and courses. It can serve as the content language for agent communication of mathematical services on a mathematical software bus. We motivate and de- scribe the OMDoc language and present an Xml document type definition for it. Furthermore, we discuss applications and tool support. This document describes version 1.1 of the OMDoc format. This version is mainly a bug-fix release that has become necessary by the experiments of encoding legacy material and theorem prover interfaces in OMDoc. The changes are relatively minor, mostly adding optional fields. Version 1.1 of OMDoc freezes the development so that version 2.0 can be started off. In contrast to the OMDoc format which has not changed much, this report is a total re-write, it closes many documentation gaps, clarifies various remaining issues. and adds a multitude of new examples. Contents 1 Introduction 1 2 Mathematical Markup Schemes 5 2.1 DocumentMarkupfortheWeb . 6 2.2 Xml, the eXtensible Markup Language . 9 2.3 Mathematical Objects and Formulae . 12 2.4 Meta-Mathematical Objects . 17 2.5 An Active Web of Mathematical Knowledge . 20 3 OMDoc Elements 22 3.1 Metadata for Mathematical Elements . 23 3.1.1 The Dublin Core Elements . 24 3.1.2 Roles in Dublin Core Metadata . 28 3.2 Mathematical Statements . 31 3.2.1 Specifying Mathematical Properties . 31 3.2.2 Symbols, Definitions, and Axioms . 35 3.2.3 Assertions and Alternatives . 38 3.2.4 Mathematical Examples in OMDoc .......... 42 3.2.5 Representing Proofs in OMDoc ............ 43 3.2.6 Abstract Data Types . 49 3.3 Theories as Mathematical Contexts . 52 3.3.1 SimpleInheritance . 54 3.3.2 Inheritance via Translations . 56 3.3.3 Statements about Theories . 58 3.3.4 Parametric theories in OMDoc ............. 60 3.4 AuxiliaryElements . 64 3.4.1 Preservation of Text Structure . 64 3.4.2 Non-Xml Data and Program Code in OMDoc . 68 3.4.3 Applets in OMDoc ................... 71 ii 3.4.4 Exercises ......................... 73 3.5 Adding Presentation Information to OMDoc ......... 74 3.5.1 Specifying Style Information for OMDoc Elements . 75 3.5.2 Specifying the Notation of Mathematical Symbols . 79 3.6 Identifying and Referencing OMDoc Elements . 86 3.6.1 Locating OMS elements by the OMDoc Catalogue . 88 3.6.2 A URI-based Mechanism for Element Reference . 90 3.6.3 Uniqueness Constraints and Relative URI references . 92 4 OMDoc Applications, Tools, and Projects 95 4.1 Transforming OMDoc by XslT StyleSheets . 96 4.1.1 OMDoc Interfaces for Mathematical Software Systems 97 4.1.2 Presenting OMDoc toHumans............. 99 4.2 QMath: An Authoring Tool for OMDoc ...........102 4.3 MBase, an Open Mathematical Knowledge Base . 105 4.4 Project ActiveMath ......................107 4.4.1 OMDocExtensions. 107 4.4.2 Adaptive Presentation . 108 4.4.3 Integration of External Systems . 108 4.4.4 CurrentStatus . 109 5 Conclusion 110 A Errata to the released Specification 133 B Changes from Version 1.0 139 C Quick-Reference Table to the OMDoc Elements 144 D Quick-Reference Table to the OMDoc Attributes 149 E The OMDoc Document Type Definition 155 iii Chapter 1 Introduction It is plausible to expect that the way we do (i.e. conceive, develop, commu- nicate about, and publish) mathematics will change considerably in the next nine1 years. The Internet plays an ever-increasing role in our everyday life, and most of the mathematical activities will be supported by mathemat- ical software systems (we will call them mathematical services) connected by a commonly accepted distribution architecture, which we will call the mathematical software bus. We will subsume all proposed architectures and implementations of this idea [FHJ+99, FK99, DCN+00, AZ00] by the term MathWeb. We believe that interoperability based on communication protocols will eventually make the constructions of bridges between the par- ticular implementations simple, so that the combined systems appear to the user as one homogeneous web. One of the tasks that have to be solved is to define an open markup language for the mathematical objects and knowledge exchanged between mathematical services. The OMDoc format presented in this report at- tempts to do this by providing an infrastructure for the communication and storage of mathematical knowledge. In chapter 2 we will describe the status quo of mathematical markup schemes before OMDoc and show that these markup schemes – while giving a good basis – are not sufficient for content-based markup of mathematical knowledge. They do not provide markup for mathematical forms like defi- nitions, theorems, and proofs that have long been considered paradigmatic of mathematical documents like textbooks and papers. They also leave im- plicit the large-scale structure of mathematical knowledge. In particular, it 1In the release document of OMDoc1.0 [Koh00c] we claimed that it would change in the next 10, and that is one year ago. 1 has traditionally been structured into mathematical theories that serve as a situating context for all forms of mathematical communication. In chapter 3, we define the OMDoc markup primitives and motivate them from either particular structures in mathematical documents or from processing needs of computer-supported mathematics. As all mathematical communication is in the form of (or can be transcribed to) mathematical documents such as publications, overhead slides, letters, e-mails, in/output from mathematical software systems, OMDoc uses documents as a guiding intuition for mathematical knowledge with the goal of providing a frame- work, where all of these forms can be accommodated. In accordance with this motivation OMDoc provides a rich mix of elements of informal and formal mathematics. To model particular kinds of documents in OMDoc usually only a subset will be needed, e.g. informal ones for traditional math- ematical textbooks, or formal ones for communication of software systems. However, availability of both kinds of markup primitives in OMDoc al- low to develop novel kinds of mathematical documents, where formal and informal elements are intimately intermixed. We will discuss current and intended applications of the OMDoc format in chapter 4 and discuss which applications will need which parts of the OMDoc format. Finally, the appendix contains useful materials like the OMDoc docu- ment type definition, and a quick reference table. OMDoc Version 1.1 This document describes version 1.1 of the OMDoc format. Version 1.0 has been released on November 1. 2001, after about 18 Months of development, to give developers a stable interface to base their systems on. It has been adopted by various projects in automated deduction, algebraic specification and computer-supported education. The experience from these projects has uncovered a multitude of small deficiencies and extension possibilities of the format, that have been discussed in the OMDoc community. Version 1.1 is an attempt to roll the uncontroversial and non-disruptive part of the extensions and corrections into a consistent language format. We have tried to keep the changes to version 1.0 conservative, adding optional attributes or child elements. In some cases we had to introduce non-conservative changes, to repair de- sign flaws and inconsistencies of version 1.0. One example is the hpothesis element that has received a required attribute discharged-in that is nec- 2 essary for specifying the scope of local assumptions in proofs, and cannot be inferred from the context. To minimize disruption we have tried to keep changes like this one to a minimum for the elements that are in frequent use today. We are working on a new version (OMDoc2.0) that will incorporate re-organizations of central features of OMDoc like the definition element. We have however re-organized some parts of the OMDoc format that are currently less used in the anticipation that this will make them more effective. Examples are the representations of complex theories (see sec- tions 3.3.2 to 3.3.4) or the organization of non-Xml data (section 3.4.2). Finally, we have added new features that were missing from OMDoc1.0 and turned out to be important for the enterprise of representing mathemat- ical knowledge. Examples of this are a new referencing scheme for OMDoc elements in section 3.6 and a new way of specifying presentation for OM- Doc elements. In both cases, the method that was used in OMDoc1.0 for symbols is extended and generalized to arbitrary OMDoc elements. These extensions have found their way into OMDoc1.1, even though they are not totally fixed yet, since we anticipate to gain implementation experience for OMDoc2.0. They are non-disruptive, since they are strictly additional. An element-by-element account of the changes is tabulated in appendix B. Acknowledgments Of course the OMDoc format has not been developed by one person alone, the original proposal was taken up by several research groups, most no- tably the Ωmega group at Saarland University, the InKa and ActiveMath projects at the German Research Center of Artificial Intelligence (DFKI), the RIACA group at the Technical University of Eindhoven, the In2Math project at the University of Koblenz, and the CourseCapsules project at Carnegie Mellon University. They have discussed the initial proposals, repre- sented their materials in OMDoc and in the process refined the format with numerous suggestions and discussions (see http://www.mathweb.org/∼mailists/omdoc for the archive of the OMDoc mailing list.) The author specifically would like to thank Serge Autexier, Olga Caprotti, David Carlisle, Claudio Sacerdoti Coen, Arjeh Cohen, Armin Fiedler, An- dreas Franke, George Goguadze, Dieter Hutter, Erica Melis, Paul Libbrecht, Martijn Oostdijk, Alberto Palomo Gonzales, Martin Pollet, Julian Richard- son, Manfred Riem, and Michel Vollebregt for their input, discussions and feedback from implementations and applications.
Recommended publications
  • A Framework for Semantic Publishing of Modular Content Objects
    A Framework for Semantic Publishing of Modular Content Objects Catalin David, Deyan Ginev, Michael Kohlhase, Bogdan Matican, Stefan Mirea Computer Science, Jacobs University, Germany; http://kwarc.info/ Abstract. We present the Active Documents approach to semantic pub- lishing (semantically annotated documents associated with a content commons that holds the background ontologies) and the Planetary system (as an active document player). In this paper we explore the interaction of content object reuse and context sensitivity in the presentation process that transforms content modules to active documents. We propose a \separate compilation and dynamic linking" regime that makes semantic publishing of highly struc- tured content representations into active documents tractable and show how this is realized in the Planetary system. 1 Introduction Semantic publication can range from merely equipping published documents with RDFa annotations, expressing metadata or inter-paper links, to frame- works that support the provisioning of user-adapted documents from content representations and instrumenting them with interactions based on the seman- tic information embedded in the content forms. We want to propose an entry to the latter category in this paper. Our framework is based on semantically anno- tated documents together with semantic background ontologies (which we call the content commons). This information can then be used by user-visible, se- mantic services like program (fragment) execution, computation, visualization, navigation, information aggregation and information retrieval (see Figure 5). Finally a document player application can embed these services to make docu- ments executable. We call this framework the Active Documents Paradigm (ADP), since documents can also actively adapt to user preferences and envi- ronment rather than only executing services upon user request.
    [Show full text]
  • Importing the OEIS Library Into Omdoc
    Importing the OEIS library into OMDoc Enxhell Luzhnica, Mihnea Iancu, Michael Kohlhase Computer Science, Jacobs University, Bremen, Germany [email protected] Abstract. The On-line Encyclopedia of Integer Sequences (OEIS) is the largest database of its kind and an important resource for mathematicians. The database is well-structured and rich in mathematical content but is informal in nature so knowledge management services are not directly applicable. In this paper we provide a partial parser for the OEIS that leverages the fact that, in practice, the syntax used in its formulas is fairly regular. Then, we import the result into OMDoc to make the OEIS accessible to OMDoc-based knowledge management applications. We exemplify this with a formula search application based on the MathWebSearch system. 1 Introduction Integer sequences are important mathematical objects that appear in many areas of math- ematics and science and are studied in their own right. The On-line Encyclopedia of Integer Sequences (OEIS) [6] is a publicly accessible, searchable database documenting such sequences and collecting knowledge about them. The effort was started in 1964 by N. J. A. Sloane and led to a book [10] describing 2372 sequences which was later extended to over 5000 in [11]. The online version [8] started in 1994 and currently con- tains over 250000 documents from thousands of contributors with 15000 new entries being added each year [9]. Documents contain varied information about each sequence such as the beginning of the sequence, its name or description, formulas describing it, or computer programs in various languages for generating it.
    [Show full text]
  • Mathematical Document Representation and Processing1
    Formats Format Usage in DML-CZ Delivery Summary and Conclusions Mathematical Document Representation and Processing1 Petr Sojka Faculty of Informatics, Masaryk University, Brno, CZ, EU Dec 1st, 2008 1Supported by the Academy of Sciences of Czech Republic grant #1ET200190513 Mathematical Document Representation and Processing Faculty of Informatics, Masaryk University, Brno, CZ, EU Formats Format Usage in DML-CZ Delivery Summary and Conclusions Purpose-driven format choices Purposes for storing mathematics I Format choice depends on application’s purpose. I Most applications have its own internal format anyway. I For exchange seems to win XML/MathML (but which one?). I As authoring tools seems to be prefered (La)TEX. I Quite different requirements have theorem proving systems. Mathematical Document Representation and Processing Faculty of Informatics, Masaryk University, Brno, CZ, EU Formats Format Usage in DML-CZ Delivery Summary and Conclusions Purpose-driven format choices Mathematical Document Representation and Processing Faculty of Informatics, Masaryk University, Brno, CZ, EU Formats Format Usage in DML-CZ Delivery Summary and Conclusions Purpose-driven format choices Math Author Tools: LATEX, AMSLATEX (pdfAMSLATEX) I Good for authors: authors may express as close as possible to their mental model in their brain (new macros, namespaces). I This author’s advantage make headaches to the editors and those wishing to convert to some standard formalism (to index, evaluate, . ). I Many different macropackages, and active development as possibilites grow (XeTeX, LuaTEX, pdfTEX), . Mathematical Document Representation and Processing Faculty of Informatics, Masaryk University, Brno, CZ, EU Formats Format Usage in DML-CZ Delivery Summary and Conclusions Purpose-driven format choices pdfTEX program (used in Infty) was born in Brno during studies of Vietnamese student Hàn Thê´ Thành (1990–2001).
    [Show full text]
  • Arxiv:2005.03089V1 [Cs.LO] 5 May 2020 Abstract ??? Accepted: / ??? Received: Optrsine a Erlangen-N¨Urnberg E.G
    Noname manuscript No. (will be inserted by the editor) Experiences from Exporting Major Proof Assistant Libraries Michael Kohlhase · Florian Rabe Received: ??? / Accepted: ??? Abstract The interoperability of proof assistants and the integration of their li- braries is a highly valued but elusive goal in the field of theorem proving. As a preparatory step, in previous work, we translated the libraries of multiple proof assistants, specifically the ones of Coq, HOL Light, IMPS, Isabelle, Mizar, and PVS into a universal format: OMDoc/MMT. Each translation presented tremendous theoretical, technical, and social chal- lenges, some universal and some system-specific, some solvable and some still open. In this paper, we survey these challenges and compare and evaluate the solutions we chose. We believe similar library translations will be an essential part of any future system interoperability solution and our experiences will prove valuable to others undertaking such efforts. 1 Introduction Motivation The hugely influential QED manifesto [2] of 1994 urged the automated reasoning community to work towards a universal, computer-based database of all mathematical knowledge, strictly formalized in logic and supported by proofs that can be checked mechanically. The QED database was intended as a communal re- source that would guide research and allow the evaluation of automated reasoning tools and systems. This database was never realized, but the interoperability of proof assistants and the integration of their libraries has remained a highly valued but elusive goal. This is despite the large and growing need for more integrated and easily reusable libraries of formalizations. For example, the Flyspeck project [20] build a formal proof of the Kepler conjecture in HOL Light.
    [Show full text]
  • Languages of Mathematics1
    Domain of Math Search Digital Libraries Document Similarity Conclusions Languages of Mathematics1 Petr Sojka Faculty of Informatics, Masaryk University, Brno, CZ, EU Dec 5th, 2009 1Supported by NPV II and AS CR grant #1ET200190513 Languages of Mathematics Faculty of Informatics, Masaryk University, Brno, CZ, EU Domain of Math Search Digital Libraries Document Similarity Conclusions Conveying the message Languages of mathematics different points of view random walking in mathematics of languages Languages of Mathematics Faculty of Informatics, Masaryk University, Brno, CZ, EU Domain of Math Search Digital Libraries Document Similarity Conclusions Conveying the message Languages of Mathematics Faculty of Informatics, Masaryk University, Brno, CZ, EU Domain of Math Search Digital Libraries Document Similarity Conclusions Conveying the message Q: Is elephant a wall (belly), hand fan (ear), solid pipe (tusk), pillar (leg), rope (tail) or tree branch (trunk)? Languages of Mathematics Faculty of Informatics, Masaryk University, Brno, CZ, EU Domain of Math Search Digital Libraries Document Similarity Conclusions Conveying the message E = mc2 ? ! E = mc2 E = mc2 Znacˇkova´nı´ Na´vrh Sazba Korektury Prˇedloha Tisk Distribuce Markup Design Typesetting Proofreading Preprint Print Distribution Languages of Mathematics Faculty of Informatics, Masaryk University, Brno, CZ, EU Domain of Math Search Digital Libraries Document Similarity Conclusions Conveying the message Levels of text/math understanding/processing 1.0 lexical { words, strings of characters/TeX's $ $. 2.0 syntactical { phrases, parsed formulas (trees/MathML). 3.0 semantical { meaning of parsed phrases (cloud tags/ontologies/OpenMath). Problem of message (content+form) representation (of math when transporting the message over the web). Google around 1.5 now (no semantics, but for the purpose are people happy).
    [Show full text]
  • Experiences from Exporting Major Proof Assistant Libraries
    Noname manuscript No. (will be inserted by the editor) Experiences from Exporting Major Proof Assistant Libraries Michael Kohlhase (corresponding author) · Florian Rabe Received: ??? / Accepted: ??? Abstract The interoperability of proof assistants and the integration of their li- braries is a highly valued but elusive goal in the field of theorem proving. As a preparatory step, in previous work, we translated the libraries of multiple proof assistants, specifically the ones of Coq, HOL Light, IMPS, Isabelle, Mizar, and PVS into a universal format: OMDoc/MMT. Each translation presented tremendous theoretical, technical, and social chal- lenges, some universal and some system-specific, some solvable and some still open. In this paper, we survey these challenges and compare and evaluate the solutions we chose. We believe similar library translations will be an essential part of any future system interoperability solution and our experiences will prove valuable to others undertaking such efforts. 1 Introduction Motivation The hugely influential QED manifesto [2] of 1994 urged the automated reasoning community to work towards a universal, computer-based database of all mathematical knowledge, strictly formalized in logic and supported by proofs that can be checked mechanically. The QED database was intended as a communal re- source that would guide research and allow the evaluation of automated reasoning tools and systems. This database was never realized, but the interoperability of proof assistants and the integration of their libraries has remained a highly valued but elusive goal. This is despite the large and growing need for more integrated and easily reusable libraries of formalizations. For example, the Flyspeck project [20] build a formal proof of the Kepler conjecture in HOL Light.
    [Show full text]
  • Towards a Mizar Mathematical Library in Omdoc Format
    STUDIES IN LOGIC, GRAMMAR AND RHETORIC 10 (23) 2007 Towards a Mizar Mathematical Library in OMDoc Format Grzegorz Bancereki and Michael Kohlhaseii i Technical University Bialystok, [email protected] ii Jacobs University Bremen, [email protected] Abstract. Mizar is one of largest libraries of formalized mathematics. The language of the library is highly optimized for authoring by humans. Like in natural languages, the meaning of an expression is influenced by its (mathematical) context in a way that is natural to humans, but hard to specify for machine manipulation. From this point of view, it may be considered as locked up in an arcane file format. Indeed, the Mizar system itself is currently the only system that can reliably operate on the Mizar library. This paper presents an experiment of using the Mizar system to trans- form the Mizar library into the OMDoc format (Open Mathematical Documents), an XML-based representation format for mathematical knowl- edge that is geared towards making formula structure and context depen- dencies explicit. We expect the result of this experiment: an OMDoc version of the Mizar library to enhance system support for formal mathematical libraries. 1 Introduction In the last years we have seen the birth of a new research area: “Mathemat- ical Knowledge Management” (MKM), which is concerned with representation formalisms for mathematical knowledge, such as MathML [2], OpenMath [9] or OMDoc [16], mathematical content management systems [12, 1, 5], search en- gines [24, 23, 19, 15, 10], as well as publication and education systems [18,20] for mathematics. The perceived interest in the domain of general knowledge manage- ment tools applied to mathematics is that mathematics is a very well-structured and well-conceptualized subject.
    [Show full text]
  • Msetool: Management Strategy Evaluation Toolkit
    Package ‘MSEtool’ August 13, 2021 Title Management Strategy Evaluation Toolkit Version 3.2.0 Description Development, simulation testing, and implementation of management procedures for fisheries (see Carruthers & Hordyk (2018) <doi:10.1111/2041-210X.13081>). License GPL-3 Encoding UTF-8 LazyData true RoxygenNote 7.1.1 Depends R (>= 3.5.0), snowfall Imports abind, dplyr, methods, grDevices, ggplot2, parallel, Rcpp, stats, utils Suggests boot, broom, covr, crayon, devtools, DT, fmsb, ggrepel, gridExtra, kableExtra, knitr, MASS, mvtnorm, openxlsx, purrr, r4ss, readxl, reshape2, rfishbase, rmarkdown, shiny, testthat, tidyr LinkingTo Rcpp, RcppArmadillo BugReports https://github.com/Blue-Matter/MSEtool/issues NeedsCompilation yes Author Adrian Hordyk [aut, cre], Quang Huynh [aut], Tom Carruthers [aut], Chris Grandin [ctb] (iSCAM functions) Maintainer Adrian Hordyk <[email protected]> Repository CRAN Date/Publication 2021-08-13 10:10:17 UTC 1 2 R topics documented: R topics documented: Albacore . .5 Albacore_TwoFleet . .6 applyMMP . .7 applyMP . .7 Atlantic_mackerel . .8 avail.............................................9 boxplot.Data . 10 calcRefYield . 10 CALsimp . 11 Can ............................................. 12 CheckDuplicate . 13 CheckMPs . 13 checkMSE . 14 Choose . 15 CombineMMP . 16 Converge . 16 Cos_thresh_tab . 18 cparscheck . 18 Cplot . 19 Data-class . 20 Data2csv . 24 DataDescription . 24 DataDir . 25 DataInit . 25 DataSlots . 26 Data_xl . 27 DecE_Dom . 28 DFO_bar . 29 DFO_hist . 30 DFO_plot . 30 DFO_plot2 . 31 DFO_proj . 31 DFO_quant . 32 DFO_report . 33 DFO_spider . 33 DFO_tab . 34 DFO_tab_formatted . 34 DLMDataDir . 35 dnormal . 36 Dom............................................. 36 expandHerm . 37 Fease . 38 Fleet-class . 39 FleetDescription . 41 FMSYref . 42 Generic_Obs . 43 R topics documented: 3 getclass . 44 getDataList . 45 getfirstlev . 45 getmov2 . 46 getsel . 47 Hist-class . 47 hist2 . 49 HistDescription . 50 Imp-class . 50 ImpDescription .
    [Show full text]
  • Omdoc - an Open Markup Format for Mathematical Documents [Version 1.2]
    Michael Kohlhase OMDoc - An Open Markup Format for Mathematical Documents [version 1.2] Foreword by Alan Bundy fyA Springer Table of Contents Part I Setting the Stage for Open Mathematical Documents 1 Document Markup for the Web 3 1.1 Structure vs. Appearance in Markup 3 1.2 Markup for the World Wide Web 5 1.3 XML, the extensible Markup Language 6 2 Markup for Mathematical Knowledge 13 2.1 Mathematical Objects and Formulae 14 2.2 Mathematical Texts and Statements 20 2.3 Large-Scale Structure and Context in Mathematics 21 3 Open Mathematical Documents 25 3.1 A Brief History of the OMDoc Format 25 3.2 Three Levels of Markup 28 3.3 Situating the OMDoc Format 29 , 3.4 The Future: An Active Web of (Mathematical) Knowledge . 31 Part II An OMDoc Primer 4 Textbooks and Articles 35 4.1 Minimal OMDoc Markup 36 4.2 Structure and Statements 39 4.3 Marking up the Formulae 41 4.4 Full Formalization 45 5 OpenMath Content Dictionaries 49 6 Structured and Parametrized Theories 55 7 A Development Graph for Elementary Algebra 59 XVI Table of Contents 8 Courseware and the Narrative/Content Distinction 65 8.1 A Knowledge-Centered View 67 8.2 A Narrative-Structured View 71 8.3 Choreographing Narrative and Content OMDoc 73 8.4 Summary 74 9 Communication Between Systems 75 Part III The OMDoc Document Format 10 OMDoc as a Modular Format 83 10.1 The OMDoc Namespaces 83 10.2 Common Attributes in OMDoc 85 11 Document Infrastructure 89 11.1 The Document Root 90 11.2 Metadata 91 11.3 Document Comments 92 11.4 Document Structure 93 11.5 Sharing Document Parts 94 12 Metadata 97 12.1 The Dublin Core Elements (Module DC) 98 12.2 Roles in Dublin Core Elements 101 12.3 Managing Rights 102 12.4 Inheritance of Metadata 104 13 Mathematical Objects 107 13.1 OpenMath 107 13.2 Content MathML 114 13.3 Representing Types in Content-MATHML and OPENMATH.
    [Show full text]
  • An Open Markup Format for Mathematical Documents
    Michael Kohlhase Computer Science Jacobs University Bremen [email protected] An Open Markup Format for Mathematical Documents OMDoc [Version 1.3] August 23, 2010 This Document is the OMDoc 1.3 Specification. Source Information revision 8755, last change August 23, 2010 by kohlhase https://svn.omdoc.org/repos/omdoc/branches/omdoc-1.3/doc/spec/spec.tex This work is licensed by the Creative Commons Share-Alike license http://creativecommons.org/licenses/by-sa/2.5/: the contents of this specification or fragments thereof may be copied and distributed freely, as long as they are attributed to the original author and source, derivative works (i.e. modified versions of the material) may be published as long as they are also licenced under the Creative Commons Share-Alike license. Springer spec.tex 8685 2010-08-23 08:55:17Z kohlhase To Andrea | my wife, collaborator, and best friend | for all her support dedication.tex 8685 2010-08-23 08:55:17Z kohlhase VII Abstract The OMDoc (Open Mathematical Documents) format is a content markup scheme for (collections of) mathematical documents including articles, text- books, interactive books, and courses. OMDoc also serves as the content language for agent communication of mathematical services on a mathemati- cal software bus. This document describes version 1.3 of the OMDoc format, the final and mature release of OMDoc1. The format features a modularized language design, OpenMath and MathML for representing mathematical objects, and has been employed and validated in various applications. This book contains the rigorous specification of the OMDoc document format, an OMDoc primer with paradigmatic examples for many kinds of mathematical documents.
    [Show full text]
  • Wiki Authoring and Semantics of Mathematical Document Structure
    Wiki Authoring and Semantics of Mathematical Document Structure Hiraku Kuroda∗ and Takao Namiki Department of Mathematics, Hokkaido University, 060-0810 Sapporo, Japan Abstract We are developing a CMS including document authoring feature based on wiki to publish struc- tural mathematical documents on the Web. Using this system, users can write documents including mathematical expressions written in LATEX notation and explicitly stated characteristic structures of mathematical articles such as definitions, theorems, and proofs. Documents input to the system is published on the Web as not only XHTML files to be browsed but also XML files complying with NLM-DTD, which is used to exchange articles electronically. Not only single wiki page document, users can build a document which consist of more than one pages and is described its structure se- mantically by the system. In order to do this, we also propose an application of OAI-ORE and RDF vocabularies to describe structures of documents consisting of several resources. 1 Introduction Today, many documents are published on the Web. The term “documents” here includes articles of news or blog, wiki pages, journal articles, and any other web pages. These documents are published as HTML or XHTML to be browsed, or as PDF or PS file to be printed out. Sometimes one document is published as several formats. Some documents consist of several resources. One of examples is a document including a graphic image. Here, we assume that body text of the document is written in a HTML file and the image is a JPG file. On the Web, each of them is independent resource and given unique URI.
    [Show full text]
  • A Semantic Wiki for Mathematical Knowledge Management
    SWiM – A Semantic Wiki for Mathematical Knowledge Management Christoph Lange Computer Science, Jacobs University Bremen, [email protected] Abstract. SWiM is a semantic wiki for collaboratively building, edit- ing and browsing mathematical knowledge represented in the domain- specific structural semantic markup language OMDoc. It motivates users to contribute to collections of mathematical knowledge by instantly shar- ing the benefits of knowledge-powered services with them. SWiM is cur- rently being used for authoring content dictionaries, i. e. collections of uniquely identified mathematical symbols, and prepared for managing a large-scale proof formalisation effort. 1 Research Background and Application Context: Mathematical Knowledge Management A great deal of scientific work consists of collaboratively authoring documents— taking down first hypotheses, commenting on results of experiments, circulating informal drafts inside a working group, and structuring, annotating, or reor- ganising existing items of knowledge, finally leading to the publication of a well-structured article or book. Here, we particularly focus on the domain of mathematics and on tools that support collaborative authoring by utilising the knowledge contained in the documents. In recent years, several semantic markup languages have been developed to represent the clearly defined and hi- erarchical structures of mathematics. The XML languages MathML [9], Open- Math [11], and OMDoc [3] particularly aim at exchanging mathematical knowl- edge on the web. OMDoc, employing Content MathML or OpenMath repre- senting the functional structure of mathematical formulæ—as opposed to their visual appearance—and adding support for mathematical statements (like sym- arXiv:1003.5196v1 [cs.DL] 26 Mar 2010 bol declarations or axioms) and theories, has many applications in publishing, education, research, and data exchange [3, chap.
    [Show full text]