omeka / plugin-CsvImport

Allows users to import items from a simple CSV (comma separated values) file, and then map the CSV column data to multiple elements, files, and/or tags. Each row in the file represents metadata for a single item. This plugin is useful for exporting data from one database and importing that data into an Omeka site.
20 stars 32 forks source link

Feature Request: CSV Update #58

Open anuragji opened 10 years ago

anuragji commented 10 years ago

I would LOVE to have the ability to update items from a prior import via a CSV file. Perhaps the log of the prior import could be used to generate a CSV files with the _itemids, which then in turn can be used to update existing items.

From a workflow perspective this would be rather dreamy :)

Daniel-KM commented 10 years ago

Hi,

My fork allows updates, but because there are multiple update schemas (replace or add fields, etc.), you need to set it each time (but settings are saved).

Sincerely,

Daniel Berthereau Infodoc & Knowledge management

patrickmj commented 10 years ago

That need is much on our minds, and gets into the other tangles of tracking changes. Part of the motivation for creating the API onto Omeka instances was to provide a more versatile mechanism for doing updates to items. It still keeps the tracking of item IDs external, or as part of the item's metadata, but in the end it will have more affordances than CSV Import

anuragji commented 10 years ago

Thank you @Daniel-KM, I will take a look at your fork.

@patrickmj while I agree that the API can be helpful in providing mechanisms to update items, from a workflow perspective on the other hand, it seems to make more sense to make the CSV batch update available from within Omeka. It may not be so relevant when seeing Omeka primarily as a web publishing platform, but it becomes crucially important when also using Omeka as a collections management tool. From that same perspective the tracking of changes is important.

patrickmj commented 10 years ago

@anuragji That is at the heart of it. Omeka is built and designed for web publishing. The API was designed to respond to requests that other collections management tools be able to talk to it as the public side to their collections, keeping those different functions separate. Of course, as @Daniel-KM has done, creating your own plugins is part of why we're open source!

anuragji commented 10 years ago

@patrickmj - and I thought that Omeka sees itself at the crossroads of Web Content Management, Collections Management, and Archival Digital Collections Systems (http://omeka.org/about/) ;)

But I understand your point - however we work with a lot of smaller institutions where Omeka is a solid step up from spreadsheets...

Daniel-KM commented 10 years ago

Hi,

For little collections, it's simpler to work with a spreadsheet, because a simple table is the most intuitive and the most used tool. Currently, the admin board is made to manage items one by one, even with the help of the very useful bulk editor of UCSC. It's certainly possible to implement a view that can manage items via an integrated spreadsheet (like a Google doc, but for free).

For big collections, it's better to work with a specific tool to avoid to reinvent the wheel and to exchange data with Omeka via the OAI-PMH protocol. The two plugins OAI-PMH harvester and OAI-PMH repository are designed for that. In that case, the API is not needed, but the two plugins should be slightly improved.

Sincerely,

Daniel Berthereau Infodoc & Knowledge management

Daniel-KM commented 9 years ago

Hi,

My fork offers now a full update and management process of records via a simple table.

Sincerely,

Daniel Berthereau Infodoc & Knowledge management