Skip to content.
Personal tools
You are here: Home » News » Adopt a Brick!

Adopt a Brick!

Christina Smart
Last modified 31 Jan, 2006
Published 31 Jan, 2006
A report from the e-Framework for Learning and Research service factorisation meeting in London on the 24th January.

You've heard of adopting children or animals at the zoo but probably not of bricks. Adopting an E-Framework brick is similar in that you agree to look after one of the bricks in the framework, be it assessment, calendaring or harvesting. The difference is that e-framework bricks probably aren't as cuddly as otters.

otters at the zoo

At this meeting a group of people from the e-framework working group met with representatives from the e-science, e-admin and e-learning communities to discuss how to develop the e-framework services, to update the service descriptions and definitions and decide who would be looking after which services. The meeting aimed to help adopters develop a shared understanding of the e-framework terminology and discuss how service areas would be developed. So why is it important that each framework brick is adopted? Partly to ensure that each service continues to be developed - and partly to ensure that there are clear boundaries drawn between services to make sure that there are no overlaps of function between bricks (factorisation).

Sam Easterby Smith kicked off the meeting by outlining the aims of the day, followed by introductions. Wilbert Kraan gave an overview of terminology: services, definitions, scopes and specs. Sam Easterby Smith gave a brief history of the e-framework showing how its predecessors, the Information Environment and the e-Learning Framework overlap. Dan Rehak presented an e-framework glossary which formalises some of the e-framework working group discussions into definitions of service, service description, service definition, and service implementation. An important distinction raised was that between service - which is the description in the e-framework box and the implementation of that service (i.e. the software). A service may therefore have many implementations - but an implementation can only have one service. A group of service implementations could then be combined into an application.

During the last part of the meeting participants gave descriptions of each e-framework service they had adopted and raised specific issues. Issues discussed included:

  • Should service names be verbs - since they represent a process?
  • Where should repositories sit?
  • What is the process for deciding upon a new service?

This meeting began the process of passing the development of the e-Framework for Education and Research over to the community. Adopters will now take their services back to their domain communities and discuss with the relevant projects in their area what individual service descriptions and definitions should be. How these services are factored will emerge from the ongoing conversations between these adopters over the coming months.

Presentations from the meeting and proposed service descriptions can be found on the e-framework web site at:

Services covered at the meeting included:

Assessment, grading, marking, plagarism detection (new proposed), audio visual conferencing, e-science specific services, calendar, content management, alerting, chat, email, forum, syndication, activity author, course management, learning flow, activity management, sequencing, packaging, curriculum, course validation, role, person, member, group, authentication, authorisation, resource list, harvesting, service registry, metadata schema registry, workflow, user preferences.

Thanks to Sarah Holyfield for the otter photo.


Supported by JISC Supported by CETIS
Powered by Plone