InLOC provides a model and framework for representing competencies and skills in a structured format. It defines an information model using XML, RDF, and JSON bindings to represent competency structures, definitions, and their relationships. Implementing InLOC could add value to skills frameworks, enable new technologies by linking frameworks to systems, and promote shared terminology by publishing competency structures on the semantic web. For InLOC to succeed, more frameworks need to adopt its format and tools should make it easy for users to connect to InLOC structures.

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