Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

InLOC: the potential of competence structures

A multi-purpose presentation outlining the basics of InLOC and its future prospects

  • Be the first to comment

  • Be the first to like this

InLOC: the potential of competence structures

  1. 1. InLOC: the potential of competence structures Simon Grant 2016-10 a general purpose explanation
  2. 2. Key points ● need to specify structures ● need a simple and powerful specification ● need to define levels, as well as attribution ● represent “binary” and “rankable” ● needs some revision since 2013 to be fully ready for contemporary practice ● opportunity to adapt
  3. 3. InLOC context ● the requirement to represent skills/competences etc. ● much structured documentation out there – including NOS, ASN, e-CF, VitaeRDF, … ● but no good specifications for structures – individual stuff is OK, e.g. IEEE RCD – but IEEE SRCM (Competency Maps) stalled 2006 ● “LOC” = “Learning Outcome or Competence” – equally for learning outcomes in education, training – and work (skills; competence; competency; etc.) ● “In” = “Integrating”
  4. 4. potential significance ● adds value to frameworks of learning outcomes etc. ● provides a sound basis for genuinely useful technologies – putting together: skills frameworks and standards; e-portfolio tools; learning, education and training tools and systems; HR, recruitment and employment services; learning resources, towards new tools and services – communicating LOC structures – if public, expose to open search and query, with the components able to be reused and remixed – prompting people to assign identifiers (URLs, IRIs) to their LOC concept definitions to enable linked data for the Semantic Web
  5. 5. reusing better than reinventing ● if reuse is not easy, people tend to invent their own ● InLOC can make it easier to reuse than to reinvent 1) assign URIs 2) publish structures 3) link data together ● when people start reusing, we start to have better understanding and communication across different classes of stakeholder
  6. 6. need for common terminology ● what if the ease of comparison when using InLOC, together with growing reuse, led to people actually starting to come together in the terminology they use for the fit of human and opportunity? – education and training approach employers – employers approach education and training – services including IAG adopting the common language
  7. 7. if it were widely adopted ● what if the common terminology (together with associated URIs) became ubiquitous, across – learning opportunity pre-requisites and outcomes – basis for assessment criteria – job descriptions – portfolio and CV claims of ability and competence – resources for learning education and training – qualifications – apprenticeships – badges
  8. 8. InLOC outputs ● an Information Model ● Guidelines explaining European Learner Mobility ● Application Profile work, relevant to Europass CV ● XML, RDF, and JSON-LD bindings of that model ● integration of our requirements with the CEN work, taking forward EN15981 and EN15982 towards practical implementation
  9. 9. a little philosophical reflection … ● different people simplify things in their own way ● a realistic common model may look complex or abstract ● InLOC makes the model simple, accepting some abstraction – to help developers and implementers get into it most easily – they can manage fine with abstraction – they then produce the user tools that will make things easy to understand for the domain practitioners (who want their own languages) ● you are unlikely to see anything else this simple that covers the ground – most models have to be broken into several pages
  10. 10. the information model
  11. 11. the model as if it were UML
  12. 12. the RDF version of the model (similar simplicity: linked data, Semantic Web)
  13. 13. key features of the model ● clarifying distinction between structure and concept ● distinction between defining and attributing levels ● requiring a greater-is-better number for levels, which makes levels simple and highly flexible ● putting together several relationships and compound properties in one information model structure ● extra simplicity at the cost of accepting abstraction so that implementation is easier ● model intended for developers, not domain experts
  14. 14. the LOC structure ● LOCstructure is a little like a document ● has an unexciting set of single-valued metadata – but including the non-standard “combinationRules” ● may have sub-structures (though not simple/common) ● stands as the container of the LOC definitions – has LOC definitions as its parts ● expressly separate from any LOC definition – for clean logic and implementation
  15. 15. the LOC definition ● LOCdefinition similar to other specifications ● can be at any granularity ● expressly excludes any structural information – separating them is cleaner – reuse is enabled ● “metadata” are only single-valued ● they may have “primaryStructure” for context – may be needed in practical examples
  16. 16. the LOC association ● LOCassociation offers a single mechanism representing various things: – structural relationships between structures and definitions – associative relationships between them – compound properties of structures and definitions ● in 5 types: “by”, “category”, “credit”, “level”, “topic” ● in XML they are contained in the LOC structure tree ● in RDF they share the same graph ● probably better to split out for ease of understanding
  17. 17. InLOC levels ● defining levels and giving them ascending numbers for automatic comparison logically comes first ● a level definition is a particular kind of LOCdefinition – it has to be “binary”, not “rankable” ● no need for maximum, minimum score etc. but can easily accommodate that if desired ● can have generic levels in a structure and specific levels of a particular competence (see e.g. e-CF) ● external framework levels can be attributed to things
  18. 18. bindings ● XML binding developed for simple UML ● RDF binding needs modified info model ● JSON-LD follows RDF
  19. 19. issues since 2013 release ● getting people to contribute to frameworks and/or tools: ask – what could their motivation be? – what is in it for them? ● usually, they already have clear business models, so ask: – what is their market orientation? ● needs new entrepreneurs to collaborate – but how do we reach them – by luck, or is there another way? ● policy drivers might help motivate business engagement – but are market motivations are more reliable? ● publicity? very little so far, need to do more
  20. 20. remaining ways forward
  21. 21. encourage publication of InLOC-format frameworks ● get hold of any owners of public frameworks that would benefit from wider dissemination ● from e-CF, to Cedefop, CEN, DGs, European and national government agencies, … ● explain URIs, interoperability, reuse, linked data ● explore what value might be added by InLOC for each stakeholder – make sure they are aware of that – motivate them towards adopting InLOC ● help them (but who, and how?)
  22. 22. embed in other projects ● adoption could come through funded projects ● after some frameworks have been published, add InLOC functionality to tools, e.g. – framework manager – e-learning tools – portfolio tools ● InLOC concepts to help guide construction ● do you know of any project that could use InLOC?
  23. 23. make sure we maintain expertise for guiding future implementation ● we don't know when different stakeholders will be ready to adopt InLOC ● it may depends on either policy development, or commercial motivation, or both ● when they are ready, the easier it is for them to adopt InLOC, the more likely they are to do it ● maintain Web resources, clear signposts ● make it easy to find sources of expertise
  24. 24. tools should make it easy for users to link to InLOC frameworks ● providing frameworks in InLOC is a first step ● the next step is more of a challenge ● people – employers, learners, etc. – will only use them if they make sense and are easy enough to use ● so: – find out what makes it easy for users – ensure that system owners and developers make it easy
  25. 25. explore ●, alongside HTML5, growing as a future path for the Web ● ideal format for easy publication of frameworks ● a few more terms need adding for InLOC – make this compatible with InLOC RDF binding ● may well be worth doing ● who is interested?
  26. 26. extend InLOC as required ● look out for opportunities to simplify and clarify ● define useful APIs ● provide facilities for representing some of the structure-specific terminology – (see examples from e-CF and VitaeRDF) ● but most of all, get people to use it, so it moves on from anticipatory to real, live, implemented ● build on existing prototype demos
  27. 27. towards standardization ● when is best timing for standardization? – probably after some implementation experience – when there is a community of supporting stakeholders – when simplified, extended, or whatever is needed in practice ● compare and contrast routes – ISO (and other de jure bodies) – IETF (that is, as an RFC) –, W3C, IEEE, IMS, etc. – some new commons standardization body ● decide what to standardize and why
  28. 28. ● the Learning Technology / ITLET community needs: – open standards that are free to implement – open documentation easily available on the web – possibly also the freedom to mix in with other specs ● (that is a problem particular to ICT) ● they may ignore standards that do not offer this ● perhaps they need a new kind of standards body? more open standards generally?
  29. 29. conclusion InLOC could play the role of ● a vital piece of the jigsaw, not the final one ● an essential enabler of a new competence ecosystem ● a standard to motivate growing consensus it will take time – but the long term outlook could be very positive see or
  30. 30. thank you for your interest @asimong