Organization & Classification

Tree Structure

Rather than store DEMML™ content in a database - which would require more maintenance - the content is stored in a relatively simple hierarchical file folder structure (called the "Tree of Knowledge" for the time being). Every major subject is broken up into sub-topics and sub-sub-topics until the educational material is broken down into the smallest set of facts about something which make sense when grouped together but taken separately from other sets of facts. This set of facts, with it's accompanying set of explanations, questions, answers, etc. is called a "topic" in DEMML™. Each branch of the tree is a "Topic" even if it has sub-branches. Just as there is an introduction in every chapter of a textbook, those "parent" branches should be designed as introductions to all the topics under them. To accommodate content in various languages, the DEMML™ tree structure incorporates a new concept called "stem folders." Each branch/topic folder has one or more stem folders, one for each language. While a branch can have sub-branches, a stem folder can only hold content files. For a much more thorough explanation of the tree structure and the associated classification system, complete with diagrams, click here.

Classification

Each topic in the DEMML™ "Tree of Knowledge" is given a specific code number. These code numbers are designed so they also reflect the file-system path to the topic folder. This system of topic code numbers is called the DEMML™ Classification System (DEMCS). A unique system has been devised for assigning these code numbers so that additional topics can always be inserted into the tree without disturbing any other topics already in the tree. Using the DEMCS it is possible to provide a unique code - and thus a unique place in the tree - for every topic taught in our educations systems today, as well as easily incorporate any new topics that come along. The DEMCS is explained more fully starting here.

Because the tree structure and the classification system are so intrinsically linked, they are both described under the same section starting here.

Special Topics

Some topic folders will be reserved for specific kinds of topics. The first of these, called "Identification Topics," are a special group of topics designed exclusively to aid students in identifying some animal or plant species, type of mineral, or even model of car, out in the real world. Any branch of the "Tree of Knowledge" which contains topics about some thing or phenomenon for which it might be educationally beneficial for students to be able to identify, will have "Identification Topics" spread throughout its sub-branches. These special Identification Topics will be placed at various levels in the tree to hold content which describes the unique characteristics which separates that branch of the tree from its siblings. Because DEMML™ topics are folders, the Identification Topic folder for for any particular topic will be placed as a sub-folder within that topic. As one works farther out on the branches of the tree, the Identification Topics become more and more specific until they identify a single species, thing, or phenomenon. In this way, the multiple levels of Identification Topics form a kind of identification key similar to the ones some of us used to identify insects in high-school biology class. The basic structure of the Identification Topic content will be the same as any other topic. The difference is that the facts within an Identification Topic will focus on how to uniquely identify the thing discussed in its parent topic when found out in the real world.

Incorporating content from other sources

It is also possible for anyone to create content and distribute it on their own, outside of the normal DEMML™ distribution system. As long as it follows the DEMML™ standard for folder and content file structure, then that content can be used within the student's learning software just like official DEMML™ content. In order to avoid folder naming conflicts, those who create their own content should place it in a folder which is named according to the format: "@domain.tld" (without the quotes). For instance, XYZ corporation may own the xyz.com internet domain name. They want to distribute content about a topic which would normally fit under DEMCS code Q/A/154/9/c/c/. XYZ corp. would create their own sub-tree of content and place it all in a folder called @xyz.com. The TopicID for the @xyz.com folder would be "Q/A/154/9/c/c/@xyz.com." Students (or their software) would then place [email protected] folder in the .../Q/A/154/9/c/c/ folder on their local hard drive. In addition, all the ItemIDs, FactIDs and any other ID code (other than TopicIDs) used within the .../@xyz.com/ folder will have @xyz.com tacked onto the end of them to prevent possible naming conflicts within the topic structure. Individuals or departments within an organization can use their official organizational e-mail address, creating TopicIDs such as "Q/A/154/9/c/c/[email protected]" or "Q/A/154/9/c/c/[email protected]."

DEMML™ compatible software will know to merge (virtually, within it's internal database, not within the file system) all the content in the @xyz.com folder with the existing content in the DEMML™ topic folder according to the Topic IDs specified in XYZ corp's content files. If the TopicID includes the @xyz.com part (i.e. "Q/A/154/9/c/c/@xyz.com/k4/q") then the software will know to treat that topic as an entirely separate topic within the "Tree of Knowledge" tree structure. This technique should be used for content that is not normally taught within the normal education system, such as how to operate a specific machine made by this company. On the other hand, if the TopicID specified in one of XYZ corp's content files omits the @xyz.com part (i.e. "Q/A/154/9/c/c/k4/q") , then that content will be virtually-merged with the existing official DEMML™ content and treated as if it were in the specified DEMML™ topic folder. The content authors should take care to use only existing DEMML™ TopicIDs. (If they feel new official TopicIDs should be created to accommodate their content then content creators can contact DEMML.org™ and something can be worked out.) This virtually-merged content can refer to any existing official DEMML™ Items just as any other DEMML™ content can. However, no official DEMML™ content can refer to unofficial content as that would then require students to have the unofficial content in order to study the official content.

All of this unofficial content must be designated as "DEMML™ formatted" content. The phrases "DEMML™ approved," "DEMML™ vetted," "official DEMML™," or similar phrases cannot be used in association with this content. To do so would be a violation of the DEMML™ trademark. That said, external content is definitely encouraged. Teachers can create content and distribute it to their students without waiting for it to be officially vetted by other educators and distributed throughout the DEMML™ system. Companies can create content to train their employees in internal procedures and that content can be easily virtually-merged with the content those employees may already be studying from other sources. DEMML™ formatted content can be included on a CD sold with a book. The readers of the book can then virtually-merge that content into their existing database of DEMML™ content and study it using the same software they are already using.

It is even be possible for other organizations to create their own database of DEMML™ formatted content with their own classification and vetting systems. As long as they don't claim the content is official DEMML™ content and they don't indicate that the classification code is a DEMCS™ classification code, then everyone will be happy. It is my hope that lots of content will be created and used for all kinds of things. Since all this content will be in the same format, people can use the same software for learning everything they need to learn, whether it be for school, work, or personal edification. Then there can be true competition among the developers of both content and the software used to present it.

Content Files

Topic Structure

A Topic consists of a collection of items, all designed to teach that topic. Within each topic there are two main groups of items: The most important set of items are what DEMML™ calls "Facts" or "FactItems." A Topic should be comprised of the smallest set of facts about something which make sense when grouped together but taken separately from other sets of facts. With apologies to Albert Einstein, a topic should be as small as possible, but no smaller. A topic also consists of many other types of items containing content intended to explain, reinforce, and test knowledge, understanding, or ability to use those facts. Each item, then, is one small piece of educational content, coded to indicate it's role within a topic. Each individual Item does not necessarily need to be in a separate file. The ideal is to have sets of closely related items stored together in a file for easy transmission and access. Of course this means all the items in a file have to be about the same topic. For a full discussion of DEMML™'s topic structure click here.

Indexing Files

These files are merely the index.html files normally found in most any folder on most any web server, except in this case they are actually used for indexing. The index.html file will contain an index of all the DEMML™ Items within the topic as well as a list of all the subtopics under that topic. Hyperlinks will allow users to easily browse through the Tree of Knowledge at their leisure. Though these index files will not normally be included in the content that is copied into the user's DEMML™ folder structure on their local hard drives, they will appear in the folder structure on DEMML™ content servers. Whenever a new file is added to a topic folder - or any of the stem folders within that topic folder - then a background process running on the server will update the appropriate index.html file. A background process is used to perform the update only once per content file update rather than using a PHP script to generate a new index.html file for each individual user because the former is much more efficient. In addition, this technique makes it easy for anyone to download an entire branch of the tree, including sub-branches, and then browse that content at will using the static index.html files even when not connected to the internet. The background process will not be an internet connected process so as to avoid introducing additional vulnerability problems. Because each DEMML™ content server may have a different subset of the Tree of Knowledge, the index updating software will need to run on each server to create index.html files that are unique to that server. All content will still be available via that index.html file, however, some of the links may direct users to other servers for access to content that is not available on their local server.

In the future, these index.html files will contain JavaScript code to enhance the user's content browsing experience. Users will be able to filter content based on any of the metadata within that content as well as find alternative explanations to selected facts or other items. Though the JavaScript code will not allow use of the web site as if it were DEMML™ software, these index.html files will provide many user's first exposure to DEMML™ content and will hopefully prompt them to install DEMML™ compatible software on their own computer.

Other DEMML™ Documents

DEMML™ is about more than just storing and organizing educational material. It is about using that content to actually learn something. And while the ability to browse through the entire Tree of Knowledge is handy, one could easily get lost in there without a guide. Just as in a regular classroom, syllabuses and lesson plans provide those necessary guides. Neither of these two documents contain any educational content themselves. They merely list DEMML™ Topics, Facts, and other Items that the student should study.

Both DEMML™ syllabuses and lesson plans can be easily built up by simply choosing topics, facts, and items from the hierarchical list of content contained within the "Tree of Knowledge." Software will be written that assists the teacher by filtering and sorting content based on the metadata mentioned above. So, if a teacher wants to find content that facilitates the "Understanding" level in Bloom's Taxonomy, follows a certain thread, and avoids content that has certain difficult prerequisites, then those will be made available for the teacher to choose from when building their lesson plan or syllabus. It sure beats searching the internet for hours on end, painstakingly evaluating everything personally, and then piecing at all back together again, now doesn't it?

Once created, a DEMML™ syllabus or lesson plan will be loaded into the student's DEMML™ compatible software. That software will check what content the user already has on their system and download what the student doesn't already have. In keeping with the No-Internet-Connection-Required rule, that "download" may consist of a request for the content to be transferred via the Intelligent Epidemic Routing Protocol. If the student happens to have loaded the syllabus and the content at the same time then the software will just use what was just loaded unless the student has special needs. In which case, the software will determine what other content the student will need based on what that software already knows about the student's current knowledge and learning abilities.

Syllabus

A syllabus is simply a list of things a student needs to learn for a given course of study. The same is true for both regular school-work and for DEMML™. In DEMML™, though, a syllabus contains just a bit more detailed information. It is an XML file that lists the specific facts within all the various topics that a student needs to know. It also indicates how well the student should know that material and when they should know it. It is possible to specify that a student should have a cursory understanding by the date of the lecture but that they must master it by the date of the test. It is even possible to indicate that the students are allowed to neglect some of it for the final, but what teacher is going to do that?

Multiple syllabuses can be loaded into the learning software to give the student an overall picture of all the things they currently need to learn and/or know. When a student feels that they no longer need to retain the knowledge listed in a syllabus, they can simply delete that syllabus from their system. The software will no longer use spaced repetition to ensure the student remembers any of those facts. Additional syllabuses can be pre-loaded for future classes. The software can use the prerequisites for all the items in those pre-loaded syllabuses as an additional list of things that the student should not be allowed to forget. This way, students won't be showing up for Physics class having completely forgotten all the calculus that they learned two semesters ago - or two years ago. Finally, people can create their own personal syllabus of things they want to remember for any designated time period, even the rest of their life.

In addition, each DEMML™ Topic folder will contain a set of mini-syllabuses - called "Default Syllabuses" - indicating what someone should know about that topic - and how well - in order to be considered a novice, intermediate, expert, or guru in that particular topic. When a Topic's Default Syllabus refers to a sub-topic then the Default Syllabus for that sub-topic will be "rolled up" into the requirements for a student to be considered knowledgeable in the parent topic. For instance, if the "expert syllabus" in the Topic folder for Algebra says that one should be 90% proficient in Trigonometry, then software would read the "expert syllabus" in the Trigonometry folder, calculate 90% of all the proficiency requirements listed there for Trigonometry topics, recursively working farther out on the tree till the expected proficiency for those sub-sub-sub-...-topics is zero. Of course this is a simplified example. The syllabus for Algebra would most likely refer to several specific sub-topics within the main Trigonometry subject rather than refer to the Trigonometry topic directly. In this way, one would not be expected to know everything there is to know about a subject in order to be considered an expert in that overall subject. These "Default Syllabuses" will be created in cooperation with academic organizations who specialize in the related topic.

Lesson Plan

While a syllabus is a list of certain facts that need to be learned, a lesson plan, in contrast, is a list of the exact items that must be presented to the student in a specified order. The teacher chooses the exact explanations that the student must read and the exact questions that the student must answer. Nothing prevents the student from reading other explanations or doing other problems. But the student must at least go through the ones specified by the teacher. This is provided for those "old school" teachers who cannot give up control over what content their students are exposed to. It can also be used to create a common foundation for discussion among students.

To reiterate: There is absolutely no actual content contained within a syllabus or a lesson plan. They are merely lists of topic and item codes that specify which content the user's software should download. The actual "items" of content are then separately transferred onto the student's computer for the software to present to the student as necessary. Though a syllabus specifies the topics a student should learn, it does not specify the exact content to download. That is determined by the student's individual DEMML™ compatible software based on the student's individual learning history. This is only possible because of the highly granular nature of DEMML™ content. Additionally, although a lesson plan does specify exact content to present, if that content does not meet the needs of the student then the software or the student can always choose to download additional content about that very specific topic or fact. Plus, instead of searching all over the internet for that additional information, all the student has to do is click one button in their software and instantly be presented with a list of appropriate alternatives.

In contrast to syllabuses and lesson plans which provide students a guide as to where to go, Progress and Historical Records show how well a student is doing and exactly where they have been.

Student Progress Record

The student progress record is like an incredibly detailed grade book. It tracks exactly how well a student knows each and every topic and fact they are currently studying. However, instead of recording only a grade or percentage, the DEMML™ progress record stores a set of variables based on Wayne Wickelgren's "Power Law for Forgetting Curves" which accurately describe the student's forgetting curve for that particular fact. A forgetting curve shows not only how well someone knows something now, but also how fast they are likely to forget it in the future. This information can be used by spaced repetition algorithms to predict the best time to review each fact or concept for best retention. Though software developers can store this information any way they choose within their software, this schema will provide a guide as to what must be stored as well as a format for exporting and importing this data so users will be able to switch to different software if they like.

Historical Record

If a student chooses to "opt in" their software will store a history of their every interaction with the DEMML™ content. It will record when they first start on a topic, which explanations they choose, what Items are used for quiz and review, and when as well as the student's responses. It will track how their forgetting curves change with each repetition of the material. This data will then be uploaded and added to a gigantic database for education researchers to analyze for information as to what works best for whom.