INST > Clients > JISC

Competencies for XCRI

Simon Grant - 2006-07-14

Executive summary / abstract

Representing course entry requirements and outcomes in a standard way would go some of the way towards enabling services to learners that clarify possible educational pathways for them, and which could also lead through to employment. XCRI has started out representing entry requirements in terms of previous courses, and now there is a clear motive for broadening this to including competency requirements, where the term "competency" is understood inclusively.

HR-XML includes a useful spec for representing competency in human-readable terms, but needs to be profiled before it can effectively provide the basis for automatic processing of requirements and outcomes. The RCD spec is used for representing individual competencies, used as identifiers when writing requirements or outcomes. For some attainments, there may be authorities willing to define and hold identifiers centrally, but for generality and use with competencies another approach is needed, extending RCD.

A new approach is outlined whereby competency definitions can be federated through explicitly naming equivalents in other institutions, and excluding non-equivalents if necessary. It is proposed to add a representation of this to the RCD spec. This will allow institutions to hold their own competency maps and definitions, and still participate in the movement towards common definitions, enabling a more open approach to educational pathway information. This approach fits well with a "Web 2.0" philosophy.

Background and rationale

The draft paper on XCRI submitted to the TEN Competence workshop in Sofia (March 2006) included the following paragraph:

"A key focus for schema development will be ensuring that course entry requirements are modelled in the same ‘currency' as recognitions of achievement - qualifications, certificates and licenses, etc. It is hoped that entry requirements expressed in such a form could be used within a service-oriented environment to discover pathways currently open to a learner, prompt them on how to structure their application, and identify any pre-requisite studies necessary to enter a particular course. XCRI will be working closely with UK e‑Portfolio and e‑Admission projects to pursue this ambition."

In broad terms, there are requirements for representing course-related competency information in two areas:

  1. course entry requirements / entry pre-requisites / entry profiles
  2. intended course learning outcomes.

Naturally related to this, information about the competencies of individuals needs representing:

  1. attainments prior to course entry, to be matched with entry requirements
  2. attainments on course completion, which could be compared with intended outcomes.

An ideal approach would be to have the same format for both sets of requirements 1 and 2, so that the competencies of individuals can be directly compared with course-related information, and so that the intended outcomes from more elementary courses can be directly compared with the entry requirements for more advanced courses. This latter comparison would provide a basis on which educational pathways can be charted. This could potentially feed in to information, advice and guidance (IAG) services.

If recruitment requirements, and person specifications used in HR, could be put in a comparable form, IAG services could gain a valuable tool in the area of careers guidance, as it would be possible to chart the plausible educational pathways leading to career goals.

The fact of having this information in a common format would already be very helpful for the services envisaged. However the potential would be very greatly increased if substantial parts of the information were represented with sufficient conformity to allow a degree of automatic processing. For example, a potential student may want to know the answer to a query of the form, "what courses in politics or economics are available in Wales for someone with an A grade in A level Mathematics, a B in English and a C in Religious Studies?" If the information is held in an unstructured textual form, the only way of discovering this information would be by painstaking reading of the course requirements. The more complex and wide-ranging the query, the more students would be deterred from fully informing themselves, with the result that the courses applied for would be a less optimal fit to individual requirements. In contrast, initiatives along the lines of XCRI could help a better fit between individuals and courses.

Key issues

Meaning of competency in this context

To be of general use, an inclusive term is needed covering all kinds of attributes of a person that could be relevant to course entry or assessment on completion, and ideally to recruitment as well. Single terms that covers all these aspects are very general: quality, attribute, etc., and do not give the desired impression that the core concept is to do with knowledge, skill or ability that can be developed or encouraged through educational processes. In the absence of a single good term, several authors have used the term "competency" in a broad sense, including IMS (e.g. in IMS LIP) and HR-XML.

The HR-XML definition of "competency" is well-suited to business HR contexts.

"A specific, identifiable, definable, and measurable knowledge, skill, ability and/or other deployment-related characteristic (e.g. attitude, behavior, physical ability) which a human resource may possess and which is necessary for, or material to, the performance of an activity within a specific business context."

For use in conjunction with XCRI, "business" in this definition could be replaced with "educational or business", and "human resource" could be changed "individual", which would tie in with the UK definition of PDP. The core business of educational and academic institutions is to educate individuals, rather than to develop teams, so it seems justifiable to lose the HR-XML implication that the human resource could be a group.

The important thing is that for these purposes, "competency" needs to include knowledge, skill, ability, attitude, personal quality, etc., in order to avoid inappropriate disputes about what counts as relevant to the e Framework and other JISC purposes. Such discussions can be taken forward elsewhere, and need not impinge on the XCRI domain.

In the rest of this report, the term "competency" is to be taken in this wide, inclusive sense.

Prior work

The first question to spell out is, how much does existing work satisfy the requirements above?

Original work for XCRI, based on Norway's "Course Description Metadata", is highly relevant, and will be analysed in more detail below. This analysis will cover the question to what extent does it cover the requirements; and what is missing?

The HR-XML schemas and specifications will be taken next in a similar way, as these specifications are relatively widely used in HR circles.

The last area of prior work to be considered here below is the representation of individual competency definitions. In 2002, IMS pioneered the RDCEO specification, Reusable Definition of Competency or Educational Objective and this is being taken forward by the IEEE as RCD (Reusable Competency Definitions http://ltsc.ieee.org/wg20/)

Detailed considerations for original requirements

If competency information about course requirements and individual attainments is to be represented according to a single schema, that schema needs to take into account the nature of the information that will be stored. Any specification needs to allow people to store information in a form which relates reasonably to the original form.

The nature of course entry requirements / pre-requisites is varied. They cover, for example:

Clearly it is likely that many of the non-competency pre-requisites can be seen as substitutes for the defined competencies which the candidate is likely to have as a consequence. However, to be useful at present, and to provide an evolutionary pathway, it is still important to be able to represent requirements not represented as competencies.

Applicants for courses can also have a variety of different kinds of attainment, and different kinds of evidence supporting claims to these attainments. These also need to be represented in a format which can be related to the original without excessive effort.

Squeezing all of these formats into one is not straightforward. One could (and many do) use a plain text format, but that is in effect admitting defeat, as it would be extremely difficult to arrange any reliable automatic use of the information.

It is easy to imagine examples of entry criteria that are clear enough, e.g. "grade B in A-level English", and examples that are "softer", or less hard-edged, such as "well-motivated" or "socially aware". But there does not appear to be any clear and reliable boundary line between such "hard" and "soft" entry criteria. "Hard" evidence can support a "soft" criterion, and particularly where a "hard" criterion has a (common) rider like "or equivalent", soft evidence can be offered in the realistic hope of fulfilling the criterion which was primarily designed to be "hard".

All these considerations need to be taken into account for an effective competency schema, to be discussed further below.

Emergent requirements

Beyond the need to represent information as initially outlined, careful consideration reveals other requirements that need to be satisfied in order to achieve a working socio-technical system that uses the competency information, in an effective way, to achieve some end. Foremost among these are the requirements firstly to use a compatible set of competency definitions, and secondly to be able to identify references to the same competency when made. Thus, the competency definitions used when composing a competency profile for an individual must be able to be mapped onto competency definitions as used in the process of selection for admission (or recruitment). If this mapping can only be done in the mind of admissions or recruitment staff, the process will be much slower, as well as being prone to human error, possibly due to lack of knowledge.

The fact that people generally understand each other when referring to competencies hides a mass of disagreement on exactly what a particular competence might mean. Take the term "social awareness" as an example. We probably all have a general idea of the kind of concept the term might be used for, but the difficulty in defining what exactly it is probably hides many concepts that differ in one way or another.

The approach taken by LUSID (originally Liverpool University Student Interactive Database, home page now http://lusid.org.uk/) was (and remains) to break down vague or debateable high-level terms into lower-level terms that are more likely to be agreed, and then allow people to disagree on how to compose the lower-level terms into higher-level ones, or on what the higher-level terms mean in lower-level terms. This is done by using primarily the agreed lower-level skills to index the information managed by the system. LUSID initially operated in the area of those generic skills often known as key skills or employability skills, which are not tied to specific subject disciplines.

This was taken on, refined and broadened in the course of the SPWS (Skills Profiling Web Service) project. SPWS worked with skills in undergraduate medical education from three institutions. The project recognised the need to separate those concepts which were likely candidates for agreement from the ones where agreement was less likely. The approach suggested by SPWS, working in the field of undergraduate medical education, was to set up agreed definitions covering the concepts, and then to let individual institutions refer to those agreed concepts when defining their own competency map for use in their own institution, whether in conjunction with courses or in other ways.

But how, in such an approach, are the agreed definitions to be set up and maintained? The approach is plausible if there is a body which is able and willing to take on an independent registry or repository of shared definitions, but what happens before that, or in cases where institutions and other bodies cannot agree, or where there may be an industry sector body, but it is not trusted to fulfil that role?

These considerations highlight the nature of the requirement in that area, which needs to be fulfilled in order to allow for effective comparison of competencies between educational or other business bodies; and for evidence gathered in one context to be reused in others.

In addition, in principle, there is also a need to consult with e assessment community, to agree a common format extending to references within assessments about what competencies they assess. This is also recognised within the HR-XML community. However, this consultation is beyond the scope of this report.

Looking again at the list of possible pre-requisite or entry requirements, it seems fairly clear that for the foreseeable future there will continue to be entry requirements which are not purely competence-related. But perhaps we can look forward realistically to a gradual shift from vaguer forms of requirement towards more competency-based requirements. It will be the competency-based requirements that will provide the best long-term hope for automatic (but not infallible) and broad-reaching pathway guides, and it is for this that we need the common definitions. Any other clearly defined and frequently used condition could be processed automatically, so there is a motive for defining these alongside the more obvious skill-based competencies, despite the fact that they will typically be less general in their application.

Existing XCRI treatment of competencies

XCRI's starting point was to cover entry requirements and "entry profiles". Alan Paull has explored how to take course requirements following the original schema, and transform them using XSL to generate a form for applicants to fill in. One could use this kind of form for direct submission to a course entry selection process. Interestingly, in his approach, some conditions are envisaged as being automatically gathered and used, whereas others need to be filled in by a candidate around the time of application, as they are typically not readily reusable.

The role of competencies in the XCRI schema current at the time of writing (2006) was through the "requirement" element, which is composed of any number of

The "Specs" elements essentially refer to other courses.

In essence, at present, this means that entry conditions requirements can be specified either as exam results (recognition) or as other courses (the other specs elements). It is easy to say, loosely, that a prerequisite for one course is another course, but this glosses over the fact that it is not the course itself that is the prerequisite: rather it is something about the individual's performance on that course. In this context, individual performance can be anything from bare attendance, through passing as opposed to failing, to particular marks or grades taken from another course transcript for different aspects of that other, earlier course.

Commonality in competency and level definitions

If individual claims and entry conditions are to be coordinated, in line with the stated objective, the language used in both claims and condition needs to match, in terms of the attainment level as well as the subject of the competency or qualification. Consistency in the representation of attainment levels could be achieved by the consistent use of a public vocabulary, but given variation and fashion, it would be perhaps safer and more flexible to allow the specification of the attainment level vocabulary for each separate entry condition. To reflect these two possibilities, a vocabulary could be specified either internally or externally. Internally, it would be given as a list, and externally, a reference could be made to a vocabulary file - with a specification such as IMS VDEX. Similar mechanisms were provided in IMS LIP, which was highly reliant on vocabularies. However, perhaps a lesson could be learned from LIP: while the original intention seems to have been for IMS to maintain at least default vocabularies themselves, this was not carried through, and so implementers were left to their own devices.

The choice is now clearer: either there needs to be yet another attempt to agree central agencies to hold definitions of competencies and levels, or a different mechanism has to be found which does not rely on a centralised approach. It is this latter approach that is explored further below.

HR-XML and XCRI

The HR-XML consortium (loc. cit.) maintains several definitions: the documentation is available freely on application, but the several parts have no distinct addresses.

This report does not set out to assess the value of the large majority of HR-XML specs. It is only the "Competencies" and "CompetencyTypes" schemas that are of direct interest. The competencies schema is able to represent in some way at least the requirements for recruitment to a particular employment position, and within a resume, the competencies claimed by an individual candidate for a particular position.

For ease of reference, the outline information model of the competency schema is shown below in Annex A, omitting some detail which is not needed for present consideration. The full details are presented in the HR-XML documentation. The competency schema is given at http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/Competencies.xsd

It can be seen quickly that there is little duplication between the HR-XML competency spec and the treatment of requirements in XCRI. Would the HR-XML spec help to fill a gap? At first glance, it seems like a possibility worth exploring. To clarify, let us look at some examples.

First, the first example given above, "grade B in A-level English". While it would be possible for the whole thing to be given in the (later) description element, this would not advance machine processability at all. To approach machine processability, one would have to use the CompetencyId and possibly the TaxonomyId elements. However, as it made clear in the HR-XML examples and documentation, no overall universal identifier for "A-level" has yet been envisaged within HR-XML - it would be a matter of agreement between all the parties to an interoperability scenario to agree identifiers. Then there is the question of "grade B". Presumably this would be represented as a StringValue element within a CompetencyEvidence element. Could everyone be sure that this would be completely agreed? It is not clear.

Moving on to the second example, it is substantially more challenging to provide anything at all machine processable for "well-motivated" or "socially aware". It should be noted carefully at this point that there are two separate issues of machine processable representation. One - which is clearly extremely difficult, and would not be attempted - is to represent evidence for good motivation or social awareness in a form which can be matched automatically and reliably. It must surely be a matter of human judgement. But the other issue is the representation of what subject the competency is required in. At present, there would appear to be nothing remotely like a universally understandable reference to good motivation or social awareness.

These points are sufficient to illustrate the role of HR-XML, or any similar specification. The specs have plenty of detailed structure available for representing, in a human-oriented form, both requirements and evidence for competency. The fact that the spec is in reasonably widespread use confirms that it succeeds in playing that role. However, HR-XML advances little towards the objective of representing competencies in a way that can be automatically matched. The major way in which interoperability and machine processing might be established in the way envisaged with HR-XML would be if one authority, or senior partner in a business relationship, set down a particular set of competencies which they recognise, together with the CompetencyId and TaxonomyID values. These ID values would ensure that reference to competencies is clearly understood without being compromised by, say, spelling mistakes, different but equivalent terminology, or different languages.

The challenge would then come in the implementation of a socio-technical system involving XCRI and course information. In order for the competencies set out as entry conditions to be comprehensible to all likely users, someone would have to lead in offering to define, and to host, common competency definitions. It is not at all clear in general who would (or indeed could) do this.

The overall recommendation for XCRI is thus contingent on the desired use of the schema. If it is judged sufficient to work with human-only readable information about competency requirements, pre-requisites, etc., then HR-XML, as is, would seem like a plausible option to fill the gap in representing competency-like requirements. If a central authority (such as UCAS) were to establish and maintain the competency definitions, it may then be just possible to answer a defined range of questions like "what courses in politics or economics are available in Wales for someone with an A grade in A level Mathematics, a B in English and a C in Religious Studies?". Even in that case, work would be needed to define what would be an application profile of HR-XML. But there seems to be no feasible way that this approach could lead to effective answering of some of the deeper imaginary questions, involving educational pathways of several steps in different institutions.

Another side to the question is the prevalence of HR-XML. As it is accepted by many employers, it would make sense to use a profile of HR-XML to deal with appropriate information. In this way, information prepared for application to courses with XCRI definitions could be potentially reused for applications to employment by employers who use HR-XML.

As a footnote to the discussion of the HR-XML specifications, one could note the HR-XML CompetencyTypes schema. The scope for this is set out as "practical exchange of competency references", and out of scope are "competency taxonomies", "proficiency levels" and "proficiency level scales". The intention seems to be to standardise on the way in which competency definitions are referred to elsewhere than the definition itself. The provision is essentially for a URN, which in turn can reference an RCD, the subject of the next section.

RDCEO / RCD for individual reusable definitions of competency

IEEE RCD is the successor to IMS RDCEO, and acknowledged as such by IMS. This family of specifications provide a format for public definitions of competencies, but neither any structure linking them together, nor any guidance about the internal logical structure of, or terms used in, any particular definition. They could easily be used in conjunction with HR-XML, or any other extension of XCRI to cover competencies.

In practice, an RCD is a particular example of the more general concepts of "subject identifier" and "subject indicator". (See e.g. http://www.ontopia.net/topicmaps/materials/identitycrisis.html.) The terms "published subject identifier" and "published subject indicator" (both, ambiguously, "PSI") have been used in the Topic Maps community. The essential concept is closely related to one of the intended uses of the URI: to provide names or references for things which can be used anywhere on the Web and is very widely used, for example as identifiers within RDF or Dublin Core. Where two resources (especially two topic maps) both use the same PSI, one is free to assume that they intend to refer to the same "subject". There is much written about this area on the web: interested readers can also find a CETIS article by Wilbert Kraan.

The current draft RCD specification (2006-03-08) has a relatively simple information model, which has not changed much from the earlier RDCEO:

RCDs can easily be used in conjunction with HR-XML or any other specification where there is a need for an external, shared, reusable reference to a particular competency. However, the specification still leaves completely open the larger question of building effective socio-technical systems which use common definitions.

Later on, we will use the term "RCD+" to refer to a definition like RCD, but with any additional elements necessary to tackle the last point.

Requirement for competency "maps"

It is well noted above that one major requirement for competency interoperability in general is for a set of competency definitions which are agreed on by the parties desiring to interoperate. Having considered the role of individual definitions of competency, the requirement that naturally follows is to specify how the competency definitions will be related to one another, and where these relationships, as well as the competency definitions, will be held.

For internal consistency, each institution, or possibly each division of larger institutions, will need to keep a record of the competency definitions used, which are relevant to that body. In addition, it is possible to envisage bodies that serve for networking or association hosting some independent records. The format in which these are held is not critical, but here they will be referred to as competency maps. A competency map could be in the form of a flat list of the competency definitions used; or in the form of a taxonomy, or a taxonomy with crossing branches, like LUSID; or a thesaurus; or, most generally, a topic map, which could represent all of the others mentioned. A competency map can then be used as the basis for locating the competencies within a wider organisational ontology, if there is one.

There is a useful image associated with the concept of a competency map. The map charts out the ground to be covered (e.g. by a course or a person), and how much each place is covered can be seen like a heap on that place on the map. After heaping up the piles of evidence (for people) or weighted learning outcomes (for courses), one can turn the map on its side and see a competency profile.

A new approach to cross-referencing competency definitions

Having competency maps is a good start, but as in the Topic Maps community, there is the question of putting maps together, or "merging" them, so that one can see how one ontology including competencies relates to another such ontology. The problem has been touched on in several places above. In the absence of an influential and respected authority prepared to define and maintain definitions, and of others willing to use these definitions rather than their own, it is necessary to have another mechanism.

The mechanism proposed here appears to be new, though it may turn out to be related to other previous ideas. In essence, it is to allow every RCD-like definition to state, as part of the definition, which other similar definitions maintained by other authorities are counted (by the owning authority) as equivalent, and which are definitely not regarded as such. Because there is no natural place for this information within the RCD information model, this extended model will be referred to in this report as "RCD+". It needs a better name, to capture its potentially very wide significance.

One way of thinking about the extra information in an RCD+ would be to compare it with the "FOAF" concept and specification. ("Friend of a Friend", http://www.foaf-project.org/) The idea of FOAF is "about creating a Web of machine-readable homepages describing people, the links between them and the things they create and do." It is clearly an idea that has some appeal to some people, and if many people used it tools would be able to show social networks in a very interesting way.

The great strength of projects like FOAF is that they are inherently decentralised. There is no concept of a central registry of friendship. It is just the power of the network, out of which (it is hoped) emerges the potential. This is one of the essences of "Web 2.0" thinking, and would be exactly the same with RCD+.

Without any of the cross-links claiming equivalence, everyone's RCDs would behave just as they do at the moment. The only way to be sure that it was the same competency referenced in two places would be that it had the exact same RCD identifier. But when one introduces a statement of equivalences, it becomes possible to establish equivalence between two or more uses of an RCD+ without them either being identical, or there being any kind of central registry.

In practice, for example, it might work that two educational institutions decided that it would be valuable to interoperate with competencies. They could compare their competency definitions, and both put in reciprocal equivalences where these were justified. This would be the basis for a solid recognition of equivalence. If only one party claimed equivalence, it would be less certain.

It is very easy to see how, in this unregulated Web 2.0 world, for instance, some course provider could groundlessly claim that the competencies achieved as the outcome of their course were equivalent to the competencies achieved in a longer-established course. To deal with this, a disclaimer facility is needed. The course with the established reputation could add a "not-equivalent" declaration aimed at the pretentious new course. After that, no one would be in any doubt but that the claimed equivalence was specious.

If this approach was undertaken, and institutions went through the process of comparing their entry requirements and learning outcomes, it would soon become clear which ones were likely to be able to be shared, and which ones were likely to be specific to the institution. For example, a requirement for a module that one had completed a previous module from the same degree programme would be essentially specific to the host institution. If there are other motives, for instance, pushing towards the ability to transfer students between institutions, it could readily be seen that this kind of condition was not open.

Thus the proposed approach would accommodate current practice, while being naturally conducive to evolution towards competency-based conditions with shared definitions.

Information model for satisfying envisaged requirements

For the original competency requirements

The original schema of XCRI does not deal substantially with competencies. HR-XML does, but is a very open specification, of the kind that works fine when holding information destined exclusively for human, not automatic, decision making. While there are no other well-known schemas (known to this writer) dealing with representing competency requirements as such, HR-XML still does seem to be rather cumbersome - woolly even, a bit like IMS LIP. On the other hand, HR-XML seems to be reasonably well adopted. Perhaps the most promising option would be to cut down HR-XML in an application profile which leaves it less open to variant possibilities for representation. To determine a good application profile needs further work, beyond the resource available in the context of this current report.

Every mention of a competency within XCRI instances should be referenced to a competency definition, as below.

For the competency definitions

The information model for these competency definitions should be based on the current draft of the IEEE RCD specification. On top of that, in order that RCD+ definitions can be federated, additional elements as discussed above should be added to the information model. The resulting information model would look something like this:

For competency maps

There are many possible ways of representing a competency map, and there seems no need to specify their exact nature at this stage. Indeed an attempt to specify the nature might be counterproductive, as it would form the basis of potential argument. If desired, Topic Maps could be recommended as a widely adopted, standardised technology offering useful visualisation tools. However, there should be no attempt to discriminate against other approaches to knowledge representation. The essential point is that all the subjects in competency maps must be referred to their appropriate RCD+ definitions.

Recommendations for strategy to implement representation of competencies on top of XCRI

Each authority (an institution or other body, or a division of one) should hold, on a publicly accessible server, the set of competency definitions used by that authority. As circumstances allow, these should be cross-referenced between institutions in the manner described above, and the cross-references actively maintained. Cross-referencing should be encouraged, with the rationale that opening up educational pathways requires entry conditions and course outcomes to be defined in common terms, rather than terms specific to the authority.

For comprehensibility, authorities should be encouraged to maintain an overall competency map (in the form of a topic map or similar human-oriented explanatory structure) explaining the interrelationships of the competencies to each other, and to other operations, perhaps representing a business ontology.

Authorities should be strongly encouraged to specify their entry requirements, and intended learning outcomes, in terms of their public set of competency definitions, as it is only in this way that services will be able to pick out educational pathways permitting increasingly open access.

The XCRI specification should be extended with an application profile of HR-XML designed to maximise the chances of machine processability. This application profile is left to be determined, but the aim would be to be as simple as possible to represent the necessary information in all its likely forms, but no simpler.

Questions of binding and implementation of the above information models are left for future decision.

Registries and repositories for competency definitions are not recommended as a first step. As stable sets of equivalences emerge, it will become clearly what the role of any future central agency could be, if any, and definitions could in some circumstances migrate to the care of a central agency, if the motivation for that step became clear. In the meanwhile, a Web 2.0 like approach will provide what is needed, as and when the various authors and authorities are motivated to put in the resource. Without such motivation, any central system would in any case be unlikely to be effective.

In the case of other entry conditions that are in widespread current use, typically qualifications rather than explicit competencies, a quick win would be for the authorities centrally involved with these - in the UK, UCAS and the examining bodies - to define and stably maintain identifiers that could be used by institutions and other bodies in their course entry requirements and course outcomes. This might have a positive priming effect.

In the longer term, as it becomes clear what is likely in practice to be agreed between institutions, relevant independent bodies may be able to hold common competency definitions, taking over from individual institutions the burden of maintaining their own. But it is important to retain the safeguard of allowing institutions to define their own competencies and equivalences, so that agreement will be by consensus and not by coercion, which is inimical to actual interoperability.

Postscript 2008

Subsequent work on XCRI has now included competencies, so that they can be referenced both as course prerequisites and course outcomes. Work on ioNW2 has now strongly suggested that RCD as such is not the ideal format, and suggests instead using RDFa in XHTML for representing competence definitions.

Annex A - an outline of the HR-XML information model

A * after the element name, as is conventional, indicates that the element can be repeated or included several times. Most elements are optional.

page maintained by and © Simon Grant, edition 2008-06-05