User Tools

Site Tools


content_server:start

Why Do We Need a Content Server?

Identify and Deploy Content Server for Campus

(by Jolee West, May 2006)

As use of online resources like Blackboard, eRes, and the media database increases on campus, the need for a centralized digital repository, or content server, is growing. By creating a central repository, we can streamline the campus file systems heavily used in teaching. Integrating a content server with Blackboard will address a number of vexing problems inherent in Blackboard, and at the same time integrate the disparate file systems currently in use on campus, for example, the /media and /openmedia storage on condor, course spaces on dragon, and eRes.

File management problems in Blackboard stem from there being no internal repository for documents, even on a course-independent basis (as is found in WebCT). Here are some of the issues in detail:

  • Files on the system cannot be moved around within a course or between courses. When an instructor uploads a document to particular page, moving that document to another location or even reorganizing it by adding it to a folder requires the instructor to re-upload it to the new location.

[Editorial Note: Bb now has a feature that allows the user to copy a document or folder from one course to another without re-uploading.]

  • Files on the server cannot be edited. They must be edited on the user's local system, and then uploaded to replace the old version on the server.
  • Files on the system cannot be shared between courses. For an instructor to use a document in two Blackboard courses, the document must be uploaded twice. For two instructors to share a document, the file must be emailed or distributed to the instructors outside the system, then uploaded to Blackboard where needed.

[Editorial Note: Bb now has a feature that allows the user to copy a document or folder from one course to another without re-uploading. However, an instructor must be an instructor in any course to which a file or folder will be copied.]

  • Files on eRes cannot be easily shared in Blackboard. An instructor cannot include an eRes document in a Blackboard. Instead the instructor can only link to an upper level of eRes and the students must navigate their way to the document through eRes.

The ideal content server would integrate with Blackboard, provide a means for instructors to reference documents in multiple courses, provide access to other instructors or groups of students, and allow the user to edit the document on the server.

Most would agree that the many file systems on campus are becoming burdensome, both to those who administer them and to students and instructors. An ideal content server would permit granular permissions to be assigned at various levels, by the ITS staff, then by users themselves. Thus, an instructor would be able to share a file with students by way of Blackboard, but also provide another instructor with access to that file (perhaps read-only access). Librarians could create discipline-specific and course-specific areas where instructors and students could access information through Blackboard or directly through the content server when Blackboard is not in use. Instructors could store their media files on the content server and set permissions on files themselves to allow browsing by Wesleyan users only, or provide world access. This would integrate the currently split media directories on condor.

Dragon and Condor User Scenarios

We are collecting scenarios to illustrate how users currently use the file server Dragon, the web server condor.wesleyan.edu, fileshare, and Blackboard. The exercise will provide us with a richer understanding of how people use the systems, with the intent of improving them and the types of services they provide.

Here is an example scenario:

I set up a dropbox on Dragon for one of my courses for the students to submit homework assignments. They can drag a file into the folder, but cannot read any files there except their own. My TAs and I have full access to this space, however. We can read, change, or delete any files in it.

**Please feel free to submit your own scenarios to the UseScenarios page. *

Product Evaluation Comments

Please post your evaluation comments on the Evaluations page.

ITS Content Server Requirements List

Platform

  • Support for Windows Explorer and Mac Finder Environment
  • Based on Open Standards
  • Oracle DB
  • file system agnostic (NAS, SAN, NFS, etc.)
  • Wide browser support (Safari, Firefox, etc.)
  • Supports SSL and VPN
  • Support of Web 2.0 infrastructure (blogs and wikis)

WebDAV

  • required

Editing

  • Editing of documents live through client
  • File-lock options
  • Simple editor via web client

File Management

  • File recovery features
  • Version control
  • Drag-and-drop file transfer
  • Customizable Workflow
  • Large file support (⇐ 2Gb)
  • Advanced Searching

Administration

  • Creation and control of automated (administrator-driven) shares
  • User Management Tools
  • Migration tools/Bulk Loader, esp. for move away from FP
  • Migration tools for move out of product

Web Support

  • Web content management functionality
  • “Virtual hosting” within one account space
  • configurable URLs (shortened URLs available)

Sharing/Access Control

  • End-user access control features
  • Sharing with off-campus users possible (via tickets or other system that doesn’t require outside user to have account on our system)

Development and Integration

  • LDAP/AD authentication
  • APIs
  • Active Development community
  • Integration support
  • Integration with Bb possible
  • Integration with eportfolio possible

Vendor Information

Xythos User Group Meeting (2/13/2007)

(attended by Jolee)

Enterprise Document Manager 6.0

  • Adding Records Management functionality; mirrors the Document Manager, but has more strict security;
  • Perfect for HR records, Grants office and grants processing;
  • When file is uploaded to particular location, will require user to fill in metadata in custom form with controlled vocabulary
  • Can specify document retention rules, disposition schedule, as specified by some granting agencies and IRS
  • Can configure disposition rules by folder
  • Has reporting functions (e.g., How many grants filed this year? How many successful NIH grants?)
  • Has XML editor for importing and exporting disposition rules between servers, institutions
  • Many administrative roles, includes those with select access to confidential financial info, confidential personal info, etc.

Presentation from Salve Regina U. (Newport, RI)

  • Use Xythos for student web development and for student teaching portfolios
  • Created templates for student to use in portfolios
  • students use Adobe Contribute to edit
  • very popular

The Future of Digital Locker/Enterprise Document Manager

A discussion of functionality they are working on for future releases. Next release, late summer.

  • RSS support (and podcasts)
  • wikis (sooner), blogs (later)
    • The discussion of wikis brought up a very interesting comment/warning from one of the attendees. He said that because wiki file structure is so flimsy and free form (“a house of cards”), in a few years there will be a “wiki meltdown” when people and institutions who’ve been using them for storing lots of mission-critical information and files are suddenly stuck with a mess and no way to clean it up. This guy pointed out that by putting a wiki over a Xythos db, an organization can force a file structure that is exportable and storage that is more easily retrieved, prolong its life and continuity.
  • Tagging
  • Drag-and-drop file transfer using web client (via a Java applet)
  • a portal-like interface (portletized)
  • Shibboleth support
  • Creation wizards (function oriented setup of folder, e.g., Do you want to create a dropbox, a podcast, a folder shared with students?)
  • Mac Drive being explored
  • JSR-170 API–>Content Repository API for Java Technology
  • They have a beta site, http://www.sharemation.com , where you can check out coming attractions, ideas they’re working on, etc.

Problems Discussed (some by other attendees, some by Xythos presenters)

  • Current GUI hard to skin, hasn’t been updated in years (the future portletized version will allow skinning)
  • Lots of concern from attendees about making sharing easier (the future version with wizards is the fix)
  • Support used to be pretty bad, but has been improving (noted by Gill Laponte, UMass-Amherst, and some folks from Vassar) sort of like blackboard, he?Henk Meij 2007/02/14 15:33

Other Higher Ed Institutions Using Xythos

content_server/start.txt · Last modified: 2007/04/20 12:07 (external edit)