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

1. InLOC:
the potential of
competence structures
Simon Grant
2016-10
a general purpose explanation

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

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 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. 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. 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
● XML binding developed for simple UML
● RDF binding needs modified info model
● JSON-LD follows RDF

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. remaining ways forward

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. 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. 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. 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. explore schema.org
● schema.org, 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. 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. 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)
– schema.org, W3C, IEEE, IMS, etc.
– some new commons standardization body
● decide what to standardize and why

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. 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 http://purl.org/net/inloc
or http://www.cetis.org.uk/inloc/

30. thank you for
your interest
asimong@gmail.com
@asimong