2. what InLOC is
● a model for representing and communicating
information about structures of learning
outcomes, competence, competencies, etc.
– skills frameworks
– occupational competence standards
– professional development (etc.)
● domain independent (“content”-free)
● hasn't been done successfully before
3. why is InLOC significant?
● adds value to work such as the European e-Competence Framework
(e-CF) and many other skills frameworks, competence standards,
structured sets 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
● that's the kind of reason why people in ITLET have been asking for
this kind of thing for several years
4. we have provided key solutions
●
we worked hard analysing stakeholder needs and sources
● we are presenting three draft CWAs for potential standardization
1.an Information Model that offers a coherent, genuine solution to how to represent
this kind of structure
2.Guidelines that explain both the model itself, and its application to wider
European Learner Mobility
3.some Application Profile work, relevant to Europass
●
and a report, not yet for standardization, 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
5. and done extra work on top
● creating two prototype demonstration applications to work
with InLOC structures
● these demonstrate that there are no problems translating the
model into a relational (or other) 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 Workshop's ELMO
project, which takes forward EN15981 and EN15982
towards practical implementation.
6. what is hard about this, and,
what have we done about it?
a little philosophical reflection …
● different people simplify things in their own way
●
a realistic common model may look complex or abstract
● we've chosen to make 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 web site
http://www.cetis.org.uk/inloc/Home
… with separate pages for the information model
and each model component, the guidelines with
all the examples, the application profiles, the
bindings, the background information, the
analysis …
… connecting them all together with very rich
cross-linking and cross-reference …
… an ongoing resource for implementation …
11. surprising challenges
● getting interest and contributions
● need for cleverer publicity, PR and marketing
● being realistic about how prospective
standardization works (or doesn't)
12. 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?
● new entrepreneurs may see the opportunities – but how do
we reach them?
● policy drivers – who might mandate InLOC?
● market motivation
– to provide better features, particularly between applications
– use InLOC as good model to save time
– collective commitment to common good
13. need for more publicity
● we didn't have a big PR campaign as no one
dedicated on the team
● we've created a great specification – this is
what the project required – but it is not all that
is needed for a successful standard
● we need you to help spread the word
● reach framework owners and tool builders
● put over the benefits
14. being realistic
● InLOC has been a forward-looking project
– “anticipatory”, “prospective” etc.
● these are hard to make successful
● we need to convert our excellent ideas into
real adoption
● we will propose recommendations to different
parties
● all help and suggestions welcomed!
15. Recommendations
● encourage framework publication in InLOC
● signpost expertise
● tool builders must allow users to refer to
InLOC
● try integrating with schema.org using RDFa
● embed integration with InLOC into projects
● extend InLOC to APIs and structural terms
● judge best time for formal standardization
16. thanks for your interest in InLOC
keep in touch
let's work together in the future
asimong@gmail.com
@asimong