Omeka

Sat Jan 5 16:29:50 EST 2013

Hi everybody

Just to share my experience.

For a client, I need to do something similar to Islandora, I mean an
special front-end, but for DSpace. It has the requirements consume
from the IR some collections, to separate featured publications, to
make exhibits or to generate special collections, for instance, this
is the month of X, and should appear all X related publications. Also
should have several search functionalities. It also has the
requirement that the publisher/administrator of the site has the
posibility to re-order the pages, create new pages and so on.

My approach was to make a cron process to consume OAI mets metadata,
to obtain digital object, make an special thumbnail (bigger than
DSpace provides) for the cover and after that discard the digital
object, because it's no more than a front-end. I've started using
Omeka and actually I've moved to Drupal.

My observations are:

1. I don't understand very well why Omeka is used in some instances as
a repository platform. There are a lot of enhacements and experience
in DSpace or eprints and a lot of work in data curation areas,
preservation and so on. Honestly I don't belive that Omeka comunity
effort will never compare with a professional repository platform as
DSpace.

2. Omeka has several plug-ins, for instance to define dublin-core
extended, apache solr search and so on. The real thing is that the
interface for searching using this plug-in is really buggy. It tries
to make auto-scroll when the user reach the end of page and it works
very bad. Aditionally this plug-in seems to be for 1.2 version and
really don't know if it's currently maintained. The support in the
google groups of omeka is infrecuent. Comparing with Drupal, Drupal
has a lot of Solr's related features (More like this, did you mean,
etc). Solr is much more mature in Drupal than in any other integrated
project that I know (except for DSpace itself).

3. Omeka has a OAI-PMH plug-in but only considers oai_dc, it has the
posibility to be extended to use METS but it has taken to me some
effort to modify it and include.

4. Omeka is only for Apache 2.2 and Linux. I have to make a lot of
touches to use it under Win32. It has a lot of linux paths hardcoded.

5. Omeka looks very difficult to be customized, even in small things,
for instance to show all the publications ordered by dc.date
descending or title, and so on. All of this stuff it's really easy to
do with Drupal's views. As far as I know, you have the posibility to
add in Omeka 2.0 a plug to re-order the publications but I think that
will never have the  flexibility of a Drupal view. For instance to
make a carousel in the front, probably you should touch the Omeka's
theme (I've not been working very much, but it seems to be harder).

6. I found that exhibits and collections have a lot of indirection, I
mean you go to the exhibit, will show the information of the exhibit
another click to go inside the exhibit, to see the content of the
exhibit and so on. A lot of effort to reduce this level of indirection
and a lot of clicks or the final user. No way to compare to the
flexibility you can introduce using blocks or some other structure in
Drupal.

7. In Omeka you should have to create the small thumb and the bigger
one when you ingest the digital objects (in my case image PDF cover
references). Drupal manages it automatically.

8. Plug-in. It's really unfair to compare Drupal with Omeka in number
and quality of plug-ins. Just to put an example. Finally my site has
an actionable google map with the publication places without coding. I
think that it will really imply a lot of effort to replicate this in
Omeka. I could continue speaking about enhacements for mobile
browsing, SEO and so on...

Really I understand that my requirements were very special, I need to
do a front-end for some collections in DSpace, it looks really
appropiate to use a CMS. I had the hope that Omeka will help me with
this project but really I found that I have to put a lot of effort in
customize and the life of some of the plug-ins are really not assured.

Speaking againts Drupal, I can say that cannot find a good plug-in for
OAI-PMH. But as I have the posibility to use Perl for Win, it gives me
the solution to the consumer module. And speaking against this
consumer module that I've made, I have to say that it interacts
directly with Drupal database (as some kind of reverse engeneering).
But this last thing I assume that comes from my own ignorance of
Drupal, I know that it has webservice plug-in that could become
independent from any future DB change.

Of course, this is my own (developer) experience, that could be
completely irrelevant under other scenario.

Regards
Emiliano Marmonti

2013/1/5 Cary Gordon <listuser at chillco.com>:
> I resemble that statement.
>
> This begs Drupal's existential identity issue — CMS or development
> framework? I agree that telling folks to load up Drupal and crank out
> a digital library might be a bit like telling Sisyphus that the big
> stone would look great on top of his mountain and he could easily push
> it up there. (FWIW, my first exposure to Drupal was in using it as the
> front end of a digital library project.)
>
> If folks want a Drupal-based digital library-in-a box, the answer is
> to create a community that will work together and build a
> distribution. Distributions package the modules and other components
> needed to deliver a product. I would be happy to lend my time, and, to
> the degree practical, some Cherry Hill time to this, if the demand is
> there. I would not, however, want to become involved with the
> leadership or governance of that project.
>
> Thanks,
>
> Cary
>
> On Fri, Jan 4, 2013 at 8:04 PM, Roy Tennant <r.)oytennant at gmail.com> wrote:
>> This is the excellent answer that I wanted to write but didn't have
>> the chops to do. I have my various beefs with Omeka (mostly having to
>> do with no thought to workflow and a slavish adherence to Dublin
>> Core), but Omeka is FAR easier to set up and use for a simple
>> repository application than Drupal. I've done both, and each have
>> their strengths and weaknesses. You should also factor in familiarity.
>> If you're a Cary Gordon and you dream in Drupal, then it might be
>> easier for you to use Drupal. But if you're coming to this fresh, and
>> want a simple repository, then I'd choose Omeka over Drupal any day.
>> Roy
>>
>> On Fri, Jan 4, 2013 at 7:30 PM, Wilhelmina Randtke <randtke at gmail.com> wrote:
>>> Omeka is built around handling items and the Dublin Core records for those
>>> items, and has functionality for common things you would want to do in a
>>> digital library setting. So, yes, you could take Drupal, then look at what
>>> plug ins / settings to install to be able to have an entry screen and
>>> storage for a Dublin Core record.  And look at what plug in to install to
>>> set up an OAI-PMH feed.  And look at what plug in to install to upload a
>>> spreadsheet of metadata, FTP in a bunch of files, and then batch load the
>>> files.  Each library thing you want to do in Drupal will be fringe for the
>>> Drupal community, and will require you to read up on how to do it.  In
>>> Omeka, the library things are built in.  For someone who wants the digital
>>> library without lots of reading documentation in the set-up, Omeka is good
>>> for an out-of-the-box platform to handle items and metadata. Most library
>>> things you want to do in Omeka are core to the Omeka community, so easier to
>>> implement.
>>>
>>> If you try to get a simple digital library with OAI-PMH feed set up in
>>> Drupal, then this will make more sense. Even though many flashy displays -
>>> like image carousel - are easier to do, the core digital library things -
>>> like sharing metadata - are harder.
>>>
>>> Islandora might be viewed as the just-do-it-in-Drupal option, but because
>>> that's also built on Fedora Commons, it's a much heavier option for server
>>> and technical staff requirements.
>>>
>>> -Wilhelmina Randtke
>>>
>>> On Jan 4, 2013 9:55 PM, "Charlie4work" <charlie4work at gmail.com> wrote:
>>>>
>>>> Is there some reason that one couldn't use Drupal to do something similar?
>>>>
>>>> - char!ie
>>>>
>>>> On Oct 31, 2012, at 3:56 PM, "Christa E. Van Herreweghe"
>>>> <Christa at UCPL.LIB.MO.US> wrote:
>>>>
>>>> Just wondering if anyone is using this and what you think of it.  A
>>>> colleague is considering Omeka and asked me if I knew anything about it.
>>>> Since I don’t, I thought it would be good to ask all the smart people I
>>>> know.
>>>>
>>>> http://omeka.org
>>>>
>>>> Omeka is a free, flexible, and open source web-publishing platform for the
>>>> display of library, museum, archives, and scholarly collections and
>>>> exhibitions.
>>>>
>>>> Thanks,
>>>>
>>>> Christa Van Herreweghe
>>>>
>>>> Assistant Director/IT Librarian
>>>>
>>>> University City Public Library
>>>>
>>>> www.ucpl.lib.mo.us
>>>>
>>>>
>>>> ============================
>>>>
>>>> To unsubscribe: http://bit.ly/web4lib
>>>>
>>>> Web4Lib Web Site: http://web4lib.org/
>>>>
>>>> 2012-10-31
>>>>
>>>> ============================
>>>>
>>>> To unsubscribe: http://bit.ly/web4lib
>>>>
>>>> Web4Lib Web Site: http://web4lib.org/
>>>>
>>>> 2013-01-04
>>>
>>> ============================
>>>
>>> To unsubscribe: http://bit.ly/web4lib
>>>
>>> Web4Lib Web Site: http://web4lib.org/
>>>
>>> 2013-01-04
>>
>> ============================
>>
>> To unsubscribe: http://bit.ly/web4lib
>>
>> Web4Lib Web Site: http://web4lib.org/
>>
>> 2013-01-04
>
>
>
> --
> Cary Gordon
> The Cherry Hill Company
> http://chillco.com
>
> ============================
>
> To unsubscribe: http://bit.ly/web4lib
>
> Web4Lib Web Site: http://web4lib.org/
>
> 2013-01-05

-- 
---------------------------
Progress (n.):  The process through which the Internet has evolved
from smart people in front of dumb terminals to dumb people in front
of smart terminals.

============================

To unsubscribe: http://bit.ly/web4lib

Web4Lib Web Site: http://web4lib.org/

2013-01-05