Distribution Concept Paper

From Bjoern Hassler's website
Jump to: navigation, search

These are some rought notes intended for a "distribution concept paper", for the Matterhorn discussion list (http://www.opencastproject.org).

By 'distribution channel' (or 'channel') we mean a service through which end-users interact with media originally deposited in a Matterhorn installation. Typical distribution channels are YouTube, iTunesU, syndication portals like CamTV web portal, but also the Matterhorn UI itself, as well as a Desktop applications such as Miro or iTunes.

How do these differ?

  • Push with media (YouTube) vs. pull metadata only (iTunesU, CamTV)
  • Range of metadata used: Very complete (Matterhorn UI), intermediate (CamTV uses a fairly complete media rss feed with some extra fields), basic (desktop clients using a simple postcast feed)
  • Degree to which data/metadata is cached: indefinite (YouTube), typically one day (iTunesU), one day or less (CamTV), very little caching (Matterhorn UI)
  • Architectures: java/tomcat/flex (Matterhorn UI???), php/mysql/flash (CamTV)
  • Authentication requirements: very little (CamTV uses publicly available feeds), Matterhorn UI (needs to write back data).

We might also look at the relation between such distribution channels and institutional units in HE.

  • YouTube and iTunesU are typically institution-wide (though individuals within the institution might be posting to YouTube or iTunes podcast section independently)
  • Web portals may be relevant for the whole institutions, or individual schools, departments, research groups.
  • There may also be a need to assemble subject based portals across institution (c.f. e.g. Steeple)

I would conjecture that the system used in these distribution channels are all fundamentally similar in functionality, but differ in implementation. Where portals are 3rd party portals, we of course don't have to build anything, but just need to provide an appropriate interface (dictated by the 3rd part service). However, there are some pieces that we have to build (within Matterhorn or otherwise), namely

  • the Matterhorn UI
  • generic syndication methods?
  • non-UI portal software?

More concretely, I would conjecture again, that those systems will be very similar in functionality, but differ in implementation. In particular, I wonder what the need for additional portal software is.

[[Image:]]

Let's look at the following scenario, and consider two points of view:

  • The overall institution, such as a University, wants everybody to use Matterhorn, because it means that the central investment is leveraged, that media is archived properly, that media is deployed with uniform standards, etc.
  • The departmental web administrator just wants to get media into their CMS. To them, uploading to a central server is easy, but the media doesn't end up where they need it, i.e. in their CMS

How would the departmental administrator contribute to the CMS? They could use a video plugin (not as advanced as Matterhorn, but gets the media right into the CMS), or perhaps they'd upload to YouTube, and plug YouTube back into their site. I would argue, that Matterhorn needs to mimick these processes. Of course the embedding of a single video is straight forward: Matterhorn only needs to offer the right embed code for cut-and-paste. However, managing a collection of videos is not so trivial, and we'd need at least some integration with the relevant CMS.

I would argue that, very broadly speaking, there is a need for multiple instances of (a range of) "Matterhorn UI" to run off a single Matterhorn core. More concretely:

  • These different Matterhorn UIs wouldn't all show the same set of records: The "main" institutional UI shows all media, while a departmental instance of the UI shows only some media. There may be cases (probably rare) where a university doesn't want to have a central UI showing all media.
  • These different UIs may not all be built using of the same technology. Centrally a java/tomcat UI would be natural for the main UI, as that fits in with the requirements of Matterhorn itself. However, in a department, a web administrator may just want to run something of their CMS (e.g. Drupal, Wordpress, ...) (We note again, that the web administrator may well want a whole portal, rather than just pulling single videos.)

There are two things to highlight: Firstly, will there just be one instance of the Matterhorn UI per Matterhorn installation? Is it desirable/viable to be able to run several "standard" Matterhorn UI?

Secondly, I would argue that we should provide Matterhorn-UI-like functionality in other technologies, primarily to support a range of common CMS systems. I would argue that there is a family of CMS based on php/mysql, that covers a broad range of common CMS solutions, including: Drupal, Wordpress, Joomla, Mediawiki, and Moodle. (Where for moodle we just consider the use of publicly available media within the moodle LMS, i.e. the video does not need to be authenticated.)

I do not have in-depth experience with all of these CMS systems, but certainly across some of these it would be straight forward to build a component that could run in several of these php/mysql-based CMS systems, and therefore cover a broad range of the market.

In the BA/UX/UI process, we should investigate what the needs are, and make arrangements accordingly. If there is indeed a need for support of a common set of CMS systems, then it may give Matterhorn a significant competitive advantage to support these.

Also, I wonder to what the relation between Matterhorn-UI-API and the feeds for iTunesU / direct subscription / syndication / federated searching is. Is it correct to assume that the information content would be similar, but that the technologies are different?


Matterhorn should provide:

  • Portal functionality
    • via Matterhorn UI (java/tomcat?, non-caching?, one-to-one correspondence with matterhorn process core?)
    • via CMS-plugins for php/mysql-based CMSs (joomla, mediawiki, drupal, wordpress, moodle)
  • Commericial site distribution
    • Distribution to YouTube, iTunesU
  • Open distribution
    • Feed with detailed video information (standard feeds + yahoo media + other extensions as needed, same format as for CMS plugins)
  • Single video or single podcast pulling
    • Ajax+flash
    • Gadgets
    • Standard podcast/rss/atom feeds

Note: difference between the datacontent required for portal functionality vs. normal rss/atom syndication.

Notes on php/mysql-based cms:

  • How do they differ? joomla, mediawiki are easy. For moodle, we consider the use-case of displaying publicly available video within moodle (no exchange of credentials needed). Wordpress also easy? Drupal has tighter integration with drupal core, so need to see.
  • What is required? Simple installation package (from within CMS-UI, no rights beyond UI-admin rights needed).

Further topics:

  • Federated searching with matterhorn data exchange

See also Syndication and metadata.