Part of LEAP 2.0
Contents |
The ideas elaborated under the title of LEAP 2.0 are intended to serve development of practical interoperability, by providing as sound a basis as is available. Nevertheless, LEAP 2.0 is the tail, and practical interoperability is the dog, and there is no intention that the tail should wag the dog! Some practical interoperability work is currently going on under the heading of Portfolio interoperability projects. This aims to develop a practical, developer-friendly spec, probably in Atom. The outcomes of that (and other practical interoperability work) will be assimilated into LEAP 2.0, whatever implications this has for changes to the ideas presented here.
We generate so many records of our work, learning and social activities these days, but it's difficult to review, combine and present them to others, like prospective employers and institutes where we might like to study. Specifications and software are being developed to enable these records to be linked together, and transferred them between systems, but existing specifications are problematic, either by requiring too much effort to implement, or by not covering the domain, or by being too open to variant interpretations. These and other requirements are detailed on the LEAP 2.0 requirements page: please add more.
The LEAP 2.0 project is intended to address this problem by means of a relatively simple and highly flexible interoperability specification for information which often occurs in the context of portfolios. It defines simpler replacements for several of the elements of IMS LIP, but holds back from defining new elements where there are currently widespread and effective specifications in place. All and any portfolio information is conceived as a directed graph - that is, simple, small items of information connected by relationships. But LEAP 2.0 is intended to allow any binding that can be reliably transformed into this simple form - which is soundly founded on Semantic Web concepts and the DCMI Abstract Model. Types of both items and relationships are defined as class hierarchies, with richer, more specific and particular elements as refinements of broader, simpler ones, to allow graceful degradation of interoperability.
There is another page to explain LEAP and Semantic Web connections.
Simon Grant has written an article expanding on this idea of a type class hierarchy.
The Portfolio SIG Meeting Chester 2006-12-05 was well represented with major players known to JISC and JISC CETIS working in the field of e-portfolio interoperability. There, it was agreed that UK LeaP and IMS ePortfolio needed development - mainly simplification - and that for want of a better name these developments should be known as "LEAP 2.0".
The name "LEAP" has its roots in "UKLeaP", which was intended to be BS 8788, but as it happened those who advised BSI (probably wisely) downgraded it to a "DD" - a draft for development, BSI's DD 8788, and now it has been abandoned. The name UKLeaP itself was the subject of some debate: some held it stood for UK Learner Profile; others for UK Lifelong learner Profile. This was in turn derived from IMS LIP, which was often held to stand for "Learner Information Profile", despite the fact that the IMS pages name it "Learner Information Package". One of the problems with UKLeaP was that its drafting was constrained by an agreement with IMS to keep within the IMS LIP information model. Along with many other names which similarly were originally acronyms, it is suggested that "LEAP" does not stand for any particular words.
"2.0" is obviously a reference to "Web 2.0". Unlike many suggestions for "Web 2.0", "LEAP 2.0" is to be pronounced, "leap two". Forget the "point", the "dot", the "oh", "zero" or "nought", because they are just there for people to disagree on. The idea of simplifying LEAP is very much in keeping with the Web 2.0 philosophy of "small pieces loosely joined".
Careful web search reveals that this is not the first time that the name "LEAP 2.0" or "Leap 2.0" has been used, but fortunately the other uses seem to be outdated.
At that meeting, we (the coordinators) judged that there was informal but clear agreement that:
In essence, the main objective is to create a specification that is much simpler to understand and implement than IMS eP.
We are encouraging a review of, and links for and use cases etc. for, requirements for e-portfolio interoperability. Please visit and add to that page.
Among many requirements which are speculative, there are a couple of fundamental ones:
We put together a LEAP road map, which may be of some interest: people are still very welcome to improve it. It refers to the pages on LEAP systems and system owners and LEAP ontology
Please go ahead and add content to the parts/speclets that you can find.
If you would like to add a personal view page, please go ahead, and link to it from this section. I suggest you use "LEAP 2.0" and your name as parts of the page title.
The LEAP classes page defines the classes.
The LEAP predicates page defines the metadata and attributes as well as the relationships,
The LEAP parts page gives some general rationale, and relates classes to other specs.
The LEAP relationships page adds a little more background about relationships.
It seems logical to assign viewing permissions to selections, perhaps more normally than to individual pieces of portfolio information. It may also be useful to transfer permissions along with portfolio information when it is communicated.
Various systems allow fine control of viewing, and what is currently practised needs to be reviewed to construct a good way of specifying this for interoperability. The spec here should cope with all common permission models which are implemented in portfolio systems, plus the normal Unix-style filesystem permissions, and web page permissions as done by Apache.
Permissions are not simple, and have inherent structure. Permissions are set by someone, can be changed by some people, last for some time, and apply to a person, group or role. So there is not going to be a single permission predicate relating just an item and an agent, but some permission item, related to agents, items, and temporal metadata.
It would be most useful to include different kinds of permission. This may include
The last would be very useful for expressing the policy that specific things should not be seen by specific people.
A rational basis for a permission item to start with might be something like this:
It might be useful to have a precedence order, to allow for general rules and exceptions with positive and negative access controls. A default might be that a more specific permission takes precedence. A permission for an individual or an item takes precedence over a permission for an organization or a selection. The difficult case would be ordering an individual permission for a selection and an organizational permission for an item. This could be avoided by specifying that the organizations cannot have item permissions.
An simpler rule would be that exclusion always takes precedence over inclusion. Perhaps this would be adequate in practice.
Then there needs to be provision to make it difficult to forge permissions. (Anyone that knows about security please feel free to add something here.)
In a world where portfolio information could be distributed across many different systems and repositories, it makes sense to think about handling and representing the origin and updating of information.
A possible outline specification for recording e-portfolio information transfer would be as follows:
If a system kept information equivalent to this, it would make it possible to track the origin of any particular portfolio parts. This information could also be transferred between systems.
Each possibility needs explanation and exploration. Please create a new page, linked from here, for any possibility not yet represented.
See also the list of LEAP references.
