Stimulated by the thought of a SIG meeting in December, Shane 
Sutherland, of Pebble Learning and Wolverhampton prompts some more 
forward thinking.

Shane is wondering whether we can have 'lite' interoperability, where 
representing an e-portfolio item can be relatively simple, compared 
with IMS ePortfolio or HR-XML - the presumed main current candidates 
for a 'heavy' approach.

Seems to me that this is at least plausible: if the 'lite' and the 
'heavy' representations had clear mappings between them both ways. Of 
course, 'heavy' mapped to 'lite' and back to 'heavy' again would 
almost certainly lose some detail, but mapping 'lite' to 'heavy' and 
back to 'lite' should ideally preserve everything.

Then there would be a more realistic entry-level option for implementers.

One thing I'd like to add to this, though - relationships: we have to 
have an acceptable way of doing this for a 'lite' spec to work 
properly, I think.

Relationships between items are vital to the semantics of portfolios. 
Which achievement is this reflection about? Which competencies were 
demonstrated in this activity? Which activities led up to this 
qualification? Etc. etc.

Currently, I can see four different approaches to representing 
relationships between portfolio items.

1. Pre-IMS to IMS LIP, and probably HR-XML (?)
One option is to have all the information relevant to one item 
contained within that item as it is represented in XML. This has 
always struck me as the thing which was responsible for the highly 
complex structures in IMS LIP in the first place. Activities can be 
evaluated, the reasoning could have gone, for example, so let's put 
an evaluation element inside the activity element. This is all very 
well for information that has a natural hierarchical structure, but I 
don't think that e-p stuff really does: it's more naturally 
represented as a network. And people don't like the big schemas that 
result. They're hard work.

2. Later IMS and UKLeaP forward-looking approach
In IMS LIP and ePortfolio there is the facility to have 
'relationship' elements so that everything can be represented just 
once, and the relationship elements take care of connecting the bits together.
This feels a bit artificial. Relating things together is something 
that is done everywhere - why have a special mechanism for doing it 
just in portfolios?

3. The RDF approach
You embed all relationship information in each appropriate element, 
but the related elements stay separate, each with its own embedded 
relationship information. Whether you have both ends of a 
relationship represented is a good question. If you don't, then which 
end is chosen to hold the relationship information? And what happens 
if the relationship is noted at both ends, but the ends don't agree?
This can be made to work, but the question is then whether that is 
what is wanted. Given the potential distribution of portfolio items 
across many servers, there are two problems.
(a) What about noting relationships between items where you don't 
have write permission on the relevant servers?
(b) Often, the relationship information can be more sensitive than 
the raw, unrelated information. If you put both together, there is no 
obvious simple way of disentangling the raw info from the 
relationship info for the purposes of controlling read permissions.

4. The Topic Map approach
You leave all the information as distinct items, and have a separate 
topic map representing the relationships between the items. Each 
portfolio item has a topic to represent it, but the topic can be 
empty of content, and just have a pointer to the place where the 
information is held. The associations of the topic map then represent 
the relationships between the items (as topics).
Perhaps this approach could also be implemented in RDF, if that is 
what was wanted.

Have I left out any significant approaches?

OK, that's enough for one post: discuss away if you have mind to!

Simon

--
Simon Grant http://www.simongrant.org/home.html
working with http://www.cetis.ac.uk/members/portfolio SIG