Stakeholders and sources
This information may be both seriously incomplete and out of date, as it was compiled over a limited period, mainly during 2012.
Stakeholders involved with material similar to InLOC, or that could be represented with InLOC
This page lists stakeholders and sources surveyed in alphabetical order within their groups.
With source material, and a model that is explicit and formal or formalisable
- Achievement Standards Network (has worked example ASN Alaska history B)
- Common European Framework of Reference for Languages (has worked example CEFR-SI-A1)
- Curriculum Exchange Format
- Europass CV and LP (from Cedefop)
- HR-XML Competency
- Kompetansemal
- O*NET
- UK National Occupational Standards (has worked example CFAMLB5)
- UK Qualifications and Credit Framework
With source material, but no explicit formalisable model
- Australian Core Skills Framework
- Certificat Informatique et Internet (C2i) (has worked example C2i.C2i2md.d6.1)
- French Cigref IS HR nomenclature (has worked example Cigref 1.1)
- e-Competence Framework
- has worked example e-CF A.2
- is used for InLOC explained through example
- has an XML binding example
- e-Competence Framework for ICT Users
- IPMA Competence Baseline
- National Curriculum - Schools England
- UNESCO ICT Competency Framework for Teachers
- Vitae Researcher Development Framework (has worked example Researcher Development Framework)
With an explicit model, but little if any real life source material
- eCOTOOL including the Europass CS
- HR-XML PositionCompetencyModel
- IEEE Reusable Competency Definition
- IMS RDCEO
- InteropAbility
- Learning Outcome Definitions
- MedBiquitous
- Personal Achieved Learning Outcomes
Stakeholders who may refer to learning outcome or competence definitions
A detailed model of LOCs is not needed for these purposes.
- ELMO (see the CEN WS-LT ELMO pages)
- EuroLMAI including the Europass DS
- Metadata for Learning Opportunities
- HR-XML Candidate
- HR-XML EPMResult
- HR-XML Europass CV application profile
- LRMI
- Mozilla Open Badges
- Schools Interoperability Framework
- xAPI, or "Tin Can"
Stakeholders who may wish to prototype InLOC systems
Companies
Projects
European agencies who might have an interest
Original InLOC Stakeholder Liaison Plan
This is left here for historical interest: it was the intended plan during the funded project.
Rationale
Even as a team, without the close involvement of others we cannot ensure the uptake and adoption of our outputs. This Stakeholder Liaison plan is designed to promote the adoption of our outputs, while at the same time acting as a common thread supporting the main tasks and outputs, and reducing the chance that work is duplicated.
Relationship with the main outputs
The Information Model encompasses the models used by, developed by, or implicit in the information of interest to, the various stakeholders, gathered through this process.
The Guidelines covers topics of importance to the stakeholders, discovered and checked by us through this liaison process.
The Application Profiles are adapted more closely than the general information model to the models relevant to the particular applications, as discovered through liaison.
The Bindings that we document as outputs are those that stakeholders tell us are actually or potentially useful.
Stakeholder sources
These include: tool developers; users of the structures (EC, agencies, employers, LET and awarding bodies); groups with models (including standards bodies); bodies of content; related specifications; and technical approaches.
Source and stakeholder liaison tasks
- S1. Compile and maintain a list of stakeholders and sources. Document organisations (but not individual contacts) on wiki.
- S2. Document information from stakeholder sources. The key information about stakeholders is what they would want or need from the InLOC model, or eventual specification, to secure their adoption of InLOC outputs; and what Guidelines documentation is needed to facilitate their use. Document on wiki.
- S3. Express relevant models. Some are implicit, and to be drawn out, ensuring they are understandable by both team and owning stakeholders. Document on wiki.
- S4. Integrate model with growing core. This involves tracking the features of the models, and ensuring that the growing core model covers all important ones.
- S5. Refer the InLOC model back to relevant stakeholders. This is essential feedback, after the interim report and CWAs have been first drafted. It is aimed to convince the stakeholders to adopt the InLOC model.
Overall process
The liaison process is thus in two stages. First, the requirements are gathered and models surfaced. This will enable the team to develop a good Information Model and Guidelines that is at least reasonably fit for purpose. Second, the initial Information Model and Guidelines will be carefully checked with the most significant stakeholders, making whatever improvements are needed to ensure the eventual adoption of InLOC outputs.