Omeka is particularly suitable for small galleries,museums,libraries and archives. Working on a small pilot project for a museum, I'm looking at nearly a 100 fields in the form to add an 'item'. This is fine and can be whittled down but I do not understand why there are no drop down menus in fields like 'rights' or 'medium' which can only take a limited number of known values. There are no date widgets or suggested formats for dates and little of no form validation.
Is this not contrary to the whole sense of the Linked Open Data cloud where existing data should be reused rather than recreated ad-infinitum?
Something like "Date" may seem to obviously call for a much more limited input method, but some users need date ranges, "circa" or other descriptors, dates in specific non-standard formats, or otherwise have needs that would be incompatible with a more locked-down form. Other fields tend to have the potential for even more widely-varied data.
Therefore, the basic philosophy of Omeka's data entry forms is to be as open as possible but allow sites to opt in to more restricted input, usually through the use of plugins.
The SimpleVocab plugin allows you to construct simple controlled vocabularies and select fields to apply them to; this converts those fields' inputs into dropdown selects rather than free text inputs. This would work well for the fields you mention as having only a limited set of possible values in your case.
In another example, LC Suggest adds opt-in autosuggestion of values from LCSH headings and other authorities and vocabularies made available by LoC.
I'm not aware of any date-input plugins currently, but the process of creating one that forced certain inputs or presented a graphical date selector would be a fairly simple extension of existing plugins.
Thanks John that is excellent, I installed the Simple-Vocab and that's exactly what I was looking for.
I will experiment with LC Suggest (I presume Getty Suggest works in similar fashion).
The dates I will talk with the client about. A suggested format with jQuery validation may be the way to go here.
Thanks also for the heads up on Omeka's data input philosophy that is useful to know.
I'd like to chime in into the date widget topic.
I'm currently developing (i.e. installing and configuring) an Omeka installation for an interdisciplinary university project – myself being a research assistant in computer science, my colleagues being cultural scientists. We have lots of source data to put in, including well-documented dates and as well timespans. As multiple editors, including low-paid student assistants, will add data, an enforced consistent time format is essential – which could probably only be realized with a date selector module.
Unfortunately, this is much more than "just" the SimpleVocab solution (which we are using extensively already for consistent select list metadata), as a fully-fledged date selector would probably be jQuery based.
But to make this issue even more challenging: Imagining data from cultural science, we're dealing with dates and timespans starting in the 16th century – so we're dealing with documents that could use an entertaining mix of Gregorian and Julian calendar dates. So whenever an editor wants to specify a date from a source document, it should not only be possible to select a date instead of typing it, but also specifying if the respective source is based on the Julian or the Gregorian calendar, possibly normalizing it over to Gregorian for consistent database storage.
Plus, in case this feature request isn't sophisticated enough: Searching for dates or timespans, one should be able to specify if they are searching for Julian or Gregorian dates.
… You can't blame a guy for asking, can you? ;-)
Update from my side: I'm planning to marry the technology found in the SimpleVocab plugin (replacing the edit field for a specific metadata field with a different widget) with the "jQuery Calendars Datepicker" –
I'll let you know what I come up with.
You might also try the brand new Element Types plugin, which includes a date picker with configurable formats.
Thanks – I'll try that! If there's a date picker in it, it'll probably be easer to replace that in case it doesn't support Gregorian vs. Julian. I'll report in time …
Hi Patrick 'Element Types' is a sensible implementation for modern administration dates, and in the future I imagine will be developed to allow further form field validation. If they could allow it to 'click' back by 'years' as well as 'months' that would be also useful.
Interested to see what GerZah comes up with for old dates and whether it will cater for BC dates.It is certainly a tricky subject.
As an after thought, archaeologists tend to break civilisations like the Minoans or Romans down into culture periods and these categories must find their way into linked data eventually. There is a case for academics to arrive at a consensus and instead of using time spans to denote the 'Created Date' of an artefact, the 'culture period' could be specified. In such a schema each civilisation would consist of a set of culture periods and a widget could be developed that allowed one to simple select the available civilisations in order to have a drop down menu of a specific civilisation's culture periods. Culture periods have a richer connotation than simple date periods.
A little update from my side: While Element Types uses the regular jQuery date picker, my local development version uses the much improved [jQuery Calendars Datepicker](http://keith-wood.name/calendarspicker.html) instead. This one very well supports both Gregorian and Julian calendar notation (among others).
What I've done now is: I've postulated that all dates stored in Omeka should be Gregorian – otherwise they wouldn't be comparable. However, my editors should be able to enter Julian dates as they find them on old document, and then convert them over to the current Gregorian date scheme with just one mouse click.
So what I have is:
- A Gregorian calendar sheet -- to be able to select single dates and timespans based on modern date designations.
- A Julian calendar sheet -- to be able to specify old-fashioned dates and timespans.
- While the date field holds the usual representation (here it's the German style dd.mm.yyyy, could also be mm-dd-yyyy or whatever else), there's a button that interprets the entry as a Julian date -- and converts it into a Gregorian date (or timespan, respectively).
- … And vice versa, although it can be expected that people will hardly want to convert a Gregorian date into a Julian one. But then again, perhaps for reference, to be able to compare different Julian dates based on a Gregorian date.
I still need to fix all that up, a couple of things need to be sorted out, mostly in terms of i18n. But my current devel version provides a lot of flexibility already. … Let's see what my colleagues over in the cultural sciences think about it. ;-)