2. InLOC context● clear requirement to represent skills/competences etc.– XCRI; OER; recruitment (in future?); IAG; VLE/LMS● much material out there– including NOS, ASN, e-CF, VitaeRDF, …● failure so far to cover structures– individual stuff kind of OK … IMS RDCEO, IEEE RCD– IEEE SRCM (Competency Maps) stalled 2006● InteropAbility (JISC project) led the way in showing thatsomething like this was practical and feasible● “LOC” = “learning outcome or competence”
3. potential significance● adds value to frameworks● provides a sound basis for genuinely usefultechnologies– putting together: skills frameworks and standards; e-portfoliotools; 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 opensearch and query, with the components able to be reused andremixed– prompting people to assign identifiers (URLs, IRIs) to theirLOC concept definitions to enable linked data for theSemantic Web
4. easier to reuse than reinvent● what if InLOC made it easier to reuse than reinvent?– assigning URIs– publishing structures– linking data together
5. common terminology● what if InLOCs easy comparison, and growing reuse,led to people actually starting to come together in theterminology they use for the fit of human andopportunity?– education and training approach employers– employers approach education and training– services including IAG adopting the common language
6. ubiquity● what if the common terminology (together withassociated 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
7. InLOC outputsCEN Workshop Agreement on:● an Information Model that offers a coherent solution to how torepresent this kind of structure● Guidelines that explain both the model itself, and its application towider European Learner Mobility● some Application Profile work, relevant to Europass CV● and a report, not yet for CWA, on bindings of that model– an XML binding, which people seem most interested in to start with– an RDF binding, which hold much promise for the future– a JSON binding, for easy communication between web tools
8. extra work● creating two prototype demonstration applications towork with InLOC structures● no problems translating the model into a relationaldatabase and using it to drive web applications, that inturn will help towards the adoption of the model● creating transforms to convert between bindings● integrated our requirements with the CEN WS-LTsELMO project, which takes forward EN15981 andEN15982 towards practical implementation.
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 canmanage fine with abstraction– they then produce the user tools that will make things easy tounderstand for the domain practitioners (who want their ownlanguages)● you are unlikely to see anything else this simple that covers theground – most models have to be broken into several pages
10. the information model
11. themodel asif it wereUML
12. the RDFversion ofthe model(similarsimplicity:linked data,SemanticWeb)
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, whichmakes levels simple and highly flexible● putting together several relationships and compoundproperties in one information model structure● extra simplicity at the cost of accepting abstraction sothat implementation is easier● model intended for developers, not domain experts– you cant please all of them anyway
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. the LOC definition● LOCdefinition rather like RDCEO / RCD definition● can be at any granularity– part definitions have one step finer granularity● expressly excludes any structural information– they are sometimes mixed together (e.g. NOS)– but separating them is cleaner● includes as metadata only single-valued items● also “primaryStructure” for disambiguation and context– often needed in practical examples
16. the LOC association● LOCassociation offers a single mechanismrepresenting 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
17. InLOC levels● defining levels and giving them ascending numbers forautomatic 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 caneasily accommodate that if desired● can have generic levels in a structure and specificlevels of a particular competence (see e.g. e-CF)● external framework levels can be attributed to things
19. XML● The XML binding follows the UML diagramclosely● the information model was based on the idea ofthis binding
20. RDF● RDF doesnt work quite the same as XML● XML isnt a natural binding for linked data● so the information model is adjusted slightly– the adjusted model covers the same ground– generally inter-convertible– slightly more restricted that the original
21. JSON● JSON is hierarchical like XML● but not as good for human reading● mainly for communication between clients andservers in web services● maps closely to the XML binding
23. getting people to contribute● why should they?● because there is something in it for them – but what?● usually, they already have their own private businessmodels quite clear – what is their market orientation?● needs new entrepreneurs – but how do we reach them– by luck?● policy drivers might help motivate businessengagement, but are market motivations are morereliable?
24. need for publicity● we really needed a big PR campaign, or to rideon the back of someone elses● but no one on the team was able to contributemuch expert time on publicity● creating a great specification is not all that isneeded for a successful standard
26. encourage publication ofInLOC-format frameworks● get hold of any owners of public frameworks thatwould benefit from wider dissemination● from e-CF, to Cedefop, CEN, DGs, European andnational government agencies, …● explain URIs, interoperability, reuse, linked data● explore what value might be added by InLOC foreach stakeholder– make sure they are aware of that– motivate them towards adopting InLOC● can anyone help?
27. embed in other projects● one way of getting adoption is to go throughEuropean funded projects● ideally first through creating frameworks● then through adding InLOC functionality to tools● do you know of any project that could use InLOC?
28. make sure we maintain expertisefor guiding future implementation● we dont know when different stakeholders will beready to adopt InLOC● it may depends on either policy development, orcommercial motivation, or both● when they are ready, the easier it is for them to adoptInLOC, the more likely they are to do it● maintain Web resources, clear signposts● make it easy to find sources of expertise
29. tools should make it easy for usersto 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 usethem 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 makeit easy
30. explore schema.org and RDFa● schema.org could be very influential, alongsideHTML5, for the future of the Web● RDFa allows the same web page to be human andmachine readable at the same time● ideal format for easy publication of frameworks● needs a little development– build on top of the InLOC RDF binding● may well be worth doing● are you interested?
31. extend InLOC as required● define useful APIs● provide facilities for representing some of thestructure-specific terminology– (see examples from e-CF and VitaeRDF)● but most of all, get people to use it, so it moves onfrom anticipatory to real, live, implemented● build on existing prototype demos
32. InLOC for standardization – ENs?● when is best timing for standardization?– probably after more time for implementation experience– when more stakeholders have offered support● ask how open the standard could be, andwhether that will work for the community● bear in mind international agenda in ISO● decide what and why to standardize● take that to CEN TC353
33. more open standards generally?● 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● W3C, IETF are the current norm for good practice● can CEN rise to the challenge? How?● can the Workshop Learning Technologies help?
34. conclusionInLOC could play the role of● a vital piece of the jigsaw, even if not the final one● an essential enabler of a new competence ecosystem● a standard to motivate growing consensusIt will take time – but it could be highly effective