1. InLOC:
the potential of
competence structures
Simon Grant
2013-05-08
for IEC-CETIS

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 that
something like this was practical and feasible
● “LOC” = “learning outcome or competence”

3. potential significance
● adds value to frameworks
● 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

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 InLOC's easy comparison, and 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

6. ubiquity
● 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

7. InLOC outputs
CEN Workshop Agreement on:
● an Information Model that offers a coherent solution to how to
represent this kind of structure
● Guidelines that explain both the model itself, and its application to
wider 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 to
work with InLOC structures
● no problems translating the model into a relational
database and using it to drive web applications, that in
turn will help towards the adoption of the model
● creating transforms to convert between bindings
● integrated our requirements with the CEN WS-LT's
ELMO project, which takes forward EN15981 and
EN15982 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 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. the information model

11. the
model as
if it were
UML

12. the RDF
version of
the model
(similar
simplicity:
linked data,
Semantic
Web)

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
– you can't 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 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

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. bindings

19. XML
● The XML binding follows the UML diagram
closely
● the information model was based on the idea of
this binding

20. RDF
● RDF doesn't work quite the same as XML
● XML isn't 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 and
servers in web services
● maps closely to the XML binding

22. issues

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 business
models quite clear – what is their market orientation?
● needs new entrepreneurs – but how do we reach them
– by luck?
● policy drivers might help motivate business
engagement, but are market motivations are more
reliable?

24. need for publicity
● we really needed a big PR campaign, or to ride
on the back of someone else's
● but no one on the team was able to contribute
much expert time on publicity
● creating a great specification is not all that is
needed for a successful standard

25. recommendations

26. 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
● can anyone help?

27. embed in other projects
● one way of getting adoption is to go through
European 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 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

29. 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

30. explore schema.org and RDFa
● schema.org could be very influential, alongside
HTML5, for the future of the Web
● RDFa allows the same web page to be human and
machine 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 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

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, and
whether 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. conclusion
InLOC 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 consensus
It will take time – but it could be highly effective

35. thanks … for
your interest
and attention
asimong@gmail.com
@asimong