Component Venn Diagram
From openmichigan
m (moved ARCHIVED-Component Venn Diagram to Component Venn Diagram) |
m (1 revision) |
Current revision
Producing - Authoring content
- Making open content available to content authors. How can this system be bootstrapped so faculty authors can start with open content
- Image library
- Multi institution - Federated search so institutions benefit from stuff others have cleared already
Content repository (general) - Should it be backing campus LMS and OER to prevent multiple copies allow access on OER/OCW site by changing access control after IP clearance and obtaining permission? - Implicit to this is that whatever content repository is adopted should provide rich support for ACLs, users, group - For UM it would require that we have content available at a very granular level in repository (individual CO). - Which content repository lends itself well to being a general store. Similar to a DB and filesystem combo like current OERca, Flickr. - Advantages of using content repository
- DSpace, DLXS provide static "handles" which prevent broken links.
- How do general content repository and image library
coexist. Should it be just image library or should it be generalized across all content types. Again, different front-end and access controlled using ACLs (flipping an Open Content switch)
Processing - Clearing content
- Currently a need since faculty aren't generally savvy to the practice of using CC or other openly licensed content - Laborious process and every institution has their own tools to support their process. - Can we have a general tool that is flexible enough to work for all our efforts?
- Metadata
- Everybody knows it is necessary - But nobody wants to be the one adding it. It's very laborious. - What do we want to add? - What standard/s should we conform to? - Should any tool adopted/created allow for multiple metadata schemes? - Ease the pain of annotation. - Drag and drop. - Automate as much as possible using other processing "services" - Inherit from "parent" entities
- A/V
- Automated transcoding - enabling access on slower connections, smaller screens, lower power devices - original full fidelity format is still available - can transcode from proprietary to open formats e.g. mp3 to ogg-vorbis audio - may optionally facilitate streaming - key-frame extraction from video - automated detection of average bitrate, codec, aspect ratio (as possible) - speech to text, to allow subtitles - closely coupled to metadata issue since format/codec metadata can be autodetected, may be added to file or perhaps can be exported in a separate text file
- Document processing
- Detect, extract and contextualize content objects embedded in office files (MS Office, OpenOffice, iWork) - Detect file format, image size etc. - Should this be embedded in CO or in a separate file
Publishing - Formalized workflow to allow correct checking of content before publishing. Different from what OERca offers, this is to prevent spelling/formatting errors.
Presenting - Allow access to content at a very granular level.
- Design should prevent users from being overwhelmed by too much choice. Current Connexions design gives too many results, cannot refine search further.
- Some authoring functionality?
- To facilitate remixing of content. How else should it be done without authoring functionality. - Perhaps make it easy to download open content, and provide pointers to desktop tools to do remixing/enhancement? Will this raise the barrier too high to get participation
Preserving - Making this a separate step, in which archived content is moved to less responsive storage may be a mistake. - Should preserving simply be backup or content repository. - Older courses should be equally available as newer ones? - Any preservation system should allow direct import from existing web resources. Perhaps as IMSCP?
