Document location | CVS:smete/requirements.html; Scott Harrison computer |
Project title: | SMETE & LON-CAPA GATEWAY |
Document scope: | Requirements Analysis |
Project supervisors | Gerd Kortemeyer, Michigan State University;
and Andy Dong, UC-Berkeley |
Project implementation | Eric Fixler and Scott Harrison |
RCS ID | $Id: requirements.html,v 1.1 2002/02/07 17:34:58 harris41 Exp $ |
National Science, Mathematics, Engineering, and Technology Education Digital Library (NSDL) | LearningOnline Network with CAPA | |
<----- harvesting ----- | ||
GATEWAY COMPUTER | ||
----- mirroring -----> | ||
The effort described herein is part of a funded pilot project to investigate integration between the National SMETE Digital Library (NSDL) [1] and the LearningOnline Network with CAPA (LON-CAPA) [2].
NSDL is meant to index and point to services across the "deep web"; there are significantly large archival collections of online multimedia resources available for scholarly study [3]. NSDL attempts to implement a uniform protocol for the searching and service referencing of these resources. This amounts to three steps: searching across metadata, viewing metadata records, and downloading a resource/service.
Examples of "services" might include: availability of CD-ROMs/DVDs, interlibrary loan requests, and supplemental paper media.
LON-CAPA is meant to deliver online educational resources across a transparent, distributed network of load balancing and instructor collaboration. Course/classroom services and extensive "homework problem" delivery and assessment features are available. LON-CAPA centers around users as the fundamental data object. A user logs in, selects an available role (student, teaching assistant, instructor, course coordinator, or a dozen other choices). This role confers a set of privileges within the system by which the user can then create/complete homework problems, view class statistics, browse or search viewable resources, set up courses, and so on (depending on the available role that a user selects).
From the standpoint of NSDL, two things must happen on the gateway: 1) LON-CAPA metadata must be available in a suitable XML format (IMS and/or Dublin core with educational extensions); and 2) LON-CAPA must implement an OAI-compatible harvesting protocol [3].
From the standpoint of LON-CAPA, two things must happen via the gateway: 1) maintaining transparency--all interaction with NSDL is to be seamless and "on-the-fly" from the standpoint of users; and therefore 2) tight integration involving caching and mirroring similar to the Cornell strategy [4] is anticipated.
Open issues: There remain outstanding issues on user authentication and online usage of academic material--some of which will likely remain open after conclusion of this pilot project. Within these constraints, it is still reasonable to think there are large amounts of users and academic material that are to be legitimately handled between the two systems. A priority of the pilot project is to "explore clear and present specifics of how roads can be built and roadblocks can be removed".
Software stability: Both LON-CAPA and NSDL are systems of relatively new usage and development. Therefore, no long-term guarantee can be made as to the stability of the gateway in relation to LON-CAPA and NSDL. Within this constraint, demonstrating a current working solution takes priority over longer-range issues specific to the evolution of either LON-CAPA or NSDL. Thus customization of the gateway server may or may not branch independently away from developing designs associated with LON-CAPA and/or NSDL (especially LON-CAPA since the gateway server will initially be set up as a LON-CAPA library server [1]).
Time to completion: This project is estimated to involve 2-3 weeks of "full-time" programming by the two programmers associated with implementation (Fixler & Harrison). In reality, this equates to approximately 100 hours of programming for each programmer and will be distributed over the next couple months (completion by March).
The metadata must be compatible. As NSDL and LON-CAPA transmit resource information, there needs to be a translation to/from NSDL's IMS/Dublin Core format to/from LON-CAPA's simpler metadata format (see all three sections of the Appendix at the end of this document).
LON-CAPA faces two choices: it can either translate to the Dublin Core format with educational extensions (IEEE) or translate to the exhaustive IMS Core and SEL standard.For this project, the goal is for LON-CAPA to allow access to resources which are available in a 100% online format (in other words, it is not necessary for LON-CAPA to coordinate access to NSDL "services" described in the Introduction).
For this project, the goal is to allow NSDL access to LON-CAPA resources of low granularity (see Appendix C). Availability and dissemination of higher granularity resources (such as courses) will be a capability outside the bounds of this project. It will be documented though as to what software location this capability might be introduced.
In order for sufficient inter-operation to take place, there needs to be accurate handling of the following metadata values (accuracy involving one-to-one mapping or other repeatable solutions):
Communications "from NSDL to LON-CAPA" occur strictly through the gateway computer via the HTTP protocol (and OAI syntax of HTTP request [3]).
Communication "from LON-CAPA to NSDL" occur in two different ways. 1) A mirrored repository of available NSDL metadata and resources is gathered through an HTTP web-crawl (using the OAI syntax [3]). 2) Non-gateway computers in the LON-CAPA network access the gateway through a combination of HTTP requests and a TCP/IP socket layer.
In an ideal world, there might be no need for restricting access to knowledge or resources. And, the pilot project is meant to demonstrate possibilities when a pool of resources are largely accessible. Part of this accessibility means being able to control the instances (however occasional) when resources are to receive special treatment in terms of their distribution.
There are to be three control "modules" (software abstract interface locations). One control module negotiates as to whether LON-CAPA mirrors a specific NSDL resource that is available for download. This control module may, for instance, dismiss resources with highly restrictive copyright policies or too great a size.
The second control module controls whether or not the NSDL resource is viewable by all LON-CAPA users or a specific group of LON-CAPA users (course coordinators, authors, LON-CAPA users at Ohio University, etc).
The third control module operates in the opposite direction (moving information from LON-CAPA to NSDL). This module will support user validation data being sent from NSDL (in other words, synchronized with an OAI request) to LON-CAPA; similar in spirit to other user authentication mechanisms being investigated by SMETE (such as Virginia Tech's V-CARD strategy).
There are complex and unforeseeable issues associated with these control mechanisms. The goal of this project is not to create a comprehensive solution in this respect. The goal is to demonstrate that informational control mechanisms can be implemented as need arises.
NSDL->answer_list_records_request NSDL->view_LONCAPAgateway_results NSDL->view_LONCAPAgateway_metadata_record NSDL->access_LONCAPAgateway_resource NSDL->answer_search_request NSDL->answer_metadata_record_request NSDL->answer_resource_request NSDL->search_against_LONCAPAgateway GATEWAY->search_against_LONCAPAnetwork GATEWAY->search_NSDLnetwork GATEWAY->view_LONCAPAnetwork_results GATEWAY->view_NSDLnetwork_results GATEWAY->view_LONCAPAnetwork_metadata_record GATEWAY->view_NSDLnetwork_metadata_record GATEWAY->access_LONCAPAnetwork_resource GATEWAY->access_NSDLnetwork_resource GATEWAY->reference_NSDLmirror LONCAPA->search_or_browse_against_NSDLgateway LONCAPA->view_NSDLgateway_results LONCAPA->view_NSDLgateway_metadata_record LONCAPA->access_NSDLgateway_resource LONCAPA->answer_search_request LONCAPA->answer_metadata_record_request LONCAPA->answer_resource_request
Two general functionalities are to be supported: LON-CAPA is to act as an OAI server, and NSDL resources are to be available for educational usage.
A typical OAI server request proceeds as follows. An internet user visits www.openarchives.org and decides to visit LON-CAPA. He is presented with a web interface screen to search all of the open LON-CAPA archives. He is thus carrying out the function: NSDL->search_against_LONCAPAgateway. The gateway receives his search request and invokes the function GATEWAY->search_against_LONCAPAnetwork. This function contacts all of the LON-CAPA library server, thereby enacting a network-distributed function of LONCAPA->answer_search_request. Finally, the user is able view the results in NSDL appropriate metadata format: NSDL->view_LONCAPAgateway_results.
Going in the other direction, a typical LON-CAPA server request proceeds as follows. A user visits a LON-CAPA access server and makes a search request; all the LON-CAPA library servers are contacted including the gateway, thus LONCAPA->search_or_browse_against_NSDLgateway. The gateway computer then proceeds to search the NSDL network, but by using a pre-compiled mirror copy of NSDL contents. Thus two functions are needed: GATEWAY->search_NSDLnetwork and GATEWAY->reference_NSDLmirror. Results are returned and are to be viewed; three functions are involved in this: LONCAPA->view_NSDLgateway_results, GATEWAY->view_NSDLnetwork_results, and again, GATEWAY->reference_NSDLmirror. A user selects a resource to access and three functions are involved: LONCAPA->access_NSDLgateway_resource, GATEWAY->access_NSDLnetwork_resource, and GATEWAY->reference_NSDLmirror
The GATEWAY->reference_NSDLmirror requires a mirror copy of NSDL. A mirror requires three web crawling functions to, on periodic and automatic basis, list archive contents, look at metadata, and retrieve resources: NSDL->answer_list_records_request, NSDL->answer_metadata_record_request, and NSDL->answer_resource_request.
The gateway server will have LON-CAPA software, and NSDL OAI server software. When possible, these software packages and protocols are to be treated as black boxes which are not to be re-engineered. By limiting the re-engineering of LON-CAPA and NSDL OAI components, we allow for further development of all three systems (LON-CAPA, OAI, and gateway) without interfering dependencies.
In the functional partitioning shown above, this means most of the software coding will involve the GATEWAY->* components. When gateway-specific changes are inseparably coupled with NSDL->* or LON-CAPA->* software components, it will be documented with the software and communicated to the project supervisors.
The gateway should be similar in performance to typical LON-CAPA library servers and NSDL OAI servers. This performance should compare the time involved to:
As a general rule, the performance times should not greatly exceed (>300%) those of regular LON-CAPA library servers and NSDL OAI servers. Lengthy processing times, as attributable to algorithms, are to be communicated to the project supervisors, and the software code location of the algorithms is to be indicated.
The gateway is to support both a LON-CAPA interface and a OAI interface (as well as the expected underlying functionalities for those existing software systems).
The gateway is a standard Linux computer with a static IP on the internet via ethernet. Gateway functionality is to be implemented within this one computer.
Legend * = control point ---> or <--- = data flow -*-> or <-*- = controlled data flow NETWORKORGATEWAYNAME->TEXT = function NSDL->view_LONCAPAgateway_results <--- NSDL->search_against_LONCAPAgateway <--- GATEWAY->search_against_LONCAPAnetwork <-*- LONCAPA->answer_search_request NSDL->view_LONCAPAgateway_metadata_record <--- GATEWAY->view_LONCAPAnetwork_metadata_record <-*- LONCAPA->answer_metadata_record_request NSDL->access_LONCAPAgateway_resource <--- GATEWAY->access_LONCAPAnetwork_resource <-*- LONCAPA->answer_resource_request LONCAPA->search_or_browse_against_NSDLgateway <-*- GATEWAY->search_NSDLnetwork <--- GATEWAY->reference_NSDLmirror LONCAPA->view_NSDLgateway_results <-*- GATEWAY->view_NSDLnetwork_results <--- GATEWAY->reference_NSDLmirror LONCAPA->view_NSDLgateway_metadata_record <-*- GATEWAY->view_NSDLnetwork_metadata_record <--- GATEWAY->reference_NSDLmirror LONCAPA->access_NSDLgateway_resource <-*- GATEWAY->access_NSDLnetwork_resource <--- GATEWAY->reference_NSDLmirror Building the mirror <-*- NSDL->answer_list_records_request <-*- NSDL->answer_metadata_record_request <-*- NSDL->answer_resource_request
There are to be three control modules as discussed in the "Information Description" section of this document. These functions will be refered to as:
GATEWAY->should_a_record_be_mirrored GATEWAY->should_a_LON_CAPA_user_access_this_record GATEWAY->should_an_NSDL_OAI_request_be_allowed
Since there will be no specific design for the control modules, the constraints are unknown.
The system states here are intended to describe the gateway computer. System states of LON-CAPA or OAI harvesting that are unrelated to the gateway service are therefore not shown.
Hardware bounds: The gateway will operate on one computer with a static IP, ethernet-connected to the internet. The computer will be a reasonably fast workstation with large hard disk capacity (>20 gigabytes). The computer will be Linux compatible and will have an Intel-compatible architecture.
Data & Metadata: The data and metadata used will conform to the protocols and existing realities of data and metadata currently present on the archives at www.openarchives.org and the LON-CAPA production cluster. If the data of resources or available metadata exceed the storage capacity of the gateway computer, then the pilot project will be executed on a subset of the NSDL archives with the assumption that the solution is scalable through the introduction and almost duplicate gateway servers and/or hard drives.
Network: A continously working internet is assumed.
Users: Users are generally considered to be members of the general public when requests are made in either direction (LON-CAPA to NSDL) or (NSDL to LON-CAPA); the software should be useful in this respect provided that sufficient amounts of public/free content exist.
User expectations: The searching, viewing, and download of resources should either be virtually instantaneous, limited by network bandwidth, or return the status of activity within 30 seconds. There should not be a labyrinth of interface screens imposed upon instructors or students as they navigate educational material.
Well-defined software: Are system dependencies reasonably catalogued? Can all the gateway-server-specific files be listed? Is there a CVS source-to-build-to-install procedure? Are any customizations of LON-CAPA files or NSDL OAI server-specific files documented and communicated to others involved in the pilot project? Is testing of gateway services automated so as to support stable software development in the future?
LON-CAPA system operability: Do all access handlers appear to be working? (If they are disabled for purposes of non-interrupted gateway processing, is this formalized, modular, and documented?) Specifically: user login, /res space, /res/NSDLDOMAIN/NSDLOWNER space, private construction space, course creation (RAT in the construction space), LaTeX processing, page rendering, metadata viewing, XML parsing, student completion resources (problem, exam, quiz, etc), and logging out.
NSDL system operability: Are all features present? Is there a web search interface? Are listing records, retrieving metadata record, and retrieving resource implemented correctly through OAI protocols?
Gateway services (specific functions): Are all of the GATEWAY->* functions tested against sample test input and output routines?
A correct solution to creating a gateway should return an answer of "yes" to all the test questions.
In addition to careful internal testing of the software by the implementation programmers and supervisors, there is to be an alpha-period of test usage by external personnel familiar with either LON-CAPA or NSDL with a recorded evaluation.
This is a first-pass effort at a problem. As such, the priority is in actively demonstrating the existence of a reasonable solution more than perfecting the complexities of tangential questions.
Therefore, tasks and choices gain importance as they most directly contribute to solving the total problem. For instance, tracking the versions of documents on NSDL could either be a simple series of incrementing numbers as documents change (similar to the LON-CAPA implementation), or could support the complex branching and labelling options of CVS. We would choose simple incrementation since this is the most direct and other features do not relate to the goals of the pilot project.
Despite the prioritization of importance, an overarching concern is whether the project augments future capabilities for integration. The functional design and validation scheme are meant, in part, to outline and modularize the software architectural locations for future potentially important features.
This Requirements document follows the outline presented in "Software Engineering A Practitioner's Approach, Fourth Edition" by Roger S. Pressman, 1997
This document reflects expectations, plans, and ideas; a number of which are attributable to Gerd Kortemeyer, Andy Dong, and Eric Fixler.
References
Number |
Element Name |
IMS Core or SEL |
|||||
---|---|---|---|---|---|---|---|
1 |
general |
|
|
|
|
|
|
1.1 |
|
idenfier:Reserved |
|
|
|
|
|
1.2 |
|
title |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
Core |
1.3 |
|
catalogentry |
|
|
|
|
|
1.3.1 |
|
|
catalogue |
|
|
|
Core |
1.3.2 |
|
|
entry |
|
|
|
Core |
1.4 |
|
language |
|
|
|
|
Core |
1.5 |
|
description |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
Core |
1.6 |
|
keywords |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
SEL |
1.7 |
|
coverage |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
SEL |
1.8 |
|
structure |
|
|
|
|
SEL |
1.9 |
|
aggregationlevel |
|
|
|
|
SEL |
|
|
|
|
|
|
|
|
2 |
lifecycle |
|
|
|
|
|
|
2.1 |
|
version |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
Core |
2.2 |
|
status |
|
|
|
|
SEL |
2.3 |
|
contribute |
|
|
|
|
|
2.3.1 |
|
|
role |
|
|
|
Core |
|
|
|
entity |
|
|
|
Core |
|
|
|
date |
|
|
|
|
|
|
|
|
datetime |
|
|
Core |
|
|
|
|
description |
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
SEL |
|
|
|
|
|
|
|
|
3 |
metametadata |
|
|
|
|
|
|
3.1 |
|
identifier:Reserved |
|
|
|
|
|
3.2 |
|
catalogentry |
|
|
|
|
|
3.2.1 |
|
|
catalog |
|
|
|
SEL |
3.2.2 |
|
|
entry |
|
|
|
SEL |
3.3 |
|
contribute |
|
|
|
|
|
3.3.1 |
|
|
role |
|
|
|
SEL |
3.3.2 |
|
|
entity |
|
|
|
SEL |
3.3.3 |
|
|
date |
|
|
|
|
|
|
|
|
datetime |
|
|
SEL |
|
|
|
|
description |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
Language |
SEL |
|
|
|
|
|
|
string |
SEL |
3.4 |
|
metadatascheme |
|
|
|
|
Core |
3.5 |
|
language |
|
|
|
|
Core |
|
|
|
|
|
|
|
|
4 |
technical |
|
|
|
|
|
|
4.1 |
|
format |
|
|
|
|
Core |
4.2 |
|
size |
|
|
|
|
SEL |
4.3 |
|
location |
|
|
|
|
Core |
4.4 |
|
requirements |
|
|
|
|
|
4.4.1 |
|
|
type |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
SEL |
|
|
|
|
|
string |
|
SEL |
4.4.2 |
|
|
name |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
SEL |
|
|
|
|
|
string |
|
SEL |
4.4.3 |
|
|
minimumversion |
|
|
|
SEL |
4.4.4 |
|
|
maximumversion |
|
|
|
SEL |
4.5 |
|
installationremarks |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
|
4.6 |
|
otherplatformrequirements |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
|
4.7 |
|
duration |
|
|
|
|
|
|
|
|
datetime |
|
|
|
SEL |
|
|
|
description |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
SEL |
|
|
|
|
|
string |
|
SEL |
|
|
|
|
|
|
|
|
5 |
educational |
|
|
|
|
|
|
5.1 |
|
interactivitytype |
|
|
|
|
SEL |
5.2 |
|
learningresourcetype |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
SEL |
5.3 |
|
interactivitylevel |
|
|
|
|
SEL |
5.4 |
|
semanticdensity |
|
|
|
|
SEL |
5.5 |
|
intendedenduserrole |
|
|
|
|
SEL |
5.6 |
|
learningContext |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
SEL |
5.7 |
|
typicalagerange |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
SEL |
5.8 |
|
difficulty |
|
|
|
|
SEL |
5.9 |
|
typicallearningtime |
|
|
|
|
|
|
|
|
datetime |
|
|
|
SEL |
|
|
|
description |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
SEL |
|
|
|
|
|
string |
|
SEL |
5.10 |
|
description |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
SEL |
5.11 |
|
language |
|
|
|
|
SEL |
|
|
|
|
|
|
|
|
6 |
rights |
|
|
|
|
|
|
6.1 |
|
cost |
|
|
|
|
Core |
6.2 |
|
copyrightandotherrestrictions |
|
|
|
|
Core |
6.3 |
|
description |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
Core |
|
|
|
|
|
|
|
|
7 |
relation |
|
|
|
|
|
|
7.1 |
|
kind |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
Core |
7.2 |
|
resource |
|
|
|
|
|
7.2.1 |
|
|
identifier:Reserved |
|
|
|
|
7.2.2 |
|
|
description |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
SEL |
|
|
|
|
|
|
|
|
8 |
annotation |
|
|
|
|
|
|
8.1 |
|
person |
|
|
|
|
SEL |
8.2 |
|
date |
|
|
|
|
|
|
|
|
datetime |
|
|
|
|
|
|
|
description |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
SEL |
8.3 |
|
description |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
SEL |
|
|
|
|
|
|
|
|
9 |
classification |
|
|
|
|
|
|
9.1 |
|
purpose |
|
|
|
|
Core |
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
Core |
9.2 |
|
taxonpath |
|
|
|
|
|
9.2.1 |
|
|
source |
|
|
|
SEL |
9.2.2 |
|
|
taxon |
|
|
|
|
9.2.2.1 |
|
|
|
id |
|
|
SEL |
9.2.2.2 |
|
|
|
entry |
|
|
SEL |
9.3 |
|
description |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
Core |
9.4 |
|
keywords |
|
|
|
|
|
|
|
|
langstring |
|
|
|
|
|
|
|
|
language |
|
|
SEL |
|
|
|
|
string |
|
|
Core |
Dublin Core # |
Dublin Core Name |
Dublin Core Label |
IEEE Learning Object Meta-data |
1 |
Title |
TITLE |
general.title |
|
The name given to the resource by the CREATOR or PUBLISHER. |
||
2 |
Author or Creator |
CREATOR |
lifecycle.contribute when lifecycle.contribute.role has a value of "Author". |
|
The person or organization primarily responsible for creating the intellectual content of the resource. For example, authors in the case of written documents, artists, photographers, or illustrators in the case of visual resources. |
||
3 |
Subject and Keywords |
SUBJECT |
general.keywords. For those wishing more specificity of Subject, a category of classification can be used with a purpose of "Subject". classification has elements for description, keywords, and taxonpath(s) that are specific for the purpose. |
|
The topic of the resource. Typically, subject will be expressed as keywords or phrases that describe the subject or content of the resource. The use of controlled vocabularies and formal classification schemas is encouraged. |
||
4 |
Description |
DESCRIPTION |
general.description |
|
A textual description of the content of the resource, including abstracts in the case of document-like objects or content descriptions in the case of visual resources. |
||
5 |
Publisher |
PUBLISHER |
lifecycle.contribute when lifecycle.contribute.role has a value of "Publisher". |
|
The entity responsible for making the resource available in its present form, such as a publishing house, a university department, or a corporate entity. |
||
6 |
Other Contributor |
CONTRIBUTOR |
lifecycle.contribute with the type of contribution specified in lifecycle.contribute.role. lifecycle.contribute can be repeated. |
|
A person or organization not specified in a CREATOR element who has made significant intellectual contributions to the resource but whose contribution is secondary to any person or organization specified in a CREATOR element (for example, editor, transcriber, and illustrator). |
||
7 |
Date |
DATE |
lifecycle.contribute.date when lifecycle.contribute.role has a value of "Publisher". |
|
The date the resource was made available in its present form. Recommended best practice is an 8 digit number in the form YYYY-MM-DD as defined in http://www.w3.org/TR/NOTE-datetime , a profile of ISO 8601. In this scheme, the date element 1994-11-05 corresponds to November 5, 1994. Many other schema are possible, but if used, they should be identified in an unambiguous manner. |
||
8 |
Resource Type |
TYPE |
educational.learningresourcetype. |
|
The category of the resource, such as home page, novel, poem, working paper, technical report, essay, dictionary. For the sake of interoperability, TYPE should be selected from an enumerated list that is under development in the workshop series at the time of publication of this document. See http://sunsite.berkeley.edu/Metadata/types.html for current thinking on the application of this element. |
||
9 |
Format |
FORMAT |
technical.format |
|
The data format of the resource, used to identify the software and possibly hardware that might be needed to display or operate the resource. For the sake of interoperability, FORMAT should be selected from an enumerated list that is under development in the workshop series at the time of publication of this document. |
||
10 |
Resource Identifier |
IDENTIFIER |
general.catalogentry. greneral.identifier is currently a RESERVED term, as there is no specified method for creation of a GUID. |
|
String or number used to uniquely identify the resource. Examples for networked resources include URLs and URNs (when implemented). Other globally-unique identifiers, such as International Standard Book Numbers (ISBN) or other formal names would also be candidates for this element in the case of off-line resources. |
||
11 |
Source |
SOURCE |
relation.resource when the value of relation.kind is "IsBasedOn". This reduction is currently under consideration within the Dublin Core Community. |
|
A string or number used to uniquely identify the work from which this resource was derived, if applicable. For example, a PDF version of a novel might have a SOURCE element containing an ISBN number for the physical book from which the PDF version was derived. |
||
12 |
Language |
LANGUAGE |
general.language |
|
Language(s) of the intellectual content
of the resource. Where practical, the content of this field should coincide
with RFC 1766. |
||
13 |
Relation |
RELATION |
relation.kind, relation.resource |
|
The relationship of this resource to other resources. The intent of this element is to provide a means to express relationships among resources that have formal relationships to others, but exist as discrete resources themselves. For example, images in a document, chapters in a book, or items in a collection. Formal specification of RELATION is currently under development. Users and developers should understand that use of this element is currently considered to be experimental. |
||
14 |
Coverage |
COVERAGE |
general.coverage |
|
The spatial and/or temporal characteristics of the resource. Formal specification of COVERAGE is currently under development. Users and developers should understand that use of this element is currently considered to be experimental. |
||
15 |
Rights Management |
RIGHTS |
rights.description |
|
A link to a copyright notice, to a rights-management statement, or to a service that would provide information about terms of access to the resource. Formal specification of RIGHTS is currently under development. Users and developers should understand that use of this element is currently considered to be experimental. |
<abstract></abstract> <author>Biology Account, MSU HHMI First Year Online Biology</author> <copyright>default</copyright> <creationdate>995924781</creationdate> <keywords></keywords> <language>seniso</language> <lastrevisiondate>996698088</lastrevisiondate> <mime>sequence</mime> <notes></notes> <owner>bio@msu, bio@msu (Michigan State University)</owner> <subject>Bio Information</subject> <title>The big Bio Map</title> |
|