Dr. Tom’s Guide to Reusable Content Objects
The Technical SCO
Purpose of Document
This document describes methods for producing learning or content objects in manageable, reusable forms. Although it refers to the SCORM Sharable Content Object (SCO), it has application in the IMS Content Package, particularly the associated content type resource in the Common Cartridge specification. This guide differentiates between the needs of development and deployment of experiences with two forms of a content package, standard and optimized. The method in this document was developed independently. SCORM SCOs are not inherently objects. This can make it difficult to manage them, reuse them and have a lively e-Learning SCO economy. The purpose of this document is to describe a uniform method for creating instructional objects (IOs) as ADL SCORM SCOs, applying the robust, proven SCORM standard. This will support extended reuse of SCOs. It supports file management systems. It supports content management systems (CMSs). It should ease alignment with other specifications. It will allow tools to be built with some uniformity of function. This document is a (Best Practices) Technical Guide for making SCOs. It is not a specification but suggests a consistent implementation of the SCORM specifications for the generation and use of SCOs that supports reuse and management. A core issue is "forward legacy," making things that should readily convert into another form for other specifications using simple utilities. The major underlying methods have been developed and tested independently by others. This document does not address instructional design.
I am grateful to Daniel Fowler and Ohad Bukai of Intelligent Automation, Inc. for their consultation. Mr. Fowler provided invaluable guidance on the use of XML Base and general comments. Mr. Bukai contributed the thoughtful questions that are the basis of the Q&A Section.
The reader is presumed to be aware of the ADL’s Sharable Content Object Reference Model (SCORM).
How are valuable instructional assets to be managed for effective course development? How can these assets be reused to produce a good return on the investment made in creating high quality instructional resources? How can instructional designers create effective courses with a minimum of technical knowledge? How can the potential for reuse be maximized? How can this be done using the existing, proven SCORM standard?
This paper presents a plan for creating stand-alone instructional objects (IOs). IOs are designed to be autonomous so they can be used--and reused--in various contexts. They can be placed in courses without conflicting with other resources in the course. They are encapsulated instructional objects. This document presents this concept in the specific case of the ADL’s Sharable Context Object Model, SCORM. The Sharable Content Object, SCO, is a specific instance of an instructional object. This SCO model can be used within both SCORM 1.2 (unsequenced) and SCORM 2004 (sequenced) courses.
Courses can be reduced to finer levels of granularity. Standalone SCOs can be managed as assets within both business and instructional inventories. They can be individually version controlled. They can be used by other enterprises with a little modification. Their use can allow work flows that are more effective.
A course is an assembly. Similarly, a content package is an assembly. A course is experiences that flow in a managed sequence. Currently most experiences are media presentations to the learner, for example an interactive web page or Flash object. The instructional flow determines how the learner moves through these experiences. The experiences are embodied in instructional objects (IOs). Instructional designers need to be able to develop, gather and arrange IOs freely to accomplish instructional objectives. IOs need to be encapsulated units. An object can be a consistent and reusable unit. How can we make IOs that can be manipulated as independent objects?
Can a SCO be an IO? How can we define a SCO structure that can most readily be converted into an object? A SCO is a resource in an XML manifest that points to files needed to execute the resource’s behavior. The resource needs a unique identifier (UID), e.g., identifier="R_123456". To be reusable, the files need unique indicators. This can be accomplished by putting all of a resource’s files in a subdirectory with a unique name, e.g., R_123456. A reference to a file is made by prefixing the subdirectory path to the filename when referenced: href="path/filename.xxx". The base attribute can be used at the resource level, e.g., <resource base="R_123456/">, to define the path for all files in the resource. Basic metadata should be included. A simple example of a manifest is provided in Section 13. This guide is consistent with the requirements in SCORM 2004 3rd Edition Content Aggregation Model (CAM).
What follows is a rationale for these recommendations with implementation notes. Some ideas outside of the specification per se have been added.
Here are some questions provided by Ohad Bukai and answers addressing the purpose and use of this guideline:
Q: SCORM is a mature standard, possibly giving way to a new one. Why develop best practices now? What is the motivation for doing this?
A: "Mature" is not the same as "static." Standards change. The way they are used changes. An objective of this guide is to provide a structure that will ease alignment with a new standard. This can be called "forward legacy." The idea is to create a method that adheres to the current standard while providing a reasonable chance of being able to convert the results of the current standard into a new one. A uniform way of pseudo-encapsulating the SCO is a step in that direction. Use of the current standard should not be blind to the future. A method of constructing SCOs such that they can be readily converted to and from existing standards, such as S1000D, is also valuable.
The latest guide from ADL, "ADL Guidelines for making reusable content with SCORM 2004," makes no recommendations as to how the packaging of SCOs should actually occur. That guide is pedagogically oriented. Here, we ignore pedagogical considerations. This is a technical guideline. This presents a uniform method for realizing SCOs that should support development work flows and still be compatible with SCORM.
Q: New emerging standards address the packaging question in a general way (mpeg 21, common cartridge) ... why bother looking back?
A: See above. The closer one is to being able to have one’s materials jump forward the more it helps the current specifications to be adopted. It also allows developers to be confident in the use of the current standard. Current implementers want to see a pathway forward for their investment. To repeat, "forward legacy." The objective is not only to implement SCORM better but also to have a method that is more SCORM 1.x independent.
Q: Packaging is a transient representation. Once the package is received by an LMS, the LMS has a prerogative to select how to represent content internally.
A: "Transient representation" is a problem. How can you reuse something that is not engineered for reuse, but changes? The existing standard works and has been proven. The intent is to build on that strength. The crucial bit here is creating a package that is consistent. An objective is to support automatic management of SCOs. This means the use of tools and utilities. This requires consistency in their representation, minimizing ambiguity. An underlying goal of SCORM has been "reuse." It has not succeeded at the level hoped for. First, there is no such thing as an actual SCO. How can they be reused if there is no "there there?" The objective here is to provide SCO autonomy. No one is required to do things this way; it is only a proposed best practice. However, if LMS developers state that they will take this format preferentially then they encourage developers to do so. LMSs could use the carrot of servicing potential course delivery in other standards formats.
The real issue is not the LMS. It is what happens when an LMS is NOT in the loop. The LMS in the loop model is a conceptual handicap. I search for SCOs. I get SCOs. I should be able to drop them into a package with minimum effort. If I have to decode different interpretations then the work load goes up and reuse declines. Another problem with reuse is sequencing. Right now organizations run from it, using Flash and its counterparts. If you can separate SCOs from sequencing in a clean way, then perhaps developers will be more inclined to use sequencing. This guide does not address sequencing.
Q: Someone might claim that the selection of package structure is a prerogative of the author and is related to his organizations’ business process. Who are we to say that our way is better? Why not live and let live?
A: Again, no one is forced to do this. Best Practices are not requirements but are intended to foster a uniform interpretation of the specifications. This is what really helps the adoption of a specification. The use of large Flash objects is simply a de facto way of ignoring the specifications’ potential for content reuse at a fine grain while supporting adaptive sequencing.
Q: Some practices must have been developed over the years by organizations that make instruction. Can you reference what is the practice is?
A: A good point. We developed the subdirectory concept within IMS years ago, initially for packaging large numbers of student records. The method was recognized as a way to package anything for safe transport that allows disaggreagation at the receiving end without filename collisions. It works. The recent ADL SCO Guideline stands mute on this. This has been discussed with a few others who independently arrived at similar solutions. We want to move from "similar" to "same" to support the automated content management mentioned above. Uniform naming with UIDs is not a handicap but a help. That is not required either.
Q: The use of base: We don’t know if the use of the base attribute is widely supported by LMS, if not, it might be risky to suggest using it.
A: True. However, the use of base is in the SCORM specification. It has been around for a long time. One must presume that such a fundamental specification has been implemented. The use of subdirectories is far more important than the use of base, but base makes the <resource> reference consistent. Base makes resource (SCO) management easier. One could also develop automated processes for deriving a new SCO from an old one through assigning a new GUID and changing the base.
Q: Uniform use of directories: If the package contains a large media file, the packager may want to reuse it across two resources in the same directory.
A: True, SCORM has a solution to this, <dependency>. The intent is not to prevent the common use of common files. This is optimization. Optimization is a separate issue. It should be treated as such. There is a difference between a standard and an optimized content package. One edits course assembly in its standard form. If one is to create a reusable SCO then one needs to include all of its guts in the SCO’s "package." Otherwise it is not really reusable or autonomous. Managing it means having to detect and control its technical context of support and control files. As repeated here, uniformity increases utility. It is also true that with fine-grained structuring of a course, it may be reasonable to put the large media file in its own SCO and put contextualizing SCOs around it in the <organization><item>s. You can then reuse that media SCO as many times as you like without duplicating it. You are reusing the SCO within the course. A course that has been developed using the reusable SCOs can be optimized. This is a utilities or tools issue. A utility can optimize a course by using subdirectory locations, filenames, checksums and hrefs.
Q: The use of a metadata file rather than tag may be a comfort for some and burden to others. There should be a strong case to suggest preferring it to using the tag.
A: A tag is an html attribute. It is not part of a SCO but is contained within the html structure of a file in a SCO. Metadata is a well-defined data structure that can carry information of use to many parties. Metadata allows SCOs to be stored, searched and retrieved. It is a key to reusability. Eventually it should be possible to encrypt a (zip, cab, jar etc.) file such that only specific content (files) can be accessed, making only the metadata available.
This is a suggestion not a requirement. Perhaps the issue is the use of a metadata file rather than in-line metadata. The objective is to create a modularized SCO: resources (manifest style), files, and directories. As much content is removed from the manifest as possible to separate what it is from how you use it. Metadata is considered by some as a valuable resource in itself, for instance in search systems. If one can expose and transmit just the metadata, the IPR of the content is maintained. Additionally, if one is going to use the SCO in some other form supporting some other specification the conversion is simplified. People don’t have to adopt all of the best practices. The use of metadata at the SCO level is strongly encouraged.
Q: Resource by reference - resources can reference files also by URI. There should be some unified way to address the two, no suggestion here.
A: According to the W3C XML Base document a URI is a local, base directed reference unless one uses an absolute reference of the form http://... This would really be a pain when the course is located in some unknown directory.
If I ask you to send me a SCO, what do you send me?
Figure 1. A SCO
This simple question has deep implications both within the community of current adopters of SCORM and relative to other specifications, current and future. These other specifications include S1000D, DITA, IEEE LTSC and IMS. In short, the SCO is not an actual independent object. Can it approach being one? Yes. The objective is to use the proven existing SCORM standard to increase SCO robustness, reuse and a SCO economy.
Let us illustrate the issues with a simple linear course (Figure 2). This course is constructed of a series of items (1, 2, 3) for example instruction, quizzes, media, whatever. The course structure of items is a skeleton, or what Don Holmes (iMediaIT) describes as a "wire frame." The items define where an instructional experience will take place in the flow of the overall experience.
Within this linear SCORM course, each item has one instructional element (Figure 3). The instructional element provides the actual instructional experience that is the "leaf" of a terminal item in the manifest’s organization hierarchy. These instructional elements are SCOs. This separation of the structure of the course, its wire frame as Don would say, from the actual carrier of the experience allows the instructional elements to be complete units. These units can be reassembled within other course structures, reused, bought and sold as individual elements. This requires that these elements be separable from the overall structure and still able to operate in a new structure.
Let us consider the general form of an instructional object (IO) before turning to a SCO approximation of an object. We are using the term "instructional object" to indicate a general case. An instructional element can be an object, an IO. From the standpoint of an instructional system, an IO encapsulates data and processes. It has what it needs to operate. It can be used in a variety of circumstances. It is effectively autonomous. Autonomous does not mean that it can function in isolation. It functions within a context. That context can be an instructional experience delivered or managed by a system such as a learning management system. The instructional context gives us some relevant examples. IOs typically carry some media files to be presented to the learner. The IO works in the context of a lesson or course.
Figure 4. Instructional element as an object
An IO typically contains one or more files (Figure 5).
An instructional object may communicate with things outside of itself such as the media, other files and items on the Web (Figure 6). Collectively all of this stuff, internal and external, can be referred to as "content." It may communicate with a learning management system (LMS). Conceptually all of this is encapsulated in the instructional object. If you send me an instructional object, it encapsulates all of this content and capabilities. Such an encapsulation also supports intellectual property rights (IPR) methods.
The use of instructional objects as reusable objects presents potential problems. The IO is embedded in a context. The developer may have made assumptions about the context. These assumptions my not all be universal. Here are some things that could go wrong:
Bringing new IOs into a course can raise unexpected problems. Removing an IO may inadvertently remove resources needed by other IOs.
An instructional object should run when it is placed in the appropriate context, e.g., a course. It contains all of the resources it needs to operate. Creating such an object is a challenge. You need to predict where problems might arise. This gives us ideas about needs the SCO an instructional object must satisfy.
In the context of SCORM a sharable content object (SCO, Figure 7) is intended to be an instructional object (IO). I’ve repeated the figure for emphasis. This is what we are shooting for. A SCO is intended to be a specific type of instructional object. However, in implementing the SCORM specifications a SCO may not conform to the intent of an instructional object. What is a method for reliably creating an object-like SCO? We want a SCO that is a complete autonomous instructional object.
When developing a course using a specification such as SCORM it is easy to violate the concept of autonomy. Currently a SCO implemented in SCORM is an abstraction. You can’t send me a "pure" SCO. You can send me a content package with a manifest with resources that refer to files that are in the package, locally or remotely available. You have to send me a manifest to send me a SCO. How can an autonomous IO be created? SCORM and its SCOs can support the creation of autonomous IOs.
Let us look at the acronym "SCO." A SCO is a Sharable Content Object. Those three words give us a starting point.
This means it is reusable elsewhere. To be truly sharable it must be possible to:
With the exception of "Run it" all of these also apply to Assets. This document can be applied to resources of "asset" type.
This means it contains stuff, generally files or references to files or URLs. ["Stuff" is a vague term frequently used in the "content" world.] There are no inherent limitations on what the stuff can do so long as it is effectively contained within the SCO. The use of URLs local to the LMS is not advised. They may not be stable and may be subject to changes in the client/server relationship.
The stuff and the stuff that makes it work needs to be encapsulated. It is in some way a whole. You can pick it up, put it some place and it will work.
Right now a SCO is not sharable, it has a modest content model and it is not an object.
Let’s dig a little deeper. How do these terms interrelate? What is necessary to make these factors work? This is where the rubber meets the road. To find it and know what it is, you need some sort of information that is available that tells you about the thing, either directly or through some sort of proxy, e.g., a search tool. Descriptions of things, such as objects (hey, we’ve seen that term before) with content (yet again!) are done with good old metadata. To maintain the "objectness" it must be possible to pull that metadata out of the object to look at it. Let’s not worry how the implementation does that. It does, and probably puts it in a database of some sort. The metadata has allowed me to find the SCO. Now I need to find out if it is something I actually want. Unless the guy in the next cubicle or I made it, I probably don’t know too much about this thing. I probably searched by fields and or key words. Tell me about yourself, SCO. You may ask for specific information such as the title and description. Does it fill your need? Can you run it? You may ask for all of the metadata: "Show me what you’ve got." In either case, you want more of the metadata revealed. As long as something can get to the metadata, no problem. In fact, the hosting system may have acquired the metadata in advance, anticipating your every wish. You may be looking in a repository that contains only metadata.
You decide this is a SCO you want. You have negotiated the right to use it. Get it. You ask the serving host to send it to you. This means you want the object with its content. Ah ha! Here we are with the old question, what is content? As above, it is the stuff and the stuff that makes it work. What’s in the object? For simplicity’s sake, let’s take a standard model:
Notice that thus far the SCO does not actually contain any content (Figure 8). It is a directory system (or index) that defines a starting point for using some files. It tells where those files are located by using their names and a path (e.g., comm/) if appropriate. I’ll stay with the term "instructional element" until we have something that is more object-like.
In SCORM the part that tells which files are going to be used and where they are is a block of information in the manifest. Since we are talking about SCORM, I’ll use the common binding for SCORM, XML. This is not a tutorial on XML. You can find one of those elsewhere. I’ll assume you know the basics of XML. The part of the element in the manifest is called a "resource" of type (adltype) "sco." An asset of "adltype=asset". An instructional element could use files that are common to all of the other resources in the manifest. It is dependent on those files. Those files could all be contained in another resource. Here, with dependency, we have some real risks. They break the autonomy of a potential object. The resource is using things outside of itself. We have broken is encapsulation on the hope that everyone else who put things into this course does it right. What if someone overwrote one of the dependency files? What if they forgot to put it there? Or put it in a subdirectory with another name? What if they removed a SCO and in the process removed a needed file? If SCOs are going to be truly reusable you can’t take this chance.
Our objective is to create a SCO that is a completely self-contained unit, or nearly so. We would like to approach its being an object. An object allows management and reuse without concern for filename collisions. It allows editing of course structures by an instructional designer rather than a programmer. It encourages an instructional object economy.
Figure 9. An object-like objective
Let us move forward with the concept of an encapsulated SCO.
Figure 10. The target: an encapsulated configuration
In SCORM a SCO is defined in the manifest as a "resource" with an adlcp:scormtype="sco" attribute. A SCO must support the LMS APIs of at least initiate and terminate. An "asset" may not support the LMS API. <resource>s are grouped within the <resources> element in the manifest.
Logically this looks like Figure 11:
In the land of XML this translates to (Code 1):
<resources> <resource identifier="R_123456" type="webcontent" adlcp:scormType="sco" href="sco1.html"> <file href="sco1.html"/> <dependency identifierref="R_67890/"> </resource> <resource identifier="R_67890" type="webcontent" adlcp:scormType="asset" href="logo.jpg"> <file href="logo.jpg"/> </resource> <resources>
Note: The attributes are shown in list form for ease of reading. Format is optional in XML.
Let’s look at that troublesome resource the instructional element is dependent on (Figure 12). The problem is that the instructional element is relying on two files that the instructional element resource has no direct control over, APIWrapper.js and logo.jpg. Additionally one of those files, APIWrapper.js, is supposed to be loaded in a specific subdirectory, comm/. We can only hope that the right things are where they ought to be. The instructional element points to those external files indirectly. It uses a special type of index member called "dependency." Dependency points to another resource of type asset.
As you can see, the instructional element uses its resource with an identifier R_123456 to point to another resource with an identifier of R_67890 through a <dependency> element. The instructional element may not use all of the files in the resource that dependency points to. Why don’t we just pull all of those dependency files needed and stuff them into our instructional element and its corresponding group of files? We could do that. See Figure 13. Consolidated files.
If our consolidated instructional element puts all of its files in the root directory, we have lost the advantage we just gained by referring to them all in the single resource. Additionally, we still have the problem of the potential collisions of files from different instructional elements with the same name. If we put all of the instructional element’s files in a separate directory then we don’t have to worry about any collisions. We don’t have to worry about the common files being overwritten. The only place we can create a reliable directory is under the course directory. If we put it somewhere outside of the course directory we have to make an absolute reference to it: http://... This is asking for trouble. It requires that any place the course is run the same path is available from the server top down to the desired specific directory. I doubt one could get every LMS installation to agree to that. It is not a viable option. It is not necessary. All you have to do is put the files in a unique subdirectory under the course’s root directory. For convenience sake you may want to use all or part of the instructional element’s identifier as part of the directory name. Not necessary, but it could be helpful (e.g., versioning). An easy way to do this is to create the subdirectory and refer to it with the base path offset. Base adds a path prefix to the filename. More about base later (4.2).
Figure 14. The resource - subdirectory pair.
Those supporting files referred to by the dependency resource of type Asset (R2) raise a question when it comes to reusability. What if several instructional elements use the same files? We have taken them out of the root directory. Later. It’s an optimization issue.
Resources are pointed to (referenced ) by <item>s in a manifest. The <resource> contains <file> elements that point to the files. As we have discussed, the problem comes with the file names. These may not be unique within a content package. The same may be true of the dependency files. The files themselves aren’t actually in the resource. They live somewhere else, namely in the course directory allocated by the LMS or SCORM authoring tool. If all of the files for a course are lumped in a common directory, how do you avoid collisions in file names?
It is inevitable that you will want to edit a web page or two at some time. Think of the mess you can get into if they are all in one big directory with weird unique names. Been there, done that. I am assuming you have some sort of document management system, either an application or a written policy that may require meaningful subdirectories. If not, you could get in real trouble if you try to manage a fair number of courses. Well, that’s YOUR problem. What’s that? Put the files in separate subdirectories? Say, maybe we’ve got something there.
There is another way to avoid file name collisions. Put the files associated with a specific <resource> in their own directory. Files will be unique by virtue of a unique path. When a file is referred to only the subdirectory needs a unique name as part of the path:
Code 2. Pointer relationships
<item identifierref> —> <resource identifier href=path/filename> —> file
This is a method that can be used in the JISC Reload tool.
A method used with HTML is to preface a file’s path with an upward reference, i.e., ../, to move up the directory hierarchy. This capability is now not allowed as a default in Microsoft servers (http://support.microsoft.com/kb/226474, http://support.microsoft.com/kb/332117/, http://learn.iis.net/page.aspx/566/classic-asp-parent-paths-are-disabled-by-default/, http://ase.tufts.edu/its/webDtParentPaths.htm), as it opens the system up to potential security violations. A hacker could back up the directory to get to some core machine controls. It is unlikely that all LMS server administrators will turn this default condition off. We must assume that not all servers will allow this upward parent path reference. You could omit base and put the full path on each file; this reduces the robustness of the SCO’s integrity. Thus every file accessed by the SCO must be in the resource directory or a subdirectory.
The content package and its manifest is a description of the relationships among its constituents. Not all content management (CMS)and learning management (LMS) systems have path parenting (../) limitations. The CMS and LMS are free to implement those relationships in any way they wish. They may, for instance, create maps or directories to content that is stored on a server separate from the manifest or its run time equivalent. A course developer may make the assumption that parent pathing will be resolved and construct courses accordingly. This assumption is not guaranteed. The assumption may not be consistent with the organization at the course creation end of the process. We shall proceed with the most reliable interpretation, namely that parent pathing is risky. Some of the issues are the same no matter which method is used. Remember, we are trying to make encapsulated, inventoriable, reusable SCOs.
The directory structure looks something like this (Code 3):
Code 3. Sub-directory structure
Course +-Content ¦+-R_123456 ¦ ¦ +-metadata.xml ¦ ¦ +-sco1.html ¦ ¦ +-comm ¦ ¦ ¦ +-APIWrapper.js ¦ ¦ +-images ¦ ¦ +-logo.jpg ¦ +-R_12347 ¦ ¦ +-metadata.xml, etc. ¦ +-R_12348 ¦ ¦ +-metadata.xml, etc. ¦ +-R_12349 ¦ ¦ +-metadata, etc.
You can simplify the situation by using the "base" attribute.
Putting the same path in front of a lot of file names that are all in the same directory can be tiresome—although that is what tools are for. One can use the base attribute in the <resource> element to reduce the load. Base is a W3C XML recommendation: http://www.w3.org/TR/xmlbase/. Base defines a path to all of the files the element contains. It has the advantage of letting you move a directory or change its name and only have to change the path reference in one place. Base uses the URI syntax. This method has been specified by no less than Tim Berners Lee, et al.: Uniform Resource Identifiers (URI): Generic Syntax: http://www.ietf.org/rfc/rfc2396.txt. You may bow now.
SCORM addresses the use of base in the CAM document (184.108.40.206. ). Base has lots of uses. Let’s stick to the current topic, SCOs.
Code 4. Use of base attribute
<manifest> <organizations> <organization> <item identifier="IR_123456" identifierref="R_123456"> </item> </organization> </organizations> <resources> <resource identifier="R_123456" xml:base="R_123456/" type="webcontent" adlcp:scormType="sco" href="sco1.htm"> <file href="sco1.html"/> </resource> </resources> </manifest>
Use of base creates the reference from <item identifier="IR_123456" ... > to R_123456/sco1.html.(Code 4) sco1.html is in the R_123456/ directory. You get the idea.
We do not recommend the use of the <dependency> element. There is a problem with base. You can’t "climb uphill" (reference a parent directory) with a relative path reference in SCORM. You can’t reference upward against the base declaration in the resource. You have dug a hole and you can’t get out of it as base will prefix any reference you make with the base path.
The <dependency> element is not of much use here. The resource would have to have the same path as the SCO subdirectory so there is little point in creating the dependency’s resource. It could be beneficial to put the files considered into a common ("comm") subdirectory within the SCO directory. If someone should wish to make a tool for optimizing a package after it is fully assembled into a course, this might be useful. <dependency> requires the presence of an additional <resource>. By not using dependencies you end up with the entire SCO defined in one <resource>. This makes a nice clean system to work with. It maintains SCO autonomy.
The underling concept is to create fully self-contained SCOs that will work no matter where they are used. Tools should take care of the donkey work.
This differs from the recommendation in the SCORM CAM, Section 3.6.2. Using the <dependency> Element, that suggests the use of the element to reduce the replication of files used by multiple SCOs. In this guideline, <dependency> is considered useful in optimized content packages. A course could be reconfigured for delivery. It may be useful once the standard course has been developed. See Section 8, Standard, Consolidated and Optimized Packages.
Metadata supports the use and management of SCOs. The following comments are focused on those needs and do not reflect instructional factors that are also important but apt to be of specific value to an entity. The ADL Guidelines for making reusable content with SCORM 2004 covers those topics. There are many metadata tools out there. As Eliot Christian of USGS said, "Any metadata is infinitely better than none." Just do it. With the right tool, once it is part of your work flow you will hardly notice it. In addition to the <resource> element, the <file> element may also contain the <metadata> element. With a reasonable metadata tool you can call up information about a SCO without having to open it. This may aid in the (re)use of individual files in the SCO or Asset.
SCORM uses the IEEE Learning Object Metadata (LOM) specification. The following SCO ADL/LOM metadata elements are strongly recommended: (Code 5)
Code 5. Strongly recommended metadata
General>Identifier [catalog, entry] General>Title [string]
The recommended elements are (Code 6):
Code 6. Recommended metadata
General>Description [string] Lifecycle>Version [string]
Also recommended (Code 7):
Code 7. Also recommended metadata
Lifecycle>Contribute>[Role (editor), date)] (provides the last edit date)
An example metadata file is provided in the Example section (13.2). The metadata is the first element in the resource as defined in the CP XML Schema (imscp_v1p1.xsd). The SCO’s metadata file is placed in its file directory and pointed to by the resource (Code 8):
Code 8. Pointing to the metadata
<resource identifier="R_123456" base="R_123456/" type="webcontent" adlcp:scormType="sco" href="sco1.html"> <metadata> <adlcp:location>metadata.xml</adlcp:location> </metadata> <file href="metadata.xml"/> <file href="sco1.html"> <file href="images/logo.jpg"> <file href="comm/APIWrapper.js"> </resource>
Thus the location of the metadata for resource R_123456 is R_123456/metadata.xml. This sort of naming convention can make it easy for tools to find things and manipulate them (see Section 11). It is not required however. It will work with whatever naming you use. The keys are uniqueness of the subdirectory names and of the <resource> identifiers.
The metadata has some additional fields. You can read about them elsewhere (ref: SCORM 2004 3rd Edition Content Aggregation Model (CAM), Section 4). When possible metadata can be developed as part of the work flow. A SCO has a title and description in the storyboard phase of development. If these can be captured then the metadata is started. Similar strategies can be useful for other fields. Fields developed early can also contribute to quality assurance: What was the plan for this SCO? Did it meet that plan? Metadata can be part of project management, setting out the specifications for the SCO and work assignments.
Now we get to some problems in reusability. You really want your stuff to be "sharable." When you want something to be reused, you want a rule set to follow that should be successful. You don’t know if someone is going to reuse the SCO in a new context. The first problem encountered is uniqueness of file names. How many files might be named "introduction.html," "index.html" or "pix1.jpg?" You’ve named a file "index.html" so it will be easy to find and edit. You have to plan to avoid a collision of names. You cannot be sure your file name is unique in the larger world or in the manifest. You don’t care to give it some long meaningless UID string for a file name. Fortunately each resource refers to files that are all neatly tucked into their own little subdirectories so filename duplication need not be a problem. See Section 4.2. Files and Directories.
When there are a lot of SCOs and/or SCOs made by different people there can be identity collisions unless a standard identification method is used.
A <resource> XML element has an identifier attribute. This should have a value that is unique in the content package in which it is used. This is a locally unique ID (LUID). Initially it may be a "probably unique ID" (PUID) as discussed in Section 6.2. It may be useful to draw from the identifier in the metadata to create this ID for uniformity. That’s just a matter of style. If there is a resource ID collision, all that needs to be done is to change the identifier attribute’s value in the resource element. Using PUIDs this would happen rarely. You will probably never encounter it.
A unique identifier is unique within some scope. Let’s talk about four kinds of UID:
UUID: Universally Unique ID
GUID: Globally Unique ID
LUID: Locally Unique ID
PUID: Probably Unique ID
UUID and GUID are essentially the same. Through an algorithm a long string is generated that has an extremely high probability of being unique. A globally unique ID can be up to 128 characters long. If you consider the number of values each character can have (36) and the number of characters (128), you can see that the number of possible IDs is astronomical (36128). Some systems (e.g., the Handles system) allocate specific prefix codes within those 128 characters. Additionally, an organization may embed some identifiers with local meaning. Still, the number of possibilities remains astronomical.
SCORM 2004 does not say much about unique identifiers (UIDs) for the metadata <identifier> element:
220.127.116.11. <identifier> Element
"The <identifier> element represents a mechanism for assigning a globally unique label that identifies the SCORM Content Model Component. The notion of assigning a globally unique identifier to a component is important when dealing with multiple facets of learning content development (e.g., versioning, maintenance, etc.). "
Unique IDs can be pretty well ensured with reasonable programming practices. It’s not perfect, but very good unless someone does something stupid, e.g., uses only the date. An enterprise may choose to include some sort of enterprise and entity ID within the GUID. No problem. There are algorithms for generating GUIDs. I am not foolish or brave enough to recommend one. You can look to Wikipedia as a start on this issue: http://en.wikipedia.org/wiki/Universally_Unique_Identifier . The Handles system developed by CNRI is another starting place: http://www.handle.net/. CORDRA uses the Handles system (http://cordra.net/docs/applicationprofiles/uri/v1p00/ap-uri-v1p00.php) putting you well along the way of being able to register your content in CORDRA. A specification for a GUID is referred to by XML Base: Open_Software_Foundation which, through a series of mergers, can now be found in the Open Group: http://www.opengroup.org/. The standards world is always shifting about as the winds change. The GUID is limited to 128 characters. Have fun.
A UID that is 128 characters long is unwieldy—and unnecessary—within a constrained context. A locally unique ID (LUID) means that it is unique within a specified scope. For example a resource’s identifier ID must be unique for each use in a SCORM manifest . The developer is to ensure that this is so. This brings us to the Probably Unique ID (PUID). PUID is not an official term but we will find the idea useful. It reflects how most people develop a locally unique ID. They randomly generate a relatively short identifier that has a very high probability of being unique within the scope of use. If you use only digits, which are easier to generate algorithmically, 8 characters give you 108 possible IDs. Collisions within a manifest are highly unlikely even though a moderately fine-grained course may have 50-100 SCOs. Six characters have been used here for illustrative purposes. It can be useful to select the last characters of the metadata <identifier> value to be the locally unique ID. Consistency is good.
How you handle the various identifiers is a matter of policy for the enterprise. The important thing is to have a written policy. Or better yet, institute it in tools and utilities (see Section 11. Tools). This may be part of your work flow considerations.
Each <resource> can—and should—have <metadata>. Ah, the dreaded metadata (Section 4.4. <dependency>). The metadata in the SCO can use the <identifier> element to hold the UID. The metadata is contained in the resource. Thus the resource contains its UID. The identifier should be a GUID. Logically it is built like this (Code 9):
Code 9. SCO unique identifier in the metadata
resources resource (SCO1) metadata identifier file(s) resource (SCO2) metadata identifier file(s)
It is important that a uniform structure for SCOs be used. It provides opportunities both within the SCORM specification and outside of it. This document does not discuss what content actually goes in a SCO and its instructional quality. That is left for other discussions more relevant to instructional designers. This is a technical discussion. We are close to having our complete SCO as an isolated, autonomous object. We have a two-part SCO (Figure 15).
Figure 15. The two-part SCO
A resource’s files can be stored in a subdirectory, referred to with the path (e.g., with base). Those files need a unique subdirectory. To fulfill our objective of preventing filename collisions within a content package. You can identify your subdirectories uniquely with a good unique ID (UID). Look at Section 6. Unique Identifiers. A useful method is to derive the subdirectory name from the resource ID, e.g., for resource R_123456 the subdirectory is R_123456/. This makes it easy to extract files from a resource, manipulate, and import them into an indexing system and so forth. See more in the metadata section (5).
Now make the SCO:
We have now created all of the parts of a SCO. We put the files in a directory structure with our subdirectory, R_123456, containing all of the parts needed to make the SCO work (Code 10):
Code 10. Resource subdirectory structure
+-Content +-R_123456 ¦ +-metadata.xml ¦ +-sco1.html ¦ +-comm ¦ ¦ +-APIWrapper.js ¦ +-images ¦ +-logo.jpg +-R_12357 ¦ +-metadata.xml . .
The entire directory structure is wrapped up in the zip file with the manifest. If you are only shipping SCOs around in a content package, with the <organization> element providing an index, the manifest will look something like this (Code 11):
Code 11. Single SCO manifest
<manifest identifier="SAMPLE1" version="1.3" xml:base="mycontent/" xmlns="http://www.imsglobal.org/xsd/imscp_v1p1" xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_v1p3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1 imscp_v1p1.xsd http://www.adlnet.org/xsd/adlcp_v1p3 adlcp_v1p3.xsd"> <metadata> <schema>ADL SCORM</schema> <schemaversion>2004 3rd Edition</schemaversion> <lom:lom> <lom:general> <lom:title> <lom:string language="en-US"> Title for the Package </lom:string> </lom:title> </lom:general> <lom:metaMetadata> <lom:metadataSchema>LOMv1.0</lom:metadataSchema> <lom:metadataSchema>ADLv1.0</lom:metadataSchema> </lom:metaMetadata> </lom:lom> </metadata> <organizations> <organization> <metadata/> <item identifier="I_7890" identifierref="R_123456" isvisible="true"> <title>Indexed SCO</title> </item> </organization> </organizations> <resources> <resource identifier="R_123456" xml:base="R_123456/" type="webcontent" adlcp:scormType="sco" href="sco1.htm" isvisible="true"> <metadata> <adlcp:location>metadata.xml</adlcp:location> </metadata> <file href="metadata.xml"/> <file href="sco1.html"/> <file href="comm/APIWrapper.js"/> <file href="images/logo.jpg"/> </resource> </resources> </manifest>
Each SCO carries all that it needs to function. Each SCO is defined in its <resource> that contains references to the files and the metadata. Each SCO has a defined (sub) directory that carries all of its necessary files. This subdirectory is included in the base declaration in the <resource>.
The metadata is the standard stuff. It is acceptable to have no <organization> under <organizations>. There would be no course. This is legal. Thus, the manifest would contain the descriptions of the SCOs and the references to the actual files needed. The subdirectories under the main root directory are defined, most effectively through base. All path references are relative. An <organization> can be a useful portion of a manifest that is only transporting SCOs. The <organization>’s <items> can contain pointers to resources by identifiers. Items and sub-items in an <organization> can create a directory of the resources. This could allow you to create an index organizing your SCOs. The "index" may be useful for content management.
The principles applied to <resource>s of type SCO should also be applied to <resource>s of type asset. An asset is like a SCO except that it does not have to communicate with the LMS.
Now that a set of SCOs has been wrapped up in a content package, it is time to unwrap the package and get to the goodies. Unzipping this file then puts the manifest.xml at the root level of a directory (with all of the schema files as needed). It creates all of the unique subdirectories under the root directory with the files for the resources in the proper subdirectories in an orderly manner. Each SCO points to its appropriate subdirectory through the use of base. How is the <resource> section of the SCO created? It can be extracted from the manifest in the content package. This points out the inseparability of the SCO from the manifest in the content package. It’s still not completely an object, is it? Patience. Or jump to Section 9. The Compleat SCO.
You made a course using encapsulated SCOs. There might be a lot of redundant files. You might like to trim the course down. We can consider three forms of content packages: standard, consolidated and optimized.
Code 12. Manifest in standard form
<manifest identifier="SAMPLE1" version="1.3" xml:base="mycontent/" xmlns="http://www.imsglobal.org/xsd/imscp_v1p1" xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_v1p3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.imsglobal.org/xsd/imscp_v1p1 imscp_v1p1.xsd http://www.adlnet.org/xsd/adlcp_v1p3 adlcp_v1p3.xsd"> <metadata> <schema>ADL SCORM</schema> <schemaversion>2004 3rd Edition</schemaversion> <lom:lom> <lom:general> <lom:title> <lom:string language="en-US"> Title for the Package </lom:string> </lom:title> </lom:general> <lom:metaMetadata> <lom:metadataSchema>LOMv1.0</lom:metadataSchema> <lom:metadataSchema>ADLv1.0</lom:metadataSchema> </lom:metaMetadata> </lom:lom> </metadata> <organizations> <organization> <metadata/> <item identifier="I_7890" identifierref="R_123456" isvisible="true"> <title>Indexed SCO</title> </item> <item identifier="I_7890" identifierref="R_123457" isvisible="true"> <title>Indexed SCO</title> </item> </organization> </organizations> <resources> <resource identifier="R_123456" xml:base="R_123456/" type="webcontent" adlcp:scormType="sco" href="sco1.htm" isvisible="true"> <metadata> <adlcp:location>metadata.xml</adlcp:location> </metadata> <file href="metadata.xml"/> <file href="sco1.html"/> <file href="images/logo.jpg"/> <file href="comm/APIWrapper.js"/> <file href="comm/common.css"/> </resource> <resource identifier="R_123457" xml:base="R_123457/" type="webcontent" adlcp:scormType="sco" href="sco2.htm" isvisible="true"> <metadata> <adlcp:location>metadata.xml</adlcp:location> </metadata> <file href="metadata.xml"/> <file href="sco2.html"/> <file href="images/logo.jpg"/> <file href="comm/APIWrapper.js"/> <file href="comm/common.css"/> </resource> </resources> </manifest>
The <item>s in the manifest will point to the separate <resource>s by <identifier>s. Files that are different from the two SCOs must have different names. The file directory structure under the toot directory would be as follows (Code 13):
Code 13. File directory for a standard form.
Course root R_123456/sco1.html R_123456/images/logo.jpg R_123456/comm/APIWrapper.js R_123456/comm/common.css R_123457/sco2.html R_123457/images/logo.jpg R_123457/comm/APIWrapper.js R_123457/comm/common.css
In this tiny case only sco1.html and sco2.html are different for the two corresponding SCOs. This content package does not contain a submanifest and should process normally by an LMS.
In a consolidated form the common files in each SCO (e.g., Standard.css) are all aligned. This may mean replacing some files in SCOs to get a common appearance during presentation. The SCOs remain self-sufficient. Tools at the vendor’s or the LMS could support caching by providing a list of the frequently used common files. Codes that use an algorithm to a unique meaningless value from all of the bytes in a file (e.g., CRCs) could be used to ensure that files are indeed identical. This is outside the scope of SCORM.
SCOs can be reused within a course. If the media file is in a separate SCO (or Asset) it can be reused without having to duplicate the file. Instructional designers can be encouraged to break courses into smaller SCOs, reusing the media SCO within the more finely grained flow. This encourages the development of more interactive flexible courses, too. Courses developed in consolidated forms will maintain the encapsulation found in the standard form.
The course in the standard form is the course source. The optimized course is then a derived instantiation using the standard structures as starting points. A course that has had its internal content and directories reconfigured to reduce size and to speed delivery is optimized. It may have <dependency>s. Optimization is optional; a course should work fine without it, it is just bigger. Course development is not performed on the optimized form. Editing an optimized course has a high likelihood of regression—an error occurring in an unexpected place. Consolidation is a good intermediate stage.
In this day and age, computer memory is cheap and bandwidth is fast. You are creating standalone SCOs and building courses out of them. If multiple SCOs in a course use some of the same files, the content package will have duplicated files in different subdirectories. This package might have its size reduced by reorganizing the content package’s resource designations and the subdirectories to optimize the package. Optimization is an opportunity for tools (see Section 11) with optimization algorithms. Clearly a value-added proposition.
Common subdirectory consolidation can be useful in managing the look-and-feel for the parts of a course. Presume a course is divided into topics. Each topic has a summary. You would like all summaries to look the same but to look different from the rest of the material in the topics. You could consolidate all of the summaries into a common subdirectory with its own cascading style sheets.
This is an intermediate method for optimizing a content package by combining some of the SCOs in common subdirectories. This approach will reduce the redundancy of files in the content package. This is done by merging the files of more than one SCO in a common subdirectory (folder). To a degree the subdirectory acts as a conventional CP does at a smaller scale, although it is not a submanifest. If two SCOs have some files in common and all other files have different names (no filename collisions other than metadata.xml and resource.xml) then all of the files can be put in a common directory. There will be two <resource>s, one for each SCO. Both <resource>s will use the same base but have different "href" entry files.
Combining two resources, R_123456 and R_123457 in a common subdirectory of /R_123456 would look like this (Code 14):
Code 14. Consolidated SCOs
<resources> <resource identifier="R_123456" xml:base="R_123450/" type="webcontent" adlcp:scormType="sco" href="sco1.htm" isvisible="true"> <metadata> <adlcp:location>metadata.xml</adlcp:location> </metadata> <file href="metadata.xml"/> <file href="sco1.html"/> <file href="images/logo.jpg"/> <file href="comm/APIWrapper.js"/> <file href="comm/common.css"/> </resource> <resource identifier="R_123457" xml:base="R_123450/" type="webcontent" adlcp:scormType="sco" href="sco2.htm" isvisible="true"> <metadata> <adlcp:location>metadata.xml</adlcp:location> </metadata> <file href="metadata.xml"/> <file href="sco2.html"/> <file href="images/logo.jpg"/> <file href="comm/APIWrapper.js"/> <file href="comm/common.css"/> </resource> </resources>
The <item>s in the manifest will point to the separate <resource>s by <identifier>s. Files that are different for the two SCOs must have different names. The file directory structure would be as follows (Code 15):
Code 15. Consolidated SCO subdirectory
Course root R_123450/sco1.html R_123450/sco2.html R_123450/images/logo.jpg R_123450/comm/APIWrapper.js R_123450/comm/common.css
In this tiny case only sco1.html and sco2.html are different for the two SCOs. This approach will reduce the redundancy of files transmitted. This content package does not contain a submanifest and should process normally by an LMS.
R_123450 is the union of R_123456 and R_123457. Conceptually resources R_123456 and R_123457 are "subclasses" of an abstract resource class, R_123450. This should be undertaken with caution. It is really a job for tools. The metadata.xml and resource.xml are removed unless they are given unique names. Typically, these files are retained only in the standard form as that is when they would be accessed. The resource.xml files could be used by a tool to determine the contents of the single common directory. It might be difficult to extract a SCO from this package. This is consistent with the underlying multistage model: Instructional system designers (ISDs) edit the standard form. Technical people and/or tools do consolidation and optimization of the standard form.
When do you use the standard form? The consolidated form? The optimized form?
The same large media file may be used multiple times within a course. This is a tempting target for optimization. If this file is referred to by separate SCOs, the file will be repeated (barring optimization). Course development strategies can reduce this impact. The common subdirectory consolidation may also reduce repetition.
Don’t try to extract SCOs from an optimized course. Go back to the standard or consolidated form. If someone wants to buy a course that they will edit, sell them the standard form. Treat it like source code. Version it. First test a course in standard form. The core resources should retain self-contained SCOs in the storage system. The standard course is saved. The other forms are derived from it. Reliably going backward from an optimized to a standard form is apt to fail—or at least not result in the original standard form. The difficulty in extracting pure, original SCOs from an optimized form can provide a low level of IPR support.
Consolidation and optimization will attempt to put SCOs that use the same support files into common directories, possibly the root directory. Doing this requires that the common files actually be either common or interchangeable and that files unique to a SCO be uniquely named. Let us consider file names: how do we avoid name collisions? We can tell people to use longer file names and try to always include something in the name that is apt to make it unique, e.g., F15elec01_introduction.html. This is a good start but may be unreliable. Given human nature there are apt to be any number of SCOs with files named "image01.jpg" or "Summary.html." An alternative is to (automatically or manually) add random characters in the name, such as at the end. The result is then something like image01_27a4.jpg. This adds a PUID (probably unique ID) to the name. Just a few random characters greatly increase the probability of uniqueness of the filename within one content package, yet the name retains human readability. The objective is to increase the level of effective consolidation and optimization through a decrease in file name collisions. This is particularly important when SCOs come from a variety of sources. It supports reuse of SCOs. Such a file naming convention is only a suggestion. If optimization is not an issue, then neither are file names as long as files within a SCO are unique named.
Some may prefer not to use a SCO object model. This requires standard programming policies. If SCO and course development are tightly controlled within an organization this can work. There must be strict naming conventions for files, both SCO specific and common. Non-"object" SCOs cannot be reliably exchanged with other organizations in a risk-free manner. There will be a temptation to make larger SCOs because reuse is less of an issue. A policies model can incorporate some runtime efficiencies from the start. Common files can be used. It ids possible to use unique subdirectories for files within a resource, prefixing each filename with the path. A problem is that it requires instructional designers to have an awareness of the underlying XML, work that should be buried in the tool. It also makes it difficult to reuse a SCO by editing it, for in creating it new file names and/or directories must be developed. With proper policies some of these difficulties can be overcome. The result can be streamlined courses with few redundancies of files.
The object approach can lead to "fat" courses with considerable redundancy of files. An optimization tool or utility can convert a fat object course into a more streamlined non-object course. It would probably be very difficult to go from a non-object course to a standard object course. A standard course model has more nearly object-oriented SCOs. A SCO can be placed in a minimal manifest framework and run through a RTE for testing. Thus, individual SCOs can be tested before integrating them into a full course. The difficulty is in making an optimization tool. It is non-trivial. Many programmers will have neither the inclination nor time to do it. It could be a strong tool in the marketplace, however. Whatever the case, the fat course should always run properly, although it may be a bit slow
Courses are deployed to CMSs and LMSs for subsequent delivery to learners. Constitutes may be used in more than one course or more than one edition of a course. The courses, or their constituents may undergo versioning. The three forms, standard, consolidated and optimized differ with respect to deployment and versioning. The standard form has distinctly separate SCOs. For a very large course, the SCOs can be deployed in a set of content packages, breaking the course into more manageable size pieces for transmission. The SCOs are independent; the course can be safely reassembled at the receiving end. Individual SCOs can be updated and deployed to replace previous versions. The separate SCOs can be used in more than one addition of a course. This is subject to agreements between the course provider and the course deliverer. The penalty is a potentially larger total size if there are redundant SCOs.
The consolidated form may still have manageable blocks. A set of resources will use a common resource block. This can be treated as a "super-SCO," affording course division for delivery, editioning and versioning. The optimized form may or may not be subdivisible. The form to be deployed is subject to policies and negotiations among the parties involved.
Compleat: An archaic form of complete. "Compleat" has a richer connotation of capability than the modern form, "complete." We can have a complete kitchen. We may have a compleat chef. The most common reference to "compleat" is to Izaak Walton’s The Compleat Angler (1653).
Let us now move to the compleat SCO, a SCO that moves toward the autonomy of an object. We have discussed the SCO in the content package. We have included the metadata. We have not used <dependency>. We are using an ID that is unique enough for the situation. We have set the files aside in a subdirectory using xml:base. We still don’t have an "object" that can be neatly tied up in the manifest in a single piece beyond wrapping the pieces up in one zip file. At this point the SCO has two parts: the subdirectory of files and the <resource> section in the manifest. As a suggestion—and only a suggestion—it might be useful to put the <resource> information in the subdirectory as an XML file so that it could be extracted easily to be included in the manifest. This block could be placed in a file named resource.xml. It is a fragment of the resources section of the manifest. The resource.xml file defines the contents of the subdirectory. That file would be placed in the subdirectory. This is allowed within the specification. To ensure that it travels with the SCO when it is unwrapped it would be included in the <resource> definition itself:
Code 16. The Compleat SCO
<resource identifier="R_123456" xml:base="R_123456/" type="webcontent" adlcp:scormType="sco" href="sco1.htm" isvisible="true"> <metadata> <adlcp:location>metadata.xml</adlcp:location> </metadata> <file href="resource.xml"/> <file href="metadata.xml"/> <file href="sco1.html"/> <file href="comm/APIWrapper.js"/> <file href="images/logo.jpg"/> </resource>
The inclusion of the resource.xml file allows zipping up only the subdirectory to create a completely defined SCO. The <resource> section is defined in the subdirectory. That file can be opened and pasted into the <resources> section of a new manifest when a course is being developed. The <resource> section for this SCO is going to have to be developed or extracted anyway. We might as well make it easy. The uniform naming of resource.xml means that a utility can look for that file. If it is not there, it can look for the file elsewhere or it can get it from the manifest by matching up the base and subdirectory if the SCO is in a content package.
As you would imagine, the subdirectory now looks like this (Code 17):
Code 17. The Compleat SCO’s subdirectory
+-Content +-R_123456 ¦ +-metadata.xml ¦ +-resource.xml ¦ +-sco1.html ¦ +-comm ¦ ¦ +-APIWrapper.js ¦ +-images ¦ +-logo.jpg
Forward legacy -- Remember the initial question, "If I ask you to send me a SCO, what do you send me?" It is possible to make an isolated SCO that you could send me. This is not in the specification, but if you build SCOs as above that are within the specification, it is but a small step to the isolated SCO. The discussion in Section 9 The Compleat SCO describes a method for capturing the <resource> definition to allow a more complete encapsulation of a single SCO. We could go outside of the content packaging specification and zip up a single subdirectory including a resource.xml file. This creates a SCO as object-like. It is something you can send to me. I can unwrap it and use it. This individual encapsulation is not, repeat NOT, part of the specification. It is here because it can be useful for content management and SCO reuse. It can only be done by an agreement among participating parties. Content Packaging with a manifest is always a more generalized solution, but it requires unwrapping the whole package to get at what you might want. It makes it hard to put a SCO "on the shelf." In the isolated configuration the file is unzipped, the resource.xml file is opened and copied. The copy is pasted into the resources part of the manifest and the importation is complete into the standard form.
There are limitations in creating such a singular SCO. Dependency files in each SCO are contained in its directory. This may cause redundancy in the overall package of SCOs. Don’t try to get fancy in trying to use one set of dependency files for a bunch of SCOs to reduce redundancy. You will only open yourself up to problems. As stated in the Q&A, don’t confound SCOs with optimization. A course is built with SCOs. Course optimization may be used, as described above. Recognize the difference between a standard (source code ) and optimized (operating code) course as you would with a compiler.
The isolated SCO looks more object-like to other specifications. Conversion should be manageable. The metadata is well isolated so it can be accessed. It is not that the SCORM 1.X SCO will run directly in some other standard, but that simple software utilities can convert it to that format. And the other way around.
Figure 16. An encapsulated configuration
Again, the isolated SCO is NOT part of the specification but could be useful for managing SCOs locally. Tools and utilities would help you do this.
The isolated SCO would most readily be adopted within an organization for SCO management. SCO transactions between enterprises would entail agreement to use something like this. An objective here is to describe something that could be readily implemented, hence help build up the traffic in SCOs. Specifications can grow by consensus based on common practice. NIST considers this good.
Tools are part of this discussion. It makes little sense to automate the delivery of instruction without automating the processes of developing instruction. Specifications can usually be implemented in several ways. Automation supported development relies on consistent and useable forms. Using standards effectively is all about tools. The standards and tools achieve adoption hand-in-hand. Good tools are a strong value proposition for vendors if specifications are uniformly implemented. The user is interested in the front end. Does it describe what the user wants to do? Is it easy to use? The back end produces the messy code that no one really wants to look at. All they care about is: Does it work? Does the course run? The technical people care about the details of the actual mess that is produced. Therefore when evaluating tools one of the things you want to do is have the technical people evaluate what comes out the back. This is more than simply having them test it against a reference LMS. They need to get into the output to see if it is going to be robust. How hard will it be to support changes in the specifications? Somehow get a technical person into the loop when acquiring tools. Do this and you long reap the rewards. This guideline is intended to provide a method for evaluating the function of some tools.
SCORM 2004 (sequenced)
These are opportunities singularly and in combinations.
A common method for creating SCOs has been defined. If SCOs are constituted in this fashion, one creates proto-objects that support a specific kind of backwards/forwards compatibility for other (including new) standards. The SCO will run on existing LMSs. The SCOs can be converted to support another specification with simple utilities operating on consistent "objects." Consider this a form of proactive forward compatibility.
This is not rocket science. The objective is to create SCOs that can be treated like objects. The <resource> declaration of the SCO and its corresponding subdirectory containing the files it is dependent on can all be wrapped up into a zip file that has a manifest file. This is a convenient way to manage SCOs as single objects. When unzipped in the root directory of a course, the new <resource>s are placed in the <resources> section of the manifest. The files themselves, in their dedicated subdirectories will be just where they need to be. If you want to remove the SCO, once the <resource> is identified, the corresponding subdirectory is easily found. It is possible to merge several content packages by combining the <resource>s in the <resources> section and combining all of the files in their subdirectories under the same root directory. This is the sort of thing that utilities do. Don’t try to be clever by trying to share common files. That is a separate topic left to final course compilation: optimization. You will be fine even if you never optimize.
A content package can be used to ship around SCOs. We saw that as an initial issue: SCOs only really exist in a <manifest>. A manifest can be created that is minimal. It will have minimal metadata identifying the collection of SCOs. It may have an <organizations> with no <organization> in it. The <resources> section will contain all of the SCO <resource>s. The directory system with all of the files, neatly in their subdirectories, is zipped up with the manifest with any control files desired (lom.xsd and so forth). When it reaches its destination, it is unzipped in a directory and—voila!—there are all of the SCOs!
The following is a manifest with a two-page course using two SCOs, R_123456 and R_123457, each with one file sco01.html, sco02.html, that uses some other files. Both have a metadata file. The sequencing block causes the presentation to flow from SCO1, R_123456, to SCO2, R_123457. This is example is not optimized. The SCOs are not in compleat form.
Code 18. Example manifest
<?xml version= "1.0" encoding="UTF-8" standalone="yes" ?> <manifest identifier="SCO_TW01" version="1.0" xml:base="mycontent/" xmlns="http://www.imsglobal.org/xsd/imscp_v1p1" xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_v1p3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.imsglobal.org/xsd/imscp_v1p1 imscp_v1p1.xsd http://www.adlnet.org/xsd/adlcp_v1p3 adlcp_v1p3.xsd"> <metadata> <schema>ADL SCORM</schema> <schemaversion>2004 3rd Edition</schemaversion> <lom:lom> <lom:general> <lom:title> <lom:string language="en-US"> Title for the Package </lom:string> </lom:title> </lom:general> <lom:metaMetadata> <lom:metadataSchema>LOMv1.0</lom:metadataSchema> <lom:metadataSchema>ADLv1.0</lom:metadataSchema> </lom:metaMetadata> </lom:lom> </metadata> <organizations> <organization> <item identifier="I_7890" identifierref="R_123456" isvisible="true"> <title>First SCO</title> </item> <item identifier="I_7891" identifierref="R_123457" isvisible="true"> <title>Second SCO</title> </item> <imsss:sequencing> <imsss:controlMode choice="false" choiceExit="false" flow="true" forwardOnly="true"/> </imsss:sequencing> </organization> </organizations> <resources> <resource identifier="R_123456" xml:base="R_123456/" type="webcontent" adlcp:scormType="sco" href="sco1.htm" isvisible="true"> <metadata> <adlcp:location>metadata.xml</adlcp:location> </metadata> <file href="metadata.xml"/> <file href="sco1.html"/> <file href="images/logo.jpg"/> <file href="comm/APIWrapper.js"/> </resource> <resource identifier="R_123457" xml:base="R_123457/" type="webcontent" adlcp:scormType="sco" href="sco2.htm" isvisible="true"> <metadata> <adlcp:location>metadata.xml</adlcp:location> </metadata> <file href="metadata.xml"/> <file href="sco2.html"/> <file href="images/logo.jpg"/> <file href="comm/APIWrapper.js"/> </resource> </resources> </manifest>
This looks like a lot of freight for two SCOs, but the overhead at the top is only needed once. You can put in many SCOs.
The general form of the resource metadata file metadata.xml is:
Code 19. Example resource metadata
<?xml version="1.0" encoding="utf-8"?> <lom xmlns="http://ltsc.ieee.org/xsd/LOM" xmlns:lom="http://ltsc.ieee.org/xsd/LOM" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ltsc.ieee.org/xsd/LOM http://ltsc.ieee.org/xsd/lomv1.0/lomLoose.xsd"> <general> <identifier> <catalog>ADL-ID</catalog> <entry>A1B2C3DE123456</entry> </identifier> <title> <string language="en">The Technical Content Object</string> </title> <language>en</language> <description> <string language="en"> A guide to learning content objects and their construction </string> </description> <keyword> <string language="en">SCO</string> </keyword> </general> <metaMetadata> <metadataSchema>IEEE LOM 1.0</metadataSchema> <metadataSchema>ADLv1.0</metadataSchema> </metaMetadata> <lifeCycle> <version> <string language="x-none">1.0</string> </version> <status> <source>LOMv1.0</source> <value>draft</value> </status> <contribute> <role> <source>LOMv1.0</source> <value>creator</value> </role> <!-- vCard for Tom Wason --> <entity> BEGIN:VCARD VERSION:2.1 N:Wason;Tom FN:Tom Wason ORG:Wason Consulting TEL;CELL;VOICE:919.602.6370 EMAIL;PREF;INTERNET:firstname.lastname@example.org END:VCARD </entity> <date> <dateTime>20091215</dateTime> </date> </contribute> </lifeCycle> </lom>
Don’t let that vCard stuff scare you. It is easy to make. Open up a contact in MS Outlook. Click "File". Click "Export to vCard". Select a file name and location to save it in and you’ve got it. Open the resulting file with any text editor (e.g., Notepad). Delete lines if you want to. Cut and paste the result into your metadata file. Of course a tool could automate much of this...
The following files are placed in the appropriate subdirectories under the root:
Code 20. Example resource directory
Course Root R_123456/metadata.xml R_123456/sco1.html R_123456/images/logo.jpg R_123456/comm/APIWrapper.js R_123457/metadata.xml R_123457/sco2.html R_123457/images/logo.jpg R_123457/comm/APIWrapper.js
If resource.xml files were implemented the file for the sco1 resource could look as follows:
Code 21. Example resource.xml file
<resource identifier="R_123456" xml:base="R_123456/" type="webcontent" adlcp:scormType="sco" href="sco1.htm" isvisible="true"> <metadata> <adlcp:location>metadata.xml</adlcp:location> </metadata> <file href="resource.xml"/> <file href="metadata.xml"/> <file href="sco1.html"/> <file href="images/logo.jpg"/> <file href="comm/APIWrapper.js"/> </resource>