I agree with this. When I initially read the idea, I found it very
appealing. But I paused a bit when I read the part about creating
specialized PDFs as the primary output format. While this might be fine as
one option, it's important to remember that even small museums and archives
may have existing procedures and systems that they want to interface with.
And from a preservation perspective, being able to choose multiple output
formats is a real benefit.
I really like the idea of building the system in layers with standard APIs
in between them, so that people can then write creative solutions that sit
on top of/in between them. IE, the Flickr model. You can choose the level of
complexity you want. If you just want to upload your vacation pictures, you
can do that very easily, with user friendly tools like the Flickr Uploadr,
the web interface, etc. But if you want to, there's a rich API there that
lets you do things like write your own batch uploader program, manipulate
your photos online, access the data in a variety of ways, etc.
In the case of this proposal, for example, if the dewarping software for
this worked really well, it would be nice if there were a way for someone to
write a script that would invoke it on images captured through some other
method, rather than being locked within this one workflow. I think this
would spur a lot of creativity and rapid improvement in the system.
Ideally, I think there would be enough hooks that other open source projects
or software vendors would easily be able to take advantage of this system as
a data source. (IE, direct paths from this into software like Archivist's
Toolkit, OpenCollection, PastPerfect, Minisis, TMS, Extensis Portfolio,
Greenstone, etc.)
I think developing standardized hardware and software tools for this would
be a huge contribution, though, and I'd certainly love to see it happen. I
think this is seen as something that's too complicated for a lot of places,
and as a result worthy projects don't get done, or people waste huge amounts
of time with flatbed scanners simply because they are commodity hardware and
well understood.
-David Dwiggins
Systems Librarian/Archivist,
Historic New England
ddwiggins [at] historicnewengland [dot] org
On Wed, Aug 6, 2008 at 10:50 AM, Morgan, Matt <matt.morgan at
metmuseum.org>wrote:
> In response to your question #2, "if we build it, will they come?", the
> answer is basically "no," in my experience developing open-source tools for
> museum use. Even institutions that really ought to be using what you built
> may need a lot of help in understanding that. And there will be others that
> could use it, and would, if it weren't for that one little thing they wish
> were different ...
>
> Your question is smart: you will have to do a lot of work to get places to
> know about it and use it, and to the extent that you can build it so that
> different institutions can attach to it in different ways ("I love it but I
> want the data to go straight into [insert name of application/storage
> device
> here]") and build their own layers on top of it, it will be more usable by
> more places. Of course, that approach can appear to complicate the software
> to the places that want the out-of-the-box solution, so perhaps you should
> do both--i.e., build the turnkey solution, but build it in a series of
> layers, some of which are optional.
>
> I think it's a great idea and if you succeed at it the community will
> seriously owe you one.
>
> Matt
>
