 |
|
|
Abstract
An employee working for a large information technology company is in a predicament. In order to properly perform his job (that is crucial to national security), he is in desperate need of the most technically up-to-date information available. Using the incorrect information could cost hundreds of lives and / or millions of dollars. Although a wealth of information is available to him through an intranet, the Internet and paper, how can he be sure what he finds is the most current, technically accurate data?
Who is this person; an analyst with the CIA? Perhaps a field agent with the FBI? Or maybe an imagery specialist assigned to the Homeland Defense Agency? NO, this person is a US Navy submarine sailor operating a nuclear reactor; or a jet engine mechanic maintaining an F-14 Tomcat on the deck of an aircraft carrier, or one of thousands of at sea and shore-based Navy personnel that require technical data and training products to do their jobs everyday.
Like Fortune 500 companies and the dot com industry, the US Navy is also adopting XML to improve business processes and describe their informational assets. This is especially evident within the Navy’s submarine, sea and air communities in the development of technical data and training products. Previous digitization efforts centered on SGML, proprietary training products and CD ROM delivery. While highly successful, this process created a) numerous configuration management problems, b) a knowledge management nightmare and c) a lack of source data interoperability within the tech data and training communities.
One effort within the Navy’s tech data community is focusing on developing an Integrated Data Environment to deliver the correct data to the correct person whenever and wherever requested. This Technical Data Knowledge Management (TDKM) IDE will feature an advanced content management and control system architecture allowing for the management, versioning, distribution, and control of electronic documents at the sub-document, information object level. Central to the TDKM-IDE will be a Warfare Community Knowledge Management System built upon commercially available enterprise management software, which will serve as a knowledge broker between the fleet end user digital library and the various content repositories maintained by and for the Navy shore establishment. Content stores, populated by XML data suppliers, will also produce rich, descriptive XML metadata indices for configuration management, versioning and keyword searching through a TDKM interface. Employing these instruments, TDKM will pull the necessary data objects from the distributed content management systems; assemble a user digital technical data library collection (or update to the existing library) according to the needs identified by the user profile(s); and push this collection of technical data and/or incremental updates to the user site.
The Navy’s training community is also taking a hard look at XML, specifically as it applies to the efforts of the Advanced Distributed Learning program under the Sharable Content Object Reference Model initiative. SCORM proposes to describe individual learning objects (called SCOs) with XML metadata, then package SCOs and supporting files into a manifest file (also in XML). Any SCORM compliant Learning Management System can then read the resulting manifest file to and display its contents an end user in a web browser. The Navy is investigating if this concept can be applied to tech data elements and if so, how can the tech data and training communities use this concept to facilitate a greater re-use of XML-based source data.
Keywords
Table of Contents
In the early 1990's, when the possibilities of the digital documentation age began to appear on the US Navy's radar, the life cycle cost of technical manuals was a significant contributor to the US Navy's operational budget. Not only were the initial research and development costs to produce a manual relatively high, but the dollars and manpower incurred as a result of dated information, managing the change page process, and delivering paper quickly bloated a manual's total cost. Additionally, the extra fuel required to transport all that paper while patrolling the world's oceans could be factored into the cost equation. By some estimates, the combined weight of the paper tech manuals and the file cabinets required to store the manuals on a Navy cruiser was several tons.
As budget cuts were mandated by the Department of Defense, the US Navy began looking for efficiencies within all aspects of its day-to-day operations. Those responsible for technical manuals set out to investigate the idea of electronic distribution of manuals on CD ROM. At first glance, electronic technical manuals were a no-brainer. CD's were cheap to buy, cheap to mail, required very little storage space, and if more copies of a CD were needed it was simple to stamp out another couple hundred from the CD master. Furthermore, ETMs provided word search capability, making information retrieval faster and they could be updated and delivered quickly. However, rather than just delivering a word processing rendition of a technical manual, the Navy wanted (and needed) a smarter, non-proprietary format. Senior Navy managers chose to adopt the Standard Generalized Markup Language (SGML). Several pilot projects highlighted where improvements could be made, yet overall the initial conversion from paper to SGML was highly successful. Committees within each Naval command developed DTDs to fit their manual structure and stylesheets were developed in hypertext-based applications such as Info Access and Dynatext for retrieval and display purposes. While the Naval Commands implemented mass conversion programs, individual Navy Program Managers quickly recognized the benefits of electronic documentation and rushed to produce their own electronic technical manuals.
By the beginning of the 21st century, the digital conversion process was nearly complete. Overall, we in the Naval community were pleased with the results of the program. We assumed we had upgraded the quality and timeliness of the technical information we were delivering to ship and shore installations. In addition, the printing budget had been reduced by over a quarter of a million dollars, savings had been realized in shipping and storage costs, methodologies to manage the electronic change process were introduced, and the Fleet seemed have readily accepted the ETMs.
However, a follow-up study revealed that we had overwhelmed Navy personnel with too much information by providing:
different versions of the same manual
manuals that didn't match the equipment configuration
different user interfaces (Info Access vs. Dynatext vs. other GUIs)
Obviously, a more controlled, tightly configured, electronic documentation delivery and update process was needed to correctly manage Navy digital technical data.
The Navy has embarked on a pilot effort to deploy a field implementation of a technical data knowledge management system to dynamically tailor and maintain the deployed digital technical data for both operational units and individual users. The Knowledge Management System is to be built upon a technical data Integrated Data Environment (IDE) designed with the potential to provide a uniform content management and knowledge distribution environment for the entire Navy. This Technical Data Knowledge Management - Integrated Data Environment (TDKM-IDE) will feature an advanced content management and control system architecture allowing for the management, versioning, distribution, and control of electronic documents at the sub-document, information object level. The Content Management System will provide a standardized document management solution, covering various data formats, supporting re-purposing of the data to deliver multiple products, and supporting changes and updates to technical manuals at the content component levels. Central to the TDKM-IDE will be a Warfare Community Knowledge Management System built upon commercially available enterprise management software, which will serve as a knowledge broker between the fleet end user digital library and the various content repositories maintained by and for the Navy shore establishment. In order to perform its primary function, the Knowledge Management System will build, store and maintain profiles describing the technical data requirements for users and also construct and maintain the map (or indices) to the content data stores. Employing these instruments, it will pull the necessary data objects from the distributed content management systems; assemble a user digital technical data library collection (or update to the existing library) according to the needs identified by the user profile(s); and push this collection of technical data and/or incremental updates to the user site. The user interface to the data in the library will be managed and controlled by Web-based management software and the user’s selected portal. TDKM will be able to “snap-in” to existing user portals through a portlet and conform to the selected portal’s presentation standards. The Web-based management software will permit the warfare community manager in the field who best knows the users needs, to update the user presentation on a daily basis and to refine and customize the user profile based on what the user needs to know. The implementation will also permit the local line management in the Fleet unit to manage and modify selected components of the portal interface.
The focus of the overall TDKM-IDE project is the entire supplier chain for technical data knowledge from the original document and other technical data supplier to the actual fleet site. There are three primary echelons that require interfaces. The interfaces will be automated in the overall project to effect seamless access and information flow from one activity to another utilizing the new Web-based capability. These are at the level of:
Wholesale Environment - The Document Manager and Knowledge Product Provider to the Fleet Warfare Community Knowledge Manager interface.
Knowledge Broker - The Fleet Warfare Community Knowledge Manager to the Fleet User Digital Library Site
Retail Environment - The Fleet User Digital Library Site to the individual Fleet User interface with the technical data knowledge itself
The Wholesale Environment is made up of several individual services that function together to manage and store the system technical data. These services can be considered separate entities, but they must communicate between each other to provide the warfare community with properly formatted and maintained integrated technical data. The description of the Content Management System is provided, since the content provided to TDKM will need to meet certain requirements prior to being distributed through the system. General descriptions of the two major supporting systems, Data Store and Document Operations Center (DOC), are also discussed in the following paragraphs.
The pilot implementation will interface with the Data Store, so the other components of the TDKM-IDE can accurately and efficiently access the data controlled by the Content Manager. The Content Manager will be the source of the Minimum Published Units (MPUs), Minimal Shareable Objects (MSOs), and Documents for the TDKM-IDE.
Content Management Systems or the equivalent will supply the documents used by TDKM.
Document Level – Documents are made up of one or more MSOs.
Minimum Sharable Object (MSO) Level – Defined by Subject Matter Expert (SME). Use the persistent identifier contained within the delivered document to identify the individual MSOs. The TDKM configuration file would detail the MSOs that make up the document and the files that comprise each MSO. The concept of the MSO is new to technical manuals. Basis for MSO was the Shareable Content Object Reference Model (SCORM) development of the Shareable Content Object (SCO) requirements defined by the training community. An MSO is comprised of one or more MPUs.
Minimum Published Unit (MPU) Level – These are the individual files that make up the published document. The files can be in various formats such as HTML, XML, PDF, JPG, MPEG, and etcetera. Each MPU is identified in the file section of the TDKM configuration file. The MPU is comprised of one or more MRUs.
Minimum Revisable Unit (MRU) Level – These are the pieces of the document that are maintained in the Content Management System used in the authoring environment. There currently isn’t a plan to manage at this level in the TDKM system, which is a publishing/distributing system.
The Data Store is the primary repository for the Minimum Published Units, Minimum Shareable Objects, and Documents needed to populate the end-user digital libraries. The specific design of the Data Store is outside the scope of this project and has been designed by others but will be interfere with the TDKM-IDE.
The DOC is the common interface to the Data Store – communications with the DOC will be accomplished using Hyper Text Transfer Protocol (HTTP) or Hyper Text Transfer Protocol Secure sockets (HTTPS) over an Internet Protocol (IP) based network.
Data Provider Interface –Internet/Intranet will provide a single point of access for the data providers. The Interface will provide a means to efficiently update the data store from a remote location by a data provider. The data provider update feature should also take into account updates by the local content manager. Updates will be accomplished with a common uniform resource locator (URL) addressing scheme and will use the HTTP or HTTPS protocol. The update manager will provide the necessary tools for the updating activity to properly configuration control the documents that are being added, modified or deleted.
User Interface – A secure network or secure virtual private network will provide a single IP point of access for the Knowledge Manager and on the local shipboard intranet for the end-users. The User Interface will be able to communicate via the HTTP or HTTPS protocols and return self-describing data sets (XML) based on self-describing queries (XQL) from outside applications using internet based messaging (SOAP protocol). The User Interface’s legal queries (XML Schema/DTD) will be published to ensure that other external applications can gain access to the functionality of the DOC. The User Interface will parse the XML query and qualify the query request.
Indexing function – Indexing function will provide a predefined indexing schema (XML), so the Knowledge Manager can query and identify the available documents at the data store. The indexing schema will be heavily influenced by the metadata requirements being developed by the metadata working group. The metadata will be a part of the configuration file that will contain each document being passed through the system. The configuration file will be used throughout the TDKM system for communication. External applications will gain access to the indexing schema through the User Interface. It should be noted that this indexing schema should be the same indexing schema used by the Shipboard Data Loader to update a ships library in disconnected mode.
The Knowledge Broker Environment is made up of several individual services that function together to create an overall knowledge management function. These functions can be considered separate entities, but they must communicate between each other to provide the overall goal of providing the warfare community with an integrated technical data knowledge management function. They include the following:
An overall Knowledge Manager that identifies the user and knows where the applicable data that the user needs is located.
A user interface portlet that communicates the appropriate information to and from the Knowledge Manager.
A Configuration Manager function that provides the Knowledge Manager with the ability to identify which data is applicable to a specific user.
A synchronization service that updates the shipboard data sets with the most current data available.
The Knowledge Manager will have two major implementations working in conjunction with each other. The Warfare Community Knowledge Manager will be installed at a shore location and be administrated by the shore-based command; however, it is envisioned that these commands will be very close organizationally and physically to the operational units. There will also be a component of the Knowledge Manager that will be installed on-board the ships and administrated by the shipboard command, which will permit local modification of the digital library as needed and determined by the using activity. There is no intent to let the technology dictate the business model at the user level. The Warfare Community Knowledge Manager will be considered the parent node for the Knowledge Management System and each shipboard installation will be considered a child node that can operate independently (disconnected) from the parent node but still relies on the parent node to determine the latest data available for the ship.
The Knowledge Manager Administrator interface will be web enabled to accommodate remote administration. The following administration functions will be included.
Synchronization Setup.
Index Crawler Setup
Configuration Manager Setup.
Database Update.
Published External Application Interface (EAI) for external application integration.
Profile Management – The Knowledge Manager (KM) provides profile management and receives profile descriptions from other applications via the External Application Interface (EAI). The KM provides management of its own profiles but can use the descriptions provided by the selected portal. Although, any selected portal could play a role in their profile management, it would still be the KMs responsibility to ensure proper access and to provide a profile template to the selected portal. The functionality of the KM based on profile descriptions should be the same whether it is being controlled internally or being accessed via the (EAI).
Synchronization setup shall allow customization through an active synchronization list. The administrator will be able to add or delete from a synchronization master list based on factors other than input from the configuration manager. This provides the ability to knowledge manage documents/MPUs/MSOs that do not specifically fall into the configuration management business rules but still need some sort of oversight to ensure that the end user receives the most current document.
The synchronization service will perform data synchronization between the Wholesaler and Retailer Environments. The Synchronization Service will identify the Shipboard Knowledge Manager by the ship’s profile. Based on the profile, the synchronization service will identify the applicable data necessary to make a complete digital library for the specific Shipboard Knowledge Manager. The synchronization service will identify the applicable updates by communicating with the Configuration Manager and Warfare Community Knowledge Manager then doing a comparison of the identified updates with the current data set being controlled by the Shipboard Knowledge Manager. The synchronization service will then compare all the identified updates to those available on the Wholesaler. The synchronization service will then locate and transfer all necessary and available data to the Shipboard Knowledge Manager then perform the appropriate add, modify or delete actions necessary to completely synchronize the Shipboard Knowledge Manager’s data library. Only the data applicable to the identified profiles will be synchronized. Additionally, only the out of synch data will be transferred between the Warfare Community Knowledge Manager and the Shipboard Knowledge Manager, i.e., incremental update technology will be employed. If the Warfare Community Knowledge Manager’s identified data already matches the Shipboard Knowledge Manager’s data, the Synchronization Service will not transfer the data. The Synchronization Service will also report all actions to both the Warfare Community Knowledge Manager Administrator and Shipboard Knowledge Manager Administrator.
The Synchronization Service will be able to operate in continuous mode with synchronization actions being performed on a predefined schedule based on system settings controlled by either the Shipboard or Warfare Community Knowledge Manager Administrators. While in continuous mode, the synchronization service will monitor all data applicable to a particular profile and with the help of the Index Crawler identify and synchronize any data being added, modified or deleted at the predefined data stores. Once data has been updated at one of the data stores, the Synchronization Service will automatically synchronize the Shipboard Knowledge Manager’s data library.
The Synchronization Service will also be able to operate in both “push” and “pull” mode with the mode to be determined by the users and not the technology or the application. Either the Shipboard Knowledge Manager or Warfare Community Knowledge Manager Administrator will have the ability to initiate the manual execution of the Synchronization Service.
The Shipboard Synchronization Service will also be able to operate in standalone mode. This mode will occur when the ship is not connected to the pier but still receives data on some form of transportable media (e.g. CDROM or DVD) from an outside organization through one of the official distribution channels. A likely scenario for the use of this service will be during a long deployment when the ship is unable to connect to the Warfare Community Knowledge Manager and perform an online synchronization. While in manual mode, the Shipboard Administrator will place the newly provided data in a predefined location on the local shipboard network, and the Shipboard Synchronization Service, with the help of the Shipboard Index Crawler and Shipboard Configuration Manager, will identify the necessary data in the update and synchronize the new data with the existing shipboard data set.
The Configuration Manager Service can obtain information from external Navy information systems and use this input to determine which data is applicable to a specific command, ship or user. Based on the level of granularity in which the data is tracked, the configuration manager service will identify which Minimal Published Units (MPUs), Minimum Shareable Objects (MSOs) and documents are applicable to a specific profile based on input from the Knowledge Manager.
The Configuration Manager will employ a Web-based service and be able to identify and return data to an external application describing the technical documentation applicable to an individual class of ship, multiple classes of ships, and individual ship or multiple ships. The data will contain the appropriate revisions/changes applicable to the requested unit. The Configuration Manager will be able to return data sets that include large amounts of configuration data such as all of the technical manuals and drawings applicable to a specific ship or return the change/revision of a specific drawing or technical manual based on the technical document number and its applicable unit.
The Configuration Manager will be considered a service that runs behind the scenes. The data being returned by the Configuration Manager will either be processed by an external application or be rendered by the external application.
A Web-based interface will be included, which will be used to provide the shore-based users the ability to communicate with the Warfare Community Knowledge Manager. All data accessed through the Shore-based User Interface will be located in its original distribution point or command specific information located locally at the Warfare Community Knowledge Manager’s site.
The Shore-based User Interface will allow the use of predefined profiles or allow the end-users to customize their profile to gain access to all or a portion of the data being managed by the Knowledge Manager. This will allow the users access to filter or unfilter data based on their specific needs.
A good example would be a shipyard worker who is only interested in data related to a specific submarine. The user would select a predefined profile for that submarine. However, the next day the shipyard worker needs information about high-pressure air compressors and will need to search the entire knowledge store for the information. The Shore-based User Interface will allow an unfiltered search for the data to find the largest data set available. Additionally, the shipyard worker may want to create a custom profile to narrow the amount of data to a specific area of interest but still provide access to a larger portion of the data store when compared to a predefined profile.
The Shore-based User Interface is not intended to be a primary user interface portal but to provide a service that a primary portal can use to locate and manage technical documents. The Shore-based User Interface will be able to “snap-in” to existing systems and rely on those system’s user management functions, such as profiles, to filter the information to a specific topic or user. The portal will provide a Web-based interface that presents information in a format to which users are already accustomed and allows users at all levels to simultaneously access the system using nothing more than a standard web browser. Communication to/from the Shore-based User Interface via the portal will be accomplished via the Knowledge Manager EAI.
The EAI will be a Web services interface that will provide a common interface structure so other programs can access the functionality of the Knowledge Manager. The EAI interface mechanisms will be published [Web Services Definition Language (WSDL)] for the ease of use by third party applications and will describe the legal methods and attributes of the Knowledge Manager. Communications with the Knowledge Manager from third party applications will be accomplished via HTTP or HTTPS protocol using XML as a self-describing communication command. HTTP or HTTPS shall be the primary communication protocol.
The Knowledge Manager EAIs legal methods and attributes will be published to ensure that other external applications can gain access to the functionality of the Knowledge Manager. The EAI will parse the XML query against the schema and qualify the query request.
The shipboard environment will be able to operate in two basic modes. The first mode will be considered the connected mode when the Shipboard Knowledge Manger component of the digital library is connected to the shore-based network (such as when the ship is in port) and in communication with the Warfare Community Knowledge Manager. During this period, the shipboard digital library can be placed in a state of synchronization between the Shipboard Knowledge Manager and Warfare Community Knowledge Manager. Shipboard users will still access the required data from the shipboard data store. It will be the responsibility of the synchronization service to ensure that the shipboard users have the ability to view the most up to date data available. When in this mode, the shipboard users will be able to access information directly through the Warfare Community Knowledge Manager interface to the supplier network. This situation may occur when a shipboard user has the need to view data not directly applicable to their ship. The second mode is the disconnected mode when the ship is at sea and does not have the means to communicate with the Warfare Community Knowledge Manager. While in this mode, all data will be accessed via the ships local data store. This data should be updated based on the last synchronization session with the Warfare Community Knowledge Manger or via CD updates while in disconnected mode.
The Shipboard Knowledge Manager component will be installed on the ships and administrated by the shipboard command. In general, the functionality available to the broker environment will be duplicated at the Retailer Environment, since the Retailer Environment will have the capability to operate in disconnected mode. While in the connected mode, the Warfare Community Knowledge Manager will be considered the parent node for the Knowledge Management System and each Shipboard Knowledge Manager installation will be considered a child node. The Shipboard Knowledge Manager will rely upon the Warfare Community Knowledge Manager to determine the latest data available for the ship.
The Shipboard Index Crawler will be available to the Shipboard Knowledge Manager and can be used to create access lists and predefined search spaces while the ship is in disconnected mode. The Shipboard Knowledge Manager Administrator should only use the Shipboard Index Crawler when the ship is unable to connect to the Warfare Community Knowledge Manager for extended periods, and it becomes necessary to update the shipboard data set via manual means. The Shipboard Index Crawler will parse data based on the same indexing schema designed for the Warfare Community Knowledge Manager’s Index Crawler. This implies that either the data has to arrive with appropriate indexing schema or the Shipboard Knowledge Manager will be able to convert legacy-indexing schemes into the Warfare Community Knowledge Manager’s compatible indexing schema.
The Shipboard Synchronization Service will be available to the Shipboard Knowledge Manager Administrator while the ship is in the disconnected mode. This service should not be confused with the Warfare Community Knowledge Manager Synchronization Service that operates in connected mode.
The Shipboard Synchronization Service may be utilized when the ship is not connected to the pier but still receives data from an outside organization through one of the official distribution channels. A likely scenario for the use of this service will be during a long deployment when the ship is unable to connect to the Warfare Community Knowledge Manager and perform an online synchronization. While in manual mode, the Shipboard Administrator will place the newly provided data in a predefined location on the local shipboard network and the Shipboard Synchronization Service, with the help of the Shipboard Index Crawler and Shipboard Configuration Manager, will identify the necessary data in the update and synchronize the new data with the existing shipboard data set.
Identifies which data is applicable to a specific command, ship or user. This may not be necessary if the Warfare Community Knowledge Manger has done its job correctly, because only the data applicable to the local ship will be on the shipboard data store. Therefore, everything that can be accessed by a user on the ship is applicable to that ship. The onboard configuration manager will require an update prior to synchronization to accurately represent to the shipboard KM what documents the ship needs. If there is no update, only those records already synchronized in connected mode would be in the Shipboard Configuration Manager. The files that the Shipboard Knowledge Manager is attempting to synchronize would not appear on the list of what should be on the ship. This would show no differences in the list of documents onboard and the documents needed. With no differences, the synchronization would not take place. Therefore, any new information added to the ship’s library would have to first update the Shipboard Configuration Manager then run the Shipboard Synchronization Service to load the data to the Knowledge Manager.
The shipboard component of the Knowledge Manager Administrator’s interface will be available to the local managers to accommodate remote administration. The following administration functions will be included.
Warfare Community Synchronization Setup (connected mode)
Shipboard Synchronization Setup (disconnected mode).
Shipboard Index Crawler Setup (disconnected mode).
Shipboard Configuration Manager Setup.
Shipboard Database Update.
Profile Management – The Shipboard Knowledge Manager (KM) will provide profile management to personnel onboard based on the profile templates created by TDKM. It will still be the KMs responsibility to ensure proper access and to provide the template necessary to create the profile. The functionality of the KM based on profile descriptions should be the same whether it is being controlled internally or being accessed via the EAI.
A Web-based interface will be used to provide the shipboard users the ability to communicate with the Shipboard Knowledge Manager. In most cases, all data accessed through the Shipboard User Interface will be located on the Shipboard network. However, the Shipboard User Interface will allow the users to access information related to other ships or classes while in connected mode.
The Shipboard User Interface is not intended to be a primary user interface portal but to provide a service that a primary portal can use to locate and manage technical documents. The Shipboard User Interface will be able to “snap-in” to existing systems and rely on those system’s user management functions, such as profiles, to filter the information to a specific topic or user. The portal will provide a Web-based interface that presents information in a format to which users are already accustomed and allows users at all levels to simultaneously access the system using nothing more than a standard web browser. Communication to/from the Shipboard User Interface via the portal will be accomplished via the Knowledge Manager EAI.
The Naval Training community has also taken steps to utilize XML to describe its training products. Leveraging the work conducted by the Advanced Distributed Learning (ADL) initiative, the Navy is essentially requiring that Navy training products be developed in smaller, reusable chunks for display within a web browser. This is in contrast to past efforts, where courses or learning modules were delivered as a large, single executable that could be viewed only with a proprietary runtime application.
The ADL initiative was established in 1997 to develop a DoD strategy for using learning and information technologies to modernize education and training and to promote cooperation between government, industry and academia. ADL defined four high level requirements for learning content:
reusability
accessibility (or discoverability)
durability
interoperability
With these “ilities” in mind, ADL has issued the Sharable Content Object Reference Model (SCORM). Currently at Version 1.2, SCORM defines a Content Aggregation Model and a Run-time Environment for learning objects. SCORM itself is a compilation of standards or specifications from leading technology groups across the globe including:
IMS Global Learning Consortium, Inc.
Aviation Industry CBT Committee (AICC)
Alliance of Remote Instructional Authoring & Distribution Networks for Europe (ARIADNE)
Institute of Electrical and Electronics Engineers (IEEE)
The SCORM Content Aggregation Model addresses the creation, discovery and aggregation of reusable objects. It contains:
Content Model
Meta-data
Content Packaging
The Content Model describes the SCORM components necessary to build a learning experience from reusable learning resources and how these lower-level resources are used are aggregated into higher level units of instruction.
Assets — Assets are electronic representations of media such as HTML pages, PDF files, JPG/GIF images, sound bytes, etc. An Asset can be described with Asset meta-data to allow for search and discovery within online repositories.
SCOs — Sharable Content Objects (SCOs) form the basic building block of SCORM. They represent a collection of one or more assets and are described by SCO meta-data for discovery and re-use. A SCO utilized the SCORM Run-time Environment to communicate with a Learning Management System. It is at the SCO level where re-usability is targeted.
Content Aggregation — The Content Aggregation is a map that can be used to aggregate learning resources (assets, SCOs) into a cohesive unit of instruction. It also provides the mechanisms for defining the sequence that learning resources are to be presented to the user (SCORM Version 1.3 will address sequencing in more detail).
The SCORM meta data requirements improve the possibility that SCORM components will be discovered and reused. The meta data requirements at each of the three component levels; Content Aggregation, SCO and Asset, can be quite extensive. However, not all meta data fields are required, for ADL has left it up to the discretion of the individual communities that adopt SCORM to tailor (extend) the baseline SCORM meta data requirements as they see fit.
The purpose of Content Packaging is to provide a standardized way to exchange digital learning resources between different systems or tools. It can also define the structure or organization and the intended behavior of a collection of learning resources. The Content Package is essentially a zip file that contains an XML manifest file and all the associated physical resources required to support the learning resource.
The purpose of the SCORM Run-time Environment (RTE) is to provide a means for interoperability of SCO-based learning content and Learning Management Systems. Regardless of the tools used to build the learning resource, SCORM compliant products must be interoperable across multiple LMSs. For this to be possible, there must be a common way for content to communicate with an LMS. SCORM addresses this issue through the three components of the RTE; Launch, Application Program Interface and Data Model. (Note: The details of the RTE are complex and outside the scope of this paper. Please access ADL's website for more information on all of the SCORM requirements.)
As the training and tech data communities within the Naval Community attempt to share larger amounts of data, a catalyst was needed to assist the sharing process to move forward. The TDKM project and SCORM appear to fit the bill. There are many similarities in the development approach of information products each community is taking:
Smaller chunks of data (SCOs and MSOs)
Describing their product using XML meta data
Storing their reusable objects in repositories
Currently, when developing a training product, training developers will use the technical manual as source material. The tech manual is either directly referenced via a hyperlink, or the material is copied and pasted into the training application. When TDKM matures, the vision is to store individual chunks (MSOs) of technical data (maybe at the paragraph level? chapter level? section level? document level?) in an online repository that is accessible by both the tech data community and Navy training community. The MSOs would be described not only by meta data required by the tech data community, but also by SCORM compliant meta data required by the training community. Developers in each community would search each others repositories for related products and combine or package for delivery to Naval personnel.
  |
Design & Development by deepX Ltd. 2002 |
