Conceptual Overview

Table of Contents

1. Introduction
2. Standards, Textbooks and Words
3. Alignments
4. Relationships

Introduction

The goal of TSD is to manage textbooks, standards, dictionary words, relationships and alignments in one place using a clean API and a usable webtool. It supplants parts of Snap Classic and a lot of "Monte's Tools". This guide goes over the concepts behind TSD and the terminology that is used throughout this and other sources of TSD documentation.

Standards, Textbooks and Words

The main elements of TSD are standards, textbooks and words. In fact, TSD standards for "Textbooks, Standards, Dictionary". Although it now does more than those three things, the initialism has remained. Standards represent curriculum guidelines that states must follow when teaching certain subjects. Textbook information is provided as well to link useful parts of textbooks with resources in our system. The dictionary contains useful terms that will be used in various projects, starting with Interactivate.

The standards and textbooks are constructed as a hierarchy. The dictionary is simply a list of words with no other structure. The hierarchies for standards come from the states themselves. The hierarchies for textbooks are based on the structure of the book. In general, the hierarchy is designed to be small and flexible enough so as to be able to apply to any state's standards or any textbook. So far, there have not been any problems with this approach.

The standards hierarchy consists of a set of trees with the root of each tree being a standard organization. An organization usually represents a state, but may also represent some other entity, such as NCTM. Each organization provides standards that are broken up first into grade bands (called standard grades by TSD) and within each grade band are a set of categories. Finally, within each category are a set of objectives and these are the actual standards. To re-iterate: an organization contains a set of grade bands, each of which contains a set of categories, each of which contains a set of objectives. Each node in this tree has an ID, which is usually not important for the end user, and a name (or description, in the case of objectives). Organizations have additional information, such as their state and address.

The textbook hierarchy mirrors the structure of a book. The hierarchy consists of a set of book nodes and each book node contains one or more chapters and each chapter contains one or more sections. Since multiple books are sometimes published with the same name, but apply to different grades or courses, each book contains a field that specifies which grade or course the book belongs to, if applicable. Each node contains an ID, name or title and description.

Words are much simpler. Each word is paired with a definition. The word itself is equivalent to the ID field found in textbook and standard hierarchies.

Alignments

TSD allows you to link TSD nodes (objectives, sections, words) to CSERD resources, including those in Interactivate. These linkages are called alignments and indicate that the resources linked to the nodes fulfill the purpose of the node. For example, if there was a standard objective called "Understand negative integers", then several resources that relate to learning and understanding negative integers could be linked to that objective. These linkages are called "alignments" and they are useful for teachers who need to fulfill standards or make use of textbooks in conjunction with our resources. Alignments additionally may have a reason for alignment, which is just a text string that describes the alignment and/or why it was made. It is optional.

To allow for alignments to be created, modified and deleted without disturbing production websites, TSD has support for dev and live versions of alignments. So you may have the alignment above, but you might later decide that that alignment needs to be removed with the next push of Interactivate. If there were no versioning, deleting the alignment would mean it also shows up immediately on the live website. With versioning, only the dev version is marked as deleted and the live version is left alone until the changes are approved.

When you create a new alignment, there will only be a dev version and it will be in the state 'new'. When it is approved, it will be copied to create a live version and both versions with be in the state 'approved' and contain the exact same data.

When you edit an existing alignment (which means changing the reason for alignment), the dev version is marked as 'changed' and the changes are not propagated to the live version until you approve them. If you edit a version that's already marked as 'new', it will remain marked as 'new'.

If you delete an alignment, the dev version will be marked as 'deleted' and no changes will be made to the live version. When you approve the deletion, both the dev version and the live version will be removed from the database. Any changes made to a deleted version are discarded.

While you can approve any changes, creations or deletions made to dev versions, you can also cancel or 'deny' these modifications, in which case the dev versions go back to the state they were in before (i.e., to be the same as the live versions) and any new alignments will be removed and any deleted alignments will be 'undeleted'.

Relationships

TSD also supports directly linking two resources. This linkage is called a relationship (sometimes also called 'relation', so watch out when reading documentation or code). The relationship simply states that two resources are, for whatever reason, considered to be related to each other. You may also specify a description of the relationship, which is equivalent to the reason for alignment that you have with alignments. It is also, of course, optional. The same rules for dev and live versions apply for relationships as they do for alignments, so see the discussion above for more on that.