Getting started¶

Welcome to Mumie, this is the starting point for people who are new to Mumie and will be involved in maintaining it. The most important concepts used in Mumie will be introduced.

What is Mumie?¶

To answer this question it is probably best to take a look at the Mumie website

Workspace and data flow¶

Data used in Mumie can be found in the following three different locations:

• svs repository
• Local
• Mumie Server

CVS repository
The CVS Repository is the centralised storing point for all #packages developed by the Mumie community. All members can browse through the repository and checkout any packages they wish or commit changes made to packages. Here are the details to connect to the CVS, for an account contact the Mumie team:

• repository path: https://svn.mumie.net
• type: ssh

Local
This is an easy one. This is the actual computer you will be working on with #MIAU. From this computer you will be connecting to the svn.

Mumie server
Once Mumie files are ready to be viewed by the outside world they can be put on the Mumie server. Mumie requires that a standard browser (such as Firefox) is used to display its contents. Files checked in to the Mumie server will never be deleted, a simple revision system is used to update existing files. A final point, the Mumie server has only one way traffic, you can send files to the server but can't retrieve them, use the svn for this. The Mumie test server for TU Delft can be found at https://www.mumie-hosting.net/tu-delft-test.

The figure shows the different locations together with arrows which indicate the flow of data. The following case scenario will describe how we can work with the given workspace.

Let us say we want to retrieve files from the svn (these files are contained in so called #packages), to do this we do a checkout from our svn repository. This downloads the selected files to our computer we are working on, the local computer. We can manipulate these files to our needs if necessary, once we are happy with the files they have to be converted so that the Mumie server is able to output the correct information. This conversion is done by the mmtex command and converts all TeX files to equivalent XML files. Before we upload our files to the server, we might want to see a preview of how the TeX files will look like. This can be accomplished by pressing the button Preview in MIAU. Once we are happy with the result of the preview it is time to upload them to the Mumie server. To do this we use the button Publish in MIAU.
This scenario gives an introduction on how files are handled when working with Mumie. A lot of information has been left out to keep the example simple.

Packages¶

As stated before, the svn repository is the centralised storing point for all Mumie files developed by the Mumie community. Files in the svn are contained in so called packages, where each package must conform to the Mumie package naming and structuring conventions. Mumie has three different kinds of packages:

• Content packages
• Teaching packages
• System packages

We are interested in the first two (bold marked) types that will be discussed here.

The first are packages containing all mathematical content in the form of small entities (math-lego blocks). These packages, referred to as content packages, belong to a specific mathematical field and to a certain institution. The package type, institution and maths field together form the name of the package and use the following convention, content_<institute>_<maths_field>. As an example, lets say TU Delft has a mathematical content package on linear algebra, the package name would now be, content_tud_linear_algebra.

The second type are packages that are needed for organisational matters, also referred to as teaching packages. They contain all files that are needed to make courses, course sections, users, etc. To do this it connects the lego blocks from the content package (the package described above) in the form of a blue print and displays this in a semantic net. The package type and institution together form the name of the package and use the following convention, teaching_<institute>. As and example, the teaching package for TU Delft has the following name, teaching_tud.

For now this is enough to know about packages, later on we will look how packages are related to the checkin tree.

Documents, pseudo documents and generic documents¶

Most of the files contained in packages are documents. Documents in Mumie are entities with textual or binary content. (An exception are the generic documents, which have no content. More on generic documents in a bit) Examples for documents are:

• theorems
• definitions
• images
• Java applets.

Besides ordinary documents, Mumie knows pseudo documents. These are entities which can be treated formally as documents, but are not documents in the actual sense of the term. Examples are:

• users
• user groups
• semesters.

A special kind of documents are the generic documents. They have no content of their own, but are placeholders for “real” (i.e., non-generic) documents. These placeholders may be implemented by different real documents in different contexts. Generic documents are a means to implement two concepts in Mumie: internationalisation and themes and are discussed at the end of this section.

Each document or pseudo document has a certain type and several meta-information. At the start of the section a few types have been mentioned, to take a look at the complete list of document types or meta-information look in the appendix.
Mumie has a simple build-in version control system for non-generic documents. If a document is checked-in for a second time, the former version it not replaced but saved. Thus, it is always possible to recover older versions.

Internationalisation and themes¶

Internationalization means that the same content is available in different languages. Mumie realizes this by generic documents which are implemented by real documents in different languages. The following figure illustrates this with a simple example:

The theme concept allows for different appearances of the same content. A theme represents a certain web layout style. Thus, the theme controls things like fonts, background colors, button shapes, etc. The theme concept is realized by the same mechanism that realizes internationalization: generic documents implemented by different real documents to adjust the theme.

Additional information on internationalisation and themes can be found in the appendix

Checkin tree¶

When a package is retrieved from the CVS it can be stored at any location on the computer. Keeping in mind that we would like to send documents to the Mumie server it would be good to have a place where all documents are organised together. As you might have guessed, such a place exists and it is called the checkin tree. The checkin tree has gone through some significant changes since the arrival of MIAU so the rest of the section only applies when using MIAU.

The checkin tree is a virtual tree structure referencing to all available packages in the workspace. Documents located in the checkin tree can be uploaded to the Mumie server. However before documents can be uploaded they have to be converted to XML files. The reason for this is that the Mumie server works with XML files to display its contents, whereas most of the original documents are Mumie-TeX files.\\
Working with documents and converting them is discussed in the [[..:guide:teacher:content]]

Checkin tree and package structure¶

Next we will take a look at the structure of the checkin tree. Because the checkin tree references to packages, the internal structure of the checkin tree closely resembles the structure of a package. In section mmm and mmm the structure of the checkin tree and package have been side by side.\\
The root of the checkin tree contains three sections namely content, org and system. At this point system is not of our interest so we will only be focussing on the content and org section.

content
This section refers to all available content packages. Content packages belong to a certain math field and institution, this math field is reflected by the underlying directories of the content section, see figure on below.
Text enclosed by <....> is variable whereas the rest is fixed. So <institution> could be tud (for TU Delft), <math_field> could be linear_algebra and the <field_taxonomy> could be multiple directories to define the <math_field>.

org
This section refers to all available teaching packages. Teaching packages belong to a certain institution. This is reflected by the the underlying directories of the org section, see
figure on below.

    <CHECKIN TREE>
    |- content 
    | |- <institution> 
    | | '- <math_field> 
    | |      |- <field_taxonomy> 
    | |      |- media 
    | |      | |- applets 
    | |      | '- images 
    | |      |- problems 
    | |      | '- correctors 
    | |     '-... 
    | '-... 
    |- org 
    | |- users 
    | |- user_groups 
    | |- <institution> 
    | | '- semester 
    | |    |-classes 
    | |    |-courses 
    | |    '- tutorials 
    | '-... 
    '- system

MIAU¶

MIAU stands for Mumie Integrated Authoring Tools and has been developed to simplify the working process with Mumie. All work can now be done in one program using various windows:

• CVS repository: this is the place to browse all available packages and retrieve where necessary. Packages retrieved from the CVS are visible in the 'Mumie packages' windows.
• Mumie packages: this window displays the physical structure of packages. From here you can easily update your changes to the CVS.
• Mumie checkin tree: here the virtual checkin tree is displayed. From here you can execute the mmcdk tools and send files to the Mumie server.
• Team synchronizing: if multiple people are working on the same file it is possible to view the difference between different versions of the same file.