The next presentation is on the e-Framework – a brief introduction to what it is etc.
What is in the e-Framework?
At it’s core, it is documentation:
- Service Oriented Knowledge Base
- It’s documentation to help others
- Describes services (based on open standards) and how to use them
- Describes use of multiple services together
- Describes best practices in use of services
It’s supported by an International Community covering the UK, Australia, New Zealand and the Netherlands – with a mixture of communities in each country, although there seems to be an ‘education’ focus (worth noting that this is clearly not a library specific thing)
Within the framework services are split into:
- Service Genre
- Service Expression
The Service Genre describes what type of service you are talking about (e.g. ‘search’) but doesn’t say anything about how it is achieved (i.e. intended to be technology neutral) (based on ‘behaviours’)
The Service Expression is about how the service is achieved – e.g. SRU/SRW, Z39.50 etc.
Standards and Service Implementations maybe linked to from the e-framework, but aren’t part of the framework themselves.
The idea is that the ‘genre’ would tell you ‘what can be done’
Building on this, you can start to build ‘Service Usage Model’ or SUM.
- An ‘abstract SUM’ can be created from business processes supported by Genres and Data Sources.
- An ‘implementation SUM’ can be created from Business Process supported by Expressions and Data Sources.
The abstract SUM would describe the situation in general terms – e.g. ‘you would need a search service’, the implementation SUM would say ‘using SRU/SRW’.
SUMs are where several genres or expressions are used together.
There were some discussions about the e-framework model, and how it worked, and how useful it would be.
I have to admit that I see the reason for it in terms of development – but I’m not completely convinced that it will work in practice, because I’m sceptical about it actually being used by developers in institutions.
Richard Wallis from Talis raised the issue that this highly structured approach seemed at odds with the ‘constant beta’ and agile development.
Owen, yet again a great job of capturing what went on.
As was probably clear from my comments yesterday, I’m clear how much a structured documentation methodology will help us move forward to engage with and emulate the so called Web 2.0 world.
That will teach me to post comments before coffee!
My comment should have read ‘I’m _not_ clear how much a structured documentation methodology will help us move forward to engage with and emulate the so called Web 2.0 world.’
I’m also a bit sceptical, however, I just noted this http://jif08.jiscinvolve.org/e-framework/ which I think expands a bit on ‘why’ we might do this – which seems to me to be about how we can more usefully capture the outcome from JISC projects.
It has to be admitted that this can be a problem. Some JISC projects have clear useful outcomes, but sometimes they achieve something in one specific environment, and it isn’t clear how it might apply to other institutions or environments. I can see that expressing what has been done in a standardised way might help make the outcomes of these projects more ‘shareable’ with others.
Anyway, I’m going to the JISC Innovation Forum, so hopefully I’ll get a chance to discuss it more there.