Scott's Workblog

This blog has moved! Go to my new blog!

July 19, 2005

Introducing IMS ePortfolio, Part 2: Vocabularies

This is the second in a series of articles about the IMS ePortfolio specification. Here's Part 1.

Naming the parts

The core of the IMS ePortfolio Information Model is a vocabulary of the parts of a portfolio.

The specification describes a portfolio as comprising a number of discrete parts, each of which represents a particular facet of the subject of the portfolio (who the portfolio is about, usually, but not always, its owner).

So what are the parts, and where did they come from?

Well, there are a whole load of different part types:

  • accessibility
  • activity
  • affiliation
  • competency
  • goal
  • identification
  • interest
  • product
  • rubric
  • rubric cell
  • reflexion
  • assertion
  • participation
  • transcript
  • security key
  • qcl (qualification, certificate, or license)

The majority of these terms are from IMS LIP, where these are the major classes or elements in that specification. However, some have been developed for the ePortfolio specification: Rubric, RubricCell, Participation, Reflexion, and Assertion.

So what do all these terms mean? Well, thats what the information model is all about - it describes what the interpretation should be for each part type. So there is a definition of what a goal is, what an activity is, and so on.

These definitions are mostly what you'd expect; for example, "The Goal class consists of the description of the personal objectives and aspirations of the Owner", however this is still useful, as it means that, if you come across a portfolio created using one of these terms, you have some idea of how it was intended and how to treat it in your application.

(As an aside, its worth noting that ePortfolio doesn't mention Plans as being distinct from Goals)

While for the most part what these terms describe are self-explanatory, a few deserve special attention:

Rubric and RubricCell are described in their own mini-specification, and provide some guidance on how other parts in a portfolio may have been assessed; for example, what the criteria are for a "Merit" grade that was awarded for a certificate.

Identification is the description of the subject of the portfolio, and contains basic biogrpahical and contact information; there is a LIP construct that maps onto this, but it would also be a logical place to hook onto a VCard or a FOAF. Unlike the other terms, the specification expects that there will be only one Identification in a portfolio.

Participation is an entity that isn't the subject of the portfolio, but had a hand in some of the parts; for example, a partner in a group project. The specification recommends the use of IMS Enterprise for representing groups and persons for Participation, but as with Identification, this is also a good candidate for using VCards and FOAFs.

This is quite a vocabulary; but note that I've described this as a vocabulary and not a data model. Why? Because the information model of the IMS ePortfolio specification has nothing to say about how you describe most of these "parts".

Or rather, it says in most cases that "This class does not have a concrete definition, but should be realized by a technology appropriate to the binding in use." for most of the part types.

The exceptions are Reflexion, Assertion, Rubric, and RubricCell, where data models are provided in the specification. However, this is entirely because a separate definition did not already exist as part of IMS LIP at the time the specification was being developed.

In the future, I think we'll see these data models migrating out of the IMS ePortfolio specification, too. So its a safe bet you can treat these parts in the same way, if you wanted to.

Which means that we can just take these part definitions, and bind them to any technology we want. We wouldn't, however, be able to claim we were "IMS compliant" if we did so, because IMS defines that claim to mean that you've implemented the binding specified by IMS. However, you could bind these terms to another technology (for example, Atom, RSS, RDF, FOAF, or even HTML) and make some statement along the lines "based on the IMS ePortfolio information model".

For example, you could create an Atom feed containing entries which represented portfolio parts rather than blog posts. To do this, you need a way of binding the IMS ePortfolio vocabulary to Atom. One way would be to tag the feed itself in some way as being a feed of "activities", for example, by adding:


Alternatively, you may want to tag each entry instead:

	<title>improve my guitar playing</title>
	<link rel="alternate" type="text/html"></link>

Or, you may want to type each entry via the XML schema-instance notation, rather than tag it:

<entry xsi:type="ims-ep:goal">
	<title>improve my guitar playing</title>
	<link rel="alternate" type="text/html"></link>

Of course, you could just use the IMS binding using LIP and CP - because then you can use the "IMS compliant" badge on your product. I'll get onto that in the next part of this series.

Creating graphs

The list of parts isn't the only vocabulary that you can find in the IMS specification. There's also a vocabulary of relationships between parts, too. This is presented in the Best Practice document, in the form of a matrix of relationship types. Each relationship type has particular semantics that apply between different parts; for example, there's a specific meaning attached to a "supports" relationship between a Goal and a Competency, as opposed to between an Activity and a QCL.

Go take a look at the table to see the types available ... OK, done that? Well, what can we do with this?

Well, this vocabulary effectively enables you to overlay a graph across a set of parts. We can draw links between each of the parts and identify the links using the relationship vocabulary; just like a concept map.

So another interesting potential binding of this work is to use something like the XML Topic Map specification, and then use a knowledge construction tool of some sort to make sense of this map of personal facets.

Alternatively, we can bind these relationships in some other fashion, such as by adding a typed dc:relation element into entries in an Atom or RSS feed:

<entry xsi:type="ep:goal">
	<title>improve my guitar playing</title>
	<dc:relation xsi:type="ep:aims-at">#competency3</dc:relation>	
	<link rel="alternate" type="text/html"></link>

Applications can then use these typed relationships as hints for presenting or organising entries and showing the links between them. In more advanced applications, these relationships could also be used for all kinds of querying and inference across the parts.

Or, you could use the IMS binding, where the LIP "Relationship" class is used to connect objects.

This relationship vocabulary is one of the more interesting aspects of the IMS specification, and you may still find it useful even if you're not interested in using the other parts of the specification, such as the Part vocabulary or XML binding.

Wrapping up

That's all for the vocabularies. I think this is the most important and valuable aspect of the specification in terms of its contribution to the wider field. However, this specification isn't just a bunch of vocabularies - there's an XML binding too, which I'll cover in the next part.

main archive