From openmichigan

Contents 1 Background 2 Infrastructure features 2.1 First generation 2.1.1 Reasonable price for system 2.1.2 Sysadmin maintenance 2.1.3 Support community 2.1.4 Usable system interface 2.1.5 Access management 2.1.6 Batch upload of content with metadata 2.1.7 Media neutrality 2.1.8 Extensive and customizable metadata 2.1.9 Machine readable metadata 2.1.10 Hierarchies of content 2.1.11 Extensive indexing and search capabilities 2.1.12 Selective content push to additional servers 2.1.13 Web services API 2.2 Future generations 2.2.1 OCR text in video 2.2.2 Audio to text conversion 2.2.3 Integration with dScribe process and OERca 2.2.4 Extraction of embedded images within documents and presentations 2.2.5 Conversion of content to different file types 2.2.6 Conversion of document and presentation pages to images 2.2.7 Translation of documents to multiple languages 3 Interface features 3.1 First generation 3.1.1 Basic and advanced search interface 3.1.2 Dynamic and flexible search result filtering and sorting 3.1.3 Basic browsing interface 3.1.4 Display of related content 3.1.5 RSS feeds 3.2 Future generations 3.2.1 User-defined tagging of content 3.2.2 User favorites list/portfolio 3.2.3 User-ratings of content 3.2.4 Social network integration 3.2.5 Passive and active collaborative filtering of content 3.2.6 Dynamic and flexible browse filtering and sorting

[edit] Background

This page begins by setting some scope to the creation and delivery of OERs. "We want to deliver OER content in a way that is easily accessible to all, modular, contexualized, decomposed yet composable, shareable, trusted, usable, free, searchable, and attributable." The typical 5-P's model of the OER process looks like so:

producing <--> processing <--> publishing <--> presenting <--> preserving

The starting point for OERs is at the onset of content creation. Often, faculty or students author or produce content through some sort of educational environment. This production might use a variety of software tools including Google Docs, PowerPoint, wikis, blogs, 280slides and so on. In order to publish that content it must first be processed so that it is vetted for copyright or endorsement issues, and it is contextualized with associated metadata. We often call this processing "content clearing." When content is cleared, it goes through a publishing process that includes editing materials and deriving new formats of the content for wider accessibility and use. After the content is published, it must be presented in a way that allows users to access it. This presentation or delivery interface will vary from place to place. While we will most likely rely on a web-based delivery and distribution interface, we realize that sometimes the content is best presented through other means (especially when distributing content to users with low-quality internet connectivity). As OERs are published, they need to be preserved according to archival standards so that we have long-term copies of our courses and educational materials. This process may require the use of persistent URLs and formatting standards. While we have allowed the use of a variety of production tools for content, our group has spent time developing and using a processing tool, OERca, to clear content. Our publication and presentation platform is currently eduCommons, but we see a need to transition away from this type of static content delivery. At the moment, we have no method of preserving our courses or educational materials, but U-M runs an instance of DSpace called Deep Blue that may be used to begin archival of content. This discussion involves learning more about the different components of the model and seeing what existing software tools would be adequate for U-M's goals.

This document outlines a general set of system infrastructure and user interface requirements for delivering OER content (delivering, presenting) from the University of Michigan (Open.Michigan). While our current focus is on the presentation of content, we are interested in developing a platform that will provide a robust framework for not only presentation, but potentially production, processing, publication, and preservation. This set of requirements addresses our vision for immediate and future components for the user interface and supporting databases/backend infrastructure. During this exploration we intend to determine the following:

1. Which audience(s) Open.Michigan will support;
2. What critical components are necessary to establish Open.Michigan as a high quality, interactive, and useful OER content presentation site (now and in the future);
3. How (and through which tools) the necessary components will be implemented;
4. Who will participate in the design and construction of the necessary components;
5. When the necessary components must be completed (timeline).

Resource:

• OCWC: OCW Platform Comparison

Summary of our comparisons:

• OER Platform Comparison Table
• OER Platform Venn Diagram

Working notes:

• Notes from the DLXS meeting with John Weise
• Notes from the BlueStream meeting with Louis King
• Notes from the Deep Blue/DSpace meeting with Jim Ottaviani
• Notes from the platform discussion with UM, MIT, Stanford
• Notes from the Feb. 4 technical BlueStream meeting
• Notes from the Oct Drupal/educommons requirements meeting

[edit] Infrastructure features

[edit] First generation

[edit] Reasonable price for system

Description: While we prefer an open source system, whatever system we use must be reasonably priced. A $5 million dollar investment is probably not the way we want to go here.

[edit] Sysadmin maintenance

Description: It must allow a local group to do simple maintenance.

[edit] Support community

Description: Must have a considerable community for support. No ‘human bottlenecks’ where all changes have to go through a small number of people with the necessary knowledge and access.

Examples:

• Drupal has a large community base for support in developing modules or even on-site assistance.
• eduCommons support is limited to a few developers at enPraxis.
• BlueStream is a Umich specific project that currently has a few department/schools using it.

[edit] Usable system interface

Description: The user interface of the management system is both powerful and usable. This interface will allow administrators to access and manipulate content within the database easily and effectively.

[edit] Access management

Description: The management system assigns access rights to content at various levels of the hierarchy. Asset-level access rights are not essential as the majority of our work relies on access rights at a higher level (e.g. course). The groupings of permissions have not been determined.

[edit] Batch upload of content with metadata

Description: Users of the system will be able to upload large batches of content and add appropriate metadata to those batches. The batch upload will also include any previously attached metadata (from OERca, for instance). Appropriate metadata includes creator and collaborator info, copyright information (holders, licenses, etc.).

[edit] Media neutrality

Description: The system will handle a large set of media and file formats. This includes documents, presentations, audio, video (download and stream), graphics, objects and executables, installers, compressions, CADs, databases, GISs, page description languages (pdf, ps, css, xml), scripts, scientific data, spreadsheets, source code, virtual machines?, others?

Reference:

• file formats (wikipedia)

[edit] Extensive and customizable metadata

Description: The system will allow us to customize the metadata associated with content to conform to metadata standards, but also our own metadata fields.

[edit] Machine readable metadata

Description: The system reads/writes embedded metadata (e.g. XMP standard, Creative Commons liblicense), and creates RDF tags for web objects.

References:

• CC liblicense
• CC RDFa description

[edit] Hierarchies of content

Description: The system enables content to be stored in a hierarchical fashion (e.g. parent, child) for easy linkages between schools, departments, courses, materials, and content objects.

[edit] Extensive indexing and search capabilities

Description: The system will have a built-in indexing and search that is consistent, reliable, and powerful. This search capability needs a useful interface within the system and an easily integrated output to the web for our presentation user interface. Searches should be full-text and should allow the user to scope and delimit the query.

[edit] Selective content push to additional servers

Description: The infrastructure is capable of selecting content (and batches of content) to be pushed to individual or groups of shadow servers (flickr, iTunesU, YouTube, others?). May reside on our servers or theirs, depending on traffic.

[edit] Web services API

Description: The management system should provide standardized connections like a web services API to build on external applications and web designs.

Reference:

• web service (wikipedia)

[edit] Future generations

[edit] OCR text in video

Description: The system will recognize characters within a video and make that text searchable through indexing.

[edit] Audio to text conversion

Description: The system will ingest audio from audio files or video files and convert them to text. The system should be ~90% accurate (consider medical terminology, multiple languages).

[edit] Integration with dScribe process and OERca

Description: The dScribe work tool, OERca, will use this database or at least will be able to deposit its content into this system. The workflow of a dScribe could then be integrated into the access management of the system to limit access rights for content that has yet to be published.

[edit] Extraction of embedded images within documents and presentations

Description: The system will extract any free-standing embedded images within a document or presentation and hierarchically connect those images to the originating material.

Note: This might be a task for OERca during the ingest of course content.

[edit] Conversion of content to different file types

Description: The system will be capable of converting files to different types. For example, a large set of .doc files might be selected and then copied and converted to .pdf, allowing us to publish not only the .doc files, but a second version in .pdf format.

[edit] Conversion of document and presentation pages to images

Description: The system will be able to convert document pages and presentation slides to images during content ingestion. This will enable quick scanning of documents and presentations within the system.

Note: This might also be a task for OERca during the ingest of course content.

[edit] Translation of documents to multiple languages

Description: The system handles the translation of all OER content to multiple languages including Spanish, Chinese, and French.

[edit] Interface features

[edit] First generation

[edit] Basic and advanced search interface

Description: The interface for search must allow quick and simple basic searches, while also enabling extensive and adjustable advanced searching using any existing metadata field (e.g. content type, license type, media type, date, course, etc).

[edit] Dynamic and flexible search result filtering and sorting

Description: This interactive interface component lets the user dynamically adjust and sort search results.

Examples:

• Clipart.com
• library search tool (do a search, then refine)

[edit] Basic browsing interface

Description: The interface will allow users to easily explore and browse through content in the site (e.g. browse by content type, license type, keywords, media type, course, and department).

[edit] Display of related content

Description: This component shows users content that is related to the curriculum, course, material, or content object being viewed. (Based on our metadata: Other works by this author, with this keyword, etc.)

[edit] RSS feeds

Description: The interface lets users subscribe to RSS feeds for content from a particular school, department, curriculum, course, or material. This might be found when viewing that particular school, department, etc. or on a general RSS feed page (we can have both).

[edit] Future generations

[edit] User-defined tagging of content

Description: This allows users to attach tags to content, courses, etc. for search purposes and descriptive purposes. These tags may be shared with all users or kept private.

Examples:

• Flickr notes
• del.icio.us tags

[edit] User favorites list/portfolio

Description: Users have an interface to keep track of viewed content or content of interest. This allows users to aggregate “favorite” material within the site, with the potential of sharing that content with other users (social networks).

[edit] User-ratings of content

Description: This interface incorporates a simple rating system for content. This might also, or instead, be a peer-review system for content. This component is not essential, but might be interesting. (see active collaborative filtering)

[edit] Social network integration

Description: Instead of creating a new social networking site, this interface component will tap into existing sites like flickr, Facebook, Twitter, and others to push content and share it among users.

Reference:

• Facebook

[edit] Passive and active collaborative filtering of content

Description: This interface component provides recommended related content to the user based on that user’s query or content view. (Based on user data: People who viewed this also viewed…)

Examples:

• Passive - provide recommendations by aggregating and analyzing user data (clicks, navigation, purchasing, etc.) - Amazon.com image
• Active - let user contributed recommendations help filter results (ratings, reviews, etc.) - Slashdot image

[edit] Dynamic and flexible browse filtering and sorting

Description: This interactive interface for browsing will allow users to sift through content in dynamic ways, including visualizations of curriculum, course, material, and content object interconnections. The users will be able to dynamically filter and sort content as they browse.