-
Notifications
You must be signed in to change notification settings - Fork 135
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 toward an initial release.
Omeka S is an evolving project. It is a complete rewrite and reimagining of Omeka using up to date technologies, and responds to up to date needs we have heard from the community of Omeka users. There are two core needs that Omeka S is focused on:
Multiple sites with easy IT administration Omeka S will be built to address the needs of institutions that want to stand up multiple sites. These might be large organizations with many subgroups that want to publish their content, or they might be universities with many course 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 will be significantly different from that model.
Data exchange Omeka S will emphasize easy interaction between different data sources. This is most clearly reflected in our use of Linked Open Data principles. Our API will function through JSON-LD, and our metadata entry will expand beyond Dublin Core to 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 will fall 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 will 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 ContentDM, Fedora, and other content management systems. Our API is based on JSON-LD. As we approach release, and 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 will provide 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.