Omeka 3 roadmap and current status?

[Jaron Kennel]

We're investigating digital exhibit and collection options, and multisite support is strongly desired.  I was looking at the roadmap and wondering what the current development status and timeline is on Omeka 3.

[Patrick Murray-John]

Jaron,

Yes, that roadmap does need an update to reflect a variety of design and infrastructure decisions that we couldn't ignore. We needed to basically rebuild from scratch to update to more modern technologies. Best estimate I can make is that the multisite Omeka will be ready for the fall 2015 semester.

Patrick

On 10/02/2014 09:16 AM, Jaron Kennel wrote:

We're investigating digital exhibit and collection options, and multisite support is strongly desired.  I was looking at the roadmap and wondering what the current development status and timeline is on Omeka 3.

--
You received this message because you are subscribed to the Google Groups "Omeka Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omeka-dev+...@googlegroups.com.
To post to this group, send email to omek...@googlegroups.com.
Visit this group at http://groups.google.com/group/omeka-dev.
For more options, visit https://groups.google.com/d/optout.

[Jaron Kennel]

Thanks Patrick,

Am I correct in assuming that https://github.com/omeka/omeka-s is the repo where the development is being done for the multisite Omeka?

[Patrick Murray-John]

Yep. That's the one!

Patrick

[Peter Sefton]

Hi Patrick,

I am wondering if there is any planned support for Linked Data in the new version? 

The item relations plugin is a good start, but it would be useful to be able to relate items to external URIs, and to be able to choose a local label for the thing you're relating to, essentially bringing together the functionality of the current "element text" approach to metadata elements with item relations. Would it make sense to add an optional "property" URI to the element schema, and allow a URI/internal reference to another ID as well as a string value and treat both kinds of metadata in the same way? This would allow some improvements to the API as well, for example being able to add metadata to an item using a URI rather than having to poll the API to find an id for a metadata element.

Peter

[Patrick Murray-John]

Hi Peter,

Glad you asked!

The API will use JSON-LD.

The Item Add interface as we're currently imagining it has three options for each property: text input (like what exists now), internal reference (sorta bringing Item Relations into core, just with a better design), and external URI. The additional details, like using a local label for an external URI sound interesting, and we'll be thinking about if/how that kind of thing might work.

Properties, too, will be much more LoD-friendly. In addition to Dublin Core, the FOAF, BIBO, and other vocabularies will be available both for expressing properties, and the classes available (analogous to the Item Types currently available).

Changes like this (and more!) are at the heart of the changes to design and infrastructure I mentioned in an earlier response. We hope that the additional time will be worth it to be able to address needs like these!

You can watch the progress at the Omeka S repo: https://github.com/omeka/omeka-s

Thanks,
Patrick

[Jaron Kennel]

I realize this is early in the process, but do you have a sense of what the upgrade path will look like from Omeka 2.2.x to Omeka S?  In a similar vein, will existing plugins need significant refactoring to function in the new version?

[Patrick Murray-John]

Jaron,

It is too early for me to be able to say anything about the upgrade path. They are sufficiently different, though, that Omeka 2 and Omeka S will coexist for some time. We deliberately stopped calling it Omeka 3 because those differences make it hard to call it a linear progression.

Regarding plugin refactoring, there will be significant refactoring, and/or rethinking for the structures and paradigms of Omeka S. The most obvious difference is that Omeka S switches to using ZendFramework 2, and the Doctrine ORM.

Patrick

[Jaron Kennel]

Thanks again Patrick!  That's pretty much what I expected, but wanted to double check rather than make assumptions.

[Daniel Berthereau]

Hi,

I see that Omeka S allows to add specialized vocabularies and ontologies, but will it allow to add natively other xml formats than Dublin Core, like EAD, TEI, Mets, Alto, etc., for both editing and viewing?

Sincerely,

Daniel Berthereau
Infodoc & Knowledge management

[Patrick Murray-John]

At least the first release will only work by importing RDF metadata elements, so for some of the examples you give it would just be a matter of finding or creating an RDF equivalent or something close enough to the metadata standards you mention.

That's separate from files or some sense of text/media content. TEI editing within Omeka S is not in our plans. Viewing TEI would, long-term, be the sort of thing for an add-on module that would work with a file attached to an item, and _possibly_ extract metadata from it. My experience with TEI, though, is that the standard allows enough variation that it is hard to create a generalized solution.

ALTO, similarly, would obviously not be edited in Omeka S. Viewing ALTO is similarly not in the cards, since presumably if you have an ALTO file, you also have a scan of the document. That said, I am interested to hear what kinds of interactions between Omeka and ALTO data would be interesting and useful to everyone.

Thanks,
Patrick

[Daniel Berthereau]

Hi,

For Alto, I don't need to edit it, but currently, I import it as full text for the search engine and as data to highlight scanned texts, in particular for the search results in the BookReader.

In fact, my question was primarly about EAD. EAD is important, because this is a standard largely used in libraries, museums and archive centers and librarians want it to describe their digitalized collections. Of course, there are tools to convert it to rdf, but they want to find the structure, the fields and the terms they know when they edit them. In particular, the main difference with other formats is that this is always hierarchised: a collection contains boxes, that contain folders, that contain subfolders, that contain letters or other items, that contain text, and all of them can be described and related to others, and are generally viewed with a tree explorer. And they want to be able to share this data with other institutions exactly as they want.

Sincerely,

Daniel Berthereau
Infodoc & Knowledge management

[Rachel Donahue]

Just to echo Daniel, it would be awesome to be able to import EAD, even if it just took the form of a Collection Tree or advanced Item Relations. Converting a finding aid to Dublin Core isn't easy.

-Rachel