You can put an alternative or longer title here
Introduction
The pressing task is to complete relevant information from a good range of significant sources, including all the important stakeholders that we know.
Each separate and independent stakeholder or source should have a separate page like this one. Use your expert judgement to record all points that are important for InLOC about this stakeholder or source. This page is able to be viewed by anyone in the Workshop, so nothing confidential should be put here. In particular, do not put any individual names or contact details.
The tables below are provided for convenience, together with explanations, but please use the format that works best in your judgement both for the writer and possible readers. If you copy this page or the tables, remove the explanations when you fill in the information. The tables are given for guidance: it is not compulsory to fill in every row. Exercise your judgement.
This initial section can be an introduction to the stakeholder or source; perhaps with a first paragraph highlighting the most key findings.
General information
This is meant to be generally useful information about the stakeholder or source model.
| information to be gathered | details (replace these explanations with your gathered information) |
|---|---|
| Name / title of source/model and version if applicable | The name or title of the source or model, such as HR-XML or CEDEFOP. Note that some sources refer to specifications, some to the stakeholder or the bodies of content where the model is implicit. |
| Stakeholder | The name and organisation of the stakeholder that provided the information. Do not put names or contact details here, but instead in the stakeholder spreadsheet. If you provide the information yourself, then identify the stakeholder community. |
| URL of source or stakeholder | Links to the source or useful information about it. |
| Orientation (work, education etc.) | Is the source model oriented to learning education and training (LET), to jobs, to both, or is it more generic (if so, how)? |
| Explicit model or implicit model? | Is the source model explicit or implicit? i.e. are you documenting an existing model or inferring the model from the data or conversation? |
| Can organisations have competence? | Is the competence of organisations covered, as opposed to the competence of individuals in the organisation? (no here means just individual competence) |
| Number of people currently affected | Approximately how many people are affected by the source or involved in processes governed by the model? |
| Sectors covered | What sectors are covered? |
| Groups of actual users | Which communities of users covered? |
| Significant use cases | Are there any use cases available? If so provide links to them or document them here, on separate pages if necessary. |
| Significant business cases | Are there any business cases available? If so provide links to them or document them here, on separate pages if necessary. |
| Sample materials | Are there any sample materials available? If so provide links to them or document them here, on separate pages if necessary. |
| Key features influencing their uptake of InLOC outputs | What do we in InLOC need to do in order to get these stakeholders to adopt InLOC IM as their way of representing LOCs or frameworks? This is vital input to the Guidelines. (Make this as long as necessary: it is probably best written separately rather than in this table.) |
Features of the model
Please see the separate Features page, put separately so that there is just one authoritative source for the features we are seeking to record, and include the table here.
Detailed information about the stakeholder or source
Here please write any more detailed or specific information that relates to InLOC, or any answers that are too large to fit comfortably in the table format. The following sections explain the tasks further, and are not template material.
Stakeholder sources
There are three obvious kinds of stakeholders, individual or collective/corporate:
- tool developers: those who may implement InLOC specifications in developing their ICT tools;
- users of the structures: those who may structure and organise their information or policies in accordance with InLOC specifications, and may use the developed ICT tools;
- groups with models, or other ideas, that can contribute to or draw from InLOC outputs, including other projects, and bodies involved in standardization.
We may consider the first two as the direct stakeholders in InLOC outputs, and third kind as indirect stakeholders, who are important to the extent that their ideas or policies affect the direct stakeholders. Then there are at least three other relevant sources of input to InLOC, which should be connected in some way to the stakeholders above, but which may have other stakeholders without a direct interest in InLOC:
- substantial bodies of LOC content – for instance O*Net, the UK National Occupational Standards or curriculum frameworks (relevant stakeholders are those who develop and use this content);
- related specifications that cover at least some of the domain (these may be associated with standardization or other communities that develop or use the spec);
- technical approaches, associated both with groups who use them and specifications.
InLOC team members may already have expertise related to the second group of inputs, and we can integrate selected input without necessarily going through the stakeholders. However, stakeholder liaison is still vital for this second group of inputs, as InLOC needs to focus on models and guidance that are relevant to the actual stakeholders.
Document information from your stakeholder sources (Task S2)
For each stakeholder or source you are dealing with
- if it doesn't exist already, start a new page on the wiki from the Stakeholders page.
- go to the stakeholder template page, edit, select Wiki Markup, and copy the whole contents of the template page
- click on the "Cancel" button on that edit page before leaving it
- navigate to your new page
- edit, select Wiki Markup, and paste
- click on the "Minor change" box and the "Save" button
- refer back to this page to help fill in the General Information table
- to fill in the features table, you can refer both to the overall Features page, and to the pages for each individual feature, such as Identifiers.
If you are going on a source of published materials, this should mostly be OK, though you may need to talk to a stakeholder to get answers on the harder questions. In this case, you won't need to fill in the Key features influencing uptake, if e.g. it is a finished project and we will not be influencing uptake.
Actually talking to stakeholders is even more important than documenting published materials. In this case, everything you can do to find out about the implicit model, and the Key features influencing uptake will be vital to the overall success of InLOC.
It is also vital for developing consensus that everyone reads each others' stakeholder / source pages. If it's not just an obvious correction or uncontroversial improvement, please make comments using the "Add Comment" link at the very bottom of each page.
Express relevant models (Task S3)
After documenting the features of the model, and comparing with some other models, write an outline of the most essential aspects of this model that are relevant to InLOC, in terms that make sense both to the stakeholder and to the InLOC team. This task is listed separately here because of its vital importance, and its input to the information modelling work. Ensure, through sharing with team, that this outline is understandable.
Output: the essential structure of each model is written, consulted, and placed on wiki. Ideally, 1 to 4 paragraphs plus a diagram (of any kind that helps). We will have a separate wiki page on models and model features, as the same model features may occur several times. Stakeholders and models will be cross-referenced.
Probably the way forward (for discussion) is:
- build up each separate one of the Features pages, pointing to good examples of each feature (sort of, "this is a good way to implement this")
- collectively review the Features, coming to at least rough consensus about which features should be in the InLOC model
- look at the good examples to choose good ways of implementing each feature
- build up the model.
Guidelines source requirements
Please put what you think needs to be in the Guidelines deliverable to help this stakeholder, or to relate to this source. This section is vital to inform the Guidelines deliverable.
Ask yourself, what do we need to tell this kind of stakeholder, or what do they need to know, in order to use our eventual InLOC model in their work? The answers will probably not all be clear initially, but they will become clearer as we formulate the InLOC model itself, and reflect on how it differs from each of the stakeholder or source models.