Manakin introduces a modular interface layer, enabling an institution
to easily customize DSpace according to the specific needs of a
particular repository, community, or collection. The project is being
developed by Texas A&M University, and I work on the project. To
answer your questions Les,
> Could you explain this a bit more? All the Manakin explanations that
> I've looked for have briefly mentioned internationalization and
> corporate branding and then got very technical. Why is Manakin needed
> for this example? What does it provide that Web2 stylesheets / script
> combos can't?
At Manakin's hart is a basic web2.0 / stylesheet model, i.e. create
an semantic representation of a page and then translate that into any
display format you want. It uses standard technologies, java,
javascript, cocoon, xsl, etc... However where the project differs
from just a standard approach is how it deals with artifacts in the
repository. The semantic representation of a page that it creates
contains METS document for each artifact and one for the entire
repository containing all the metadata and links to resources.
Manakin's theme is able to decide how each one of these artifacts are
rendered independently, typically based upon the artifact's METS
profile. Some artifacts that contain spatial metadata could be
displayed on a map while others may be displayed differently
depending on the artifacts characteristics.
> Here's some other questions- you may need to refer me to someone
> else. (I don't know what your relationship is to the site.)
> - Is the map used for deposit as well?
> - Is there a practical limit on the scalability of web 2.0 or the
> graphical display that puts a limit on the applicability of the
> technique - the URL that you gave shows a map with 11 items, but
> displaying a map with the whole collection (200+ items) takes about
> 30 seconds to display. Also the map becomes very overcrowded. Do you
> have any suggestions about the best way of deploying these
techniques?
In the examples provided maps are not used for depositing.
Yes, there are always scalability limits and they are hard to solve.
In this case the concept of viewing all artifacts in a repository at
one time is just unscalable under any system or architecture.
Artifacts have to be grouped or combined together into scalable
chunks of data that can be processed. Both of the examples provided
side step this issue because they are relatively small static
collections with no more items being added. Manakin is a new project
and while it will have its share of scalability growing pains in the
implementation there is nothing in the architecture that prevents it
from being applied to large repositories.
Rob has pointed out some of the 'wow' factor examples of manakin here
is another interesting application of Manakin, look at the Texas
Digital Library: http://repositories.tdl.org/. In this example it is
being used as a harvested virtual collection of Theses and
Dissertations from three schools in Texas.
Features that manakin provides:
- Manakin is able to brand the virtual collection with the TDL logo,
color scheme, and integrates with the existing TDL website which
includes: static pages, Open Journal Systems, and DSpace/Manakin.
- Each item is branded with the university's logo
- Manakin allows for a specialized filter search to be added that is
adapted to the needs of this particular collection.
Hopefully there will be several presentations about Manakin at Open
Repositories '07 in San Antonio at the DSpace user group meeting if
you are interested in Manakin.
Scott--
|