Tuesday, April 10, 2007
AONS II
I've just come across AONS II, a project based in the National Library of Australia. Its stated goals are:
- Provide tools useful in the judgment of obsolescence with regard to formats located in a data repository
- Demonstrate a flexible architecture which allows for both a local/enterprise as well as an example of a SOA federated deployment
The project also has a blog.
I don't know what AONS I was.
# posted by Gary McGath @ 11:55 AM 
Comments:
<< Home
Heya Gary,
Thanks for having a look at the AONS project and blog. We're still in relatively early days with the code base, but the ideas are maturing pretty quickly - I should have some more information up soon (release cycles, designs etc).
Some background (which I'll also try put up on the Wiki): AONS version 1 (AONS I) was a prototype developed by the Australian National Library funded by APSR; realistically, it had similar intentions as AONS version 2 (AONS II) but did not entirely achieve it's stated goals. The end result of version 1 was an application which could compare formats inside a repository (Fedora and DSpace) with external format registries (PRONOM and LC-DFW) and then produce a report on Obsolescence. The first version had some major drawbacks: it was command line driven, and would automatically munge the PRONOM and LC-DFW data in a not necessarily meaningful way. Also, there was little interaction with a repository owner so the output was all one way; there was no ability for a repository owner to add contextual information about their organisation and any migration plans or extended support they would offer for a particular format. The AONS I code should also be on Sourceforge for all to see and comment, but somehow has not made it up there as of yet.
What we're hoping to do with AONS II, in addition to a good user interface, is make the process of obsolescence evaluation a bit more meaningful and transparent to a repository owner. One of the issues with external registries of format information is that the data is largely unstructured and subjective - we need objective and relatively well structured data in order to produce meaningful results. Any auto-magic munging of subjective data doesn't necessarily produce anything which really helps a repository owner (going back to the garbage in, garbage out principal).
We're also trying to get past any organizational hurdles towards exposing AONS II on Sourceforge sorted out quickly: the best criticism for the coding will come from the community and I'm eager to start receiving that feedback early.
AONS II will have a kind of expert workflow system to help combine external subjective registry information with a repository owners own contextual information to produce a quantitative result. We're thinking this should help show a repository owner quickly a quantitative measure of risk in their repository.
With all these changes happening, we're entirely re-designing the application which was AONS I from scratch. AONS I architecture was a bit quirky as far as Java projects go a tightly coupled codebase and an internal data centric "all XML" approach driving a distinct lack of a lack of POJO's makes one wish the simple code. That's not to say we won't use XML for data interchange - just not internally.
One interesting requirement on our development is to expose the business functionality via two methods: a regular browser based one and a web services one (via REST) which APSR will utilise to integrate with their COSI application.
For the technically minded, it looks like we'll be using Spring and Spring Webflow for the business tier and presentation tier respectively. We've recently overcome the REST hurdle exposing our business functionality (see this post and the following one on the issues to be had there). We're starting to implement the backend with the Java Persistence API, though I'm not 100% certain which vendor I'll use for the entity manager. So I guess you could say it's all systems go on the technical front.
We'll try make the Wiki represent everything we're doing, but we sometimes forget information we take for granted isn't up there so let us know if there is any unclear aspect about the project up there (probably best to fire an email to David Pearson for any direct questions) and we'll answer as best as possible.
Cheers,
David Levy
Post a Comment
Thanks for having a look at the AONS project and blog. We're still in relatively early days with the code base, but the ideas are maturing pretty quickly - I should have some more information up soon (release cycles, designs etc).
Some background (which I'll also try put up on the Wiki): AONS version 1 (AONS I) was a prototype developed by the Australian National Library funded by APSR; realistically, it had similar intentions as AONS version 2 (AONS II) but did not entirely achieve it's stated goals. The end result of version 1 was an application which could compare formats inside a repository (Fedora and DSpace) with external format registries (PRONOM and LC-DFW) and then produce a report on Obsolescence. The first version had some major drawbacks: it was command line driven, and would automatically munge the PRONOM and LC-DFW data in a not necessarily meaningful way. Also, there was little interaction with a repository owner so the output was all one way; there was no ability for a repository owner to add contextual information about their organisation and any migration plans or extended support they would offer for a particular format. The AONS I code should also be on Sourceforge for all to see and comment, but somehow has not made it up there as of yet.
What we're hoping to do with AONS II, in addition to a good user interface, is make the process of obsolescence evaluation a bit more meaningful and transparent to a repository owner. One of the issues with external registries of format information is that the data is largely unstructured and subjective - we need objective and relatively well structured data in order to produce meaningful results. Any auto-magic munging of subjective data doesn't necessarily produce anything which really helps a repository owner (going back to the garbage in, garbage out principal).
We're also trying to get past any organizational hurdles towards exposing AONS II on Sourceforge sorted out quickly: the best criticism for the coding will come from the community and I'm eager to start receiving that feedback early.
AONS II will have a kind of expert workflow system to help combine external subjective registry information with a repository owners own contextual information to produce a quantitative result. We're thinking this should help show a repository owner quickly a quantitative measure of risk in their repository.
With all these changes happening, we're entirely re-designing the application which was AONS I from scratch. AONS I architecture was a bit quirky as far as Java projects go a tightly coupled codebase and an internal data centric "all XML" approach driving a distinct lack of a lack of POJO's makes one wish the simple code. That's not to say we won't use XML for data interchange - just not internally.
One interesting requirement on our development is to expose the business functionality via two methods: a regular browser based one and a web services one (via REST) which APSR will utilise to integrate with their COSI application.
For the technically minded, it looks like we'll be using Spring and Spring Webflow for the business tier and presentation tier respectively. We've recently overcome the REST hurdle exposing our business functionality (see this post and the following one on the issues to be had there). We're starting to implement the backend with the Java Persistence API, though I'm not 100% certain which vendor I'll use for the entity manager. So I guess you could say it's all systems go on the technical front.
We'll try make the Wiki represent everything we're doing, but we sometimes forget information we take for granted isn't up there so let us know if there is any unclear aspect about the project up there (probably best to fire an email to David Pearson for any direct questions) and we'll answer as best as possible.
Cheers,
David Levy
<< Home
