Arcs, Content Outlines, Nodes, Content

Arc	Content	Content outline	Nodes
Version: 1	Version: 1	Version: 1	Version: 1
Type: structure/media			Content: folder w/ nodes or ARC
ID	ID	ID	ID
Title	Title	Label	Label
Description	Description	Description	Description
Format
Lifecycle status
Keywords: purpose, source, taxonpath, taxons
Catalog entry
Contributors: role, entity, date
ACL
Copyright Controls
Edit history: user, action, date
Parameter values			Times: due AFTER/expose AFTER (stylesheet keywords)
Stylename, format, stylesheet			Stylesheets
Content: pointer, actual, repository	Content	Nodes	Content

Notation: * below indicates required attributes, particularly for static arcs. Dynamic arcs may have only the minimal necessary attributes for their purpose.

The content outline is the basic aggregational unit currently being worked on. The key data attributes are:

1. Version number* (currently 1) to allow enhancement without necessary converting all existing data. I.e., version 2 could be implemented while maintaining version 1 data intact.
2. ID* - unique id assigned by stellar to all data objects
3. Label* - human readable label to allow easy reference by humans
4. Description - optional textual description
5. Edit History: user, create, date*
6. List of nodes* (minimum of 1)

As an arc, the content outline has available a number of elements, including Status, keywords, catalog entry, contributors, ACL, copyright, edit history, stylesheets. The most likely to be used in reference to content outlines are status, keywords, contributors, ACL, edit history, and stylesheets.

Nodes are part of the content outlines. They have:

1. Version number*
2. Node Contains*: folder with nodes OR content
3. ID*
4. Label*
5. Description
6. Edit History: user, create, date*
7. Parameter values: (optional) currently defined as due AFTER date and expose AFTER date, these affect the stylesheets
8. Stylesheets (optional)
9. List of nodes OR content ID* (minimum of 1)

Like the content outline, the nodes are arcs, so they have available the full range of arc attributes. It is likely that nodes will not use additional attributes.

Content is where the actual data to be displayed is catalogued. This contains:

1. Version number*
2. ID*
3. Title*
4. Description (optional, but especially useful when the actual media is large, requires special viewers, etc.)
5. Edit History: user, create, date*
6. Content*: pointer, actual, or repository reference

As with content outline and nodes, content is a full arc, so other attributes are available. The content especially may use format, status, keywords, catalog entry, contributors, ACL, copyright controls, edit history, parameter values, and stylesheet attributes.

The arc is the fundamental "wrapper" containing all content data within stellar. For example, any of the following media files: text, HTML, PDF, image, video, audio, Microsoft Word documents, PowerPoint documents, etc. can be loaded into stellar. By adding an arc "wrapper," we store additional information allowing easier processing, display, management, etc. of the file. For example, by adding an ID, title, and description, we produce a minimal "content" data object. We can then attach that "content" or media arc in a content outline (or other structural) arc to allow us to aggregate upwards into more complex structures. We can also take an "empty" content outline template (structure without content) and by attaching various content arcs, "populate" the content outline.

The parts of the arc are:

1. Version number*: 1 to allow implementation of later arc formats without requiring complete conversion of existing data stores
2. Type*: structure or media (currently content outline or content)
3. ID* - unique ID provided by stellar for all data objects
4. Title*: human readable label
5. Description: optional text description, especially useful for text only views of the stellar data
6. Format: mime-type
7. Lifecycle status: to allow separation of draft, final, review, etc.
8. Keywords: this is an optional list using a system based on the IMS spec. Each set of keywords would indicate purpose (what is the intended purpose of the arc), source, taxonpath (which reference work defines these keywords), and one or more taxons (actual keywords)
9. Catalog entry: catalog system and entry within it (where information has a catalog associated with it)
10. Contributors: role, entity, date
11. ACL: roles (which defines a list in context), named lists, or specific individuals along with the access permissions given them. Basic definition at present includes L: list; R: read; M: modify; I: insert; D: delete; A: admin.
12. Copyright controls: this is largely a placeholder for later addition. Unfortunately, at this point I suspect the best we can do is say something has copyright controls (and thus count accesses to it?), but I have no idea what else to do with this.
13. Edit history: user, action, date - a list of actions taken on this arc (user, create, date* for static arcs)
14. Parameter values: parameter name, value pairs. Interpreted by stylesheets or other processing.
15. Stylename, format, and reference to stylesheet
16. Content: pointer, actual content, repository reference. Since information may be stored in the local stellar repository, the "pointer" is probably really a repository reference. In any case, a media arc points to real content, while a structure arc uses this same location to identify the "lower level" arcs.

It may be worth noting that the creation date (user, create, date) should be available for all of these.

The easiest metaphor for the arc is that of an outline, with the structural levels of the outline being "structure" arcs, and the various labels as "media" arcs. E.g.

1. Lecture One
1. Introductions

This is some real live content, which could be a videotape, etc.

2. Lecture Two
1. First part of the talk
2. Second part of the talk

1. Lecture One <- structure arc, label "Lecture One"
1. Introductions <- structure arc (node), labeled "Introductions"

This is some real live content, which could be a videotape, etc. <- CONTENT! (would be under a content arc)

2. Lecture Two <- structure arc, label "Lecture Two"

a. First part of the talk <- structure arc (node), labeled "First…"

b. Second part of the talk <- you get the idea, I'm sure

So for this outline, we would probably have 7 arcs (the five structure arcs I identified, one content arc, and one more to contain the two top level arcs).

Minimal data wrapping (for a content outline with one piece of content):

Content outline:

1. Version: 1
2. ID 542152345
3. Label: Mike's Minimal Content
4. Description: Not much content, but plenty of wrapper
5. Edit History: mbarker, create, 12/29/2000
6. List of nodes: 23456789

Node 23456789

1. Version: 1
2. Node Contains: content
3. 23456789
4. Label: MM Node
5. Description: For a single bit of data, this is a lot of wrapper
6. Edit History: mbarker, create, 12/29/2000
7. Parameter values: due 1/15/2001, expose 1/1/2001
8. Stylesheets
9. content 54315431

Content 54315431

1. Version: 1
2. 54315431
3. Title: MM Content
4. Description: Getting close!
5. Edit History: mbarker, create, 12/29/2000
6. Content: stellar/minimal/file1.txt

Functions needed (methods?):

CreateArc (type, title, content) returns ID or failure

SetArcxxxx(value) are there groupings that make sense?

FindArcbyTitle

FindArcbyKeywords

FindArcbyDate

FindArcbyCatalogEntry

(may be other finds, but at least these seem likely)

renderArc(ID)

getArcTitle(id)

getArcDescription(id)

Variations for content outline (CO)

createContentOutline(title, description)

addContentOutlineNode(COID, label, description, more nodes or content ID)

There are at least four types of use associated with creating arcs, content outlines, and content.

1. A content developer may want to upload content into the basic arc library. I.e., they have some media (text, html, pdf, word doc, ppt, videostream) which they want to make available as a media arc. They should be able to go to an "upload media" page and provide this information to stellar. The upload media page must support both the minimum required info (title), recommended additional info (description, lifecycle status, keywords, contributors, copyright controls), and the full arc information where desired. I propose that the page contain both minimum required and recommended additional info, with a button to request an "experts" page for those who want to use the full arc information set. Individuals who habitually use the "experts" page may go directly there.

Information loading should allow the basic types of: file upload (with browse); URL link (data is left external, only link is saved); URL upload (data is read from the external source and stored in stellar); text entry. Additional capabilities to handle aggregate files (zip, tar) and to provide additional editing capabilities through a java applet are desirable, but may not be available in early versions of stellar.

2. A content developer may want to "build" a content outline from the basic pieces of a container (or folder) and actual content. This is what the UI group currently has developed (see http://web.mit.edu/stellar/ui/courseoutline/main.html) Notice that their content outline builder includes a version of the content upload page tailored to linking content directly into a content outline (http://web.mit.edu/stellar/ui/courseoutline/newdoc.html)
3. A content developer may want to construct structure arcs for later use. These can be called "templates". An example interface page is available at http://stellar/design1/co001229.htm. This interface would be used to construct templates, which could be used in multiple courses simply by filling in the appropriate content throughout the parts. It can also be used to construct the structural parts of a content outline for a specific course.
4. A content developer may want to connect data (previously uploaded OR uploaded at the time) with an instantiation of a content outline template. For example, before the class began, the content developer put together an outline indicating that week 3 would have a lecture on a specific topic. During week 2, the content developer may have written the materials, and now needs to put them into the system and connect them with the course-instance content outline. A proposed interface for this is in http://web.mit.edu/stellar/design1/co001230.html. It basically assumes that the content developer browses through the course-instance content outline to the appropriate point, and selects one of: upload new document; attach existing document (which browses the stellar content library -- a list of media arcs); or expand the outline (attach structural arc from library of arcs; create new folder?)

For near-term, we may want to provide an administrative form interface that allows manual setting of most or all of the arc attributes, although this is NOT the interface that we would like to use for the long-term. It is probably a useful interface for problem-solving, though, so we should keep this available.

Incidentally, the other major use of the content outline (when instantiated with content and associated with a course-instance), is for viewing. I.e., someone may want to look at this information!

One of the key organizing principles for the content outline (templates and instances) will be to provide organizing pages to allow the student views.