JISC-funded projects produce a great deal of valuable outputs, in terms of software, data formats, formal models and other more informal guides and reports. But how can those outputs be made more visible, and disseminated more widely, and how can their context be captured to ensure their sensible reuse?
The international e-Framework is intended to be part of the answer. It is built on the principle that information on technical services should be collected and shared. But what about other supporting information, such as the applications which use those services, or the working practices and processes in which these applications are embedded, and in turn the recipients and beneficiaries of this work?
JISC is now starting to prototype a higher level knowledge base to capture these further types of knowledge. As well as better supporting the technical e-Framework, this also has the potential to capture and make available the findings of a much wider range of JISC projects than just those dealing with technical services. It is planned that the structure (ontology!) as well as the content, be developed in an agile, i.e. iterative and participative, way with all the stakeholders involved.
This raises some thorny questions, if not all to be answered or even addressed in this event, then certainly over the prototype’s development – how do you feel the context, learning and outputs of your project should be made visible to others in the community so that it can be most effectively taken up and used by others?
Alex Hawker, JISC e-framework programme manager, thanked everyone for attending and introduced the panel for the session – eframework – Bill Olivier, director of technology for JISC; Phil Nicholls, technical editor for the e-framework programme, and Dave Millard, from Southampton University.
AH: The intention is to give you an introduction to the programme.
BO: How many people know nothing about the e-framework programme? (Show of hands) We need to cover that background information, so I’ll talk about where it came from. We discovered that some of our major areas were about working with services. E-learning was coming at it from a standards perspective, how to exchange information, about e-portfolios. We were concerned to look for synergies, and different approaches. The e-framework is a meta-programme which identified a number of areas – we connected with people in Australia, Holland and New Zealand who were looking at the same issues, and they are now our partners in an international programme. Phil’s work focuses on technical interfaces, and what we want to do is look at the human face of it – uses and applications. That informs the e-enterprise architecture programme.
PN: Communities do stuff. They have processes to do things – any business processes you like, they might have absence management, how they assess, how they teach, and they’ll have a range of applications to support that. What we’re doing is coming up with a consistent vocabulary for those processes – if everyone has the same vocabulary, sharing will be a lot easier. A community will document what they’ve done as a technical component, and then they can use or refine that, or another community can reuse what they’ve contributed or build upon it. At its core, that’s the common vocabulary – explaining how we do things.
There’s engagement with standards bodies and standards activities. We’ve got our communities, and some of them will be using open standards and making them fit what they want to do, or engaging with the standards bodies. All of that work can go on, and in the e-framework we can use that work. We can take a standard and say that a community uses it in a certain way, and look at how it works, making it more reusable.
The e-framework looks at descriptions of things; we provide information to allow developers to write code and for business analysts to see what’s going on. Communities use what’s in the centre. framework components are documents, designed for people to read, and make use of the standard vocabulary. We’ve taken the view that we want to look at a distributed-service oriented approach. We’ve defined the notion of a service genre – it’s a readable description of what each of the elements does – not how we do it, but just what it is. Service expression is the next step down – we start to bind it to a particular technology. We don’t say what it is, because we’ve done that through the genre. It’s that sort of information that we’ve found people have problems with in terms of interoperability. Service expression ensures there are no nasty surprises. Outside of the e-framework, service implementation and instances – it’s not our role to say, this is how you must do it, but we say, these are six or seven ways you could do this, and here are the standards you might adhere to.
The SUM is a service usage model – it takes behaviour and builds a set of processes around that. We note the types of data that you’re working on, the sources of data, and the SUM is where we hit the community. SUMs talk in terms of what communities do. The stuff behind the SUM is the e-framework layer. Behind it, we can have our consistent layer.
AH: It’s a complex and technical programme. We want people to understand it.
Q1: Can you give me an example of a service instance?
PN: It’s a running service with an end point. An implementation would be the code libraries I use to build that service.
David Kay, TILE project: Is it technical stuff or not? It ought to be about giving us mutual language, but you’re helping us to batten it down in a specific way.
PN: I disagree. Things are abstract at the genre level. At the expression level, we’re talking about web servers, and that is technical. We can explain it in non-technical ways.
DK: Do you see one of your missions as giving us a language to talk about things like this, rather than just dealing in abstractions?
PN: If we can’t, then we’ve got a problem. The e-framework is an international project. We have problems in the UK where the guy down the road talks slightly differently.
Q1: David and I went to models workshops, which was at a service genre level. We came up with things like discover, locate, research, access. It would be interesting to populate that with things we think we’re familiar with to see how the layers come into things.
PN: The expression will tell you how you could do it.
Q1: When you get to the code toolkit level, that would be standards?
PN: Yes, C++ libraries that implement that expression in that way.
Shirley Williams, University of Reading: I can see how it works, but how easy is it for people to find what they want?
PN: We don’t have case studies but I think this leads on to what the innovation base is trying to do with making the e-framework more accessible and putting it into other sites hosted in the community. We hope that if we can find the right sites with the right content, we can bridge that gap, but it has been difficult.
SW: My point is that it would become write-only.
Q2: In terms of writing, it’s already the case that there’s a community wiki attached to the international e-framework. You have a template for SUMs and expressions where you can detail what it is that a particular project has contributed in this realm. We’re encouraging it as much as possible.
Mark Baker, University of Reading: Is it likely to be subsumed by emerging technologies?
PN: Time will tell. Certainly I don’t see how this would be competing or subsumed by REST. That’s one way of implementing a set of processes, but we still need a description of what they are.
MB: But you guys spend ages developing it and then get superceded. You’ll push it, but will it be useful?
PN: I think it will be, but I’m not sure that I’m the right person to answer the question.
Q2: You can’t predict in advance if a framework like this will fly or not. You can’t until you’ve tried it. It depends on how useful people find it. To address the technological change point, if you look at the knowledge base as it is, there are pure 2.0 mash-ups in there. It might be easy for a developer to tweak it, it can accommodate that.
Tom Franklin, Innovation Base: One of the big problems is establishing a critical mass that makes it useful. We’re aware of that. Once there’s sufficient stuff in it, there’s a good chance there’s something in it that meets your need. It’ll change and evolve as new technologies come along, and possibly even changes in the service genre. We need to get that critical mass, and that’s down to all of us putting stuff in and finding it useful.
AH: Due to the time pressure, I’ll hand over to Dave.
DM: I’m from the University of Southampton, and I’ve been working with e-framework on the Innovation Base. The intent is to look at other types of things that could be captured and reused.
Industry expects results – universities don’t – I don’t think that’s true, but the problem is with disseminating results. Our ability to share them with each other in a way in which they can be reused is not as good as it could be. We’re looking for a way to integrate and disseminate.
How might we do that? Material appears in different forms – documents, definitions (maybe technical), a body of work, and also things like pieces of stofware. What we could do is give people a common place to put these results and share them, but the problem with that is these things are opaque blocks – systems – large sheafs of definitions, when what’s interesting is what’s inside them. It may be that the admissions team description details lots of different roles, and then you begin to see interconnections between different materials. We want to get to the material, see the interconnections, share, and get to share best practice.
That’s what the Innovation Base is for – to extend the way the e-framework works. So the way we’re planning on building this is in two ways, or one system with two ways of looking at it.
First, a knowledge base interface. People can take their outputs and express it in a more formal way so it can be more clearly understood. It promotes good structure. It requires us to think more formally about the materials we’re producing. People have got used to writing up things informally, so we’ll be supporting people through that process. The principle is people will come along and express their stuff in that way to start with. You might link in your admissions software and processes. Over time, whole blocks will be filled in and start to appear.
It’s a structure-first view. Get the holistic picture, find out what the connections are. At the moment we’re prototyping an interface that will allow people to explore connections. We’re looking at graphing tools.
People may also want a content-first view, and look at a particular item and see how it connects, rather than seeing the bigger picture. So the second way is a wiki interface. It allows large documents to evolve into proper structures. The challenge for us is how to encourage people to add that structure. The model here would be refining the structure over time. Somebody may put in a definition; somebody may put in a system later; somebody may refine that and build more connections as time progresses. The model we use for this is the wiki model, but the back-end still has the common knowledge base. It’s a content-first approach and the main emphasis is on the thing you’re actually looking at. We’re trying to bring in knowledge-based elements.
These two views of one single knowledge base will form an expanding and evolving Innovation Base – it’s a place to record community outputs, and then link them together to form a powerful knowledge base. We are building interfaces to encourage people to make connections and encourage people to make those connections in the first place.
AH: It will only work if people are motivated to share their experience.
Q3: When you talk about a knowledge base, is that a repository?
DM: We’re talking about an ontology-driven store, a database of material. The knowledge base is the formalism of the structure of relationships. A database that can be queried mechanistically.
AH thanked attendees and the panel members before closing the session.