Scott's Workblog

scott.bradley.wilson@gmail.com


attention!
This blog has moved! Go to my new blog!


August 22, 2005

Sharing Learning Contexts Within A Distributed Conversation Model

There has been an interesting discussion recently about the development of distributed conversations using blogs and syndication. However, to enable a distributed conversation of any kind to take place requires an agreement of context among participants - that is, we have to have a way of knowing whether something is part of the conversation or not. Some of the posts on this topic so far have cited the use of tagging and social bookmarking services as a way of constructing and sharing context.

One of the difficulties facing collaboration based around feed ecologies is the lack of a mechanism to creating and sharing a context that links disparate feeds and entries. This is not usually a big problem, as the conversation usually emerges in a fairly spontaneous manner and working your way through the flimsy connections isn't too difficult for those interested enough to dig through them. (Though as Ewan McIntosh observes, there is the tricky question of figuring out whether a conversation has actually even started.)

However in a learning context I can see that it will be useful for teachers to be able to help students contextualize a set of sources within a topic, and to initiate a conversation within a group.

This isn't to say learners might not reshape the scope of the conversation from their perspective, adding the resources that they think are relevant, but having the initial scaffold for a course of "here's where I'll share some useful resources, and here are your fellow students" is something students will generally need to have provided for them.

For example, for a course a teacher may create a set of audio monologues or video presentations, a set of useful reading material and bookmarks, use a blog to pose questions and respond to students, and have students post their ideas and supplementary resources they discover on their own blogs. All of these can be shared using the aggregation model as feeds, podcasts, and vodcasts. All of these resources, however, in addition to being part of the web, are also part of a particular context, that of the course.

So, an aggregator would ideally be able to import the collection of appropriate feeds and label them as being part of a logical group, facilitating their being viewed within a particular context by the learner. The teacher also needs to be able to set this all up without being immersed in the syntax of XML and RDF; it should be possible to create and share a context with relatively little setup, augmented by simple authoring tools. Otherwise, the shift in technology culture away from a centralized to a decentralized model is going to be an extremely difficult one for teachers to make. As Stephen correctly points out, "you can't just 'require' that teachers use this stuff."

I've already had a few attempts at conjuring up ideas for the kinds of tools needed, and I'll probably post some more on that topic some other time, but right now I'm wearing my CETIS hat, so I'm going to look at this from an interoperability modelling standpoint.

I've discussed the topic of sharing contexts before under the heading of Shared Learning Contexts (SLCs), but back then I only considered a few of the possibilities available for representing context, and the whole concept of distributed conversations using feeds was very new then.

Looking around now, there are several technologies it may be possible to use for sharing a context:

  • OPML
  • Atom
  • IMS Learning Design
  • IMS Enterprise
  • RIDDL
  • RSD
  • Neutrino
  • FOAF
  • UDDI
  • Web autodiscovery

I've got a few comments below on some of these technologies. For now, I'll just pretend for a moment that none of these things exists; how might I go about designing a "context schema"?

First off, the scope is quite small - I need to describe the context, what feeds are part of it, and who the participants are.

To do this, I want to re-use as much existing metadata as possible, so I'll reference rather than include descriptions as much as possible. So, instead of including data about each person in the context along with their feed URLs, instead I'll just point to their online FOAF profile, which will either have this information or point to it. This means a bit more effort by the aggregator to discern where participants' feeds are by accessing and parsing FOAF records, but has the advantage that they are always going to be accurate and up to date, plus the creator of the context doesn't have to know where the participants have hosted their blogs in advance.

I'll do the same with feeds; there really isn't much point putting in anything other than the link as feeds are self-describing documents anyway.

Finally, if I can get away with using existing vocabularies, such as Dublin Core, I should include their elements rather than invent new ones.

So if I follow these principles, what might a context instance look like?

<context>
    <dc:title>Viable Systems Model and PLEs</dc:title>
    <dc:description>Exploring the applicability of the VSM to modelling Personal Learning Environments</dc:description>
    <dc:subject>VSM</dc:subject>
    <dc:subject>PLE</dc:subject>
    <dc:creator xlink:href="http://www.cetis.ac.uk/members/scott/foaf.rdf"/>
    <!-- feeds -->
    <dc:related dc:format="application/atom+xml" xlink:href="http://an.example.org/feed.atom"/>
    <dc:related dc:format="application/rss+xml" xlink:href="http://another.example.org/rss.xml"/>
    <dc:related dc:format="application/atom+xml" xlink:href="http://diff.example.org/xml/podcast.atom"/>    
    <!-- schedule -->
    <dc:related dc:format="application/x-vcalendar" xlink:href="http://example.org/calendar.ics"/>
    <!-- people -->
    <dc:contributor xlink:href="http://www.cetis.ac.uk/members/alice/foaf.rdf"/>
    <dc:contributor xlink:href="http://www.cetis.ac.uk/members/bob/foaf.rdf"/>
    <dc:contributor xlink:href="http://www.cetis.ac.uk/members/chris/foaf.rdf"/>
    <dc:contributor xlink:href="http://www.cetis.ac.uk/members/diane/foaf.rdf"/>
</context>

So, from top to bottom, we have some metadata that describes the context itself, then a reference to the metadata for the person who created it. Then we have references to the feeds for resources, a reference to a timetable, then references to the metadata about the participants.

The "subject" metadata is intended to be used for filtering the feeds within the context - the participants are going to take part in multiple conversations after all, so some means of identifying the applicable entries is going to be needed.

So, from this exercise I know its theoretically possible to create a context metadata format using just one new element - context! Which gives a baseline criteria against which to evaluate the available options, which I've looked at below.

OPML

OPML is commonly used by aggregators for importing and exporting groups of feeds, and while I'm not convinced its even appropriate to that task, pragmatically its worth considering for sharing contexts.

Using just OPML elements results in the example below, which is certainly brief, but not exactly very meaningful. For example, there is no distinction between people and feed sources, as OPML really isn't designed with personal metadata in mind. OPML is intended as a format for exchanging the content of outliner tools (typically the sort of thing you use to plan large documents), and its uptake as a "blogroll" format has always been a puzzle to me, given that 90% of the specification is irrelevant, like the attributes for determining how many lines should be visible in the editing window. Anyway, I think it might be possible for an aggregator to look at this and get some sort of idea as to what it needs to do. I haven't come across any examples of OPML with namespaced elements - the specification itself predates this practice - but I imagine you could include dublin core to augment the context description in the "head" part.

<opml version="1.1">
 <head>
    <title>Viable Systems Model and PLEs</title>
 </head>
 <body>
    <outline xmlUrl="http://an.example.org/feed.atom"/>
    <outline xmlUrl="http://another.example.org/rss.xml"/>
    <outline xmlUrl="http://diff.example.org/xml/podcast.atom"/>
    <outline xmlUrl="http://example.org/calendar.ics"/>
    <outline xmlUrl="http://www.cetis.ac.uk/members/alice/foaf.rdf"/>
    <outline xmlUrl="http://www.cetis.ac.uk/members/bob/foaf.rdf"/>
    <outline xmlUrl="http://www.cetis.ac.uk/members/chris/foaf.rdf"/>
    <outline xmlUrl="http://www.cetis.ac.uk/members/diane/foaf.rdf"/>
 </body>
</opml>

Atom

Atom is designed for sharing feeds rather than metadata about multiple feeds and participants, but I think with some tweaking it would be possible to create an Atom document that describes a context. Its already possible to create an Atom feed whose entries are all Atom feeds; like OPML, however, it suffers from the lack of distinction between a person and a resource at the "entry" level. This can be overcome by using the "contributor" element in the feed itself, as in the following example.

<feed>
    <id>tag:example.org,2005:5</id>
    <title>Viable Systems Model and PLEs</title>
    <subtitle>Exploring the applicability of the VSM to modelling Personal Learning Environments</subtitle>
    <category><term>VSM</term></category>
    <category><term>PLE</term></category>
    <author>
        <uri>http://www.cetis.ac.uk/members/scott/foaf.rdf</uri>
    </author>
    
    <!-- feeds -->
    <entry>
        <title>Example</title>
        <link rel="alternate" type="application/atom+xml" href="http://an.example.org/feed.atom"/>
    </entry>
    
    <!-- people -->
    <contributor><uri>http://www.cetis.ac.uk/members/alice/foaf.rdf</uri></contributor>
    <contributor><uri>http://www.cetis.ac.uk/members/bob/foaf.rdf</uri></contributor>
    <contributor><uri>http://www.cetis.ac.uk/members/chris/foaf.rdf</uri></contributor>
    <contributor><uri>http://www.cetis.ac.uk/members/diane/foaf.rdf</uri></contributor>
</feed>

The problem with this is that its not possible for the aggregator to know whether to treat this as a context or a normal feed just by looking at the data, which means that it might not bother resolving feed URIs from the contributor's FOAF profiles, or create a new group for the feeds.

This is quite possibly why OPML tends to be used instead of RSS for distributing blogrolls - simply that the aggregators can tell the difference, explicitly, between feed metadata and meta-feed metadata, by the type of file.

IMS Learning Design

Can IMS Learning Design be used for sharing a learning activity, the main type of context I've been discussing?

From a casual glance it would appear that the sharing of learning activities is the primary motivation for the specification; however, IMS Learning Design is primarily a templating language.

By that I mean, IMS Learning Design is typically used to describe a class of activity, rather than an instance of activity. Put simply, IMS Learning Design has no place to put the individual participants, just the roles that participants are intended to fill within the learning scenario when it "runs". So in a sense, the specification is one level above sharing a context - a series of contexts may be constructed using Learning Design as a template, but they need to be shared and managed using another technology. Typically this is where an LMS comes in, but in our case this is the distributed conversation technology offered by blogs and feeds.

So IMS Learning Design isn't a candidate for context sharing. Which is a relief in some ways as an example would take up about 10 pages. Next!

IMS Enterprise

I've considered IMS Enterprise before in this role. Unfortunately, IMS Enterprise suffers the reverse problem from OPML and Atom - it has plenty of capabilities for participants, but has no concept of resources. So we would need to use extensions to reference the resource feeds. Another disadvantage is that Enterprise is designed primarily as an API for institutional systems (hence the name), and isn't really the sort of thing you'd host on a webserver as a simple file - it requires, at the very least, some script handling capabilities at the server end (in the REST version). So while it may fit in a traditional educational setting, it wouldn't be easy for students to create and share their own activities, for example to organise their own project groups. This could be overcome by creating a special kind of service for accepting and distributing contexts, but this added complexity hints that Enterprise isn't a good generic solution to the context problem, although it may have some utility in a traditional institutional setting.

RDDL: Resource Directory Description Language

This document describes the Resource Directory Description Language (RDDL). A RDDL document, called a Resource Directory, provides a package of information about some target, including: Human-readable descriptive material about the target, A directory of individual resources related to the target, each directory entry containing descriptive material and linked to the resource in question.

The targets which RDDL was designed to describe are XML Namespaces. Examples of "individual related resources" include schemas, stylesheets, and executable code designed to process markup from some namespace. A Resource Directory is designed to be suitable for service as the body of an entity returned by dereferencing a URI serving as an XML Namespace name.

Well, its not the most snappy description, but I think its enough to make me suspect this isn't what we're after!

RSD: Really Simple Discovery

Really Simple Discovery is a way to help client software find the services needed to read, edit, or "work with" weblogging software. Although I talk about weblogging software, there's no reason this format can't apply to other forms of web client/system software that I wasn't considering, or may not even exist as of this writing. (There is an example below where I did just that.) This format is simple but flexible. One of the deisgn goals was to ensure that it would be human writeable. This was my "test" for ensuring that the format was easy for everyone to implement.

This would appear to be superceded by the Atom spec, which uses LINK syntax to reference REST endpoints from within a blog feed, so the comments on Atom apply equally here.

Neutrino

Neutrino is a format devised by Fraser Spiers (the author of several bits of software I make use of). Neutrino is intended as a solution to the "subscribe to my brain" problem - how can I find all of a person's output? This is sort of the obverse of the context issue, which is where we want to get several people's output and contextualize it within a topic. So Neutrino isn't really suitable. It is interesting in the sense of needing to resolve a participant's feeds, but I think FOAF can handle this adequately already.

FOAF

FOAF is normally used for describing a person, but it does also have a Group construct, which could be used for collecting together a set of foaf:Person profiles, and some resources. For example:

<foaf:Group>
    <foaf:name>Viable Systems Model and PLEs</foaf:name>
    <dc:description>Exploring the applicability of the VSM to modelling Personal Learning Environments</dc:description>
    <dc:subject>VSM</dc:subject>
    <dc:subject>PLE</dc:subject>
    <foaf:maker>
        <foaf:Person rdfs:seeAlso="http://www.cetis.ac.uk/members/scott/foaf.rdf"/>
    </foaf:maker>
    <dc:related dc:format="application/atom+xml" rdf:resource="http://an.example.org/feed.atom"/>
    <dc:related dc:format="application/rss+xml" rdf:resource="http://another.example.org/rss.xml"/>
    <dc:related dc:format="application/atom+xml" rdf:resource="http://diff.example.org/xml/podcast.atom"/>
    <dc:related dc:format="application/x-vcalendar" rdf:resource="http://example.org/calendar.ics"/>
    <foaf:member>
        <foaf:Person rdfs:seeAlso="http://www.cetis.ac.uk/members/alice/foaf.rdf"/>
    </foaf:member>
    <foaf:member>
        <foaf:Person rdfs:seeAlso="http://www.cetis.ac.uk/members/bob/foaf.rdf"/>
    </foaf:member>
    <foaf:member>
        <foaf:Person rdfs:seeAlso="http://www.cetis.ac.uk/members/chris/foaf.rdf"/>
    </foaf:member>
    <foaf:member>
        <foaf:Person rdfs:seeAlso="http://www.cetis.ac.uk/members/diane/foaf.rdf"/>
    </foaf:member>   
</foaf:Group>

This is actually rather close to my original "thought experiment" schema above, although partially this is a result of my taking an RDF-like approach in my example (even though I used XML rather than RDF notation), and partly due to all the Dublin Core included. This is because while FOAF has various relation constructs for homepages, weblogs and online accounts such as chat, there isn't really anything directly suitable for a list of feeds. It is also possible to use RSS 1.0 elements within FOAF (as RSS 1.0 also uses RDF); however, for the most part the feeds referenced won't be RDF so this isn't a good solution. So in the end I've used the Dublin Core "related" element to reference the feeds here.

The use of foaf:Group hasn't really been explored much in the FOAF community yet - perhaps the sharing of learning contexts could be one of its first applications?

UDDI

UDDI is a very generic service registry specification with query APIs and so on. I've no doubt that its quite possible to use UDDI for sharing a learning activity, but the effort needed would seem somewhat excessive, what with all the registration of service models and the like.

Autodiscovery

I've discussed this previously. In some ways the simplest method of context sharing, this involves putting the context links within a (X)HTML page. The relevant portions would look like this:

<head>
    <title>Viable Systems Model and PLEs</title>
    <meta name="description" content="Exploring the applicability of the VSM to modelling Personal Learning Environments"/>
    <meta name="keywords" content="VSM PLE"/>
    <link rel="meta" type="application/rdf+xml" href="http://www.cetis.ac.uk/members/scott/foaf.rdf"/>
    <link rel="related" type="application/atom+xml" href="http://an.example.org/feed.atom"/>
    <link rel="related" type="application/rss+xml" href="http://another.example.org/rss.xml"/>
    <link rel="related" type="application/atom+xml" href="http://diff.example.org/xml/podcast.atom"/>
    <link rel="related" type="application/x-vcalendar" hrefe="http://example.org/calendar.ics"/>
    <link rel="meta" type="application/rdf+xml" href="http://www.cetis.ac.uk/members/alice/foaf.rdf"/>
    <link rel="meta" type="application/rdf+xml" href="http://www.cetis.ac.uk/members/bob/foaf.rdf"/>
    <link rel="meta" type="application/rdf+xml" href="http://www.cetis.ac.uk/members/chris/foaf.rdf"/>
    <link rel="meta" type="application/rdf+xml" href="http://www.cetis.ac.uk/members/diane/foaf.rdf"/>  
</head>

One drawback here is that the relationship between the HTML page and the FOAF records is ambiguous; they could easily be interpreted as being the owners of the page rather than the members of a group. To get around this involves using FOAF statements like "maker", at which point you may as well just use FOAF to begin with. Likewise, to read this information as being a context requires a specific instruction to the aggregator to do so - there isn't anything in the data that makes this meaning explicit - so the overall approach is ambiguous.

Conclusions

Overall, the foaf:Group approach looks the most attractive, but what do other people think? Are there other alternatives I've missed? Is there even a gap that needs to be filled? I'm thinking that the applications of eLearning 2.0 need something like this, but I've been wrong before...

main archive