Aug 5, 2006 - The software developed so far, named SWiM (Semantic Wiki for ... a market-ready application, I am going to continue this research in my PhD ...
International University Bremen/Universität Trier
Diploma Thesis
A Semantic Wiki for Mathematical Knowledge Management Christoph Lange Matriculation Number 697886 Universität Trier – FB IV – Informatik August 5, 2006
Advisor: Prof. Dr. Michael Kohlhase∗ 1st Examiner: Prof. Dr. Bernd Walter†
∗ †
Computer Science, International University Bremen FB IV, Informatik, Universität Trier
Declaration The research subsumed in this thesis has been conducted under the supervision of Prof. Michael Kohlhase from the International University Bremen. Part of the results have been pre-published as a paper and a poster for the 1st workshop on semantic wikis1 [LK06a] and as a section of the “Applications and Projects” chapter in the OMDoc book [LK06b], both co-authored by Michael Kohlhase. Apart from his contributions to these two publications, which have been incorporated into sections 2.1.3, 3.1, 3.2.1 and 3.3.4 of this thesis, all material presented is my own, unless specifically stated. I hereby declare that this submission is my own work, and that — to the best of my knowledge — it does not contain any material previously published (except for the above-mentioned paper) or written by another person. Any contribution made to my research by others is explicitly acknowledged in this thesis. Christoph Lange Trier, August 5, 2006
Erklärung – Deutsche Fassung Die in dieser Arbeit zusammengefasste Forschung wurde unter Betreuung von Prof. Michael Kohlhase von der International University Bremen durchgeführt. Ein Teil der Ergebnisse wurde vorveröffentlicht als Artikel und Poster für den 1. Workshop zu semantischen Wikis2 [LK06a] und als Abschnitt des Kapitels “Applications and Projects” (Anwendungen und Projekte) im OMDoc-Buch [LK06b], beide gemeinsam mit Michael Kohlhase verfasst. Außer seinen Beiträgen zu diesen beiden Veröffentlichungen, die in die Abschnitte 2.1.3, 3.1, 3.2.1 und 3.3.4 der vorliegenden Arbeit eingeflossen sind, ist alles hier vorgestellte Material mein eigenes, sofern nicht ausdrücklich anders angegeben. Hiermit erkläre ich, dass diese Einreichung meine eigene Arbeit ist und nach meinem besten Wissen kein Material enthält, das vorher veröffentlicht (außer dem oben genannten Artikel) oder von anderen Personen geschrieben worden ist. Jeder Beitrag Dritter zu meiner Forschung ist in dieser Arbeit ausdrücklich als solcher genannt. Christoph Lange Trier, 5. August 2006
1
see http://www.semwiki.org for the workshop and http://kwarc.eecs.iu-bremen.de/projects/ swim/pubs.html for our contribution 2 siehe http://www.semwiki.org für den Workshop und http://kwarc.eecs.iu-bremen.de/projects/ swim/pubs.html für unseren Beitrag
ii
Preface In this thesis I propose a semantic wiki technology for collaboratively building, editing and browsing mathematical knowledge. Its hyperlinked pages, containing mathematical theories and statements, are stored in OMDoc [Koh06], a markup format for mathematical knowledge representation. My long-term objective is to develop a software that, on the one hand, facilitates the creation of a shared, public collection of mathematical knowledge (e.g. for education). On the other hand the software shall serve work groups of mathematicians as a tool for collaborative development of new theories. The software developed so far, named SWiM (Semantic Wiki for Mathematical Knowledge Management), can be found on http://kwarc.eecs.iu-bremen.de/projects/ swim/. From the beginning, it was certain that this task would go beyond the scope of a sixmonth diploma thesis. Building on the results gained so far and in consideration of the experiences made with the implementation, which is rather a research prototype than a market-ready application, I am going to continue this research in my PhD studies at the International University Bremen, starting in September 2006.
Vorwort – Deutsche Fassung In dieser Arbeit stelle ich die Technologie eines semantischen Wikis zum kollaborativen Aufbau, zum Bearbeiten und zum Durchlesen mathematischen Wissens. Seine untereinander vernetzten Seiten, die mathematische Theorien und Aussagen enthalten, sind in OMDoc [Koh06] gespeichert, einem Auszeichnungsformat für mathematische Wissensrepräsentation. Mein langfristiges Ziel ist es, ein Programm zu entwickeln, das einerseits die Erstellung einer gemeinsam genutzten, öffentlichen Sammlung mathematischen Wissens (z.B. für die Lehre) erleichtert, andererseits aber auch Arbeitsgruppen von Mathematikern als Werkzeug zur kollaborativen Entwicklung neuer Theorien dienen soll. Die bisher entwickelte Software, genannt SWiM (Semantisches Wiki für Mathematische Wissensverwaltung), ist unter http://kwarc.eecs.iu-bremen.de/projects/ swim/ zu finden. Von Anfang an war klar, dass diese Aufgabe den Rahmen einer sechsmonatigen Diplomarbeit sprengen würde. Aufbauend auf den bisher gewonnenen Ergebnissen und unter Berücksichtigung der Erfahrungen mit der Implementation, die eher ein Forschungsprototyp ist als eine marktreife Anwendung, werde ich diese Forschung in meinem Promotionsstudium an der International University Bremen fortsetzen, das im September 2006 beginnt.
iii
Acknowledgments I would like to thank, first and foremost, my advisor, Prof. Michael Kohlhase, head of the KWARC group at the International University Bremen, for offering me a thesis on semantic wikis, to be continued with PhD research, under his supervision, and for guiding and supporting me during my work. Despite the distance from Trier to Bremen, he was available for answering my questions and giving me valuable suggestions at almost any time. I am also extremely grateful to Normen Müller from the KWARC group for his input, his proof-reading, his patient explanations regarding OMDoc and development graphs and, of course, for accomodating me when I met Michael Kohlhase and him at the IUB. Furthermore I would like to thank other colleagues from the KWARC group: Octavian Druta for designing a cute logo for SWiM and Immanuel Normann for his helpful comments. As regards my work in Trier, I would like to thank Prof. Bernd Walter from the University of Trier for supporting my external diploma thesis and for his willingness to be my examiner. I am also grateful to him for providing me an office at the university. Special thanks go to his staff members: Patrick Reuther for his valuable suggestions on writing and programming, Alexander Weber for helping me to set up my computer — and to recover from a hard disk crash — and to Agnes Jacoby for helping me with organizational tasks. Thanks also go to Peter Weißgerber from the chair for software engineering for his helpful comments and to Steffen Büffel from the department of media sciences for his imaginative suggestions regarding Semantic Web and wikis in the very beginning of my work. Thanks for helping me with performing special programming tasks go to several people: when I had to improve my proficiency in XSLT and XPath, my fellow student Dimitrij Zub taught me several useful tricks. When I was involved with debugging the OMDoc example documents, the bug reports from Alberto González Palomo where of great help to me. I would also like to thank Rebecca Mäke, who advised me to impose a strict time management upon myself. I am especially thankful to Verena Höcker and Steffen Salewski for proof-reading. Special thanks go to the developers of Semantic MediaWiki [VKV+ 06] for arousing my interest in semantic wikis through their talk at Wikimania 2005 and to Sebastian Schaffert, the head developer of IkeWiki, which I based my work upon, for his quick support and for many inside tips. Thanks also go to Rosa Riebl from C&L Computer- und Literaturverlag, the publisher of my book on wikis [Lan05], for extending the deadline for the second edition of the book with respect to my thesis. Love, sympathy and encouragement from my parents and, particularly, from my girlfriend Kerstin enabled me to face this challenging task. They deserve my special thanks. Since the fourth semester of my studies, I have been financially supported through a scholarship of the Konrad-Adenauer-Stiftung, which made it easier for me to travel to Bremen for meetings, to attend the European Semantic Web conference in Budva/Montenegro and to buy the books and computer equipment I needed. I am especially grateful to them for prolonging the scholarship beyond my standard period of study until the end of my work on this thesis.
iv
Special thanks for acquainting me with Michael Kohlhase go to the German National Academic Foundation (Studienstiftung des deutschen Volkes), of which I have also been a (non-financially supported) fellow. On a summer school of the Studienstiftung in 2005 I participated in a work group on “Natural-Language-Aware Search Engines – Linguistic Ontologies for Exploiting Text Information”, co-led by Michael Kohlhase. Last but not least I would like to thank all the developers of the great open source software tools I used for my work, including Eclipse, KDE (especially karm and Konqueror), LATEX, Mozilla, PmWiki, Saxon, Subversion, vim, Xfig and others.
v
Contents 1 Executive Summary 2 Foundations 2.1 Markup Languages for Mathematical Knowledge . . . . . 2.1.1 MathML . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 OpenMath . . . . . . . . . . . . . . . . . . . . . . 2.1.3 OMDoc . . . . . . . . . . . . . . . . . . . . . . . . 2.2 The Semantic Web . . . . . . . . . . . . . . . . . . . . . . 2.2.1 RDF Notations and Libraries . . . . . . . . . . . . 2.2.2 Extracting RDF from XML . . . . . . . . . . . . . 2.3 Wikis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Semantic Wikis — Wikis for the Semantic Web . . . . . . 2.4.1 Wiki Improvements Through Semantics . . . . . . 2.4.2 Data Model of Semantic Wikis . . . . . . . . . . . 2.4.3 Navigation in Semantic Wikis . . . . . . . . . . . . 2.4.4 Import and Export to and from the Semantic Web 2.4.5 No Mathematical Semantic Wikis so far . . . . . . 2.5 Added-value Services and Web 2.0 . . . . . . . . . . . . . 2.5.1 Social Bookmarking . . . . . . . . . . . . . . . . . 2.6 Mathematical Encyclopedias on the Web . . . . . . . . . . 2.6.1 Open-content Projects . . . . . . . . . . . . . . . . Wiki-based Projects . . . . . . . . . . . . . . . . . PlanetMath . . . . . . . . . . . . . . . . . . . . . . 2.6.2 Closed-content Projects . . . . . . . . . . . . . . . MathWorld . . . . . . . . . . . . . . . . . . . . . . Digital Library of Mathematical Functions . . . . . The On-Line Encyclopedia of Integer Sequences . .
1
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
2 2 2 3 3 4 5 6 7 8 8 9 11 12 12 13 13 14 15 15 15 16 16 17 17
3 Requirements Analysis 3.1 OMDoc Considered as an Ontology Language . . . . . . . . 3.1.1 What Makes an OMDoc Wiki Different? . . . . . . . 3.2 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Ontological Requirements . . . . . . . . . . . . . . . 3.2.2 Requirements Imposed by Wiki Usability . . . . . . 3.2.3 Technical Requirement: Validity . . . . . . . . . . . 3.2.4 Discussion Pages and Proposed OMDoc Extensions .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
19 19 20 21 21 22 23 23
vi
Contents
3.2.5
Utilizable Semantic Information . . . . . . . . . . . . . . Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . User Interface and Interaction Model . . . . . . . . . . . . . . . . 3.3.1 Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Dynamic Navigation Links . . . . . . . . . . . . . . . . . 3.3.3 Interactively Navigating the Dependency Graph . . . . . 3.3.4 Preserving Dependencies on Editing . . . . . . . . . . . . 3.3.5 User-friendly Editing . . . . . . . . . . . . . . . . . . . . . Splitting Documents into Smaller Parts and Edit-in-place Separate Metadata Editor . . . . . . . . . . . . . . . . . . Simplified syntax . . . . . . . . . . . . . . . . . . . . . . . Auto-completion . . . . . . . . . . . . . . . . . . . . . . . External Editors . . . . . . . . . . . . . . . . . . . . . . . General Requirements for Hypermedia Systems . . . . . . . . . . Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Import and Export . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Integrating Existing OMDoc Tools . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
24 24 24 24 25 25 26 28 28 28 29 29 30 31 31 32 33 33 33
4 Architecture 4.1 The OMDoc System Ontology . . . . . . . . . . . . . . . . . . . . 4.2 Re-interpretations and Adaptations of OMDoc’s Syntax . . . . . 4.2.1 Extracting Semantics from OMDoc’s Syntax . . . . . . . 4.2.2 Constitutive Statements Made Usable . . . . . . . . . . . 4.2.3 Practical Hints for Modeling . . . . . . . . . . . . . . . . 4.2.4 Naming Conventions for Identifiers and URLs . . . . . . . 4.2.5 Normalization on Export . . . . . . . . . . . . . . . . . . 4.3 Reasoning on OMDoc and Other Knowledge . . . . . . . . . . . 4.3.1 Reasoning on OMDoc Knowledge . . . . . . . . . . . . . . 4.3.2 Knowledge from User Interaction and Reasoning Thereon 4.3.3 Reasoning on OMDoc and User Interaction . . . . . . . . 4.3.4 Complementing Reasoning by Manual Annotations . . . . 4.4 Co-existence of Wiki Text and OMDoc . . . . . . . . . . . . . . . 4.5 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Source View . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Presentation View . . . . . . . . . . . . . . . . . . . . . . Notation of Symbols . . . . . . . . . . . . . . . . . . . . . Including Parts from other Documents . . . . . . . . . . . OMDoc’s Presentation Workflow . . . . . . . . . . . . . . 4.6 Management of Change . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
34 34 36 36 37 37 38 38 39 39 40 40 40 41 42 42 43 43 44 45 45
3.3
3.4 3.5 3.6
vii
Contents
5 Implementation 5.1 Software Survey . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Criteria for Evaluation . . . . . . . . . . . . . . 5.1.2 Software Evaluated . . . . . . . . . . . . . . . . XWiki 0.9.840 . . . . . . . . . . . . . . . . . . MediaWiki 1.5.7 and Semantic MediaWiki 0.2a JSPWiki 2.3.72 and Makna pre-release . . . . . IkeWiki Snapshot 2006–03–08 . . . . . . . . . . Rhizome 0.5.1 . . . . . . . . . . . . . . . . . . . Rhaptos 1.5 . . . . . . . . . . . . . . . . . . . . 5.1.3 Reasons for IkeWiki . . . . . . . . . . . . . . . 5.1.4 Keeping Rhaptos at the Back of one’s Mind . . 5.2 Implementation Steps . . . . . . . . . . . . . . . . . . 5.2.1 Forking IkeWiki . . . . . . . . . . . . . . . . . 5.2.2 Handling OMDoc and Wiki Text . . . . . . . . 5.2.3 Importing Test Documents . . . . . . . . . . . 5.2.4 Source Code View . . . . . . . . . . . . . . . . 5.2.5 Validation and Preparation of Documents . . . 5.2.6 Presentation View . . . . . . . . . . . . . . . . 5.2.7 Page and Link Types . . . . . . . . . . . . . . 5.2.8 Reasoning . . . . . . . . . . . . . . . . . . . . . 5.2.9 Further Improvements to IkeWiki . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
48 48 48 50 50 51 52 53 54 55 57 57 57 57 58 60 60 61 62 64 65 66
6 Evaluation 6.1 Basic Data Model and Storage . . . . . . . . . 6.2 Page and Link Types and the System Ontology 6.2.1 Coverage of the OMDoc Standard . . . 6.2.2 Rule-based Reasoning . . . . . . . . . . 6.2.3 Metadata . . . . . . . . . . . . . . . . . 6.2.4 Browsing the System Ontology . . . . . 6.2.5 Extraction of Semantic Information . . 6.2.6 Dealing with Semantic Inconsistencies . 6.3 User Interface and Interaction Model . . . . . . 6.3.1 Rendering . . . . . . . . . . . . . . . . . Presentation View . . . . . . . . . . . . Source View . . . . . . . . . . . . . . . . 6.3.2 Navigation . . . . . . . . . . . . . . . . Inline Links . . . . . . . . . . . . . . . . Typed Links . . . . . . . . . . . . . . . Interactive Navigation . . . . . . . . . . 6.3.3 Editing . . . . . . . . . . . . . . . . . . 6.3.4 Management of Change . . . . . . . . . 6.3.5 Miscellaneous Wiki Features . . . . . . 6.4 Import and Export . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
67 67 68 68 69 69 70 71 72 72 72 72 75 75 75 76 77 77 78 78 79
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
viii
Contents
7 Further Work
80
A SWiM Source Directories
82
Bibliography
85
Index
96
ix
List of Figures 2.1 2.2
Typed links in Semantic MediaWiki, inline and grouped by facets . . . . . 12 Graph on the integration of social software and semantic web . . . . . . . 14
3.1 3.2 3.3 3.4
Sketch of a theory page with navigation links . . . . . . . . . . . . . A subgraph of a dependency graph . . . . . . . . . . . . . . . . . . . Sketch of the command buttons to navigate along the dependencies . The metadata editor in IkeWiki . . . . . . . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
26 26 27 30
4.1 4.2 4.3 4.4
A subset of OMDoc’s system ontology . . . . . . . . . . . . . Refactoring of wiki classes before adding OMDoc functionality OMDoc source code formatted via XSLT . . . . . . . . . . . . Transformation from OMDoc to XHTML+MathML . . . . . .
. . . .
. . . .
. . . .
35 42 43 46
5.1 5.2 5.3
A subset of IkeWiki’s database schema . . . . . . . . . . . . . . . . . . . . 58 Data flow from page source to presentation output . . . . . . . . . . . . . 60 Presentation view of a theory page with typed links on the right . . . . . 63
6.1 6.2
A Creative Commons license in IkeWiki . . . . . . . . . . . . . . . . . . . 70 Browsing a property from an ontology in IkeWiki . . . . . . . . . . . . . . 71
. . . .
. . . .
. . . .
x
1 Executive Summary My aim is to develop a wiki1 [LC01] technology for collaboratively building, editing and browsing mathematical knowledge. I am prototyping this technology in the SWiM system (Semantic Wiki for Mathematical Knowledge Management). Its hyperlinked pages, containing mathematical theories and statements, are stored in OMDoc [Koh06], a markup format for mathematical knowledge representation with numerous applications: creation of customized modules for e-learning, data exchange between different theorem provers, web services and more. SWiM will be based on an already existing wiki software, preferably a semantic one. SWiM shall encourage users to collaborate: non-mathematicians can collaborate in creating a “Wikipedia [Wikb] of mathematics” by compiling the knowledge available so far, while scientists can collaboratively develop new theories. However, to encourage users to contribute, wiki-like openness to anybody probably will not suffice. Unlike the text formats used by common semantic wikis, the OMDoc format makes the finegrained semantic structure that is implicit in the text explicit in the markup, making it tedious to author by hand. Moreover, only after a substantial initial investment (writing, annotating and linking) on the author’s part, the community can benefit from the added-value services supported by the format — e.g. the creation of customized textbooks [MS04]. If author and beneficiary of such services were different persons, though, only few persons would be willing to contribute to a knowledge base. This “MKM author’s dilemma” [KK04] can be overcome when the authors themselves are rewarded for their contributions by being offered added-value services, which improve immediately the more annotations and cross-references the users contribute, — for example a facility for navigation through the knowledge base along paths of semantic relations between the theories, which are computed from the OMDoc document collection. The contribution of this thesis is threefold: 1. I specified the architecture of SWiM. 2. I did a partial implementation and evaluated that. 3. I participated in improving the OMDoc 1.2 standard (mainly those parts used in the SWiM implementation, i.e. the example documents, the presentation XSLT style sheets and the system ontology).
1
The word “wiki” can have several different meanings: a wiki engine is a software running a wiki site, while the latter is a website consisting of many editable wiki pages. A wiki site may be run by a wiki community. I will distinguish between those meanings by using composites when necessary.
1
2 Foundations 2.1 Markup Languages for Mathematical Knowledge One of the best known open1 markup languages for mathematics is TEX, which, however, will not be considered here for two reasons: first, it is not optimized for use on the web2 , secondly, it only allows for presentational markup of mathematical formulae, not for semantic markup3 . On the web, MathML [ABC+ 03] and OpenMath [BCC+ 04]4 , which form two complementary standards, are more common. They are both based on XML, while OpenMath can also be binary encoded for better efficiency. language by since origin markup coverage status activity website a b
MathML W3C Math WG 1997 math for HTML content + presentation limited to K-14b mathematics Version 2.2e (VI 2003) maintenance http://w3.org/Math/
OpenMath OpenMath society 1999 integration of CASa content extensible Version 2 (VI 2004) maintenance http://www.openmath.org
Computer Algebra Systems primary/secondary school and undergraduate college level
Table 2.1: The Status of Markup Standardization for Mathematical Formulae, after [Koh06]
2.1.1 MathML The original objective for MathML was to display formulae in HTML documents with presentational markup, but there is also a subset of the language offering limited semantic 1
Proprietary languages will not be considered here. For example, hyperlinks are not a built-in feature, and the preferred output medium is fixed-sized paper. 3 . . . as regards “out-of-the-box distributions” of TEX or LATEX. As TEX is programmable, one can, however, extend it by semantic markup, as has been done with sTEX [Koh05]. Since sTEX can be transformed to OMDoc without loss, it will not be covered here on its own. 4 See also [Koh06, chapter 2] and [Bus99] for a short introduction into both languages 2
2
2 Foundations
markup called Content MathML which is limited to K-14 mathematics, though. Presentation MathML can be extended beyond this scope because its symbols are taken from the rich Unicode character set. A semantics element, together with the annotation and annotation-xml elements, is provided for semantic annotation of Presentation MathML formulae in more powerful languages than Content MathML. This is where OpenMath comes into play.
2.1.2 OpenMath OpenMath is a content-only markup language, which, on the one hand, can be used to annotate MathML, and, on the other hand, can be rendered for presentation using an XSL transformation [Kay06] to Presentation MathML5 . Originally designed for communicating mathematical objects between different applications, OpenMath allows more rigorous semantic expressions than Content MathML, whereby it is useful for computer algebra, for example. The core language consists of only 15 basic XML elements6 , but it can be extended by defining content dictionaries (CDs), which introduce new symbols along with their semantics. The semantics of a symbol can be expressed formally using OpenMath expressions (“formal mathematical properties”, element FMP) and in natural language (“commented mathematical properties”, element CMP). There are more than 60 standard CDs available with more than 40 additional ones contributed. The usage of CDs establishes “semantics by pointing” [Koh06, chapter 2.1.2]: if two objects have the same structure and if their symbols come from the same content dictionary, they have the same meaning7 . Note, however, that CDs themselves were not designed to be communicated. They only back definitions of symbols used by mathematical objects that are communicated. CDs still lack some clarity, though. Expressions on semantics must be attached to individual symbols, so it is unclear where to specify relations between multiple symbols, as, for example, the distributivity of addition (symbol +) over multiplication (symbol · ). Moreover, it is not always clear how the FMP of one symbol relates to the accompanying CMP element — in theory, they could even be completely different. CMPs can only contain plain text, which is insufficient for describing the semantics of mathematical objects. Furthermore, CDs do not distinguish between constitutive and non-constitutive properties of elements. (Non-constitutive properties are, for instance, examples, see also page 22.)
2.1.3 OMDoc MathML and OpenMath are still insufficient for communicating knowledge. They are restricted to small mathematical objects and formulae, but human mathematical knowl5
Style sheets for a limited conversion from OpenMath to Content MathML to Presentation MathML are available from [ORC] 6 as of Version 2, not counting the elements for defining content dictionaries 7 The value of semantics by pointing should not be underestimated. For example, using Wikipedia’s URIs as identifiers for ontology concepts has been investigated, although Wikipedia does not even contain formal knowledge [HBS06].
3
2 Foundations
edge involves larger structures like theorems, proofs, even whole theories. These can be expressed in OMDoc, a superset of both OpenMath and MathML, which specifies three levels of markup: Object Level Objects are formulae, written in a content markup language (OpenMath or Content MathML) that represents their logical structure. Their presentation is specified separately. Statement Level This level is made up of axioms, definitions, theorems, proofs and examples connected by references. Usually, proofs are not formally verified — instead an assertion is already considered as true when there is a proof attached to it via a hyperlink. This is sufficient for many OMDoc applications. Theory Level The highest level denotes a graph of theories, connected by dependency relations, in particular inheritance from more general theories and imports from premised theories. One document contains at least one theory that in turn consists of several contextually related statements. A theory provides a context that fixes the meaning of an individual symbol, be it a symbol defined in the same theory or a symbol imported from another theory, but provided with a modified meaning in the importing theory. Additional features are available as modules: Dublin Core metadata on theory and statement level (module DC [Koh06, chapter 12]), formatted text (RT [chapter 14.6]), style hints for presenting (module PRES [chapter 19]) and more. In the whole space of mathematical knowledge representation, OMDoc resides between informal mathematic vernacular used by humans for communication and formal logical frameworks for automated proof checking [Koh06, figure 3.2]. Compared to logical frameworks, OMDoc has a broader coverage, but it lacks support for inference modeling. While it does not cover as many areas as mathematical vernacular, it is better supported by machines, though.
2.2 The Semantic Web The Semantic Web [W3Cb] is an approach to turn the World Wide Web into a giant searchable knowledge base, a “web of data”. It “provides a common framework that allows data to be shared and reused across application, enterprise and community boundaries”. Since we do not want to wait until artificial intelligence is capable of understanding web pages written for humans by humans at last, we assist the machines by supplying machine-readable metadata and semantic annotations8 . Foundations of the Semantic Web include [MvH04, chapter 1.2]: 8
“Instead of tackling the perhaps insurmountable artifical-intelligence problem of training machines to behave like people (‘greater AI’), the Semantic Web approach is to develop languages and protocols for expressing information in a form that can be processed by machines. This ‘lesser AI’ approach is transparent to the human users, yet brings information-space usability closer to the original and inclusive vision.” [Leu06]
4
2 Foundations
XML [BPSM+ 04] as a syntax for structured documents without explicit semantics. XML Schema [W3Cc] to define the syntactic structure of XML documents and to define data types9 . RDF — the Resource Description Framework [W3Ca] — to declare metadata and to assert relations between objects (“resources”) identified by URIs. RDF statements are subject–predicate–object triples, thus annotations in terms of definition 2.4.1. In terms of knowledge representation, they form the ABox (“assertional box”) of a knowledge base. RDF Schema (RDFS) — officially: RDF Vocabulary Description Language — [BG04] to describe hierarchies of classes (i.e. a taxonomy) of RDF resources and their properties in an RDF-compliant syntax. OWL — the Web Ontology Language [MvH04] (“ontology” is defined below) — a description logic10 approach to define relations between classes and to describe types and characteristics of properties. Inference rules can be defined as well. In terms of knowledge representation, both OWL and RDFS describe the TBox (“terminological box”) of a knowledge base. Like RDFS, OWL uses an extended RDF syntax. Query Languages like SPARQL (Simple Protocol and RDF Query Language [PS06]) to query data given as RDF triples. Web Services supplying information to user agents or to autonomous agents. Definition 2.2.1 (Ontology) An ontology, basically, defines a vocabulary of terms and the relations between them11 . It is a formal, “explicit specification of a [shared] conceptualization” [Gru93]. Usually, an ontology describes a specific domain; it is the result of a shared (social) understanding among experts in that domain.
2.2.1 RDF Notations and Libraries A collection of RDF triples forms a labeled, directed pseudo-graph. RDF is merely a data model, hence there are many notations for it: 9
There are other XML schema languages, such as DTD or RelaxNG. In the following, the lowercase spelling “schema” shall refer to arbitrary XML schemas, regardless of the actual language. 10 Description logic is a decidable subset of first-order predicate logic. The OWL-DL sublanguage corresponds to the description logic calculus SHOIN (D). The OWL-Lite sublanguage, which corresponds to the SHIF(D) description logic, is less expressive but easier to implement, whereas OWL-Full relaxes the constraints of description logics and thereby gets more expressive but loses decidability. 11 In knowledge representation, the term “ontology” often comprises the TBox as well as the ABox part of a knowledge base. Adhering to the definition given here and to the W3C’s separation of RDF for ABox knowledge and “ontology languages” like RDFS and OWL for TBox knowledge, I will continue to mainly use the term “ontology” for the TBox part of a knowledge base.
5
2 Foundations
RDF/XML [Bec04b] — the standard and most common representation — uses XML, making it suitable for data exchange, but hard to write by hand. RXR [Bec04a] (Regular XML RDF) is a cleaner alternative to RDF/XML, which is often criticized as clumsy and overly complicated. N-Triples [GB04] is a primitive plain-text notation, where each line forms one subject– predicate–object statement. It is a subset of N3. N3 [BL06] (Notation 3, not to be confused with N-Triples) is a compact plain-text notation intended to be read and written by humans. It allows statements to be grouped by subject or predicate, as in RDF/XML. N3 can express statements that are neither covered by RDF nor description logics, such as implications12 . Turtle [Bec06] (terse RDF triple language) is a variant of N3, cut back to RDF conformance. RDFa [AB06] annotates XHTML with embedded RDF triples. There are special libraries for handling RDF data and ontologies13 . Their central part is a so-called “triple store”, a database storing RDF triples. Simple query languages like SPARQL support querying for triples with a given subject, predicate, or object as well as operations on sets of triples. Reasoners that are based on description logics14 additionally take inference rules from ontologies into account, and hence support even more advanced queries.
2.2.2 Extracting RDF from XML As mentioned in the listing above, XML and RDF are two important foundations of the semantic web. XML per se does not carry any explicit semantics, so ways of extracting the implicit semantics — as, e.g., specified in a human-readable documentation of the respective XML document format — and making it explicit as an RDF ABox (possibly backed by an RDFS or OWL TBox) must be found. One of them is GRDDL (Gleaning Resource Descriptions from Dialects of Languages [HMC05, HM05]), a proposed W3C standard for associating arbitrary XML documents with a custom XSL transformation that generates RDF/XML from the XML: the RDF is extracted by a handwritten XSLT style sheet, referenced by a designated link from the XML schema or the XML document. 12
Implications can be expressed in RDF via reification, i.e. expressing statements about other statements by treating them as resources, but reasoning on reified statements is not supported by common reasoners. 13 One of the most popular is the Jena Semantic Web Framework for Java, see http://jena. sourceforge.net. 14 As, for example, RacerPro [HM03], FaCT++ [TH06], or Pellet [SPG+ 05]
6
2 Foundations
GRDDL has, however, been developed mostly with non-annotated XHTML and microformats15 in mind and employs the full power of XSLT16 for “scraping” semantics even from rather unstructured, possibly invalid, X(HT)ML sources. On the other hand, it can output arbitrary RDF/XML — valid or not — using terms from any vocabulary — consistent or not. In a more formal context, with a strict XML schema restricting the input and a limited ontology restricting the output17 , more formal approaches — with less expressivity but stronger constraints — are desirable. A standard for mapping an XML schema to an ontology and thus mapping XML instances to RDF has not yet emerged, but there is research towards it: Given Ontology, Implicit Mapping A very simple algorithm mapping XML to RDF triples, given an XML Schema and an RDFS ontology with corresponding names for elements and attributes, on the one hand, and classes and properties on the other hand, is described in [Kle02]. Given Ontology, Explicit Mapping WEESA is a powerful declarative language that defines a mapping from XML to RDF using classes and properties from a given OWL ontology. XPath18 is used to extract subjects, predicates and objects of RDF triples from the XML source [RGJ05]. As with GRDDL and XSLT, this allows for the structure of the resulting RDF to be entirely different from the structure of the XML input, admitting flexibility. Given Ontology, Constructed Mapping A heuristic algorithm that constructs a mapping from an XML Schema to a given OWL ontology with only an initial set of mappings from XML attributes to OWL datatype properties given is presented in [ABM05]. Simple Ontology Construction A simple, straightforward construction of a basic OWL ontology, which is suitable for manual rework, from a given XML Schema — or even from an XML Schema generated from an instance document, if no schema is available — is presented in [BA05].
2.3 Wikis Wiki was invented in 1994 by Ward Cunningham as “the simplest online database that could possibly work” [C+ 02]. A wiki is a web server application that allows users to browse, create and edit hyperlinked pages19 in a web browser, usually using a simple 15
a non-formal approach to semantically annotated XHTML — more lightweight than RDFa, but less generic and less expressive; see http://www.microformats.org 16 . . . which is a Turing-complete functional programming language capable of arbitrary transformations from XML to XML or text 17 This is the case with OMDoc, as we will see. 18 a simple query language for XML that is also employed by XSLT [CD99] 19 Some wikis use the term “topic” for a page. Encyclopedic wikis mostly use the term “article”. Some semantic wikis refer to pages as “concepts”, for one page usually describes one real-world concept.
7
2 Foundations
text syntax. In contrast to documents in most content management systems, wiki pages are accessible via an URL containing their title. A new page can be created by entering the URL of a non-existent page, or, preferably, by linking from an existent page to the page to be created. This link will then lead to an edit form. Usually, anyone is allowed to edit pages on a wiki, but access can as well be restricted to a work group — in corporate settings, for example. Other characteristics of wikis include permanent storage of old page versions (with facilities to display differences between two versions and to restore a certain version), notification about recent changes, a full-text search and, in most cases, a simple kind of user management. Due to their simplicity and flexibility, many use cases for wikis are possible, from content management to groupware to personal knowledge management. Wikis became established chiefly through their use for public and open community projects. The first public wiki, Cunningham’s WikiWikiWeb20 , started as a repository for know-how on design patterns and extreme programming21 , had grown to more than 30,000 pages by 2004. The biggest and most well-known wiki, however, is Wikipedia [Wikb], a project to create a free encyclopedia, started in 2001. By July 2006, Wikipedia has grown to more than three million pages in over 100 languages22 . The main advantages of wikis in general are openness, simplicity, as well as — thanks to hyperlinking — their incremental and organic structure23 . Considering open wikibased communities in special, up-to-dateness, principles of grassroots democracy — for example, when discussing about the bias of some page — and the motive of learning from each other come along24 . Several disadvantages of (non-semantic) wikis will be analyzed in section 2.4.1.
2.4 Semantic Wikis — Wikis for the Semantic Web A semantic wiki is a wiki with an “underlying model of the knowledge described in its pages” [Wik06g]. The concept of a semantic wiki, however, is not definitive as of 2006, for semantic wikis did not emerge until 200425 . Common semantic wikis, most of which are still research prototypes, combine the wiki principle with semantic web technologies.
2.4.1 Wiki Improvements Through Semantics The main disadvantage of (non-semantic) wikis is their lack of structure [Aum05]. One page is an arbitrary collection of data, not restricted to describing one concept26 . Secondly, “hyperlinks do not carry any semantics” [Aum05], so any organization of the 20
See http://c2.com/cgi/wiki See http://c2.com/cgi/wiki?PeopleProjectsAndPatterns 22 Of these, about 1.3 million pages are in English and 450,000 in German 23 See [C+ 06] for more 24 A survey of many well-known wiki communities and their characteristics can be found in [Lan05, chapter 5] 25 For an overview, see [VKS+ 06], or [ODM+ 06] 26 Restrictions can be established by social convention (see [Wik06i], for example), but not formally. 21
8
2 Foundations
pages must be done manually by creating additional hyperlinks and summary pages. Common extensions like page categories27 only solve part of these problems. Not only are wikis lacking semantic relations (expressed by hyperlinks) between pages, they are also lacking semantically annotated (meta-)data on individual pages. There are only rare ad-hoc solutions for the latter problem, like, for example, the metadata for personal biographies in the German Wikipedia [Voß05]. “Using Wikipedia currently means reading it” [VKV+ 06] — wikis badly need semantic annotations to be usable by machines or agents, not only by humans. Semantic wikis will even improve daily life for humans; the documentation of Semantic MediaWiki [K+ 06] mentions some use cases: • Lists (e.g. the twenty largest metropolitan areas in Spain) could be generated by querying the knowledge base instead of maintaining them by hand. • Searches will become more powerful. • Less categories will be needed; as with lists, many categories can be inferred from the knowledge base28 . • Different language versions (e.g. of Wikipedia) will become more consistent by sharing common data. • External semantic-web-aware applications can re-use the knowledge from the wiki (see section 2.4.4). Precursors of semantic wiki engines provided means for storing page-related metadata and tags and searching them29 . Most of today’s semantic wikis utilize formal languages known from the semantic web, such as RDF or OWL ontologies (see section 2.2) — “Where a regular wiki enables users to describe resources in natural language, a semantic wiki enables users to additionally describe resources in a formal language.” [ODM+ 06]. Their capabilities range from annotating pages and links with metadata to representing ontological concepts [Kie06, “The Semantic Wiki Idea”]. Actually, a sophisticated semantic wiki should offer many levels of knowledge representation [VO05, page 7].
2.4.2 Data Model of Semantic Wikis The first attempts to classify the different approaches of semantic wikis have been made in the run-up to the first workshop on semantic wikis in June 2006; preliminary results can be found in [ODM+ 06] and on the OntoWorld wiki site30 [Ont06b]. On the one 27
These are usually taxonomies built on “is-a” and subclass relations, denoted by a link-like syntax, where the link target is a special “category page”. 28 The list of asteroids named for people is mentioned as an example; see http://en.wikipedia.org/ wiki/Category:Asteroids_named_for_people. 29 XWiki (see page 50), for example 30 OntoWorld is both a wiki community about semantic wikis in general and a testbed for Semantic MediaWiki (section 5.1.2), one specific semantic wiki engine.
9
2 Foundations
hand, there are semantic wikis for different application areas: while some of them aim at personal knowledge management [VO05], others aim at global communities31 . On the other hand, there are different ways of annotating knowledge. An annotation can be defined as a quadruple [ODM+ 06]: Definition 2.4.1 (Annotation) An annotation A is a tuple (as , ap , ao , ac ), where as is the subject 32 of the annotation — the annotated data —, ao is the object of the annotation — the annotating data —, ap is the predicate 33 — the annotation relation, that defines the type of relationship between as and ao — and ac is the context 34 in which the annotation is made. The authors further define formal annotations as annotations with each of the four tuple components being a URI and semantic annotations as formal annotations with the predicate ap and the context ac being an ontological term (see definition 2.2.1) and ao conforming to an an ontological definition of ap — with respect to the range35 of ap or some other constraints. RDF is a natural way to express subject–predicate–object annotations; there are also RDF extensions supporting context. Most semantic wikis, Platypus [TCC04] being one of the first, regard one wiki page as the description of one concept from a real-world domain. Consequently, that concept is the subject of all annotations written on that page. In most cases, the page is identified with the concept it describes, while some wikis (e.g. SemperWiki) make a “representation distinction” between annotations having the concept as subject — and the page, on the other hand36 . Others, e.g. IkeWiki and Semantic MediaWiki, make a “lightweight” representation distinction by referring to a concept using a special URI, which is not identical with the URI of the wiki page. It is, however, not possible to annotate the wiki page itself (by using its URI) — this can only be done with external applications after the wiki’s knowledge base has been exported. A third group of semantic wikis, including Rhizome (see section 5.1.2) and Kaukolu, also supports marking up sections of pages as concepts37 . Most semantic wikis support annotating concepts with types38 and typed links39 . The object of an annotation is usually another concept. Consider a link from a wiki page 31
such as Semantic MediaWiki, designed for the upcoming “Semantic Wikipedia” [VKV+ 06] a resource in RDF terminology 33 a property in OWL terminology: an object property if ao is another resource, or a datatype property if ao is a literal 34 A context can, for example, indicate the provenance of an annotation, or a temporal or spatial scope of validity, e.g. “valid in Germany during the soccer world cup 2006”. 35 . . . in RDFS terminology 36 To understand, why, consider a “creation date” annotation on a page describing Wikipedia: does it mean that the page was created on that date, or does it mean that the concept (Wikipedia) was created on that date? 37 See the SWikiFeat:SubjectGranularity attribute on OntoWorld [Ont06a]. 38 categories in wiki terminology, classes assigned through annotations with the rdf:type predicate in OWL terminology 39 WWW researchers have been aware of the importance of typed links for a long time, see [BBM+ 96] or even [BL90, “The topology of the web of links”] 32
10
2 Foundations
about “Life, the Universe and Everything” to another page about Douglas Adams typed as “is author of”, where the isAuthorOf relation would usually be defined in an ontology (see definition 2.2.1)40 . Links can either be typed in the source code of a page (e.g. [[link type::link target]] in Semantic MediaWiki), or they are written like untyped links and typed through a separate user interface (as in IkeWiki)41 . Some semantic wikis, such as Semantic MediaWiki, also support annotations with literal objects42 , so that assertions like “The city of Bremen covers an area of 326.72 km2 ” get a machine-understandable meaning. Most semantic wikis that allow for more than just ad-hoc annotations expose their ontology to the (experienced) user, who can edit it using the wiki itself. Semantic MediaWiki, for example, keeps categories, relations and attributes in separate namespaces each and makes them editable as any concept page. For example, specifying a category on a category page expresses an rdfs:subClassOf relation [VK06]. Yet another kind of semantic wikis keep the knowledge base of concepts and relations entirely separate from the set of wiki pages and offer a separate ontology editor: COW [FGR+ 06] only allows for queries against the knowledge base to be embedded into wiki pages, while SweetWiki [BCG+ 06] allows wiki pages to be tagged with concepts from the ontology.
2.4.3 Navigation in Semantic Wikis Navigation in conventional wikis is done through inline links in the page content and through global special pages like the recent changes list, which are reachable through a navigation bar from anywhere in the wiki. If typed links, the wiki representation of RDF triples, are not defined as inline links, they must be displayed in a navigation box to be visible at all. If, on the other hand, there are only inline links, only their label is apparent to the reader of a rendered page, but not their type. Thus, it is useful to additionally summarize them in a navigation box. Most semantic wikis aim at facilitating the exploration of large datasets through faceted browsing [ODM+ 06]. A facet is an “orthogonal conceptual dimension of the data”, represented by an annotation predicate (see definition 2.4.1) in a semantic wiki. Usually, all typed links are summarized in a navigation box, where they are grouped by their predicate (see figure 2.1). So far, this has only been implemented for semantic wikis where one page describes one concept43 . The display of typed links on a navigation bar is context-dependent, where the context is the current page. Even more context-dependent links are displayed in some semantic 40
A relation from a standard ontology, which is possibly already included with the wiki, such as dc:creator from Dublin Core, could be used likewise. 41 IkeWiki can also create links that do not appear in the page source at all. The latter is advantageous for links that do not fit inside the human-readable text or for which the user does not want to first contrive a natural language sentence just to hold the link. 42 called attributes in Semantic MediaWiki 43 Kaukolu, which allows statements about different subjects on one page, also displays a navigation box, but it merely lists all statements instead of grouping them.
11
2 Foundations
Figure 2.1: Typed links in Semantic MediaWiki, inline and grouped by facets (example from [Ont06a]) wikis. SHAWN [Aum05], for example, shows links to other concepts of the same type, if a page has been typed. Context-dependent navigation links improve usability by answering the questions “Where am I?” and “Where can I go?”44 . If dynamic linking directly depends on the page contents editable by the user, as is the case with typed links, users are instantaneously gratified for contributing to the structure of the wiki by creating connections between concepts [Aum05, section 3.2].
2.4.4 Import and Export to and from the Semantic Web From the wiki point of view, semantic wikis are better wikis, as they formalize wiki content to make it more machine-understandable and thus better browseable and searchable. On the other hand, the need for semantic wikis can be justified from the semantic web point of view, as collaborative tools are needed to create and manage the knowledge that can be represented using semantic web technologies [TB06]. Therefore, semantic annotations in a wiki should be compatible with other semantic web applications by offering import and export of standard formats like RDF. Most semantic wikis use such formats natively and are capable of importing and exporting them: Rhizome (see section 5.1.2), for example, is built on RDF, and IkeWiki (see section 5.1.2) can even be used to build RDFS or OWL ontologies. In most cases, at least the export facility supports more than one notation of RDF (see section 2.2.1).
2.4.5 No Mathematical Semantic Wikis so far The above-mentioned extensions of wikis towards semantics, however, only deal with wiki text, not with mathematics. When a wiki allows for mathematical formulae embedded into pages, presentational-only TEX syntax is employed in most cases. Wikipedia 44
[Aum05, section 3.1], after [Nie99]. Breadcrumbs, answering the question “Where have I been?”, are also helpful, but already provided by the browser history in most cases.
12
2 Foundations
lists45 only one wiki engine that currently supports MathML on wiki pages, namely UniWakka46 , which, however, does not utilize the semantics of (Content) MathML.
2.5 Added-value Services and Web 2.0 The term “Web 2.0” denotes a new phase of development of the World Wide Web. While this term is rather used as a buzzword, some aspects of it can be considered definitive [O’R05]: Web 2.0 is intended as a platform for web services, a notion similar to that of the Semantic Web. The role of the user changes from either publishing static content or reading content published by others to participating in communities like wikis or the blogosphere, driven by so-called social software. The degree of participation ranges from rating content (like with friends in social networks) through tagging (like with social bookmarking, see below) and commenting (as with weblogs) up to editing content (as with wikis). The more users participate in a community, the more do its contents improve — spoken in terms of network theory: the organic graph connecting the individual resources gets denser. Improving the contents frequently does not even require additional effort from the users, for Web 2.0 applications “set inclusive defaults for aggregating user data and building value as a side-effect of ordinary use of the application” [O’R05]. To facilitate the use of applications, they usually feature rich user interfaces. Thanks to techniques like Ajax47 the behavior of web applications approaches that of desktop applications. Developers appreciate that many Web 2.0 applications offer web service interfaces. Thus, content becomes available for “remixing” by customized applications — provided that the contents have been made available under a “some rights reserved” license like Creative Commons [Cre06].
2.5.1 Social Bookmarking Social bookmarking is “the practice of saving bookmarks [of internet resources] to a public website and ‘tagging’ them with keywords.” [Lom05]48 The more users tag a certain resource, the higher a social bookmarking service will rank it. Since the keywords assigned to resources do not stem from a fixed taxonomy, arbitrary keywords can be used, which leads to a “folksonomy”, effectively expressing the users’ opinion about certain resources. On the other hand, this lack of formal rigor is a disadvantage of social bookmarking and social software in general, which can probably be overcome by integrating semantic web technologies and social software. 45
See http://en.wikipedia.org/wiki/List_of_wiki_software, last visited June 26, 2006 http://uniwakka.sourceforge.net 47 Asynchronous JavaScript and XML [Gar05], a technique to make web applications more responsive by implementing client-side scripts that exchange small amounts of data with the server in the background, i.e. asynchronously. 48 According to Wikipedia, social bookmarking also includes ranking of internet resources [Wik06h]. 46
13
2 Foundations
Figure 2.2: Graph on the integration of social software and semantic web [Spi06]
2.6 Mathematical Encyclopedias on the Web An encyclopedia “is a comprehensive written compendium that contains information on all branches of knowledge or a particular branch of knowledge” [Wik06f]. This section preferably covers open mathematical encyclopedias, but others will also be mentioned, as SWiM is intended to be a universal tool that is not exclusively targeted at open encyclopedias and, secondly, it can likely adopt certain technologies from any mathematical encyclopedia. Ideas to create an open encyclopedia49 on the WWW emerged in the 1990s for the first time. At least one of them has proven successful: Wikipedia [Wikb], whose articles have been acknowledged an — on average — high quality50 by several independent studies like that performed by Nature [Gil05]. Wikipedia proponents believe that this high quality has not developed despite the openness to anyone, but actually because of it. Although lacking a formal peer review system, Wikipedia articles are read by so many people that — in theory — any mistake will eventually be detected and fixed51 . Most closed-content52 projects (see section 2.6.2), however, stress the fact that they either 49
. . . where “open” means “open content”, i.e. content under a license that allows free redistribution and modification, such as the GFDL (see below). 50 See http://en.wikipedia.org/wiki/Wikipedia#Quality for an overview 51 Cf. Linus Torvalds’ law of open source software development, “Given enough eyeballs, all errors are shallow” [Ray99] 52 . . . as opposed to open content; this usually means that the content is freely readable, but not freely redistributable.
14
2 Foundations
only allow readers to submit comments (as the DLMF does) or that all contributions will be reviewed by editorial staff (as with MathWorld and the OEIS) in order to ensure high quality.
2.6.1 Open-content Projects Wiki-based Projects Since many wikis support TEX formulae (see page 12), is seems obvious to use a wiki for a mathematical encyclopedia. Under the umbrella of the Wikimedia Foundation, there are the mathematical sections of Wikipedia53 or the related Wikibooks project54 ; both use the MediaWiki engine, which has originally been developed for Wikipedia, and their contents are published under the GNU Free Documentation License55 . In July 2006 only few further wikis dedicated to mathematics are listed on WikiIndex, on its part a well-maintained wiki listing several thousands of public wikis, none of them being dedicated at mathematical knowledge in general: MathCircle56 , for example, aims at archiving mathematical problems and exercises from Russian “Math Circles” and “Math Schools”. It runs MathWiki, a derivative of Cunningham’s original WikiWikiWeb; a license has not been defined. WikiMath57 , whose largest language version, the German one, only comprises 32 articles until now, primarily focuses on mathematical exercises of interest to students and teachers. It is hosted by the free wiki hosting service Wikia, who also run MediaWiki, and uses the GNU Free Documentation License. None of those wikis, however, contains any explicit semantics apart from taxonomy in the form of categories. PlanetMath In 2006 the only open encyclopedia entirely dedicated to mathematics is PlanetMath58 , which has grown to more than 5,000 entries describing over 8,000 concepts since its creation in response to the temporary shut-down of MathWorld in 2001 (see section 2.6.2). All content is published under the GFDL. Noösphere, the collaborative software driving PlanetMath, although sometimes referred to as a wiki, differs from a wiki in several points: • The articles are not generally open for anyone to edit. Every page has an owner, who grants other users rights on his page by means of an access control list (ACL). 53
http://en.wikipedia.org/wiki/Portal:Mathematics http://en.wikibooks.org/wiki/Wikibooks:Mathematics_bookshelf 55 The GNU Free Documentation License (GFDL) [Fre02] is an open content license in the same “copyleft” spirit as the GNU General Public License (GPL) for software; both have been developed by the Free Software Foundation. Basically, the GFDL grants any reader of a work the right to copy, redistribute and modify it, provided that all copies and derivatives are made available under the same license. The “share-alike” licenses from Creative Commons are similar to the GFDL. 56 http://www.mathcircle.org 57 http://math.wikia.com/ 58 http://www.planetmath.org, see also [Kro03] 54
15
2 Foundations
In most cases, other users are only allowed to file requests for correction. Some users, however, allow “their” pages to be edited by any other registered user, as with a wiki. • The whole content of an article, not just the formulae, is written in LATEX, which can be rendered to HTML with images or to whole page images. Most links to other articles are set automatically by an elaborate algorithm, while LATEX commands for manual linking are provided as well. • Discussion forums are available for any article as well as for general topics. • Users are rated by their activity, much like in a web forum. While the LATEX part of an article does not allow for semantic annotations, there is a fixed set of metadata associated with every article. Those include type (definition, theorem, etc.), parent topic, Mathematics Subject Classification (MSC), synonyms and keywords. LATEX sources as well as metadata are searchable by a vector space full-text search engine.
2.6.2 Closed-content Projects MathWorld MathWorld 59 , sponsored by Wolfram Research since 1999, started as a personal collection of notes taken by Eric W. Weisstein and was first put online in 199560 . It covers all areas of mathematics in more than 12,000 entries in July 2006. The content is mostly stored as hyperlinked LATEX, with additional features, such as interactive graphics, powered by Wolfram’s Mathematica computer algebra software. It can be searched in full text and by browsing a category tree. Apart from Dublin Core metadata and Mathematics Subject Classification, there are no further annotations. MathWorld’s content is “free as in beer”61 . Comments on existing entries and contributions of new entries are appreciated, with all contributors being listed, but entries are not directly editable. The downside of contributing to a closed-content project became apparent when MathWorld was taken offline during a lawsuit62 from October 2000 to November 2001. During this time the content was not accessible, for it had not been permitted to copy and redistribute it otherwise. That gave the inspiration for the creation of PlanetMath: “MathWorld was the most direct catalyst for the development of PlanetMath and Noösphere, through its one-year absence from the Internet (which at the time was 59
http://mathworld.wolfram.com, see also the review in [Kro03, chapter 3.2.1] called “Eric’s Treasure Trove of Mathematics” then 61 a phrase made popular by Richard Stallman, founder of the Free Software Foundation, to distinguish non-freely-redistributable works from “copylefted” ones, which are “free as in speech”. 62 CRC Press, who had published Weisstein’s compilation in print and CD-ROM in 1998 sued Wolfram Research for publishing the MathWorld website, which they considered a violation of the 1998 contract; see http://mathworld.wolfram.com/docs/faq.html 60
16
2 Foundations
open-ended)” [Kro03]. Its creators intended to speedily recreate an extensive mathematical encyclopedia in a short time with a collaborative tool and to avoid the legal issues that resulted in the removal of MathWorld by using the GFDL. Digital Library of Mathematical Functions The NIST63 Digital Library of Mathematical Functions64 (DLMF) is intended to succeed the famous Handbook of Mathematical Functions [AS64] of 1964, “the reference of choice for applications of special functions” [Loz01]. According to [Loz01], it is intended to provide high quality contents about functions (as the Handbook did before): formulae, graphs, methods of computation, and references, further augmented by hyperlinks, interactive graphics and tables, and tools for downloading and searching, as well as user feedback forms. In contrast to an open encyclopedia, the contents of the DLMF will mainly be written by paid experts, and they will only be “free as in beer”. LATEX is used as data format. It is “the technology of choice for presentation of mathematics in print but it is not well suited to equation search” [Loz01] and other semantic applications — thus, LATEXML65 has been created, which consists of a TEX parser, an XML emitter, and a post-processing pipeline and “encourages a modestly semantic markup style” [MY03]66 that allows authors to focus on the mathematical contents while minimizing ambiguities. The DLMF markup will be less formal than that of OMDoc; employed annotations and metadata include links from formulae to proofs67 and to the definitions of symbols as well as data used for indexing. Complete semantic markup, which is desirable for integrating external tools like computer algebra systems, is planned for a later version. The On-Line Encyclopedia of Integer Sequences Like the DLMF, the Encyclopedia of Integer Sequences68 (OIES) started as a book (published in 1973 and 1995) and went online in 1995, after the author, Neil J. A. Sloane69 , had collected so many sequences and received so many submissions that the collection had become unmanageable in book form. It is rather a database than a document collection. In July 2006, it contains more than 120,000 lexicographically arranged sequences (proper integer sequences, but also sequences of fractions and digits of transcendental numbers), each with an ID number, an URL, 50 to 100 initial terms (if appropriate), name and description, references and external links, a formula and an algorithm in a programming language, keywords, a list of authors of the entry, and cross-references to related sequences. The database-like structure entails much implicit semantic information, which could easily be made explicit in terms of the semantic web, but annotations beyond the fields of a record are not possible, and the fields contain plain 63
[American] National Institute of Standards and Technology http://dlmf.nist.gov 65 http://dlmf.nist.gov/LaTeXML, see also [Mil04] 66 Consequently, it is also employed for the conversion from sTEX to OMDoc 2.1. 67 . . . which are mostly external resources, as the DLMF focuses on functions. 68 http://www.research.att.com/~njas/sequences/, see also [Slo03] 69 Sloane is supported by a board of associate editors since 2002. 64
17
2 Foundations
ASCII text only. The encyclopedia can be searched by keywords or by sub-sequences. An open-content license is not employed (i.e., the contents are “free as in beer”), but as with MathWorld, anyone is invited to contribute a new entry of to comment on an existing one and will be listed as contributor.
18
3 Requirements Analysis To develop a semantic wiki for OMDoc, it will first be necessary to define what makes OMDoc “semantic” and then to formalize the semantic information that is provided by the OMDoc-encoded mathematical concepts (and actually usable in a semantic wiki!) and by the user interaction logs (editing, rating, tagging, etc.). Next, it will be necessary to specify which additional information can be inferred from that, and finally, in which way this information will be utilized. Furtermore, a model for user interaction with the wiki — including Web-2.0-like added-value services — will be specified. The rest of this chapter contains a full requirements specification for an OMDoc wiki technology. Not all of them could be realized in the SWiM prototype in the course of a next to each section heading — if applicable six-month diploma thesis. A scale like — indicates how much of the requirements made in this section has approximately been implemented. Those requirements that remained unimplemented will be re-evaluated (see also chapter 6) and then realized during my PhD studies.
3.1 OMDoc Considered as an Ontology Language According to the definition of an ontology (see page 5), OMDoc can be regarded as an ontology language for mathematics. While, however, in most areas of the semantic web, resources (anything with an URI, for example XML fragments, described by RDF triples), are separated from their context (a vocabulary and background knowledge encoded in an ontology), the content resp. context1 markup language OMDoc can express both of them2 , using the above-mentioned three levels of formalization (see page 4). This turns collections of OMDoc documents into referentially closed systems (all the knowledge referred to, i.e. ABox and TBox, can be expressed in the system itself), which in turn allows ontological bootstrapping: the ontologies needed to draw inferences can be built up as we build up the data. Note that only part of the mathematical knowledge embedded in mathematical documents can be exploited for ontological reasoning3 , as it cannot faithfully be expressed in first-order logic (much less so in description logics or RDF). Consider for instance the following fragment from a math book: 1
All OMDoc statements must be made in proper context. The context is provided by theories and, syntactically, indicated by a certain content markup. 2 Consider the statements “all differentiable functions are continuous” (background knowledge) and “the derivative of the sine function, evaluated at 0, is 1” (assertion about resources): Both can be expressed as OMDoc statements. 3 For the sake of this argument we will use the term web ontology language synonymously with “description logics”, as in OWL-DL; if we pass to more expressive logics like KIF [Gea92] (first-order logic), we lose decidability and thus the raison d’être for web ontologies.
19
3 Requirements Analysis
Definition: f ∈ C 0 (R, R) , iff for all x, y ∈ R and > 0, there is a δ > 0, such that |f (x) − f (y)| < if |x − y| < δ. Definition: f ∈ C 0 (R, R) , iff for all x ∈ R and > 0, there are f 0 (x) and δ > 0, such |f (x)−fh(x+h)| − f 0 (x) < for h < δ. Examples: If f (x) := |x| and g(x) := 3x2 + 2x − π, then f ∈ C 0 (R, R) and g ∈ C 1 (R, R) , but f ∈ / C 1 (R, R) . Theorem: C 1 (R, R) ⊆ C 0 (R, R) Proof: Let f ∈ C 0 (R, R), x ∈ R and δ = > 0, then |f (x) − f (y)| ≤ h · |f (x)|. . .
Here, only the boxed fragments contain taxonomic information, which can easily be expressed in description logics. Its justifications via /δ arguments cannot be (simultaneously) expressed in description logics. Thus, any web ontology that deals with objects such as the ones above will necessarily have to approximate the underlying mathematical knowledge. Taxonomic relations are, however, only implicitly expressed in OMDoc: one can write statements (definitions, assertions, . . . ) about mathematical concepts, which, for example, state that one concept (e.g. the set C 1 (R, R) of differentiable functions) is a subset of another one (e.g. the set C 0 (R, R) of continuous functions). To explicitly reformulate the taxonomic information in description logics (and thus making them usable for semantic web applications), it would have to be extracted from OMDoc, which is non-trivial, because there are many ways to express taxonomic relations (e.g. as A ⊆ B, or as ∀x : x ∈ A ⇒ x ∈ B), and the semantics of the symbols used here (e.g. the universal quantifier) would have to be formalized in a machine-understandable way in some other OMDoc document. For the time being, a semantic wiki should thus confine itself to those semantic informations that can explicitly be expressed in OMDoc: those from the theory and statement level (see page 4), e.g. the import relation between theories. The concepts on these levels are statements about mathematical concepts, not mathematical concepts by themselves. An OMDoc system ontology — a formal description of OMDoc’s data model, not to be confused with ontologies in the domain of mathematics, which can be written in OMDoc — covering these levels will be presented in section 4.1. Providing description logics information about mathematical concepts like sets, functions, numbers, operators, etc. is future work, but would nevertheless be interesting for the integration of future semantic-web-aware computer algebra systems or theorem provers. Despite the above-mentioned limitations, it is useful for developing a semantic wiki for OMDoc to keep in mind that OMDoc is an ontology language. Thus, results from research in collaborative ontology editing with wikis or similar applications (such as pOWL [Aue05] or COW [FGR+ 06]) can be reused for SWiM.
3.1.1 What Makes an OMDoc Wiki Different? A wiki for OMDoc will be different from other semantic wikis in several aspects. First, the enhancements of the data model semantic wikis bring along — compared to con-
20
3 Requirements Analysis
ventional wikis — are already present in the OMDoc format, so that an OMDocbased wiki only needs to operationalize their underlying meaning. For example, typed links, which are implemented via an extension to the wiki syntax in Semantic MediaWiki [VKV+ 06] or editable through a separate editor in IkeWiki [Sch06], are implemented by means of the @for attribute4 to OMDoc’s XML elements (e.g. ). It remains left to the wiki to extract them, to visualize them adequately and to make them editable easily. The latter is in particular important because many OMDoc annotations are not optional5 , but required by the XML schema. While the @for attribute is optional in most cases, OMDoc’s equivalent of a type annotation is not, for the type of a statement is given by the name of its XML element, which must be present. Secondly, a semantic wiki targeted at mathematics must ensure that dependencies between concepts are preserved (see section 3.3.4). This is not the case with “low-level” semantic wikis that only support annotations and RDF statements. It is the case with wikis supporting ontology editing, but dependency preservation is even more important in the domain of mathematics, where logics of higher order are applied — even though they are not supported by the semantic wiki itself.
3.2 Data Model The smallest unit in a wiki that can be displayed, edited, linked to, or archived is a page6 . In a non-semantic wiki, one page is a document with arbitrary contents. In a semantic wiki, one page usually describes one concept. Concerning SWiM, we have to decide which OMDoc elements to regard as concepts. This decision has to be corroborated by ontological reasons (“What is a concept in mathematics and in OMDoc’s system ontology?”) and by reasons of wiki usability (pages should be small).
3.2.1 Ontological Requirements An OMDoc document usually contains at least one theory7 . There is no single kind of “mathematical concept”, but one could regard theories as concepts, as well as the statements they are composed of, such as definitions, assertions and proofs. (A subset of this system ontology of OMDoc has been modeled in OWL-DL, see section 4.1.) As our wiki shall be semantic, we will try to restrict one page to describing one concept. But what shall be selected to form a concept? — A theory or a statement? 4
In the following, XML attributes will be prepended by an @ sign (as in XPath) to distinguish them from elements. 5 In the original sense of the word, an annotation is an additional comment or margin note, but we adhere to the more general definition 2.4.1. 6 Editing of and linking to page sections is possible in some wikis, such as MediaWiki [Wik06d], but only in a limited way. 7 Actually, there are some kinds of OMDoc documents that contain no theory at all. These include presentation-only documents and master documents containing references to individual chapters or theories. Documents containing theories are prevailing, though.
21
3 Requirements Analysis
If we choose one theory to form a concept, one very important relation — the dependency relation formed by theory imports — can consistently be mapped to links between wiki pages. In contrast, a statement can be as small as the definition of a symbol, which often only receives semantics when used in axioms or assertions and hence does not form a self-contained concept. Moreover, dependencies between individual statements can become confusing: an example, for instance, does not exemplify a symbol alone, but a symbol’s definition along with some related statements: axioms defined for that symbol, sometimes even additional assertions on the symbol. If we grouped all of them into their own, compact theory and kept the example separate, the dependency relation would become easier to understand. Finally, it is still possible to express dependencies between individual statements — for example, between a proof and the assertion it proves —, even if theories are the base unit of modeling. On the other hand, arbitrarily large theories make it hard to model dependencies. If, for example, one and the same theory t included a definition of a group and a definition of a ring as an extension of a group, we could not model the fact that the definition of a ring depends on that of a group by a dependency between theories, for we could only express that the theory t depends on itself — a tautology. This example is problematic because “ring” and “group” are actually two different mathematical concepts. Hence, we should assure that theories only contain closely related statements lest they become merely loose collections of statements8 . Allowing both theories and statements as concepts (i.e. as wiki pages) will be a workable compromise, leaving it to the user to choose the appropriate granularity for a specific case. At any rate, “little theories”, which do not contain more statements than necessary, are desirable — not only for SWiM, but also from a mathematical point of view [FGT92]. Such theories shall only comprise a few interdependent constitutive statements like symbols, definitions and axioms. Non-constitutive statements9 depending on the constitutive ones shall be rolled out to separate documents. Note that this approach does not preclude concepts to be made up of (interdependent) subconcepts: for example, to introduce the natural numbers via the Peano axioms, we need to introduce the set of natural numbers, the number zero and the successor function at the same time. In summary, it will be necessary to formally specify OMDoc’s system ontology (preferably in description logics) and to encourage, if not force the wiki users to model little theories.
3.2.2 Requirements Imposed by Wiki Usability Wikis are more effective the smaller the pages are, as small pages facilitate editing and re-use by linking and allow for a better overview through lists of recent changes and other automatically generated index pages. Small pages can be accomplished by either rolling out all statements of a theory to individual pages, while the theory page remains 8 9
Imagine the extreme example of only one theory containing all statements in the knowledge base! Non-constitutive for theories are: all kinds of assertions (assertion element), their proofs (proof) alternative definitions (alternative) of concepts already defined, type assertions (type with @for attribute set) and examples (example) — see [Koh06, chapter 15.4]
22
3 Requirements Analysis
a scaffold with “include” references to the statement pages in the appropriate places, or by keeping a theory in whole on a page but encouraging the author to keep the theory as small as possible. The former case, using includes, is possible with OMDoc’s element (see also section 4.5.2), but it entails other problems: when viewing an old version of a page, the included pages must also be displayed in an old version, accordingly. But as the page and its includes can be edited (and thus versioned) independently, it is hard for the wiki to determine corresponding versions. Actually, there is not even an unambiguous solution, when the included page has been edited more than once between two subsequent edits of the including page. Wikis supporting includes currently solve this problem by completely ignoring it10 . The latter case, encouraging little theories, can be implemented with or without assistance by the software. While the wiki could automatically detect non-constitutive statements by validating against a tighter XML schema and suggest them to be rolled out to separate theories, I do not consider this necessary. As mentioned above, the wiki will become more maintainable with small theories anyway, so I consider the lack of assistance in this regard a feature rather than a bug.
3.2.3 Technical Requirement: Validity In any case, wiki pages should stay valid OMDoc XML documents. Validating XML documents after wiki users edited them assures a higher quality, and adhering to the OMDoc specification for the structure of documents facilitates the import and export of documents to and from the wiki (see section 3.6.1). If the OMDoc syntax has to be extended to adapt it to other requirements of the wiki, an extended OMDoc XML schema must be provided to keep documents validatable, and it must still be possible to normalize documents from the extended format to equivalent and valid standard OMDoc.
3.2.4 Discussion Pages and Proposed OMDoc Extensions Some wikis, such as MediaWiki, associate a discussion page with every wiki page — an idea, that shall be picked up for SWiM. The discussion page for an OMDoc concept shall provide an adequate space for questions, answers and discussions about this concept. First, the native wiki text format of the wiki to be used can be maintained for the discussion pages, but in addition, it is worth considering to extend OMDoc towards semantically annotated discussions by introducing new values for the @type attribute of the omtext element [Koh06, chapter 14.3], indicating certain kinds of discussion posts: “question”, “explanation”, “opinion”, “note” and so forth. Private annotations (for personal knowledge management) could be a further extension to the wiki. 10
See, for example, MediaWiki [Wik06c]
23
3 Requirements Analysis
3.2.5 Utilizable Semantic Information Not all knowledge encoded in OMDoc will directly be usable in SWiM: on the one hand, there is knowledge that is only implicitly expressed in OMDoc (see page 20) and thus cannot easily be extracted, on the other hand there is knowledge that is too finegrained for a wiki whose pages contain statements and theories, such as the structure of a single formula or the individual steps of a proof [Koh06, chapter 17.3]. We thus must define a restricted set of explicit knowledge SWiM shall operate on — namely relations between concepts (i.e. annotations with other concepts as their object) and metadata (i.e. annotations with literal objects).
Relations SWiM should take several kinds of semantic relations into account: first, there are basic relations provided by the OMDoc concepts. Then, there are basic relations given by the user interaction logs. Further, inferable relations can be defined as transitive closures of the former and as unions of OMDoc relations and interaction relations. An example of a relation inferred from basic relations between mathematical concepts only is the (transitive) dependency relation between concepts: on theory level, it is given by theory imports, while on statement level, it is expressed through @for attributes as in . Finally, there may be other useful relations that cannot be expressed in OMDoc itself, but which the authors should be able to express by manual annotations. The relations between mathematical concepts and those that can be inferred from them are defined in OMDoc’s system ontology; the others form an implicit system ontology of SWiM, which might rather be hard-coded than explicitly written down in a description logics language. Both of these system ontologies are fixed, except for improvements to SWiM’s code base, so they need not be editable by the user.
Metadata Furthermore, SWiM should allow the user to search and enter metadata associated with any wiki page. OMDoc allows for annotating documents and fragments of them with Dublin Core metadata [Koh06, chapter 12]. Part of them, such as the last editor and the last editing date of a page, are recorded by any wiki, while others, such as dc:description, should be made editable via a form (see also section 3.3.5).
3.3 User Interface and Interaction Model SWiM must enable the user to view pages, to navigate by activating hyperlinks and to edit pages.
24
3 Requirements Analysis
3.3.1 Rendering OMDoc pages should be presented to the user in a human-readable form, preferably XHTML plus Presentation MathML. Presentation MathML is favored over Content MathML because the latter is limited to K-14 mathematics (see section 2.1.1), while the symbol repertoire of the former is more extensive. Independently of SWiM, XSLT style sheets for transforming OMDoc to XHTML plus Presentation MathML are available (see section 4.5.2); it is obvious that they should be integrated into SWiM and tailored to its needs. The generated XHTML should contain inline hyperlinks to other pages where appropriate, for instance, from an example to the symbol or assertion it exemplifies. LATEX-generated images as in PlanetMath (section 2.6.1) or some wikis (section 2.4.5) is a second option, but it is less preferable, as the possibility of additional post-processing by other applications would be lost. As OMDoc documents need not contain human-readable sections denoted with omtext or human-readable comments to mathematical objects denoted with CMP, the output generated that way need not necessarily be meaningful. In order not to force authors to attach human-readable text to every page — after all, the knowledge base might be used to support a theorem prover, not to create a textbook! —, there should also be a source code view with lines indented, keywords highlighted and URIs displayed as hyperlinks. An intermediate view mode could render mathematical objects in the source code as formulae, as can be seen in the listings in [Koh06]11 . Those embedded formulae could be rendered as MathML or TEX.
3.3.2 Dynamic Navigation Links Navigation links must be generated consistent with the concept page c being displayed: a link to its discussion page and, most notably, links to pages related in some way. Links to other concepts shall be displayed on a navigation bar, grouped by their type (e.g. the “theory–imports–theory” relation). When a page consisting of several concepts is displayed, e.g. a theory containing multiple statements, links from individual statements to other concepts in the wiki do not belong to the concept displayed on page level. Hence, they should not be displayed on the navigation bar lest the user be confused12 , but instead, they could be rendered inline. If morphisms are used with theory imports, as is the case with the import from monoid to ring, which is used to define that a ring is a monoid w.r.t. multiplication13 , they could also be displayed. The triangle next to the link to monoid in figure 3.1 points out that a morphism has been specified, which will be displayed when the user clicks it. At least links to the pages related to c via relations from OMDoc’s system ontology are to be displayed on the navigation bar. Links to pages related to t via frequent joint 11
See, for example, listing 2.6 Actually, today’s implementations of semantic wikis that assume “one page = one concept” never display links between sub-page concepts in their navigation bars. 13 This morphism basically maps the monoid’s ◦ operator to the ring’s multiplication operator · and renames the identity element from e to 1. Actually, the import from group to ring needs a morphism as well, which has been left out here for simplification. 12
25
3 Requirements Analysis
Figure 3.1: Sketch of a theory page with navigation links, example after [Koh06, listing 18.4] editing (see page 40) could be displayed as well.
3.3.3 Interactively Navigating the Dependency Graph Not only shall the user be able to navigate along the dependency graph, he or she shall also be able to interact with the system14 : he15 should be asked whether he wants to explore the concepts required as dependencies in further detail. Consider the algebra example from the OMDoc specification [Koh06, figure 7.1]: Suppose that the user is currently reading a page about theory ring, which depends on group and monoid, with group importing monoid and monoid in turn depending on semigroup: ring
imports
group imports
imports
monoid imports semigroup Figure 3.2: A subgraph of a dependency graph In this case the wiki shall not only display navigation links to the direct dependencies group and monoid, but it shall also provide unobtrusive buttons that allow the user to 14 15
Context-defined interactivity is mentioned as a basic feature of the semantic web in [Leu06, section 3] I will continue to use the male form for all users, including women. See also page 74.
26
3 Requirements Analysis
give one of the following acknowledgements: No, thanks! “I already know group and monoid, please let me just read about ring.” Explain “Please show me group and monoid so that I can learn about ring’s prerequisites.” — group and monoid will be displayed. Each of them could be opened in a new window, but they could also be displayed in the current window in a serialized form, replacing ring. Explore “Please show me all prerequisites for ring.” (by computing the transitive closure of the dependency relation) — Analogously, all prerequisites (in our example, group, monoid and semigroup) could be opened in separate windows or serialized into one page. Suspend “I want to know about group and monoid, but only later.” — The system keeps a notice in the user’s profile that he wants to read group and monoid sometime. Reminder links to suspended concepts could be displayed in a separate navigation bar.
Figure 3.3: Sketch of the command buttons to navigate along the dependencies Not only the last case should be recorded — the others are interesting as well for social bookmarking (section 2.5.1). For example, if many users requested a concept c to be explained, the system could default to display not only the direct dependencies but also the level-two dependencies, for it seems that c is too difficult for only being explained shallowly. This behavior should nevertheless be customizable by the user, for such heuristics could always fail to guess what the user wants. Furthermore, the system should not only keep track of which concepts the user wants to be explained, but also which concepts the user has already learned. For each concept, a button shall be offered for telling the system “I have learned this”. Links to concepts learned could then be disabled or displayed in a more unobtrusive color than links to concepts that are new to the user.
27
3 Requirements Analysis
3.3.4 Preserving Dependencies on Editing So far, there has not been any approach to preserving dependencies between pages in a semantic wiki. Tracking dependencies and reasoning about them is an integral part of mathematical practice. Known results are often generalized to find the “real” dependencies, mathematical theories and books are rewritten to make dependencies minimal. Therefore, this problem cannot be neglected in a mathematical wiki. In the special case of OMDoc, where dependencies need not be formally verifiable when they have sufficient structural properties (see section 2.1.3), a dependency could formally be broken but seem intact to the system anyway. If a theory t depends on a theory t0 , which can be edited independently from t, we cannot exclude that modifying t0 breaks t because some definition in t0 required by t might have been changed fundamentally16 . To keep the knowledge base as consistent as possible, the wiki software must warn authors when they are about to break other theories through their ongoing editing of a theory.
3.3.5 User-friendly Editing In contrast to usual wiki text, OMDoc’s raw XML syntax is hard to edit because of its verbosity and the XML validity constraints. Therefore, SWiM must offer some assistance to the editor. There are several approaches to that, which can be combined: • Split documents into smaller parts • Use a separate editor for metadata; hide them from the default edit form • Offer a simplified syntax • Perform auto-completion on element names and (wiki-internal) link targets • Integrate external editors that offer assistance on their part Splitting Documents into Smaller Parts and Edit-in-place Even without further assistance, the user himself can split large documents into their individual concepts (section 3.2.1) and will be rewarded by the wiki becoming more usable (section 3.2.2). In some cases, even a single concept can be too large to edit, though — consider a complex proof. The wiki could facilitate editing such concepts by allowing to edit sections of pages. Some wikis, such as MediaWiki allow for editing paragraphs of pages in the same way as whole pages can be edited [Wik06d]. An even more user-friendly approach is made by the Edit-in-place interface of Rhaptos (see section 5.1.2) is a promising approach to editing XML documents with shallow structures17 . Edit-in-place18 is an Ajax-based editor — and therefore more responsive than It would be good style to copy t0 to a new theory with a different name, anyway. Currently, it is restricted to Rhaptos’ own CNXML format; see [HG05]. 18 http://cnx.org/help/EditingModules 16
17
28
3 Requirements Analysis
MediaWiki’s solution requiring a round-trip to the server to edit a section —, which can insert or edit several types of page sections: paragraphs, equations, lists and more. All sections are displayed in a near-WYSIWYG view, but clicking one of them replaces its view by a text area containing the XML source of only that section, while the rest of the page remains in WYSIWYG state. Three buttons are displayed below the text area: “Cancel”, “Save” and “Delete”, the latter two of which commit the editing transaction by sending an asynchronous request to the server. As OMDoc is more complex than CNXML, an adaptation of Edit-in-place should allow for hiding awkward sections of the OMDoc document to be edited. The wiki interface should focus on editing theories and their statements; so less frequently edited OMDoc elements like metadata (see section 3.2.5) could be hidden by default and left to a special editor (see below). That does, however, not mean that Edit-in-place should completely ignore metadata. Quite the contrary: if one section of a document has been edited, the Dublin Core metadata of the document or of the section could be updated with the current time stamp and the name of the author. While Edit-in-place can facilitate editing OMDoc on theory and statement level (see page 4), it is not helpful on the object level because. . . 1. Mathematical formulae are deeply nested in most cases, while “Edit in place” has been designed with shallow XML structures in mind. 2. There are shorter and more intuitive notations for formulae than OpenMath or Content MathML. Therefore, a simplified syntax should be offered for formulae (see below). Separate Metadata Editor Some wikis, such as IkeWiki (see section 5.1.2) offer an edit form for page metadata, which is separate from the page editor. Such a form could be used for OMDoc’s pagelevel metadata well. Simplified syntax SWiM should allow for editing mathematical objects in a simpler syntax than raw OpenMath or Content MathML. QMath19 , a batch processor that transforms plain text with a straightforward syntax to OMDoc, looks promising. QMath uses tables mapping text symbols to their OMDoc or OpenMath representation; these tables could also be made editable in a wiki. While QMath can be used for whole documents, which are then converted to OMDoc, its text syntax does not cover the whole complexity of OMDoc. Therefore, it is preferable to use OMDoc with QMath embedded only for the formulae in the wiki — a mode that is supported by QMath. Most likely, the wiki will keep mathematical objects entered in QMath in this format for usability reasons, only converting 19
http://www.matracas.net/qmath/, see also [Pal06a]
29
3 Requirements Analysis
Figure 3.4: The metadata editor in IkeWiki them to OMDoc when pages are exported to another application or transformed for presentation output using the OMDoc XSLT style sheets (see section 4.5.2). For the time being, an easy text input facility like QMath will be sufficient. There are several WYSIWYG editors for MathML in the market20 , but in most cases they are not available under an open source license, or they only generate Presentation MathML, while only Content MathML is allowed in OMDoc. When SWiM will be used in real-world projects, an import facility for legacy formats like TEX should also be taken into consideration. The same way as QMath can be used to facilitate the creation of mathematical formulae, wiki text syntax could be employed as a simple way to enter OMDoc’s rich text [Koh06, chapter 14.6]. Auto-completion Some semantic wikis feature auto-completion of link targets in the source editor. Kaukolu [Kie06], for example, offers ontology-driven suggestions for link targets in a box next to the editing box while the user is typing21 . SweetWiki [BCG+ 06] has a similar completion feature. One of these should be implemented into SWiM. (Semantic) auto-completion in OMDoc will be useful for link targets in particular. It requires Ajax for querying the RDF triple store interactively. For example, when the user entered
