1.1 --- a/doc/griesmayer/add-content.tex Thu Sep 25 13:21:28 2003 +0200
1.2 +++ b/doc/griesmayer/add-content.tex Sun Sep 28 22:08:37 2003 +0200
1.3 @@ -72,7 +72,7 @@
1.4
1.5
1.6 \section{The Knowledge Browser}
1.7 -
1.8 +\label{ADD:knowledge_browser}
1.9 A \isac\/-\emph{knowledge-browser} is used to enter the
1.10 \emph{knowledge} and gain informations about the content and use of
1.11 the special \isac\/ System. Although only HTTP-access is needed in the
1.12 @@ -252,8 +252,7 @@
1.13
1.14 The first point is obvious. A WebServer simply has to serve different
1.15 users. The second decision is necessary to enable the system to run
1.16 - differen BrowserFontends concurrently (e.g. to reduce server-load of
1.17 -%WN ...t BrowserFrontends
1.18 + different BrowserFrontends concurrently (e.g. to reduce server-load of
1.19 the WEB-server by using multiple WEB-servers which access the same
1.20 \isac\/-system or to allow a user to access different types of
1.21 Browser-Frontends --- WEB-based and a browser-shell ---
1.22 @@ -853,7 +852,7 @@
1.23 informations on the web\footnote{See also section \ref{metadata}}.
1.24 % A full set of used metadata is given in the SDD.
1.25
1.26 - \section{dialog}
1.27 + \section{The Dialog}
1.28
1.29 \label{ADD:dialog}
1.30
1.31 @@ -1185,7 +1184,7 @@
1.32 % \item $\Rightarrow$ XSLT-transformations
1.33 %\end{itemize}
1.34
1.35 - \subsection{KE-Objects and external Informations}
1.36 + \subsection{KE-Objects and external Informations} \label{ADD:xml}
1.37 \isac gets its math-descriptions out of the \emph{KE-Store}-module
1.38 which processes the stored informations and builds an
1.39 object-structure for the dialog to work with. The process of
2.1 --- a/doc/griesmayer/da_griesmayer.tex Thu Sep 25 13:21:28 2003 +0200
2.2 +++ b/doc/griesmayer/da_griesmayer.tex Sun Sep 28 22:08:37 2003 +0200
2.3 @@ -20,6 +20,7 @@
2.4 \def\sisac{{\small${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}}
2.5 \newcommand {\kommentar}[1]{\marginpar{\begin{flushright}\tiny#1\end{flushright}}}
2.6 \def\isac{{\small${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}}
2.7 +\def\lisac{{\LARGE${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}}
2.8 \newcommand {\frage}[1]{
2.9 \marginpar{
2.10 \begin{tabular}{p{5mm} p{2cm}}
2.11 @@ -37,6 +38,7 @@
2.12 }
2.13 \def\see{$\rightarrow$}
2.14
2.15 +\newcommand {\cnumber}[1]{\put(8,4){\circle{11}}\put(5,1){#1}\hspace{5mm}}
2.16
2.17 \ifx\undefined\pdfoutput
2.18 \typeout{(Formatting for DVI/PS)}
2.19 @@ -70,14 +72,15 @@
2.20
2.21 \chapter{Introduction}
2.22 \section{Initial Requirements}
2.23 -\subsection{isac}
2.24 -\paragraph{mathengine with full functionality and structured KB}
2.25 -\paragraph{high demands in interactivity on KB}
2.26 -\paragraph{no frontend}
2.27 -\subsection{Standalone Browser}
2.28 -\subsection{Course Administration}
2.29 -\subsection{Enhanced Knowledgebase}
2.30 -...KEStore...
2.31 +\include{isac-intro-eng}
2.32 +%\subsection{isac}
2.33 +%\paragraph{mathengine with full functionality and structured KB}
2.34 +%\paragraph{high demands in interactivity on KB}
2.35 +%\paragraph{no frontend}
2.36 +%\subsection{Standalone Browser}
2.37 +%\subsection{Course Administration}
2.38 +%\subsection{Enhanced Knowledgebase}
2.39 +%...KEStore...
2.40
2.41 \chapter{Technologies/Components}
2.42 \section{XML-Applications}
2.43 @@ -1021,166 +1024,11 @@
2.44 \input{sdd-content}
2.45
2.46 \chapter{implementation}
2.47 -\section{introduction}
2.48 -Part of my work on \sisac was to build an preliminary implementation
2.49 -of the \emph{BrowserServlet} and the modules which are necessary to
2.50 -make it work to show the internal communications while fulfilling the
2.51 -single actions.
2.52 +\label{impl}
2.53 +\input{implementation}
2.54
2.55 -At time of the implementation, there was no running java-version of
2.56 -\emph{dinopolis}. This led to a number of tradeoffs in communication-
2.57 -and security-matters.
2.58 -
2.59 -Instead of dinopolis, \emph{XML-RPC} \kommentar{referenz auf xml-rpc
2.60 - beschreibung einfuegen} -- a simple XML-based
2.61 -communication-protokoll -- was used for module-communication.
2.62 -
2.63 -\emph{XML-RPC} is sufficient for this first implementation of the
2.64 -system but instead of the possibility to transfer references to
2.65 -objects between modules, it needs an explicit marshalling of the
2.66 -objects content. This concernes objects like \emph{formulas} which we
2.67 -planned to transfer as object-references without to care about the
2.68 -representation within the inner modules.\kommentar{referenz zu
2.69 - passender stelle im ADD}
2.70 -
2.71 -The new protocol also changed the type of the returned informations.
2.72 -In section \ref{SSD-browser-servelet}, we talked about a returned
2.73 -\textbf{map} which carries the gathered informations. This was because
2.74 -of the better performance of a map in comparison to a to be parsed
2.75 -XML-file. Because all parameters and results are transferred as XML
2.76 -anyway, we dropped this internal representations in favour of pure
2.77 -XML-interfaces. \kommentar{im sdd die (gedroppted) maps noch genauer
2.78 - erklaeren}
2.79 -
2.80 -\section{BrowserServlet}
2.81 -An exemplary implementation of the BrowserServlet can be found in the
2.82 -java-package ``isac.BrowserServlet''. It handles only \emph{static
2.83 - browsing} and consists of following classes:
2.84 -\begin{description}
2.85 -\item[Encoder] transformes the XML-representation of
2.86 - \emph{KEObject}\/s and \emph{Hierarchy} to a HTML-representation
2.87 - using XSLT.
2.88 -\item[InformationProcessor] connects to the \emph{BrowserDialog} and
2.89 - fetches informations requested by the \emph{BrowserFrontend}.
2.90 -\item[LoadContent] Fetches KEObjects from the
2.91 - \emph{InformationProcessor} and returns them to the BrowserWindow
2.92 - after using the \emph{Encoder} to transform them to HTML.
2.93 -\item[LoadFile] Loads statical files without accessing the
2.94 - \emph{InformationProcessor}. The files are returned as they are
2.95 - without using the \emph{Encoder}. Examples for files accessed this
2.96 - way are the frameset and decorations like the footer.
2.97 -\item[LoadHierarchy] is responsible for all files which are necessary
2.98 - for the java-script tree which is used to present the hierarchy as
2.99 - there are
2.100 - \begin{itemize}
2.101 - \item java-scripts for ``Morten's JavaScript Tree Menu''
2.102 - (\emph{http://www.treemenu.com/})
2.103 - \item images
2.104 - \item \emph{code.html} which builds up the content of the hierarchy.
2.105 - It is composed of a statical part and a javascript part which is
2.106 - dynamically created from the XML-hierarchy using an XSL-stylesheet.
2.107 - The hierarchy is fetched from the \emph{InformationProcessor}
2.108 - \end{itemize}
2.109 -\item[Login]
2.110 - performes a login and stores the logininformations within the session
2.111 - \kommentar{erweitern auf kommunikation mit einfachem session-dialog}
2.112 -\item[Logout]
2.113 - logout of the user
2.114 -\end{description}
2.115 -
2.116 -\begin{figure} [htb]
2.117 -\centerline{\psfig{figure=fig/screenshot1.eps,width=11cm}}
2.118 -\caption{screenshot of the Problem-Browser}
2.119 -\label{fig:bs_screenshot}
2.120 -\end{figure}
2.121 -
2.122 -Figure \ref{fig:bs_screenshot} shows the screenshot of the
2.123 -BrowserServlets output. The output consist of a frameset with header,
2.124 -hierarchy-frame (left) and content-frame (right).
2.125 -
2.126 -The header gives informations about the login-state and links to
2.127 -choose between Problem- and Method-Browser. The hierarchy on the left
2.128 -utilizes ``Morten's JavaScript''\kommentar{referenz einfuegen} to
2.129 -display the ProblemHierarchy. The underlying JavaScript code is
2.130 -generated dynamically using XSL out of an XML-description which is
2.131 -gained from the \emph{BrowserDialog}.
2.132 -
2.133 -The content-frame on the right shows a very simple rendering of a
2.134 -problem (equation-univariate-root). The formulars are represented in
2.135 -the internal stringformat, the headings show their meaning. Again, XSL
2.136 -is used for creation of the HTML-code.
2.137 -
2.138 -The screenshot is very examplary because it relies on the frameset and
2.139 -the xsl stylesheets which are both not part of the java-code and easy
2.140 -to change.
2.141 -
2.142 -\subsection{tomcat}
2.143 - \kommentar{informationen ueber die konfiguration vom tomcat}
2.144 -\subsection{servlet}
2.145 - \kommentar{start des servlets/einbinden in eine tomcatinstallation}
2.146 -\section{BrowserDialog}
2.147 -Because there is no usermanagement and dialog-logic yet, the
2.148 -Browserdialog is reduced to the functions to fetch informations from
2.149 -the KEStore and filter fields if no user is logged in.
2.150 -
2.151 -Again, communication is done with XML-RPC. Filtering is performed with
2.152 -the \emph{xerces} XML-processor.
2.153 -
2.154 -\section{KEStore}
2.155 -Because the lack of a description of the aimed \emph{MoWGLI}
2.156 -document-format, the KEStore is reduced to serve the mathematical data
2.157 -which is exported from the \sisac\/s ME.
2.158 -
2.159 -KEStore accesses the informations -- hierarchy as well as the nodes --
2.160 -as XML-Files from the filesystem.
2.161 -
2.162 -\section{SessionDialog}
2.163 -The SessionDialog is the ``fixpoint'' within \isac to manage a users
2.164 -sessions and create connects between the arbitrary modules.
2.165 -
2.166 -\begin{description}
2.167 -\item[Handler] Is the abstract base-class to handle incoming XMLRPC
2.168 - calls which have to be forwarded to other modules like
2.169 - \emph{WorksheetDialog} or \emph{UserModel}. It implements
2.170 - \emph{XmlRpcHandler} to answer XmlRpc calls and provides methods to
2.171 - forward them to their destinations using java-reflection.
2.172 -
2.173 -\item[SessionDialog] class SessionDialog is the main part of the
2.174 - Session-Module. It listens on port 1050 for incoming XMLRPC connects
2.175 - to distribute the calls to the appropriate handlers.
2.176 -
2.177 -\item[UMHandler] manages creation and access to the
2.178 - \emph{UserModule}\/s of a \isac instance. Its derived from
2.179 - \emph{Handler} and uses its mechanism for communications after
2.180 - selecting the proper UserModel for a given session. Additionally,
2.181 - it provides a method to create and maintain new instances of the
2.182 - UserModel.
2.183 -
2.184 -\item[UserModel] Stub class to simulate the forwarding mechanisms of
2.185 - the SessionDialog
2.186 -
2.187 -\item[WSDHandler] manages the creation and access to the
2.188 - \emph{WSDialogs}. Unlike the \emph{UserModels}, there is more than
2.189 - one \emph{WSDialog} for a single session because a user can work on
2.190 - different calculations concurrently. Therefore the access to a
2.191 - WSDialog is not handled by the session-id but an own id.
2.192 -
2.193 -\item[WSDialog] Stub class to simulate the firwarding mechanisms of
2.194 - the SessionDialog.
2.195 -
2.196 -\end{description}
2.197 \chapter{summary}
2.198 -Computer added math-processing and ``computer-understandable''
2.199 -representation are areas in highly movement. While developing the
2.200 -system, a number of changes and additions where necessary or
2.201 -reasonable when new, related projects approached.
2.202 -
2.203 -While XML was only mentioned marginaly at begin of our work, it
2.204 -emerged to be one of the core technologies of our current design.
2.205 -
2.206 -Besides the general benefites ob XML, this evolution was resonable
2.207 -because of a number of projects to store and process and display
2.208 -mathematical data which use XML.
2.209 +\input{summary}
2.210
2.211 \appendix
2.212 %\chapter{terms}
3.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
3.2 +++ b/doc/griesmayer/implementation.tex Sun Sep 28 22:08:37 2003 +0200
3.3 @@ -0,0 +1,359 @@
3.4 +\section{introduction}
3.5 +\label{impl:introduction}
3.6 +Part of my work on \sisac was to build an preliminary implementation
3.7 +of the \emph{BrowserServlet} and the modules which are necessary to
3.8 +make it work to show the internal communications while fulfilling the
3.9 +single actions.
3.10 +
3.11 +At time of the implementation, there was no running java-version of
3.12 +\emph{dinopolis}. This led to a number of tradeoffs in communication-
3.13 +and security-matters.
3.14 +
3.15 +Instead of dinopolis, \emph{XML-RPC} \footnote{http://www.xmlrpc.com/}
3.16 + -- a simple XML-based communication-protocol -- was used for
3.17 + module-communication.
3.18 +
3.19 +\emph{XML-RPC} is sufficient for this first implementation of the
3.20 +system but instead of the possibility to transfer references to
3.21 +objects between modules, it needs an explicit marshalling of the
3.22 +objects content. This concernes objects like \emph{formulas} which we
3.23 +planned to transfer as object-references without to care about the
3.24 +representation within the inner modules.
3.25 +
3.26 +The new protocol also changed the type of the returned informations.
3.27 +In the design documents ADD and SDD, we talked about a returned
3.28 +\textbf{map} which carries the gathered informations. This was because
3.29 +of the better performance of a map in comparison to a to be parsed
3.30 +XML-file. Because all parameters and results are transferred as XML
3.31 +anyway, we dropped this internal representations in favour of pure
3.32 +XML-interfaces.
3.33 +
3.34 +\section{BrowserServlet} \label{impl:browser_servlet}
3.35 +An exemplary implementation of the BrowserServlet can be found in the
3.36 +java-package ``isac.BrowserServlet''. It implements the
3.37 +\emph{Knowledge Browser} as described in section
3.38 +\ref{ADD:knowledge_browser} and consists of following classes:
3.39 +\begin{description}
3.40 +\item[Encoder] transformes the XML-representation of
3.41 + \emph{KEObject}\/s and \emph{Hierarchy} to a HTML-representation
3.42 + using XSLT.
3.43 +\item[InformationProcessor] connects to the \emph{BrowserDialog} and
3.44 + fetches informations requested by the \emph{BrowserFrontend}.
3.45 +\item[LoadContent] Fetches KEObjects from the
3.46 + \emph{InformationProcessor} and returns them to the BrowserWindow
3.47 + after using the \emph{Encoder} to transform them to HTML.
3.48 +\item[LoadFile] Loads the files which make up the HTML-page. Among
3.49 + these, ther are the frameset, decorations like header and footer.
3.50 + The files are returned as they are without using the \emph{Encoder}.
3.51 + Besides the frameset, \emph{LoadFile} is also used to create and
3.52 + load all files which make up the hierarchies:
3.53 + \begin{itemize}
3.54 + \item java-scripts for ``Morten's JavaScript Tree Menu''
3.55 + \item images
3.56 + \item \emph{code.html} which builds up the content of the hierarchy.
3.57 + It is composed of a statical part and a javascript part which is
3.58 + dynamically created from the XML-hierarchy using an XSL-stylesheet.
3.59 + The hierarchy is fetched from the \emph{InformationProcessor}
3.60 + \end{itemize}
3.61 +\item[Login] performes a login and stores the logininformations within
3.62 + the session. The login is performed using the corresponding method
3.63 + of the \emph{SessionDialog}.
3.64 +\item[Logout]
3.65 + logout of the user
3.66 +\end{description}
3.67 +
3.68 +\begin{figure} [htb]
3.69 +\centerline{\psfig{figure=fig/screenshot1.eps,width=11cm}}
3.70 +\caption{screenshot of the Problem-Browser}
3.71 +\label{fig:bs_screenshot}
3.72 +\end{figure}
3.73 +
3.74 +Figure \ref{fig:bs_screenshot} shows the screenshot of the
3.75 +BrowserServlets output. The output consist of a frameset with header,
3.76 +hierarchy-frame (left) and content-frame (right).
3.77 +
3.78 +The header gives informations about the login-state and links to
3.79 +choose between Problem-, Method- and Example-Browser. The hierarchy on
3.80 +the left utilizes ``Morten's
3.81 +JavaScript''\footnote{http://www.treemenu.com/} to display the
3.82 +ProblemHierarchy. The underlying JavaScript code is generated
3.83 +dynamically using XSL out of an XML-description which is gained from
3.84 +the \emph{BrowserDialog}.
3.85 +
3.86 +The content-frame on the right shows a very simple rendering of a
3.87 +problem (equation-univariate-root). The formulars are represented in
3.88 +the internal stringformat, the headings show their meaning. Again, XSL
3.89 +is used for creation of the HTML-code.
3.90 +
3.91 +The screenshot is very examplary because it relies on the frameset and
3.92 +the xsl stylesheets which are both not part of the java-code and easy
3.93 +to change.
3.94 +
3.95 +\subsection{tomcat}
3.96 + \kommentar{informationen ueber die konfiguration vom tomcat}
3.97 +\subsection{servlet}
3.98 + \kommentar{start des servlets/einbinden in eine tomcatinstallation}
3.99 +
3.100 +\section{BrowserDialog}
3.101 +Because there is no usermanagement and dialog-logic yet, the
3.102 +Browserdialog is reduced to the functions to fetch informations from
3.103 +the KEStore and filter fields if no user is logged in.
3.104 +
3.105 +Again, communication is done with XML-RPC. Therefore the
3.106 +\emph{BrowserDialog} listenes on port 1040 for incoming requests.
3.107 +Filtering is performed with the \emph{xerces} XML-processor.
3.108 +
3.109 +Following services from the \emph{BrowserDialog} are accessible
3.110 +through XML-RPC:
3.111 +\begin{description}
3.112 +\item[loadBinary] is used to transfere data from the KEStore ``as
3.113 + is''. For instance images used in descriptions.
3.114 +\item[loadContent] loads content-items like examples and problems from
3.115 + the KEStore and filters them according to the users needs. The
3.116 + current implementation simply filters some fields if the user is not
3.117 + logged in. Future implementations will consult the user-model about
3.118 + a users properties and filter regarding didactical rules.
3.119 +\item[loadHierarchy] is the equivalent to \emph{loadContent} for
3.120 + hierarchies. The current implementation simply loads end returns a
3.121 + requested hierarchy from the KEStore while future implementations
3.122 + can filter or add some nodes.
3.123 +\end{description}
3.124 +
3.125 +\paragraph{example-communication with the BrowserDialog using python}
3.126 +
3.127 +\begin{verbatim}
3.128 +Python 2.2.2 (#1, Mar 17 2003, 15:17:58)
3.129 +[GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2
3.130 +Type "help", "copyright", "credits" or "license" for
3.131 +more information.
3.132 +>>> import xmlrpclib
3.133 +>>> bdserver = xmlrpclib.Server("http://localhost:1040")
3.134 +>>> bdserver.BDialog.loadHierarchy("", "exp")
3.135 +['<?xml version="1.0" encoding="UTF-8"?>\n<NODE>
3.136 + <ID> Examples </ID>
3.137 + <NODE>
3.138 + <ID> IsacCore </ID>
3.139 + <CONTENTREF> exp_IsacCore.xml </CONTENTREF>
3.140 + <NODE>
3.141 + <ID> Simplification </ID>
3.142 + <CONTENTREF> exp_IsacCore_Simplification.xml
3.143 + </CONTENTREF>
3.144 + </NODE>
3.145 + <NODE>
3.146 + <ID> Equations </ID>
3.147 + <CONTENTREF> exp_IsacCore_Equations.xml
3.148 + </CONTENTREF>
3.149 + </NODE>
3.150 + <NODE>
3.151 + <ID> Tests </ID>
3.152 + <CONTENTREF> </CONTENTREF>
3.153 + <NODE>
3.154 + <ID> solve_linear_as_rootpbl </ID>
3.155 + <EXAMPLE> exp_IsacCore_Tests_1a.xml </EXAMPLE>
3.156 + </NODE>
3.157 + <NODE>
3.158 + <ID> miniscript_with_mini-subpbl </ID>
3.159 + <EXAMPLE> exp_IsacCore_Tests_1b.xml </EXAMPLE>
3.160 + </NODE>
3.161 + <NODE>
3.162 + <ID> root-eq_and_subpbl_no_met_linear </ID>
3.163 + <EXAMPLE> exp_IsacCore_Tests_1c.xml </EXAMPLE>
3.164 + </NODE>
3.165 + <NODE>
3.166 + <ID> run_scripts_for_maximum-example </ID>
3.167 + <EXAMPLE> exp_IsacCore_Tests_7a.xml </EXAMPLE>
3.168 + </NODE>
3.169 + </NODE>
3.170 + </NODE>
3.171 + <NODE>
3.172 + <ID> Biology </ID>
3.173 + <CONTENTREF> exp_Biology.xml </CONTENTREF>
3.174 + </NODE>
3.175 + <NODE>
3.176 + <ID> Mechanics </ID>
3.177 + <CONTENTREF> exp_Mechanics.xml </CONTENTREF>
3.178 + </NODE>
3.179 + </NODE>']
3.180 +>>>
3.181 +\end{verbatim}
3.182 +
3.183 +The example demonstrates the initialization of XML-RPC within python
3.184 +and the call to fetch the example-hierarchy. The returned XML showes
3.185 +the current format of the hierarchy. Nested nodes with their name in
3.186 +$<$ID$>$ and the id of the corresponding XML-description within
3.187 +$<$CONTENTREF$>$.
3.188 +
3.189 +\section{KEStore}
3.190 +Because the lack of a description of the aimed \emph{MoWGLI}
3.191 +document-format, the KEStore is reduced to serve the mathematical data
3.192 +which is exported from the \sisac\/s ME.
3.193 +
3.194 +KEStore accesses the informations -- hierarchy as well as the nodes --
3.195 +as XML-Files from the filesystem. It offeres following services on
3.196 +port 1030 by the handler ``KEStore''.
3.197 +
3.198 +\begin{description}
3.199 +\item[loadBinary] loads and returns binary document from the
3.200 + filesystem ``as is''. The path to access the document is created
3.201 + using the information about type and id. The data is transfered as
3.202 + bytearray which is transported within the XML-RPC layer as BASE64
3.203 + encoding. (used to put binary data into a XML document)
3.204 +\item[loadContent] loads and returns ``KEObjects'' to the caller. In
3.205 + the current implementation, it simply takes the the XML-description
3.206 + from the filesystem and returnes it without change. Future
3.207 + implementations will be capable of assembling complex KEObjects out
3.208 + of a number of simpler pieces -- e.g.to construct a
3.209 + example-collection out of single Examples.
3.210 +\item[loadHierarchy] loads and returns hierarchy-objects to the
3.211 + caller. The current implementation simple takes the information from
3.212 + the filesystem and returns it without further interference. Future
3.213 + implementations will be able to create hierarchies out of
3.214 + course-descriptions and assigned pages.
3.215 +\end{description}
3.216 +
3.217 +\paragraph{example-communication with the BrowserDialog using python}
3.218 +\begin{verbatim}
3.219 +Python 2.2.2 (#1, Mar 17 2003, 15:17:58)
3.220 +[GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2
3.221 +Type "help", "copyright", "credits" or "license" for
3.222 +more information.
3.223 +>>> import xmlrpclib
3.224 +>>> kesserver = xmlrpclib.Server("http://localhost:1030")
3.225 +>>> kesserver.KEStore.loadContent("exp",
3.226 + "exp_IsacCore_Tests_1a.xml")
3.227 +['<?xml version="1.0" encoding="UTF-8"?>
3.228 +<EXAMPLE>
3.229 + <META> </META>
3.230 + <NO> 1a
3.231 + </NO>
3.232 + <DESCRIPTION>
3.233 + Solve
3.234 + <math xmlns="http://www.w3.org/1998/Math/MathML">
3.235 + <mrow>
3.236 + <mn>1</mn> <mo>+</mo>
3.237 + <mfenced open="(" close=")">
3.238 + -1
3.239 + </mfenced>
3.240 + <mn>2</mn> <mo>+</mo> <mi>x</mi>
3.241 + <mo>=</mo> <mn>0</mn>
3.242 + </mrow>
3.243 + </math>
3.244 + <p> some text.</p>
3.245 + </DESCRIPTION>
3.246 + <VARIANT>
3.247 + <FORMALIZATION>
3.248 + [...]
3.249 + </FORMALIZATION>
3.250 + <SPECIFICATION>
3.251 + <THEORY> "Test.thy" </THEORY>
3.252 + <PROBLEM>
3.253 + <KEY>
3.254 + [...]
3.255 + </KEY>
3.256 + </PROBLEM>
3.257 + <METHOD>
3.258 + <KEY>
3.259 + <ID> "Test" </ID>
3.260 + <ID> "solve_linear" </ID>
3.261 + </KEY>
3.262 + </METHOD>
3.263 + </SPECIFICATION>
3.264 + <HIDE> </HIDE>
3.265 + <DETAIL> </DETAIL>
3.266 + </VARIANT>
3.267 +</EXAMPLE>']
3.268 +>>>
3.269 +\end{verbatim}
3.270 +This -- slightly shortened -- output shows the communication with the
3.271 +KEStore while loading an example. The returned XML containes the
3.272 +formal description within $<$VARIANT$>$ as well as the informal one
3.273 +within $<$DESCRIPTION$>$. The informal text is the part which appears
3.274 +on the Browser-Window when the example is loaded -- the $<$VARIANT$>$
3.275 +is the interesting part for the WorkSheet because it marks up the
3.276 +example. Putting these two different views of the example together in
3.277 +one document is one of the main advantages of XML.
3.278 +
3.279 +\section{SessionDialog}
3.280 +The SessionDialog is the ``fixpoint'' within \isac to manage a users
3.281 +sessions and create connects between the arbitrary modules.
3.282 +
3.283 +It provides its services through three handler which listen on port
3.284 +1050.
3.285 +
3.286 +Services of the handler ``SDialog'' provide basic functions for login
3.287 +and session-management:
3.288 +\begin{description}
3.289 +\item[getUsername] returnes the username for a given sessionid. It is
3.290 + used by the Browser to display the name of the current logged in
3.291 + user.
3.292 +\item[login] performes a user-login. It takes username and password
3.293 + and returnes a sessionid. If a login is called twice without
3.294 + interleaving logout, the same session-id is returned.
3.295 +\item[openWSDialog] opens a new WSDialog for a given session. The
3.296 + WSDialog is initiated with the username to adjust its behaviour.
3.297 +\end{description}
3.298 +
3.299 +The handler ``WSDialog'' and ``UserModel'' take as first argument the
3.300 +ID of the session or WSDialog and then forward the request and the
3.301 +rest of the parameters to the corresponding WDDialog or UserModel.
3.302 +This means, that the handler calls methods of the respective classes
3.303 +without knowing their methods. This is done by using a mechanism
3.304 +called \emph{java-reflection}.
3.305 +
3.306 +This functionality is achieved using following classes:
3.307 +
3.308 +\begin{description}
3.309 +\item[Handler] Is the abstract base-class to handle incoming XMLRPC
3.310 + calls which have to be forwarded to other modules like
3.311 + \emph{WorksheetDialog} or \emph{UserModel}. It implements
3.312 + \emph{XmlRpcHandler} to answer XmlRpc calls and provides methods to
3.313 + forward them to their destinations using java-reflection.
3.314 +
3.315 +\item[SessionDialog] class SessionDialog is the main part of the
3.316 + Session-Module. It listens on port 1050 for incoming XMLRPC connects
3.317 + to distribute the calls to the appropriate handlers.
3.318 +
3.319 +\item[UMHandler] manages creation and access to the
3.320 + \emph{UserModule}\/s of a \isac instance. Its derived from
3.321 + \emph{Handler} and uses its mechanism for communications after
3.322 + selecting the proper UserModel for a given session. Additionally,
3.323 + it provides a method to create and maintain new instances of the
3.324 + UserModel.
3.325 +
3.326 +\item[UserModel] Stub class to simulate the forwarding mechanisms of
3.327 + the SessionDialog
3.328 +
3.329 +\item[WSDHandler] manages the creation and access to the
3.330 + \emph{WSDialogs}. Unlike the \emph{UserModels}, there is more than
3.331 + one \emph{WSDialog} for a single session because a user can work on
3.332 + different calculations concurrently. Therefore the access to a
3.333 + WSDialog is not handled by the session-id but an own id.
3.334 +
3.335 +\item[WSDialog] Stub class to simulate the firwarding mechanisms of
3.336 + the SessionDialog.
3.337 +
3.338 +\end{description}
3.339 +\paragraph{example-communication with the BrowserDialog using python}
3.340 +\begin{verbatim}
3.341 +Python 2.2.2 (#1, Mar 17 2003, 15:17:58)
3.342 +[GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2
3.343 +Type "help", "copyright", "credits" or "license" for
3.344 +more information.
3.345 +>>> import xmlrpclib
3.346 +>>> sdserver=xmlrpclib.Server("http://localhost:1050")
3.347 +>>> sdserver.SDialog.login("bobby", "bobby")
3.348 +['bobby0']
3.349 +>>> sdserver.UserModel.sayHello("bobby0")
3.350 +'Hello'
3.351 +>>> sdserver.SDialog.openWSDialog("bobby0")
3.352 +['bobby0_0']
3.353 +>>> sdserver.WSDialog.sayHello("bobby0_0")
3.354 +'Hello, i am a WSDialog for session bobby0'
3.355 +>>> sdserver.SDialog.getUsername("bobby0");
3.356 +'bobby'
3.357 +>>> sdserver.SDialog.login("jack", "jack");
3.358 +['jack1']
3.359 +>>> sdserver.SDialog.login("bobby", "bobby");
3.360 +['bobby0']
3.361 +>>>
3.362 +\end{verbatim}
4.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
4.2 +++ b/doc/griesmayer/isac-intro-eng.tex Sun Sep 28 22:08:37 2003 +0200
4.3 @@ -0,0 +1,186 @@
4.4 +%\documentclass[12pt,a4wide]{report}
4.5 +%\usepackage{latexsym}
4.6 +%\bibliographystyle{alpha}
4.7 +
4.8 +%\def\isac{${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}
4.9 +%\def\sisac{{\footnotesize${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}}
4.10 +
4.11 +%\begin{document}
4.12 +%\tableofcontents
4.13 +
4.14 +%\chapter{Introduction}
4.15 +
4.16 +The title of this thesis contains two terms related to highly active research and current developments: {\bf knowledge representation for math on the web} is just at the beginning. Driven by the demand for e-learning, authors of engineering courses (and others) request for the representation and for interactive handling of math formulae on web-browsers --- which still does not work at the time of writing this thesis. Also the requests for worldwide interchange of math knowledge is a driving force for standardization of math knowledge representation.
4.17 +
4.18 +The {\bf architecture of distributed multifunktional software} is another actual issue tackled by the development of 'content management systems', 'integrated learning platforms' and the like, and addressed by research on 'computer-supported cooperative work'.
4.19 +
4.20 +Both terms will be considered with respect to the construction of web-based math learning system. The construction is based on an existing system, \sisac. This system provides novel kinds of interactivity with the learner, and it provides a novel structure for the math knowledge base. \sisac s novel features give raise to specific requirements on both, architecture and knowledge representation. Thus it seems appropriate to give a survey on this system and the overall goals of the \sisac-project.
4.21 +
4.22 +%###################################################################
4.23 +\section{Survey on the \isac-project}
4.24 +%###################################################################
4.25 +
4.26 +%-------------------------------------------------------------------
4.27 +\subsection{Goals of the project}\label{5pkte}
4.28 +%-------------------------------------------------------------------
4.29 +The \sisac-project started about ten years ago; the aim was to make the state of the art in computer mathematics and in software technology available for learning math. The initial goals, in a keen formulation, were:
4.30 +\begin{enumerate}
4.31 +\item a software tool capable of automatically solving problems of applied math\label{auto-solve}
4.32 +\item automatic generation of user-guidance based on capability \ref{auto-solve}.
4.33 +\item The mechanically generated steps solving a problem should be similar to paper and pencil work.
4.34 +\end{enumerate}
4.35 +Such a system would generate learning opportunities of a wide range, from learning by observing the 'transparent' system at work, to active learning by indepently solving problems, where the learnig is guided by the systems feedback on the correctness of the step (and the capability of the system to suggest the subsequent step).
4.36 +
4.37 +The goals seem to be futuristic, but severl actual developments in computer mathematics will provide support on the way towards the goals, for instance 'single stepping' and 'logic frameworks' with separated (and thus 'transparent' human readable) knowledge bases.
4.38 +
4.39 +Details on the goals of \sisac{} are given below following \cite{visit-me-00}.
4.40 +
4.41 +\paragraph{Transparent knowledge base\\}
4.42 +The knowledge underlying a math software system should be human readable (represented by formulae in the traditional mathematical notation), in the same format as it is interpreted by the system.
4.43 +
4.44 +There is an old proposal \cite{bb:3d-math} for a 3-dimensional structure of math knowledge, which \sisac{} implements the first time:\\
4.45 +{\bf (1) Theories} capture the deductive structure of mathematics (axioms, definitions, theorems and respective proofs). \sisac{} uses the knowledge base of the theorem prover Isabelle \footnote{\tt http://isabelle.in.tum.de/library/HOL/index.html} in HOL \cite{Paulson:Isa94, Isa-obj}. This knowledge base already comprises almost all of math knowledge used in high-schools (and definitly more).\\
4.46 +{\bf (2) Problems} capture the aspect of applying math: solving a 'problem' is the task of constructing new objects from given ones, where the new objects have to met specific requirements. The objects are being described in the language (predicates, functions constants) as defined in the theories. Problems should be specified interactively by the user, and vaguely specified problems should be refined automatically by the systems.\\
4.47 +{\bf (3) Methods} describe the algorithms solving the problems. For describing the algorithms \sisac{} extends Isabelles HOL-language. The semantics of this language comprises the construction of a 'proof'-tree by tactics. The interpreter of the language suggests the tactics to the user, users are free to apply tactics of their own.
4.48 +
4.49 +\paragraph{Notion of 'correctness'\\}
4.50 +A math learning system should be capable of qualifying an input by the student as 'correct' or 'wrong'. In order to provide this capability, a math system needs strong foundations in logic and a rigorous framework (prerequisites not given, for instance, in presently available computer algebra systems).
4.51 +
4.52 +\sisac s formulae are the {\bf typed(!)} formulae of Isabelle/HOL, thus rejecting a large class of errors. And \sisac s problem solving process adheres to a solid structure: First the problem has to be described in a {\bf model} comprising all objects given and to be determined (\sisac{} may assist the user regarding the prepared problem hiearchy), then a {\bf specification} has to be provided, i.e. a triple (theory, problem, method) pointing into the 3-dimensional knowledge base. Entering the execution of a method is controlled by a {\bf guard}, and the steps promoting the calculation can only given by {\bf tactics} which construct a {\bf 'calculation'-tree} under rigoros control of \sisac.
4.53 +
4.54 +If an author has prepared a {\bf formalization} of an example (which contains the data for the model and a specification) \sisac{} can solve the problem automatically and also generate user-guidance mechanically.
4.55 +
4.56 +\paragraph{Stepwise formal reasoning\\}
4.57 +
4.58 +\paragraph{Transparent 'single stepping'\\}
4.59 +
4.60 +\paragraph{Extensibility and adaptability\\}
4.61 +
4.62 +%-------------------------------------------------------------------
4.63 +\subsection{Technical issues}\label{techn-aufg}
4.64 +%-------------------------------------------------------------------
4.65 +
4.66 +\begin{enumerate}
4.67 +\item{\bf Computer mathematics}
4.68 + \begin{enumerate}
4.69 + \item{\bf The definition of formal languages}\label{formale-sprachen}
4.70 +
4.71 + \item{\bf The structure of the knowledge base}\label{struktur-wissen}
4.72 +
4.73 + \item{\bf Meta-mathematical foundations}
4.74 +
4.75 + \item{\bf The contents of the knowledge base}\label{inhalt-wissen}
4.76 +
4.77 + \end{enumerate}
4.78 +
4.79 +\item{\bf Software technology}
4.80 + \begin{enumerate}
4.81 + \item{\bf The interpretation of the languages}\label{interpreter}
4.82 +
4.83 + \item{\bf The software architecture}\label{sw-architektur}
4.84 +
4.85 + \item{\bf A variety of implementation tasks}\label{implementation}
4.86 +
4.87 + \item{\bf The dialog design}\label{worksheet}
4.88 +
4.89 + \item{\bf The knowledge representation}\label{presentation}
4.90 +
4.91 + \item{\bf Mathematics on the web}
4.92 +
4.93 + \end{enumerate}
4.94 +
4.95 +\item{\bf Psychology of learning and didactics}
4.96 +
4.97 + \begin{enumerate}
4.98 + \item{\bf The user model}\label{usermodel}
4.99 +
4.100 + \item{\bf The dialog strategies}\label{dialog}
4.101 +
4.102 + \end{enumerate}
4.103 +\end{enumerate}
4.104 +
4.105 +
4.106 +%###################################################################
4.107 +\section{Locating the thesis within \isac}
4.108 +%###################################################################
4.109 +The thesis at hand is a subproject within the \sisac-project. At first the subproject is being located within the technical issues raised by the project as a whole, as described in subsection \ref{techn-aufg} p.\pageref{techn-aufg}. And secondly the expected contribution of the thesis to the general goals of \sisac{} will be specified.
4.110 +
4.111 +%-------------------------------------------------------------------
4.112 +\subsection{Location within the technical issues} \label{intro:goals}
4.113 +%-------------------------------------------------------------------
4.114 +The main concern of this thesis are issues of software technology. Computer mathematics is just touched by the issue of presentation of math, and for the work on didactics and psychology elementary prerequisites are provided.
4.115 +
4.116 +In the sequel all the points of subsection \ref{techn-aufg} are recalled for adding the issues specific to this thesis, the not relevant points are dropped.
4.117 +
4.118 +\begin{enumerate}
4.119 +\item{\bf Computer mathematics}
4.120 + \begin{enumerate}
4.121 +% \item{\bf The definition of formal languages}\label{formale-sprachen}
4.122 +% \item{\bf The structure of the knowledge base}\label{struktur-wissen}
4.123 +% \item{\bf Meta-mathematical foundations}
4.124 +
4.125 + \item{\bf The contents of the knowledge base}\label{inhalt-wissen} are already implemented to an extent (comprising simplification \cite{MG:thesis} and elementary equation solving \cite{richard:da}) which will allow a realistic demonstration of the appropriateness of the software architecture (efficiency etc.) and the usability of the components to be implemented within this thesis.
4.126 +
4.127 +This thesis is not concerned with adding any math content, but there shall be some 'explanations' for some groups for demonstration purposes.
4.128 + \end{enumerate}
4.129 +
4.130 +\item{\bf Software technology}
4.131 + \begin{enumerate}
4.132 +% \item{\bf The interpretation of the languages}\label{interpreter}
4.133 +
4.134 + \item{\bf The software architecture}\label{sw-architektur} of the \sisac-system is one of the main concerns of this thesis. The architectural design will have to locate the components of the massively distributed system, and will have to select the appropriate protocols for the communication between the components. A specific challenge will be the handling of different access of various users (admins, authors, students of different groups etc.)
4.135 +
4.136 +The design shall employ standard components (from Dinopolis, MoWGLI etc.) as much as possible.
4.137 +
4.138 + \item{\bf A variety of implementation tasks:}\label{implementation} This thesis is not expected to raise any issues concerning complicated algorithms or critical masses of data.
4.139 +
4.140 + \item{\bf The dialog design}\label{worksheet} shall be done in close co-operation with the designers and implementors of the worksheet and the worksheet-dialog. The learner will interact with worksheet and knowledge browsers at the same time; it will be a challenge to make these interactions such that the users will not get lost in the complexity of the matter and the tools they use.
4.141 +
4.142 +In this phase of development a detailed dialog design cannot be expected; rather the implementations concurrent to the elaboration of this thesis will provide the means to gain experience with the new kind of \sisac s functionality and knowledge base. The issue within this thesis is, however, to make the design general enough for later detailed design and implementation of the dialog (regarding different access-rights etc.).
4.143 +
4.144 + \item{\bf The knowledge representation}\label{presentation} is the other main concern. This thesis will decide for the basic formats; for this purpose it shall search the literature for content-standards of learning-sytems and of math-systems, select and document the most appropriate ones.
4.145 +
4.146 +The thesis also shall create the overall design of the tools accessing \sisac s 3-dimensional knowledge base and the example collection. It shall identify the basic tools and implement them in basic versions, and it shall identify other tools to be developed later.
4.147 +
4.148 + \item{\bf Mathematics on the web} and the display of math formulae are the most basic issue of knowledge representation, and it is not yet solved: Following the proposals of the MoWGLI-project, formulae are moved through the web in MathML-{\em content}-format, and just for display on the front-end the MathML-content will be transformed to MathML-{\em presentation}-format. The transformation if Isabelle's {\em typed} terms (with mix-fix notation~!) into MathML and vice versa is an open problem, not to be solved within this thesis.
4.149 +
4.150 +The design of the architecture will have to find a way how to implement the essential parts of \sisac s functionality {\em before} the 2-dimensional presentation of formulae is available. The calls for the XSLT-transformers, however, have to be provided in the overall architecture of the system (see \ref{sw-architektur} p.\pageref{sw-architektur}).
4.151 + \end{enumerate}
4.152 +
4.153 +\item{\bf Psychology of learning and didactics}
4.154 +
4.155 + \begin{enumerate}
4.156 + \item{\bf The user model:}\label{usermodel} As already mentioned, \sisac s development is in a phase to early for designing a detailed user model. The architectural design within this thesis, however, shall mark the calls for the components handling the user model; in particular, a history of user-interaction on the knowledge-base shall be implemented.
4.157 +
4.158 +% \item{\bf The dialog strategies}\label{dialog}
4.159 +
4.160 + \end{enumerate}
4.161 +\end{enumerate}
4.162 +
4.163 +
4.164 +%-------------------------------------------------------------------
4.165 +\subsection{Relation to the overall goals of the project}\label{ssec:BezuegeZurZielsetzung}
4.166 +%-------------------------------------------------------------------
4.167 +
4.168 +\paragraph{Transparent knowledge base\\}
4.169 +
4.170 +\paragraph{Notion of 'correctness'\\}
4.171 +
4.172 +\paragraph{Stepwise formal reasoning\\}
4.173 +
4.174 +\paragraph{Transparent 'single stepping'\\}
4.175 +
4.176 +\paragraph{Extensibility and adaptability\\}
4.177 +
4.178 +
4.179 +\section{Structure of the capters}
4.180 +%Die Kapitel der vorliegenden Diplomarbeit sind folgenderma\3en strukturiert: \dots
4.181 +
4.182 +\section{Prerequisites, terms, notation}
4.183 +\dots
4.184 +
4.185 +%\chapter{\dots}
4.186 +%\dots und jetzt gehts richtig los \dots
4.187 +
4.188 +%\bibliography{bib/didact,bib/math-eng,bib/dia-form,bib/RISC_2,bib/misc,bib/isac,bib/pl}
4.189 +%\end{document}
5.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
5.2 +++ b/doc/griesmayer/summary.tex Sun Sep 28 22:08:37 2003 +0200
5.3 @@ -0,0 +1,145 @@
5.4 +
5.5 +Computer added math-processing and ``computer-understandable''
5.6 +representation are areas in high movement. While developing the
5.7 +system, a number of changes and additions where necessary or
5.8 +reasonable when new, related projects approached.
5.9 +
5.10 +While XML was only mentioned marginaly at begin of our work, it
5.11 +emerged to be one of the core technologies of our current design.
5.12 +
5.13 +Besides the general benefites of XML, this evolution was reasonable
5.14 +because of a number of projects to store and process and display
5.15 +mathematical data which use XML.
5.16 +
5.17 +Another process of development was made towards the layered structure
5.18 +which dominates the current design and classifies the \isac\/-modules
5.19 +to the \emph{frontend}, \emph{dialog} and \emph{backend} layer.
5.20 +
5.21 +Early designes were already modularized but there were connections
5.22 +between some of the modules which are ommitted in the current version.
5.23 +
5.24 +\begin{figure} [htb]
5.25 +\centerline{\psfig{figure=fig/design.eps,width=11cm}}
5.26 +\caption{early design}
5.27 +\label{fig:early_design}
5.28 +\end{figure}
5.29 +
5.30 +Figure \ref{fig:early_design} shows communication paths between
5.31 +worksheet and webbrowser \cnumber{5} and between worksheet and
5.32 +knowledge-browser \cnumber{6} which are now routed through the
5.33 +dialog-layer (see also section \ref{ADD:dialog}, The Dialog).
5.34 +
5.35 +A reason for this layering was the ability to control and bias the
5.36 +information flow between all parts of \isac by the dialog.
5.37 +
5.38 +\section{achieved goals}
5.39 +This section will outline the goals and results of this thesis. The
5.40 +goals were given in section \ref{intro:goals}.
5.41 +
5.42 +\begin{enumerate}
5.43 +\item{\bf Computer mathematics}
5.44 + \begin{enumerate}
5.45 + \item{\bf The contents of the knowledge base}\label{inhalt-wissen}
5.46 + It was a big concern to visualize the already available and just
5.47 + added mathematical content of the knowledge base.
5.48 +
5.49 + Section \ref{ADD:ke_store} identified the different ``axes'' of
5.50 + the knowledge-base as well as ``external'' informations like
5.51 + examples and collections of examples as similar objects which can
5.52 + be represented and processed in an analogous way. This led to the
5.53 + introduction of \emph{KE-Objects} which carry virtualy all content
5.54 + of the \isac\/-system and to a homogenous design to process them.
5.55 +
5.56 + The procesing part of these objects within \isac{} is the
5.57 + \emph{Knowledge Browser} (section \ref{ADD:knowledge_browser})
5.58 + whose parts have been implemented to an amount to be able to
5.59 + visualize the content of the KB. The implementation is documented
5.60 + in section \ref{impl:browser_servlet}.
5.61 + \end{enumerate}
5.62 +
5.63 +\item{\bf Software technology}
5.64 + \begin{enumerate}
5.65 +% \item{\bf The interpretation of the languages}\label{interpreter}
5.66 +
5.67 + \item{\bf The software architecture}\label{sw-architektur} of the
5.68 + \sisac-system. \\
5.69 + We created an layered architecture and located the main modules
5.70 + for
5.71 + \begin{description}
5.72 + \item[user-interaction:] BrowserFrontend and Worksheet (GUI)
5.73 + \item[user-guidance:] The Dialog, consisting of the
5.74 + SessionDialog the handle user-logins and its sessions, and the
5.75 + peers for the frontend-applications, the WorksheetDialog and
5.76 + the BrowserDialog.
5.77 + \item[backend-modules:] MathEngine to process the calculations
5.78 + and KE-Store to hold the informations presented to the user.
5.79 + \end{description}
5.80 +
5.81 + These modules are described in section \ref{ADD}.
5.82 +
5.83 + As protocol, respectively dataformat on the ``borders'' of the
5.84 + system, an XML-format was chosen for in- and output (section
5.85 + \ref{ADD:xml}). Internally, a transfer of objects is suggested.
5.86 + Nevertheless the current implementation uses a XML-interface
5.87 + instead of object-passing. This is because of the designated
5.88 + middleware \emph{dinopolis} is not ready to use yet and described
5.89 + further in section \ref{impl:introduction}.
5.90 +
5.91 + Section \ref{ADD:user_admin} copes with the handling of the
5.92 + students and groups. This part has to be seen as proposal and is
5.93 + not implemented yet.
5.94 +
5.95 + \item{\bf A variety of implementation tasks:} The current
5.96 + implementation is able to show the content of the mathematical
5.97 + knowledge base. The implemented modules and a description of the
5.98 + implementation are described in section \ref{impl}
5.99 +
5.100 + \item{\bf The dialog design} is reduced to the stubs which are to be
5.101 + extended in future work. We identified the place to put didactical
5.102 + inteligence as filtering mechanisms inside the
5.103 + \emph{BrowserDialog}. Communication channels to the
5.104 + \emph{SessionDialog} which carries session- and userinformations
5.105 + are already established.
5.106 +
5.107 + \item{\bf The knowledge representation} was defined in section
5.108 + \ref{ADD:ke_store} by reviewing the main types of information to
5.109 + be stored. Fortunately, we managed to create an single object
5.110 + which is able to represent all necessary types. This enables us to
5.111 + keep the further design relatively simple. All three types of the
5.112 + knowledgebase as well as the examples can be accessed through the
5.113 + same interface. The final way of storing the informations is not
5.114 + available yet -- the current verion stores all informations in
5.115 + simple xml-files within the filesystem, future versions of the
5.116 + \emph{KE-Store} will store them in a finer granularity and most
5.117 + likely in a database. The mathematical content will be stored in
5.118 + an XML-format (see \emph{Mathematics on the web}).
5.119 +
5.120 + \item{\bf Mathematics on the web.} Nowadays, math on de web is done
5.121 + mostly through text as HTML and additional formulars as images.
5.122 + Because of the high effort for these publications, More complex
5.123 + documents have to be provided as external formats like PDF.
5.124 +
5.125 + To cope with this problem, a number of projects and standards
5.126 + emerged within the last years. The best known is probably MathML
5.127 + which is already well-supportet and responsible for
5.128 + formular-rendering within a WEB-Browser. Nevertheless, MathML is
5.129 + only the top of a number of ways to manage mathematical
5.130 + informations. Section \ref{xml_applications} copes with techniques
5.131 + to display and manage mathematics - not only on the web but
5.132 + through the whole system with an single format.
5.133 + \end{enumerate}
5.134 +
5.135 +\item{\bf Psychology of learning and didactics}
5.136 +
5.137 + \begin{enumerate}
5.138 + \item{\bf The user model:} In the current work, the usermodel is
5.139 + reduced to a stub which chall store the history of a users
5.140 + actions. The requirements are very vague and will emerge when the
5.141 + work on the didactical model is intensified.
5.142 +
5.143 +% \item{\bf The dialog strategies}\label{dialog}
5.144 +
5.145 + \end{enumerate}
5.146 +\end{enumerate}
5.147 +
5.148 +
6.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
6.2 +++ b/doc/griesmayer/terms.tex Sun Sep 28 22:08:37 2003 +0200
6.3 @@ -0,0 +1,109 @@
6.4 +\chapter{List of terms used in the \lisac-project}\label{app.terms}
6.5 +
6.6 +\begin{description}
6.7 +\item{\bf }
6.8 +\item{\bf Browser-Window (Browser-Window)}\label{browser-window} is the presentation of data generated by the \see browser, which also handles the http requests generated by the browser window. (The browser-window is that what usually is called a 'browser').
6.9 +\item{\bf Browser (Browser):}\label{browser} There are browsers for \see theories, \see problems, \see methods and \see examples. The browser generates the html-representation of the respective \see browser-window, and handles the respective http-requests.
6.10 +\item{\bf }
6.11 +\item{\bf Calculation (Rechengang)} leads from the \see description of an \see example via the \see modeling phase, the \see specification phase and the \see solving phase to the result.
6.12 +\item{\bf Calculator (Rechner)} is that part of the \see SML-kernel which does single steps of calculation without touching the \see proofstate.
6.13 +\item{\bf }
6.14 +\item{\bf Current formula (aktuelle Formel)} is the unique formula marked on the \see worksheet. If another item on the worksheet is marked, the formula closest (.. to be specified) to the marked item is the current formula.
6.15 +\item{\bf }
6.16 +\item{\bf Course admin (Kurs-Administrator)} is a person administering the use of \isac{} for learning within a group of \see learners.
6.17 +\item{\bf }
6.18 +\item{\bf Course designer (Kurs-Designer)} edits the \see example collection which can be solved by a given \see math knowledge base (edited by a \see mathematics author) and/or edits \see explanations within the \see math knowledge base.
6.19 +\item{\bf }
6.20 +\item{\bf Decorated knowledge (Erweitertes Mathematik-Wissen)} is the \see mathematics knowledge(base) plus \see explanations.
6.21 +\item{\bf Description (Beschreibung)} of an \see example consists of \see formulas, eventually of text and/or a figure. The \see modeling phase transforms the description into a \see model.
6.22 +\item{\bf }
6.23 +\item{\bf Dialog atom (Dialog-Atom)} is a predefined, minimal unit of interaction between the \see learner and \isac. These atoms are symmetrical w.r.t. the two dialog partners.
6.24 +\item{\bf Dialog pattern (Dialog-Muster)} is assembled from \see dialog atoms such that it can adapt to certain situations in a dialog, e.g. if the \see learner produces many errors. Dialog patterns are designed and implementd by a \see dialog author.
6.25 +\item{\bf Dialog mode (Dialog-Modus)} is assembled from \see dialog patterns and supports certain learning strategies, e.g. exploratory learning, written examniation etc. Dialog patterns are designed and implementd by a \see dialog author.
6.26 +\item{\bf Dialog profile (Diaolog-Profil)} defines certain \see dialog modes for examples in the example collection for a certain course. A dialog profile is defined by a \see course designer and set/reset for a specified duration during a course by the \see course admin.
6.27 +\item{\bf Dialog author (Dialog-Autor)} an expert in learning theory who adapts and extends the \see dialog guide.
6.28 +\item{\bf Dialog guide (Dialog-Komponente)} is a component of \isac{} which combines \see dialog atoms to dialog strategies in order to adapt \isac's behaviour to different user models and learning situations.
6.29 +\item{\bf }
6.30 +\item{\bf Example (Beispiel)} is a unit to be calculated and solved separated from others. In general, they are prepared by an author in an \see example collection. Within such a collection the example has a unique identifier.
6.31 +\item{\bf Example browser (Beispiels-Browser)} is an interactive representation of the \see example collection within the \see front-end.
6.32 +\item{\bf Example collection (Beispielsammlung)} contains \see examples, each of them consisting of formulas, of a hidden \see formalization and \see specification, and eventuallly of text and a figure.
6.33 +\item{\bf Example profile (Beispiels-Profil)} describes the structure of an\see example collection; this structure provides data for the \see dialog guide.
6.34 +\item{\bf }
6.35 +\item{\bf Explanation (Erkl\"arung)} is an optional addon (text, formulas, figures, movies, links, \see examples and any combination of these) to elements of the \see math knowledge base.
6.36 +\item{\bf }
6.37 +\item{\bf Formalization (Formalisierung)} contains the formulas in a minimal structure necessary for automated solving the example (together with a \see specification).
6.38 +\item{\bf }
6.39 +\item{\bf Formula (Formel)} consists of variables, constants and functions constants (for logical, algebraic etc. operators); all these parts, however are not yet structured as a (typed) \see term.
6.40 +\item{\bf }
6.41 +\item{\bf Front-end (Frontend)} consists of the \see worksheet, the \see theory browser, the \see problem browser, the \see method browser and the \see example browser.
6.42 +\item{\bf }
6.43 +\item{\bf Interpreter (Interpreter)} comprises the modules \see math engine, the \see calculator and \see dialog guide.
6.44 +\item{\bf }
6.45 +\item{\bf Isabelle} is the name of one of the most successful interactive theorem provers; Isabelle provides the \see theories containing the deductive part of \isac's knowledge base.
6.46 +\item{\bf }
6.47 +\item{\bf Item (Item)} of a \see model, which can be an input item (in the field 'given'), a precondition (in the field 'where'), an ouput item (in the field 'find') or a relation (in the field 'relate'). 'Given', 'find'and 'relate' may be input by the user, where 'where' is supplied by the system. An item consists of the \see item-description and the \see item-data.
6.48 +\item{\bf Item-data (Item-Daten)} are the formulas following the \see item-description.
6.49 +\item{\bf Item-description (Item-Beschreibung)} is an identifier heading each \see item in the fields 'given', 'find' and 'relate'. It indicates the kind of data to be input to the respective item by the users, serves typechecking of the data etc.
6.50 +\item{\bf }
6.51 +\item{\bf KE-base (KE-Basis)} is the \see decorated math-knowledge plus the \see example collection.
6.52 +\item{\bf }
6.53 +\item{\bf Kernel (SML-Kern)} comprises the \see interpreter and the \see knowledge base, all written in SML.
6.54 +\item{\bf }
6.55 +\item{\bf Knowledge base} \see mathematics knowledge base
6.56 +\item{\bf Knowledge browser} is one of the \see theory brosers, \see problem browser, \see method browser.
6.57 +\item{\bf }
6.58 +\item{\bf Learner (Lernender)} a user of \isac, who uses \isac{} for learning and exercising, i.e. who calculates \see examples by use of the \see math knowledge base.
6.59 +\item{\bf }
6.60 +\item{\bf Match (Matchen):} a \see model matches a \see problem, or not. This kind of matching is different from the matching-algorithm of symbolic computation: it checks if all \see items are input, and evaluates the predicates in 'where'.
6.61 +\item{\bf }
6.62 +\item{\bf Math engine (Mathematik-Maschine)} provides for all functions doing \see calculations: for applying \see tactics, for input \see formulas, for calculating resulting formulas, for proposing the next tactic, and for doing calculations automatically; it maintains a \see proofstate for each calculation.
6.63 +\item{\bf Mathematics author (Mathematik-Autor)} an expert in computer mathematics who adapts and extends the \see mathematics knowledge base.
6.64 +\item{\bf Mathematics knowledge base (Mathematische Wissensbasis)} is stored in three SML-datastructures, in an acyclic graph of \see theories, in a hierarchy of \see problems, and in a hierarchy of \see methods. It is extensible by \see math authors and can be both, read by \see learners and interpreted by \isac. See also \see decorated math-knowledge.
6.65 +\item{\bf }
6.66 +\item{\bf Method (Methode)} contains a \see script describing the algorithm for calculating the result, and a guard structured like a \see problem in order to inhibit inappropriate application of the script.
6.67 +\item{\bf Method browser (Methoden-Browser)}
6.68 +\item{\bf }
6.69 +\item{\bf Model (Modell)} consists of \see items. It \see matches a \see problem, or not.
6.70 +\item{\bf Model context (Modell-Kontext)} comprises all the information handled in the \see modeling phase as represented on the worksheet. This is at least one of the folloging items: a \see model (of a problem and/or of a method), a \see problem, a \see theory, a \see problem, a \see method.
6.71 +\item{\bf Modeling phase (Modellierungs-Phase)} is the initial phase in problem solving. In this phase either the system automatically transforms a \see formalization of an example into a \see model or the user inputs the \see items into the model.
6.72 +\item{\bf }
6.73 +\item{\bf Parsing (Parsen)} is the process of transforming an 'plain' formula into a typed term. Parsing requires the specification of a \see theory containing information about infix position of operators etc.
6.74 +\item{\bf }
6.75 +\item{\bf Problem browser (Problem-Browser)}
6.76 +\item{\bf Problem (Problem)} consists of patterns of items which can be \see matched with a \see model during the \see specification phase.
6.77 +\item{\bf }
6.78 +\item{\bf Proofstate (Beweiszustand)} is given by an internal prooftree (partially represented on the \see worksheet) and a \see current formula.
6.79 +\item{\bf }
6.80 +\item{\bf Rewriting (Rewriting)} transforms a formula into a new one by application of a \see theorem. \isac{} provides conditional as well as ordered rewriting.
6.81 +\item{\bf }
6.82 +\item{\bf Script (Skript)} describes the algorithm solving a particular problem; a script contains \see tactics, expressions for guiding the flow of evaluation, and eventually subproblems.
6.83 +\item{\bf }
6.84 +\item{\bf Selection-tool (Auswahls-Tool)} displays the contents of either the \see example collection, or the dependency graph of \see theories, or the hierarchy of \see problems, or the hierarchy of \see methods; and it allows to select a respective item for detailed display.
6.85 +\item{\bf }
6.86 +\item{\bf SML-kernel} \see kernel
6.87 +\item{\bf }
6.88 +\item{\bf Solving phase (L\"osungs-Phase)} is the final phase in problem solving, which generates the solution from the \see model and the \see specification; this phase may comprise all problem solving phases for one or more subproblems.
6.89 +\item{\bf }
6.90 +\item{\bf Specification (Spezifikation)} relates a \see model to the knowledge base while determining a \see theory, \see a problem and a \see method.
6.91 +\item{\bf Specification phase (Spezifikations-Phase} is the second phase in problem solving, which determines the \see theory, \see the problem and the \see method.
6.92 +\item{\bf }
6.93 +\item{\bf Step ((Rechen-) Schritt)} propagates a \see calculation and involves both partners once, i.e. the \see learner and the \see dialog guide. A step is represented by one of the \see dialog atoms.
6.94 +\item{\bf }
6.95 +\item{\bf Tactic (Taktik)} is applicable or not to the current \see formula within the current proofstate, and generates a new formula accordingly.
6.96 +\item{\bf }
6.97 +\item{\bf Term (Term)} is an Isabelle term (simple typed lambda calculus) generated from a \see formula by \see parsing.
6.98 +\item{\bf }
6.99 +\item{\bf Theorem (Theorem)} is a predicate proven true by \see Isabelle w.r.t. certain preconditions. Theorems are applied by \see rewriting.
6.100 +\item{\bf }
6.101 +\item{\bf Theory (Theorie)} is the part of the \see math knowledge base which defines (function) constants and axioms. Within a theory usually the related \see theorems are being proven by \see Isabelle and stored.
6.102 +\item{\bf Theory Browser (Theorie-Browser)}
6.103 +\item{\bf }
6.104 +\item{\bf User (Benutzer)} of \isac{} may be one of the following: \see visitor, \see learner, \see math author, \see dialog author, \see course designer, or \see course admin.
6.105 +\item{\bf }
6.106 +\item{\bf Visitor (Besucher)} a user of \isac, which occasionaly browses an \isac-site, i.e. the \see knowledge base and the \see example collection.
6.107 +\item{\bf }
6.108 +\item{\bf Worksheet (Arbeitsblatt)} contains the \see calculation of an \see example eventually leading to a result.
6.109 +\item{\bf }
6.110 +\item{\bf }
6.111 +\item{\bf }
6.112 +\end{description}
7.1 --- a/doc/griesmayer/titlepage.tex Thu Sep 25 13:21:28 2003 +0200
7.2 +++ b/doc/griesmayer/titlepage.tex Sun Sep 28 22:08:37 2003 +0200
7.3 @@ -8,7 +8,7 @@
7.4 \textbf{\LARGE{Architecture and Knowledge-Representation}} \\
7.5 %WN -''- -Representation
7.6 \medskip
7.7 - \textbf{\LARGE{of the Web-based Math-Learning-System \Large{\isac}} }
7.8 + \textbf{\LARGE{of the Web-based Math-Learning-System \lisac} }
7.9 %WN of the Web-based Math-Learning-System \isac
7.10 %WN ~~~~ ... das ist das Spezielle an Deiner DA !
7.11