 |
1EdTech Resource List Interoperability Version 1.0 Final Specification |
Copyright © 2004 1EdTech Consortium, Inc. All Rights Reserved.
The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name: 1EdTech Resource List Interoperability Best Practice and Implementation Guide
Revision: 8 July 2004
IPR and Distribution Notices
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © 2004 1EdTech Consortium. All Rights Reserved.
Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.
Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
Table of Contents
1. Introduction
1.1 Specification Overview
1.2 1EdTech RLI Specification Components
1.3 Structure of this Document
1.4 Nomenclature
1.5 References
2. Relationship to Other Specifications and Standards
2.1 Meta-data
2.1.1 IEEE Learning Object Metadata Standard
2.1.2 ISO 690-2 Citation Format
2.1.3 Dublin Core
2.2 Locators
2.2.1 Resolvable Locators - OpenURL
2.2.2 Other Locators
2.3 Behavior Services
2.3.1 1EdTech Enterprise Services Specification
2.4 Content Packaging
2.4.1 1EdTech Content Packaging Specification
2.5 Digital Repositories
2.5.1 1EdTech Digital Repositories Interoperability Specification
3. Creating, Managing, and Using Resource Lists
4. Implementation Recommendations
5. Stakeholders
6. Application Scenarios
6.1 Use Case 1
6.2 Use Case 2
6.3 Use Case 3
6.4 Use Case 4
6.5 Use Case 5
6.6 Use Case 6
6.7 Use Case 7
6.8 Use Case 8
6.9 Use Case 9
6.10 Use Case 10
6.11 Use Case 11
6.12 Use Case 12
About This Document
List of Contributors
Revision History
Index
1. Introduction
This section is not normative.
1.1 Specification Overview
The Resource List Interoperability (RLI) specification details how structured meta-data can be exchanged between systems that store and expose resources for the purpose of creating resource lists and those that gather and organize those Resource Lists for educational or training purposes. A typical example of such a resource list is a reading list.
The specification is based on an abstract service behavior and data model that describes in generalized terms a resource at the item level, a collection of these resources (i.e., a list), and the behaviors associated with a resource list management service. The data model is then bound or expressed in XML, combining elements that primarily map to subsets of the IEEE-LOM (Learning Object Metadata) and ISO 690-2 bibliographic citation standards to describe the resource items and aggregated resource list. The abstract service interface is bound to web services expressed as WSDL. The 1EdTech Content Packaging specification wraps the resource list to enable transfer between systems. Because the data model is generalized, other bindings may be (and it is expected, will be) added to future releases of the specification (please see Information Model for a fuller description).
1.2 1EdTech RLI Specification Components
This document is the 1EdTech RLI Best Practice and Implementation Guide. As such it should be used in conjunction with:
- 1EdTech Resource List Interoperability Information Model;
- 1EdTech Resource List Interoperability XML/WSDL Binding;
- 1EdTech Resource List Interoperability Conformance Requirements.
1.3 Structure of this Document
The structure of this document is:
1.4 Nomenclature
1.5 References
| [RLI, 04a] | 1EdTech Resource List Interoperability Information Model v1.0, A.Jackl, 1EdTech Consortium, Inc., July 2004. |
| [RLI, 04b] | 1EdTech Resource List Interoperability XML/WSDL Binding v1.0, A.Jackl, 1EdTech Consortium, Inc., July 2004. |
| [RLI, 04d] | 1EdTech Resource List Interoperability Conformance Requirements v1.0, M.Maljkovic, 1EdTech Consortium, Inc., July 2004. |
| [IEEE LOM] | IEEE 1484-12:2002, Standard for Learning Object Metadata, http://ltsc.ieee.org |
| [IMSBUND] | Using 1EdTech Content Packaging to Package Instances of LIP and Other 1EdTech Specifications, v1.0, B.Olivier, M.McKell, 1EdTech Consortium, Inc., August 2001. |
| [IMSCP] | 1EdTech Content Packaging, v1.1.3, 1EdTech Consortium, Inc., June 2003 |
| [IMSDRI] | 1EdTech Digital Repositories Interoperability Specification v1.0, 1EdTech Consortium, Inc., January 2003. |
| [IMSES, 04] | 1EdTech Enterprise Services v1.0, 1EdTech Consortium, Inc., June 2004. |
| [ISO 690-2] | ISO 690-2 Citation Format |
2. Relationship to Other Specifications and Standards
2.1 Meta-data
The RLI specification structures the description of resources and resource lists for the purpose of easily sharing them between the meta-data and content repositories (OPACs, electronic journals, etc.), of libraries, publishers and their vendors, and the course management systems and learning object repositories of the e-learning domain. To better ensure close interoperability with the 1EdTech community's meta-data specification for describing learning objects and because the RLI specification has been generated within that community, the IEEE-LOM data model standard forms the foundation of the RLI data model.
The IEEE-LOM alone, however, is insufficient to describe the reading list resources typical of the library and publishing communities that the RLI specification addresses in particular. This situation is complicated by the fact that libraries and publishers themselves employ no basic, universal bibliographic meta-data standard that describes the full range of textual content they provide. The 1EdTech RLI specification consequently uses meta-data elements from a number of standards to describe a resource list and its component resources. The following sections briefly treat each of the meta-data schemas that contributed elements to represent the RLI data model. It should be emphasized that the RLI element set is not intended to be the missing universal bibliographic meta-data standard alluded to above; but RLI does define a core set of elements sufficient to support a full range of basic bibliographic citation types and standard locator schemas.
Finally, it should also be noted that there is a very close relationship between the emerging OpenURL resource locator standard and RLI (see details in sub-section 2.2.1). Growing compliance with OpenURL will ensure that the kind of structured meta-data standard citations required will be readily available to those applications intending to use them.
2.1.1 IEEE Learning Object Metadata Standard
The IEEE LOM data model has been developed to describe complex digital "learning objects", e.g., an interactive simulation; yet, it is also fairly general in its scope. Because of the LOM's broad purview, many of the RLI meta-data elements within the RLI Information Model map fairly readily to the LOM. Despite the relative ease in mapping to RLI meta-data elements, the LOM is not fully suited to describe a fundamental requirement of RLI, a bibliographic citation; nor does it provide a means for describing all the meta-data needed to support standard locator schemas, another requirement.
For a bibliographic citation, the LOM lacks adequate semantic specificity and structure. In addition, it does not provide for the sequencing of elements which is important for certain citation types, i.e., part of a whole such as a volume in a multi-volume set, a chapter of a book, or an article in a particular issue and volume of a journal series.
Structurally, the meta-data within the LOM for several key components of a bibliographic citation is stored in a single element, 7.2.2:Resource.Description. This concatenation of elements makes it much more difficult to parse and display the information in a typical bibliographic citation format, as recommended by as ISO 690-2 (see sub-section 2.1.2).
Ironically, the element concatenation of the LOM matches the treatment of citation meta-data by many of the content vendors whose resources the RLI specification targets. To date there has been virtually no compliance with the ISO standard or adoption of any other consistent format across the vendor community. To accommodate this fact, desktop bibliographic management software such as ISI's EndNote and ProCite come packaged with multiple filters to parse and regularize the various ways that the different vendors structure citations. The lack of a consistent format has prevented the standardization of a method to import and export the meta-data necessary to aggregate discrete resources into resource lists. This makes it necessary to customize solutions for any implementation, resulting in aggregations that are very difficult to share; (and hence the value of an RLI specification).
Finally, the IEEE-LOM element 2.3.2:Lifecycle.Contribute.Entity does not contain a value for "owner" that is required by the RLI data model. This element was considered necessary for purposes of documenting, at the resource list level, the entity having the authority to decide about the permissions and constraints related to re-use of the resource list.
Please see sub-section 2.2.1 for implementation recommendations and the itemized list of elements that map directly to the LOM. See also RLI Data Model (section 4 of Information Model) for the semantics of each element.
2.1.2 ISO 690-2 Citation Format
The first release of the 1EdTech RLI specification expressly addresses traditional lists of resources, i.e., reading lists. Thus, the descriptive elements for the resources within this type of resource list are closely aligned to typical bibliographic citations, as described by the ISO 690-2 standard for bibliographic citations of electronic materials.
Another RLI element that does not appear either in the IEEE-LOM, or in the OpenURL specifications, but is included in the ISO 690-2 requirements is "Publication Place". It could be argued that from an electronic resources point of view, the place of publication is less relevant than in the print world. Instead, it is once again, the reliable locator of the resource that is most important. For this reason, the RLI specification does not require the "Publication Place" element, but does include it since many content providers provide the information as part of the meta-data that accompanies the display of the resource.
Please see sub-section 2.2.1 for implementation recommendations and the itemized list of elements that maps directly to the ISO 690-2 standard. See also RLI Data model (section 4 of Information Model) for the semantics of each element.
2.1.3 Dublin Core
The "Resource Type" element within the RLI specification for which the value is "bibliographic citation" does not exist, per se, in the IEEE-LOM. The dc:type element from the Dublin Core schema is used for describing these semantics. Also note that the value "bibliographic citation" is not included in the DC Type Vocabulary although a proposal to include such a phrase has been made and withdrawn in the past few years. The Learning Resource Type Vocabularies identified in the CanCore Guidelines for the Implementation of Learning Object Metadata 1.9 do not have a similar term either. Hopefully, one of the results of the successful adoption of the RLI specification will be the inclusion of an appropriate term either within one of the Learning Resource Type Vocabularies or the DC Type Vocabulary.
Future specifications will include implementation recommendations and the itemized list of elements that map directly to the Dublin Core. See also RLI Data Model (section 4 of Information Model) for the semantics of each element.
2.2 Locators
The RLI data model provides a "locator" element to store any locator information as part of the meta-data associated with a given resource and/or resource list. As well, the model contains other meta-data elements necessary for an application to construct OpenURLs and DOIs, if desired.
2.2.1 Resolvable Locators - OpenURL
NISO's OpenURL locator standard enables the context-sensitive resolution of user requests for digital library objects. Requests are fulfilled by the transmission of meta-data for the objects, including standard identifiers, to a resolution service, which in turn provides additional services available to the requesting user (e.g., full text for an article, an inter-library loan request form, etc.), depending on the user's institutional affiliations and authorizations or "context".
It is the San Antonio Profile Level 1 (SAP1) for journal or book of the OpenURL v 1.0 specification which provides a means to describe resources in citation format. In addition, SAP1 allows a citation to be further described by denoting the context in which a particular resource resides, such as the whole document of which a subpart is being cited. SAP1 encourages the parsing of citation meta-data so that it can be constructed as part of the locator string. For this reason, the RLI specification recommends that applications using RLI meta-data import and order the descriptive elements as discrete elements that correspond to those needed to construct an OpenURL, or use/leverage existing OpenURL locators in the resource records, when available.
Here is an example of a v1.0 OpenURL:
url_ver=Z39.88-2003 &url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx &rfr_id=info:ofi/rfr:db:mimas.ac.uk:zetoc &rft_val_fmt=info:ofi/fmt:kev:mtx:journal &rft.genre=article &rft.atitle=Phase compositions... &rft.jtitle=Scripta Materialia&rft.issn=1359-6462 &rft.aulast=Apps&rft.auinit=P.J.&rft.date=2003 &rft.volume=48&rft.issue=5&rft.spage=475&rft.epage=48
[From PowerPoint presentation of Ann Apps at NISO workshop on OpenURL, October 29, 2003, http://www.niso.org/standards/resources/appsopenurl-using.ppt]
OpenURL is not yet a universal standard, but its adoption is growing rapidly. It represents the current best chance for a widely accepted, relatively simple, but sufficiently broad meta-data structure for bibliographic data that will actually be implemented by vendors who have previously relied on proprietary solutions. Because RLI conforms to the San Antonio profile, Level 1, it should be relatively straightforward for OpenURL-compliant vendors to provide equally rich meta-data in the RLI format.
Future specifications will include implementation recommendations and an itemized list of elements that map directly to OpenURL. See also RLI Data Model (section 4 of Information Model) for the semantics of each element.
2.2.2 Other Locators
See the RLI Data Model (section 4 of Information Model) for the semantics of each element.
2.3 Behavior Services
2.3.1 1EdTech Enterprise Services Specification
The RLI abstract interface defines fairly generic Create/Read/Delete operations that are paralleled in the 1EdTech Enterprise Services Specification. One element critical to the practical implementation of RLI is establishing a relationship between a resource list and a "class" or group of users within a course management system. The 1EdTech Enterprise concept of Group can define a class to which a resource list is assigned or associated through the Resource List Assignment operation. The association between resource list and class is created at runtime and subsequently managed within the target system. Both the sending and target systems will need a common understanding of a Group (although this might not include membership data).
2.4 Content Packaging
2.4.1 1EdTech Content Packaging Specification
1EdTech Content Packaging is a specification for packaging learning resources (for example resource lists) for easier transport from one system to another, facilitating easier delivery, reuse, and sharing of materials. 1EdTech Content Packages enable the export of content from one virtual learning environment, content management system, or digital repository, and import into another while retaining information describing the learning resources and their organization (such as a table of contents). The use of the 1EdTech Content Packaging specification to package instances of other 1EdTech specifications such as 1EdTech RLI is described in the 1EdTech implementation handbook "Using 1EdTech Content Packaging to Package Instances of LIP and Other 1EdTech Specifications" [IMSBUND]. In the context of 1EdTech RLI an 1EdTech Content Package contains a resource list manifest that may include individual Resources and/or other Resource Lists. The Package Interchange File can be a ZIP, JAR, or a TAR file. The manifest is an XML file that describes what the Package contains and how the content is organized. The manifest XML file contains three main sections:
- a Meta-data section that describes the whole 1EdTech Content Package;
- a Resources section that lists the resources in the 1EdTech Content Package and any meta-data that describes them;
- an Organizations section that describes the structure of the resources within the 1EdTech Content Package.
For a Content Package containing a resource that is an XML-bound instance of a resource list conforming to this specification, the Resources section should specify that the resource is of type imsrli_xmlv1p0.
2.5 Digital Repositories
2.5.1 1EdTech Digital Repositories Interoperability Specification
There is a strong relationship with the 1EdTech Digital Repositories Interoperability (DRI) specification in that DRI and RLI are focused on interoperability within environments that span both online information services and e-learning provision. Both specifications are also focused on managing assets and meta-data as well as collections of information objects and learning objects.
In providing a broad interoperability context the 1EdTech DRI Information Model also presents a functional architecture that focuses on the most common repository functions (search/expose, gather/expose, submit/store, request/deliver, and alert/expose). These functions clearly have a role in managing resource lists.
The 1EdTech DRI Best Practice Guide details operational recommendations that have been adopted within RLI, in particular Web Services. The RLI abstract interface is expressed as a WSDL file, with SOAP specified for messaging and transport. Other recommendations have relevance for the searching and gathering of individual resources as well as resource lists per se.
3. Creating, Managing, and Using Resource Lists
While there has not been a great deal of published discussion about the practices of creating, managing, and using Resource Lists, per se, there has been related work going on in the Dublin Core Metadata Initiative. The Dublin Core Citation Working Group is in the process of writing guidelines for encoding bibliographic citation information in Dublin Core Metadata which may have some impact upon the practices associated with creating, managing, and using Resource Lists, and consequently upon the RLI specification, thus requiring future revisions of this specification.
4. Implementation Recommendations
Until there are reference implementations of the RLI specification, it is difficult to anticipate what would be the best practices associated with implementing it in any of the several repository or learning environments in which they might be found. Therefore, this section of the RLI specification will undoubtedly be expanded in the future.
5. Stakeholders
There are a number of stakeholders who stand to benefit from this specification. These stakeholders have been grouped into the following categories (a brief example use case is illustrated in the subsequent paragraphs; many of the use cases are applicable to multiple stakeholders and should not be considered exclusive to or exhaustive of a particular domain):
- Learners:
Learners will be able to easily access selected resources and/or specific resource lists, made available to them within the context of a specific learning environment. - Faculty:
Faculty will be able to log in to their course environment, and from there, search/browse for relevant library and other resources, build a resource list, and incorporate the resource list into the course environment, where it would become available to learners. - Instructional designers:
Instructional designers working with an authoring tool will be able to easily access resource lists and incorporate resources from them into structured course content in the fashion of other learning objects. - Librarians:
Librarians using a combination of library services will be able to select resources or use instructor-selected resources to build resource lists for specific courses or subject areas. Librarians would publish specific resource lists associated with particular courses or send them to a digital repository with the meta-data necessary for ready incorporation into a course management system. - Course management system vendors:
Course management system vendors will be able to integrate course management systems with library systems, content repositories and digital libraries that maintain reading lists through the exchange of resource list meta-data. - Learning content management system vendors:
Learning content management system vendors will be able to integrate learning content management systems with library systems, other content repositories and digital libraries that maintain reading lists through the exchange of resource list meta-data. - Library system vendors:
Library system vendors will be able to integrate library systems with course management systems through the exchange of resource list meta-data. Integrated Library Systems (ILS) that support course reserves, federated searching of catalog and article databases and bibliographic management facilities already provide services for the creation of personal reading lists. The definition of these lists as RLI meta-data will enable their ready transport into the course context. - Content repositories:
Content Repositories will be able to incorporate resource lists from other systems and store them as searchable digital objects. Content Repositories will also be able to receive resource list updates from the originating systems. - Content publishers:
Content publishers will be able to build resource lists in particular subject areas and publish them into searchable repositories for distribution to customers. Customers may acquire and deploy resource lists as learning objects for incorporation into course content.
6. Application Scenarios
These application scenarios comprise the functional requirements that were used to determine the scope and structure of the Information Model. They are included to help readers gain an understanding of the range of uses to which RLI may be put and to provide the initial ideas to help people apply RLI to their problems. The scenarios are not meant to imply any degree of constraint.
6.1 Use Case 1
Title: Resource List Is Created Based on Federated Search of Library and Third Party Licensed Databases
Goal: Instructor wants to create a new Resource List within a course that may include any of the following:
- Citations to print only articles within journals that the institution's library owns, with links to journal record and specific volume/copy information within the Online Public Access Catalog.
- Citations to print only books that the institution's library owns, with links to monograph record and volume/copy information within the Online Public Access Catalog.
- Citations to electronic books and journal articles, with links to the full text.
- Instructor searches library catalog and third-party licensed databases for desired resources.
- Instructor selects desired resources among search results to add to the Resource List.
- Instructor saves Resource List.
- Instructor exposes Resource List within the course environment.
6.2 Use Case 2
Title: Online Public Access Catalog Records of Printed Materials in a Resource List Are Prepared for Course Reserves
Goal: An instructor designates printed materials for course reserves in a Resource List.
- Instructor selects records for printed materials from an existing Resource List.
- Instructor submits records to Online Public Access Catalog's course reserves module.
- Reserves module flags corresponding records in the OPAC for course reserves processing.
- Library staff modify appropriate records to activate course reserves list.
The two previous use cases assume that instructors are the primary actors in the resource list creation process. Depending on institutional preferences, other staff, including library personnel, could be assigned and authorized to first create and then expose a resource list within the course environment.
6.3 Use Case 3
Title: Resource List Is Shared Between Courses and/or Course Management System (CMS) Environments
Goal: Instructor wants to move a resource list from one course or course management system to another.
- Instructor selects from a Course or CMS a resource list to share.
- Selected resource list is exported from a Course or CMS.
- Created resource list is imported into another Course and/or CMS.
6.4 Use Case 4
Title: Supplying the Learner with a Course Reading List
Goal: A learner within a CMS wants to access a resource list to locate readings and cite them in a bibliography.
- Learner chooses to view the resource list within a course.
- Learner chooses to view a resource from the resource list that is described within the Library Online Public Access Catalog.
- Learner is taken to the Library system which displays selected resource, either as a catalog record for an item in printed format or as a link to the item itself if in electronic format.
- Learner selects resource from the resource list.
- Learner exports resource meta-data.
6.5 Use Case 5
Title: Resource List is Created from Harvested Meta-data in a Personal Database
Goal: Instructor wants to create a new resource list using previously retrieved and stored citations from various information sources.
- Instructor opens personal database and selects resource records for inclusion in the resource list.
- Instructor exports selected records in 1EdTech RLI format.
- Instructor uploads list of records into CMS or resource list creation tool.
- Instructor exposes resource list within the course or virtual learning / learning management environment.
6.6 Use Case 6
Title: Resource List is Modified by the Instructor to Include Local Content
Goal: Instructor wants to edit an existing resource list to include locally created content, e.g., an unpublished manuscript.
- Instructor opens existing resource list.
- Instructor adds meta-data into 1EdTech RLI fields for file previously uploaded into course management system.
- Instructor saves modified resource list.
This showcases that resource lists when they arrive in a system should allow editing.
6.7 Use Case 7
Title: Extensibility for Vendor Specific Needs
Goal: Allow vendors (and other parties creating or managing learning resources) to extend the specification and incorporate proprietary extensions to the meta-data elements needed.
Vendor extends to resources specification to include proprietary information necessary to use or manage the resource list within the vendor's system.
6.8 Use Case 8
Title: Propagate Resource and Resource List changes to the system in which it is being managed Goal
Goal: Allows propagation of changes in the individual resources and entire resource lists to the management system. It assumes that the individual resource or resource list has been already created.
- New version of a resource list has become available, e.g., a new edition of a book that has just been received by the Library Acquisitions Department is included on the Course Reserve List managed by the campus Library ILS vendor.
- Faculty members using that resource list are notified of changes made to the resource list, and are given the option of accepting or rejecting it's inclusion in the environments in which it is currently being used. (Optionally, this behavior could have been set during create and/or deploy action for particular Course Resource or resource list; this would be an example of two way communication between Library and CMS Systems.)
- If Faculty decides to accept new version of Resource List, subsequent Learners accessing the Course Resource or resource list are presented with a new version.
6.9 Use Case 9
Title: Harvesting and Reusing of Resource and Resource List Meta-data
- Allows reuse of resource meta-data, coming from different systems and following different schemas, for resource.
- Allows creation of resource list meta-data.
- Provides tracking of administrative actions in the resource and resource list meta-data.
- Meta-data imported from various content providers maps into required and desired meta-data for newly created resources and resource lists.
- Resource and resource list meta-data is edited and modified, if necessary or desired upon inclusion into the learning environment.
- Administrative information (edit log, versions) is associated automatically in the resource and resource list meta-data.
6.10 Use Case 10
Title: Facilitating Reuse of Resources and Resource Lists by means of Annotations (References)
- Allows faculty to create multiple pedagogic annotations for each resource and resource list.
- Provides contextual information about the individual resource or resource list. Facilitates more granular referencing and use of discrete resources within a resource list, thus allowing more flexible reuse of resources within a learning environment.
- Faculty creates new Annotation(s) for a desired resource or resource listing.
- Thereafter, Annotations become a part of resource or resource list (in case of Resource export, and then import, annotation would also export and import).
6.11 Use Case 11
Goal: A library's digital repository is used to archive selected resource lists that have been used and within a VLE. The resource list and its meta-data are retained in the digital repository separately, but include contextual information about where the resource list has previously been used in the VLE. The VLE deactivates and archives courses that are not currently being taught. These courses may be reactivated in future terms, and instructors can then access the resource list and use it in the reactivated course, or in other courses. Changes to the resource list are added to the resource list archive as a newer version of the original resource list.
- A previously instantiated course is reactivated for the current term, thus making the resource list associated with the course visible to the current instructor.
- Instructor chooses to keep as part of the new version of the course the resource list used previously.
- The Instructor modifies the list.
- The modified resource list is archived with the course once the course is completed, and also separately within the digital repository.
6.12 Use Case 12
Goal: Resource list managers wish to create a list containing zero items. Empty resource lists may also be created automatically as part of the initial set up of a course environment.
- The instructor instantiates a list within the resource list manager.
- The instructor exits the system without entering an item in the resource list.
- Teaching Assistant adds resources to the list at a later dateTime.
About This Document
| Title | 1EdTech Resource List Interoperability Best Practice and Implementation Guide |
| Editor | Alex Jackl (1EdTech) |
| Team Co-Leads | Oliver Heyer (UC Berkeley), Mladen Maljkovic (WebCT) |
| Version | 1.0 |
| Version Date | 08 July 2004 |
| Status | Final Specification |
| Summary | This document describes the Resource List Interoperability Best Practice and Implementation Guide |
| Revision Information | July 2004 |
| Purpose | This document has been approved by the 1EdTech Technical Board and is made available for adoption. |
| Document Location | http://www.imsglobal.org/rli/rliv1p0/imsrli_bestv1p0.html |
| To register any comments or questions about this specification please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=22 |
List of Contributors
The following individuals contributed to the development of this document:
Revision History
Index
B
Behavior 1, 2
Bibliographic 1, 2, 3, 4, 5, 6
C
CanCore 1
Catalog 1, 2, 3
Citation 1, 2, 3, 4
Content Package 1
Course
content 1
environment 1, 2, 3
I
IEEE 1, 2, 3, 4
1EdTech Specifications
Content Packaging 1, 2, 3
Digital Repositories Interoperability 1
Learner Information Package 1, 2
Resource List Interoperability 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Vocabulary Definition Exchange 1
Interoperability 1, 2
ISO 1, 2, 3, 4
L
Learning 1, 2, 3, 4, 5, 6, 7
Learning Object 1, 2, 3
Libraries 1, 2
LOM 1, 2, 3, 4
LTSC 1
M
Meta-data 1, 2, 3, 4, 5, 6, 7, 8, 9
N
Normative 1
R
Records 1, 2, 3
Repositories 1, 2
Resource 1, 2, 3, 4, 5, 6
Resource list 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
Resource list meta-data 1, 2
Resources 1, 2, 3, 4, 5, 6, 7, 8, 9
RFC 1
S
Schema 1
SCORM 1
Services 1, 2, 3, 4
Standards 1, 2
Structure 1, 2, 3
W
W3C 1
1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this 1EdTech Resource List Interoperability Best Practice and Implementation Guide ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
1EdTech would appreciate receiving your comments and suggestions.
Please contact 1EdTech through our website at http://www.imsglobal.org
Please refer to Document Name: 1EdTech Resource List Interoperability Best Practice and Implementation Guide Revision: 08 July 2004
