-
Notifications
You must be signed in to change notification settings - Fork 131
What to expect in Omeka S
This page is periodically updated to reflect the most current design directions of Omeka S. As a wiki, it will change over time as choices for the Omeka S codebase change over time. That is, it does not necessarily reflect a firmly committed to roadmap. Rather, it reflects the current status of Omeka S development plans, which will change as the "cone of uncertainty" narrows with subsequent releases.
Omeka S is an evolving project. It is a complete rewrite and reimagining of Omeka using up-to-date technologies. It also responds to the needs we have heard from Omeka users who manage many installations and work at the intersection of many content management systems and repositories.
Omeka S focuses on two core needs:
Multiple sites with easy IT administration: Omeka S has been built to address the needs of institutions that want to stand up multiple sites. These might be medium to large GLAM organizations with many subgroups that want to publish their content, or they might be universities with many instructors using Omeka in different pedagogical contexts, or any number of broad uses that call for some centralized IT management that facilitates easy creation of new sites for presentation and interpretation of many resources. A rough analogy to a WordPress networked installation works, but our design is significantly different from that model.
Data exchange: Omeka S emphasizes easy interaction between different data sources. This is most clearly reflected in our use of Linked Open Data principles. Our API functions through JSON-LD, and our metadata entry expands beyond Dublin Core and facilitate using additional vocabularies.
The universe of GLAM standards and formats is far too broad for Omeka S to address in a general way. Thus, handling of the import, display, and editing of many commonly used standards will not be part of Omeka S core. Instead, that falls to the job of addon module functionality. For example, the nested structure of metadata found in many standards will be better addressed as a module that handles the logic of each specific standard than as core Omeka S functionality. Alternatively, existing core data structure might be used to recreate the needed relationships.
Basic RDF vocabularies form the basis of metadata entry in Omeka S. Dublin Core, Friend Of A Friend, Bibliography Ontology are available out of the box, and additional vocabularies can be imported. Omeka S will import the properties and classes, but does not attempt to address OWL structures or RDF subproperties or subclass representations.
A major goal of Omeka S is to facilitate cross-system interaction, e.g. between Omeka S and DSpace, Fedora, and other content management systems. We have developed a number of initial modules to facilitate import from key systems. If you anticipate data interaction at your institution, it is safe to say that planning for JSON-LD representations transferred over a RESTful API will be part of your Omeka S strategy.
Omeka S provides a basic structure that modules can use to design and add workflows and permissions logic specific to each organization's needs. Core permissions and workflow will be fairly general, and allow for more nuance as addon functionality.
User Roles include: Global Administrator, Site Administrator, Editor, Reviewer, Author, and Research.
Users may create items, by selecting from the available vocabulary elements for description, and then attaching media if desired. To facilitate easy item description, users may create resource templates that can be reused. Items may be organized into Item Sets for organizational purposes.
Users can create sites, which are composed of individual pages. Users can then attach items and other content to the pages. Pages may be nested and arranged to build a custom navigation. Theme selection and customization happens at the level of the individual site.
Omeka Classic (2.x) and Omeka S will exist and be maintained side-by-side for the foreseeable future.