This paper divides into two parts. In the first part it defines and describes the RSS (Rich Site Summary) format and its emerging use as a format for content syndication by news and media organizations on the World Wide Web. Through the use of working models and demonstrations, the development, display and distribution of content modules via RSS will be discussed. In the second part, the theories and practice employed by news and media organizations are applied to online learning. Using MuniMall, an online learning community developed by the author, as an example, the method of integrating syndicated content with online courses and learning materials will be described and illustrated.

Part One: Content Syndication

1. Channels and Channel Definitions

If you surf the web using a Netscape browser and followed the ‘My Netscape’ button to its logical conclusion, you will have encountered a description of something called RSS, or "Rich Site Summary." An RSS file allows a website publisher to produce a on Netscape's site; Netscape users, in turn, may select your channel as one of several channels on their 'My Netscape' page

A channel, typically, looks like this [1] :

 

Figure 1: Netscape RSS Channel

 

The idea of a channel is that it is a brief summary of a website or online publication. It is composed of a channel name, a logo, and a set of headlines listing items on the site. Each headline points to a different article or column and may be supplemented with a brief description of its contents.

So far so good, and when Netscape launched its service early last year I was quickly on board with an RSS file of my own. It was a frustrating experience: Netscape's validation didn't work properly and I found myself re-registering over and over with the site's somewhat slow interface. Eventually the wrinkles were smoothed and my Rich Site Summary was accepted into Netscape's interface. Here’s an abbreviated version of what it looks like:

 

<?xml version="1.0"?>

<rdf:RDF

   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

   xmlns="http://my.netscape.com/rdf/simple/0.9/">

 

   <channel>

       <title>Stephen's Web Threads</title>

       <link>http://www.munimall.net/scripts/downes/clist/clist.cgi</link>

       <description>Stephen's Web Threads</description>

   </channel>

 

   <item>

      <title>Distance Education vs. Traditional</title>

      <link>http://www.munimall.net/ /topiclist.cgi?topicid=969550119</link>

      <description>

Does assigning distance students more work make up for the lack of classroom contact? Well, no.

      </description>

   </item>

 

   <item>

      <title>Interview with Presidential Candidate Jackie Strike</title>

      <link>http://www.munimall.net/ /topiclist.cgi?topicid=969464710</link>

      <description>

The one-on-one chat with the talking 3-D candidate sets not only a

political precedent, but is a technological first.     

      </description>

   </item>

 

</rdf:RDF>

 

Figure 2: RSS File

 

As you can see from the diagram, there are two main elements to an RSS file: the channel definition, and the item definition.

A channel is a set of related items. Items are descriptions of individual articles. A channel may describe items from a single website or items which discuss a particular topic. Items in turn may be anything at all, though typically they are a particular essay, news item, column, or similar chunk of content.

Channels and items each have properties. In the example above, a channel will have a title, a link or URL, and a description. Channels frequently have images associated with them, may be provided by a publisher or website, and may have keyword descriptors. In a similar manner, items also have properties: a title, a link, a description, and perhaps some keywords, author and publisher information.

The idea here is that an RSS file is a structural description of a website or a group of related websites. Because the information is structured, when it is retrieved by a remote service – such as Netscape’s NetCenter – it can be manipulated, displayed in various templates, and made the subject of intelligent searches. But more importantly, for the author of the RSS file, it allows content to be created and published once and distributed and viewed on many different websites. This is the heart of the concept behind RSS and of content syndication generally.

 

2. A Wee Bit of History

Where there is Netscape there is always Microsoft, and it should be no surprise to the reader that the Redmond software company developed an alternative channel format. The Microsoft format is called 'Channel Definition Format' and was introduced in 1997 for its Internet Explorer 4.0 web browser. The specifications [2] were described in the November, 1997, issue of Microsoft Interactive Developer and a software development kit was released.

The idea behind Microsoft's 'Active Channels' was that website summaries could be displayed in the browser itself via a 'channel bar.' For some reason, Microsoft abandoned this feature in its release of Internet Explorer 5.0 thinking, perhaps, that it might incorporate it later as part of the Windows desktop. [3] Ironically, a Netscape version of the channel bar was one of the major features added to the Netscape 6.0 [4] release in April of this 2000.

Both the Microsoft and Netscape initiatives centered around a set of protocols described by the World Wide Web Consortium as RDF, or Resource Description Framework. [5] The purpose of RDF was to provide a generalized format for online resources; major implementations thus far have included the Dublin Core [6] for publications and the IMS Protocols [7] for instructional materials.

But RSS channels need not be defined in an RDF format. Dave Winer's Scripting News, [8] for example, adopted a non-RDF version of RSS. Started in December of 1997, the Scripting News Format, as it was called then, was launched to introduce the use of XML to news pages. [9] By June of 2000, the Scripting News format had evolved into something called RSS 0.91 - which should not be confused with Netscape's RSS for while Netscape's 'RSS' stands for 'Rich Site Summary', Winer asserts that that there is "no consensus on what RSS stands for, so it's not an acronym, it's a name" [10] .

Finally, in August, 2000 (which, by the way, explains why my paper is late), a group of developers adapted the best of RSS 0.91 and re-adopted the RDF format, producing the widely accepted RSS 1.0 specification. [11] This design allows content developers to design and employ “RSS modules” in their RSS files, thus greatly increasing the potential vocabulary and use of RSS files. Content designers can now include, for example, threading, referencing, categorization, and more to the core RSS data set.

 

3. Syndication

The purpose of creating RSS files is to allow for the syndication of news content. Syndication on the world wide web works in much the same way syndication works in the world of print and electronic journalist: somebody writes a story, it is posted on 'the wire', and somebody else picks up the story for inclusion in their own publication.

On the web, the earliest syndicators of online content were the portal sites such as Yahoo and Excite. The basic idea behind these portals was that a reader could locate information from many sources from a single web site. Syndication on Yahoo [12] has become extensive. The site no longer merely lists headlines; it also prints complete sets of news stories [13] from suppliers such as Associated Press, Motley Fool and Forbes. While attracting remarkably little attention, Yahoo has become the most comprehensive news service on the web.

Syndication can be time consuming and expensive. Content syndicators want mechanisms that allow headlines and articles to be collected automatically. Programs that search through the web - called crawlers - have been around since the early days; the first well-known crawler was WebCrawler [14] . Today, the most popular crawlers are AltaVista [15] and Google. [16]

But these are very generic crawlers and they do not organize their information in any systematic way. That's why they are better known as 'search engines' than as syndicators. Nonetheless, the technology for automatic syndication is essentially the same as for web crawling, and it was only a matter of time before automatic syndication came to the fore.

Perhaps the largest such syndicator is Moreover.Com. [17] . This site collects headlines from 1500 newspapers and content providers around the globe and organizes the results into 280 separate categories. What Moreover has to do is retrieve the headline page from each of these content providers, parse the HTML in order to find headlines and links, and then store these in appropriate categories. It then outputs a series of RSS files, one for each category. News and information sites around the world use RSS feeds. Providing a similar service is iSyndicate.Com, [18] which enters into content distribution agreements with publishers and provides RSS feeds and complete articles for syndication.

Figure 3: RSS Data Feeds

Pictured above is a flow chart diagramming the syndication process. Original content sites (Site 1 and Site 2) produce headings or content on different topics. The aggregator retrieves this content, which sorts the retrieved content, producing topic based news feeds in RSS or JS format. These news feeds are in turn retrieved by other content sites (Site 3 and Site 4) and are displayed as HTML pages.

Earlier content syndication sites collected content from content providers in the form of HTML pages. This is not nearly so simple as it looks. HTML is not designed to organize content; it is designed to display content. It turns out that it is a lot easier to retrieve and parse XML files - and in particular, RSS files. Sites that do this are called 'aggregators', and today's new breed of aggregators is focusing almost exclusively on RSS files.

RSS was used to good advantage by Netscape, but a major problem with the My Netscape directory was that users could not view the actual RSS files - Netscape would only let readers access the site summaries through its portal. The same was also true of another repository, My Userland, [19] the portal application for the Scripting News Format discussed above. But RSS files may be located through yet another repository, XMLTree.Com, [20] which indexes a wide variety of XML and RSS files. Launched early in 1999, the site has grown over the last year to include thousands of sites sorted by category.

 

4. Uses for Content Syndication

Although the easiest and most obvious use for content syndication is in the production of relatively current lists of news links on a given topic, RSS developers are beginning to perceive that a wide range of uses will be possible. In a document released in September, 2000, Ian Graham and Benet Devereux suggest the following [21] :

• New bulletins or news summaries, currently largely distributed using a simple XML dialect called RSS. An examples of this is My Netscape.
• Web site content replication or distribution (often done using tools such as rdist, which is Rdist is a program to maintain identical copies of files over multiple hosts. [22]
• Database-related content distribution, such as gathering event calendar data for use in a local calendar.
• Gnutella-like file/resource sharing services. This is a serve where multiple copies of the same file (for example, a music video) are located on different servers, with syndication information being used to facilitate retrieval.
• Dmoz.org-like catalogues. The Mozilla Open Directory project is a human-created directory of Web-accessible resources. This directory is available as an open -source archive (in RDF), and is integrated into many other Web cataloguing systems (for example, Google or Lycos).
• The HEML (Historical Event Markup and Linking) Project [23] . This is a project aimed at creating a world wide collection of history-research related XML resources, with each academic research group being able to create their own resources, which can then be syndicated and distributed amongst the different institutions.
• To aggregate proprietary scientific data, as described by David Detlefsen. [24]  

As Graham and Devereux point out, in each of these cases, “one organization publishes 'origin' data and makes it available in some form, and another organization downloads the data and processes the data to integrate it in some way into their own database or application.”

 

Part Two: Content Syndication and Online Learning

5. The MuniMall Project

MuniMall, a project funded by Alberta Municipal Affairs, was intended to provide a common services and information platform for people working in Alberta’s municipal sector. It would provide resources, learning and points of contact to elected officials, municipal administrators, and students of municipal government.

Figure 4: MuniMall Home Page

 

As such, it was intended to be what has since come to be called an “online community of interest” or “vertical community.” The original design was modeled on the concept of online community as described in Hegel and Armstrong’s Net Gain. [25] At that time, the concept of content syndication had yet to reach the mainstream; it was envisioned as a portal for all things municipal in Alberta.

Because MuniMall was perceived to be a threat to existing services (and especially websites hosted by the Alberta Urban Municipalities Association and the Alberta Association of Municipal Districts and Counties), the commercial aspects of MuniMall were quickly removed and the website was re-purposed to provide a strictly educational function. [26] To enhance its value as an educational site, MuniMall would include, in addition to resources and links to resources, an online simulation of a municipal website, MuniVille, to act as a training tool.

The removal of the commercial component probably doomed the project to failure: one the one hand, when government funding runs out (as it will in the spring of 2001), the project will be unsustainable. But more importantly, to act as the locus of a community of interest, the site would have had to be able to link to and contain information about all aspects of the community; to draw an artificial boundary around the content MuniMall is ‘allowed’ to have and that which is not is to limit its effectiveness as a community of interest.

As a research project, however, MuniMall remains invaluable. Unlike most work in the fields of online learning and online community development, MuniMall had an explicit mandate to merge educational content with information and resources used by the community of practice. In other words, MuniMall would be a tool used by municipal administrators in the course of their day to day activities, and at the same time, function as a teaching tool for students in the Government Studies certificate program.

The next three sections will describe three approaches taken to accomplish this.

 

6. Content Syndication

The first area of integration looked at by the MuniMall team focused on the resources used by both students and administrators. In particular, Alberta Municipal Affairs has over the years developed a Handbook for Municipal Administrators. This handbook contains detailed instructions on how to conduct a municipal election, draft and pass a by-law, approve building permits, and more. The Handbook, in turn, refers extensively to legislation and regulations governing the conduct of municipal affairs in Alberta.

Although an important – indeed, essential – resource, the Handbook was paper-based and not available online anywhere at all. It was maintained, as many similar Handbooks are, as a set of loose-leaf inserts into a massive binder. Periodically, updates would be issued from Municipal Affairs; these updates would be delivered to individual municipalities and also to the Government Studies program, where they would (sometimes) be placed into the binder.

An examination of the Handbook also revealed that it was out of date and in many ways redundant or internally contradictory. The maintenance of the Handbook was a major task for staff at Alberta Municipal Affairs, and the output was of minimal usefulness to practitioners in the field.

MuniMall proposed that the content of the Handbook be placed online and syndicated. Placing the content online would mean that it could be updated online, through a forms processing system, and thus, much of the time and expense in maintenance would be eliminated. Syndication, moreover, would allow the same (always up-to-date) document to be used in a wide variety of locations: and in particular, in online courses, in the MuniMall portal listing, and as help for any online forms or documents employed by municipalities.

Figure 5: Content Data Flow

 

In the end, this model of content syndication was never put into place. Several major obstacles emerged:

 

First, the Handbook was (as mentioned above) in a considerable state if disrepair and would have required extensive revision, a task in which Alberta Municipal Affairs was unwilling to engage (as events transpired, they instead launched an extensive ‘Best Practices’ initiative which may have as a final outcome a content syndication model as described here). Moreover, Alberta Municipal Affairs had no mechanism for assigning authority or responsibility for the upkeep of the Handbook.

 

Second, it was not clear that MuniMall, or even Municipal Affairs, could get permission to distribute the content of relevant legislation as described. Copyright over the legislation is held by the Queen’s Printer, which currently returns revenues to the provincial government through its printing service.

 

And third, even were the content available, there was no place to put it. The online course design for the Government Studies program adopted a mixed mode of delivery, with the course outline and discussion occurring online, but with course materials distributed as part of a paper-base package.

 

A modified version of content syndication was instead employed in the MuniVille to serve as a demonstration of how a similar technique could be employed by local governments for the wide distribution of documents and information. The MuniVille website consists of a set of topical pages, such as ‘Industry’, ‘Recreation’ and ‘Restaurants’. Content in each of these pages is updated via an online form, and the content is available for insertion into multiple pages. Thus, for example, a real estate agency could draw upon the community website to provide up to date demographic information; the municipal website could in turn draw from a real estate agent’s site an index of new listings.

 

Figure 6: Content Input Window

 

Figure 7: Content Display Window

 

7. Link Syndication

As part of its mandate to provide resources and information, MuniMall developed a portal of links relevant to Municipal administrators and elected officials. To date, more than 1200 resources have been added to the portal, with more being added each day. Links are entered into a common database and then displayed in a set of topic-based pages, much like traditional portals such as Yahoo.

The idea behind the link syndication system was to act as a means of accessing resources that could not be stored as web pages on MuniMall itself. The most common type of these resources is the external link; MuniMall staff added a large number of links and MuniMall users were encouraged, through an online submission form, to submit their own links.  Three major categories of links emerged: links that dealt with specific municipalities, link which addressed aspects of municipal governance (especially as it related to the provision of online services), and links that related to some aspect of a community (in other words, links that correspond to one of the topic-based pages in the simulation).

Figure 8: Links Display in a Portal

 

In order to facilitate this system of link syndication, four systems were developed over-and-above the link submission forms and syndicated output. First, an automatic categorization tool was developed to sort the links as they were submitted. Second, an automatic link-retrieval engine (similar to a web crawler) called Grasshopper was built. Third, a link editing tool was created. And finally, a search tool or “drill” was added to the system.

Although stored in a common database, these link lists are available to multiple web pages. As new links are processed, output files in both RSS and JS are produced (the JS file is a server side Javascript file which can be used by any HTML page without special processing). Thus, the same list of links can be used in the MuniMall portal and also (for applicable categories) in the MuniVille simulation.

Figure 9: Links Display in MuniVille Simulation

 

The system was originally designed to allow for up-to-date resource lists to be used in online courses as well. Ideally, both students and people working in the field of municipal affairs would submit links. These links would then be embedded in a WebCT course page (using the single-line Javascript command to embed the content).

To date, however, the link system has functioned mostly as a portal. Part of this is due to the fact that the tools are not as reliable as would be liked (the editor, for example, still has some major bugs in it). Part of it is due to the fact that there has not been a consistent and useful flow of content into the system – such a system needs multiple contributors, and more importantly, contributors expert in the field of enquiry. And part of it has been due to the fact that, other than the “today’s links” page and MuniVille, there has been no place to display the syndicated content.

 

8. Discussion Syndication

As MuniMall was intended to foster an online community, a forum for discussion and communication was essential. To this end, a discussion list program (Allaire Forums) was added to the site, where it sat – empty.

It became apparent that the discussion forum had to be seated much more closely to the main content; indeed, the discussion forum had to be a part of the main content. Once again, the idea was that posts, lists of posts, and list of discussion topics should be syndicated, so that they were available to a large number of web pages.

Because no discussion list program currently offers this feature, a specialized discussion list program was developed and used in place of Allaire Forums. The program – CList – provides output in RSS and JS as well as HTML. In addition, CList, like many other discussion list programs, allows email notification as well (in other words, if the user selects the option, the program will send an email message when somebody adds another post to the discussion).

Discussion on the MuniMall site still languishes; the two threads today have a combined 17 posts. Indeed, the most effective use of CList has not been on MuniMall at all, but rather, on my personal home page, where I used the discussion list program to format and display articles – like this one – on one website, while using the JS feed to list and link to the articles on another one, my main home page. And even in this system, discussion is minimal.

Part of the reason for the ineffectiveness of the discussion tool is the low traffic. Although, starting September 2000, the tool was employed in one of the Online Courses; it is accessed only as an external link, and not embedded in the course content as designed. In addition, on both MuniMall and on my home page, traffic is low, proving once again that a certain level of traffic is necessary in order to sustain a discussion board. Third, there has been no concentrated attempt to foster discussion: no events have been scheduled, no course requirements for discussion, no moderation or introductory articles. And finally, the sort of people who use MuniMall are just the sort of people who do not have time to engage in unfocussed online discussions.

 

9. Why Things Didn’t Work

I am standing before you and saying that, in three major areas of content syndication, the MuniMall project failed. As I suggested above, perhaps it was doomed to failure in any case because of the segregation of its potential audience. But it also failed as a result of a number of structural flaws. These flaws are worth investigating, especially when placed against an area of substantial success, yet to be discussed.

First and foremost, I think, an entity like MuniMall cannot exist in isolation. Like any form of syndication, it needs content at the input end, and it needs recipients at the output end. MuniMall suffered from shortfalls on both ends.

Input:

-       commercial and provider content was banned from the site almost immediately

-       government content, such as the Handbook, the manual, and even web site contents, was not forthcoming

-       there is a dearth of subject matter experts (or even knowledgeable participants) providing links, articles, discussion list posts and other materials

Some of this could have been addressed through better management. For example, a coordinated campaign to generate user contributions might have helped. Course professors should have been recruited to provide expert commentary. Students should have been recruited to provide discussion.

But in the absence of the more substantial content – especially content the target audience really wanted, such as business contacts and government documents – MuniMall was bound to suffer.

 

Output:

            no external sites used MuniMall as a content source

A syndication site that cannot market its materials anywhere is a site which is in deep difficulty. Obvious locations for syndicated content would have included the online courses, community and government sites, and the AUMA and AAMD&C sites.

These problems are indicative of a second and deeper cause for the difficulties faced by MuniMall. The project, from its inception, ran counter to two major features of information networks:

First, the market was just too small. And as Metcalfe’s law states that the value of a network increases exponentially with an increase in the number of participants, its corollary, which I’ll call Downes’s law, states that the value of a network decreases exponentially as the number of members decreases. A variety of factors, structural, organizational, personal and political, led to successive reductions in the numbers of people using MuniMall, and this led to its exponential decrease as a network.

Second, prospective participants in the network didn’t participate (in other words, the size of the network decreases), an instance of Downes’s second law of networks, which is, that the value of a network decreases exponentially as the size of the network decreases. As the associations, the commercial entities, online courses, and the governments were removed from the network, the value of the network collapsed.

 

10. A Success Story: The MuniMall Newsletter

The MuniMall Newsletter was launched in September, 1999, and circulation has grown steadily since that launch date (it now stands at 359, about a quarter of the total market population). It is widely read, often printed and distributed in municipal offices, commented upon favorably at conventions and in research studies. [27]

Figure 10: MuniMall Newsletter

 

The MuniMall newsletter is an example of syndication in action. Published once a week, it contains links to websites and articles of relevance to municipal administrators and elected officials. It draws from oft-ignored sources, such as local newspapers and government press releases, and presents this list of links, each with a short description, as a weekly email message. The newsletter is also published on the MuniMall site, and as Items are added to the site, the “What’s New” page is automatically updated.

Figure 11: What’s New Display

 

The MuniMall newsletter address the two major weaknesses identified in the previous section.

First, it has content. The typical newsletter is a collection of links from external sources and articles produced by MuniMall staff. Moreover, this content is highly filtered, designed to reflect the specific interests of the community it targets. Such highly filtered content is possible only if some form of syndication is employed, whether the process is implemented automatically or by hand.

The Newsletter, in other word, incorporates the first two of the three types of syndicated content described above: it contains textual content, in the form of articles, and it contains resources, in the form of links. In only the third form of content – online discussion – is the Newsletter lacking, though there is every reason to believe that with better content filtering and integration, a discussion component would be a useful addition (as it is in so many list services around the world).

Second, it has recipients. The MuniMall newsletter circumvents the usual channels for syndication, bypassing websites almost altogether, by being placed directly into readers’ email in-boxes. Because it is an email newsletter, it is easy to read (people tend to use email a lot more than they tend to use a particular website), and because it provides a list of filtered resources, it is easy to use.

The MuniMall Newsletter thus offers two of the best features of content syndication: content and convenience.

 

11. All Together Now: Doing Educational Content Syndication Right

What can be learned about content syndication in the educational domain from the MuniMall example?

First, and not trivially: it is technically feasible. Using the tools described in this paper (or tools which are becoming widely available on the internet) any course (or program of courses) or any online learning application can tap into up-to-date resources from remote sources, and tap into them in such a way that content is tailored specifically for the course in question.

But second, and also not trivially: because content syndication requires the development of a network, the practices and politics of building networks must be observed. Especially where the syndication network is breaking new ground (which today, is everywhere), the ground rules and principles of participation must be laid out in advance of any development.

Because, third, a content syndication network needs content, and in an educational setting, it needs authoritative content, which means that the providers of that content – whether they be government agencies, university professors, or professional associations – must be on board and willing to provide that content.

Of course, this is a two-way street: fourth, no content provider can go it alone. The reason for this is clear: in our examination of the municipal sector, we found dozens of agencies which provide authoritative content of one sort or another, agencies such as newspapers, community websites, research institutions, multiple government departments, a dozen professional associations, and more.

Fifth, there must be an audience, which means that at least as much care must be taken to present content in contextually useful situations as is taken in gathering the content to begin with. Even less comprehensive content – such as found in the MuniMall Newsletter – can be widely used if it is presented in an attractive format; conversely, even the best content will not be used if it is not accessible. The mechanisms employed by the Newsletter, including content filtering and a gentle push, tell us what an attractive format is likely to look like.

And sixth, although the temptation is often to start small – a pilot course, a pilot class – in endeavors which depend on a network phenomenon, it is best to start with as large a set of participants as possible. A large network may be scaled back or subdivided if it becomes unwieldy, but a small network may never get off the ground because the interactions upon which it depends are not there.