LEAP road map

Part of LEAP 2.0

Here is a sketch of a road map towards those objectives. In particular, we envisage a set of parts, each with an information model which is as simple as possible, elegant and subtle, but no simpler. Discussion of bindings and implementation technologies may often be fruitfully postponed, as long as there are no particular hazards foreseen. The process as described below is bound to have room for improvement. Please discuss this on the CETIS-PORTFOLIO-DEV list, and conclusions from there will be reflected here. Alternatively, just send us (the SIG coordinators) the ideas.
 * 1) Identify the actual LEAP systems and system owners concerned about interoperability. (This was vital for XCRI.)
 * 2) Agree in outline on the types of part (element, object, item, record, whatever) to be distinguished. Don't spend ages insisting on complete agreement at this stage, just the general principles. This should be really quick, as we have covered the ground in the last year or two.
 * 3) From the start, some consolidation work would be useful, if suitable people volunteer. The main development should not await outcomes, but these processes should feed in when results are agreed.
 * 4) * A LEAP ontology exercise, in conjunction with people from related domains, to guide the choice of fundamental elements.
 * 5) * Object-oriented design exercise, culminating in a model of classes and inheritance.
 * 6) Starting with the easiest and least controversial, look at each part in turn.
 * 7) * Work to agree on the attributes of those parts that are reckoned as important by most people
 * 8) ** not necessarily by all, but more than a small minority.
 * 9) * Consider how to include the really useful true metadata
 * 10) ** ownership
 * 11) ** user classification and/or tagging (or are those relationships)
 * 12) ** anything else?
 * 13) * Check to see which other specs or standards could beneficially coordinate with that part.
 * 14) ** What other approaches are already taken by other systems on the web, or web services?
 * 15) ** Is this kind of information already held somewhere, and if so, in what typical form?
 * 16) ** What APIs are there, or could there realistically be, for accessing this information?
 * 17) ** This should help to guide the approach towards coherence with current practice.
 * 18) ** Obviously, a particular interest will be other specs of interest to JISC CETIS.
 * 19) * As each element is agreed, publish the agreement (on this site), so that it can
 * 20) ** serve as a prototype for other elements to come
 * 21) ** be open for criticism and improvement.
 * 22) Continue this process, part by part, until a substantial number of important parts have an agreed, self-contained information model.
 * 23) * The essence of this approach is that the spec for each part should be self-contained; thus it is possible for there to be principled variation in the approach taken for each part. This may be particularly appropriate for
 * 24) ** skill or competence
 * 25) ** assertion/reflexion statements
 * 26) ** consider also relationships (as next below)
 * 27) As the process is proceeding, reopen the question of representing relationships between parts.
 * 28) * Consider the pros and cons of the established ways of representing knowledge structures, including RDF and XTM.
 * 29) * Pick up the work on relationships from UKLeaP
 * 30) The information model needs to be supplemented by proposals for implementation. At this point, investigate and discuss different approaches to implementation, including XML-based specs, RDF, or XHTML / RDFa.
 * 31) At this stage, it should be ready for trial, roughly at the stage that was reached a year ago with UKLeaP and IMS eP, but which has not progressed very quickly since.
 * 32) As trials proceed, the remainder of the development processes are resolved.
 * 33) * The issue of permissions (with legal and data protection implications) is a general problem in distributed systems and includes the question of how to identify groups and users and policies across heterogeneous systems. This argues for it not being included in the 'core' of LEAP 2.0 but instead a reference to a solution 'out there' as it develops (maybe based around OpenID or CardSpace)
 * 34) We then have a working draft spec.
 * 35) * We initiate taking this through the JISC CETIS channels to whichever we feel is the most appropriate standards body.
 * 36) * The community who will have helped develop the draft should get a clear say about where to go.
 * 37) Meanwhile, JISC encourages projects to use the draft, and experience of actual interoperation builds up.
 * 38) An important development at or before this stage will be the reconciliation with other related specs. The idea will be to integrate as seamlessly as possible, allowing XML files with mixed namespaces, and fixing on the fewest possible ways of representing a given piece of personal information, shared between the specs. Consider whether this kind of integration would be useful (or not) in respect of:
 * 39) * IMS eP itself (as backwards compatibility)
 * 40) * IMS Enterprise, which also represents people, contact details, and relationships between people in provision systems
 * 41) * HR-XML, which represents competency (for requirements, in particular)
 * 42) * XCRI for the shared use of competence goals and attainments, related to courses undertaken or planned
 * 43) * IEEE RCD for competency definitions
 * 44) * ATOM/RSS as a general approach to fetching blog entries and similar material for inclusion as reflexions etc.
 * 45) * Dublin Core for metadata
 * 46) * etc. - please suggest reasoned additions here