XSD importing

[SCDRC]

Hi all,

I asked this in the forums, but Jim pointed me to this group as the
best place to ask questions. I'm evaluating Omeka for inclusion in a
grant proposal as the project repository. I would be looking to add
lots of additional element sets for the metadata I'm hoping to capture
(MIX, PREMIS, TextMD, MODS, all in METS; etc). While I would do the
dev for it if needed, I was wondering if anyone else has already done
the grunt work for a generic XSD importer.

Additionally, is there a desire out there for true hierarchical
elements and sets with complex types (date, enumerated list, regex
validation, etc)? Most of the above listed metadata schema are a bit
more restrictive in data types than just the sting/integer dichotomy.
The idea would be to be able to output valid XML for the schema for
inclusion (via XMP) in PDF/A files.

If I'm the only one insane enough think this is a good idea, I would
probably just branch the source code locally. If there is more
interest I would ask the devs to create on "official" branch so others
could use it too.

--Mark G.
South Central Digitization Resource Center (proposed)

[Dave Lester]

Hi Mark,

Thanks for your interest in the project and for joining the dev list.

Regarding Element Sets, I'm hoping that Patrick can jump into this thread because he has done a lot of work with element sets in Omeka.  I've cc'd Patrick, and would encourage you to check out a blog post where he linked to six different element sets that he has created: http://www.patrickgmj.net/node/177  If possible, try to keep your Omeka discussions on the list so we can all chime-in where necessary.

The second part of your email about hierarchical elements in Omeka is interesting.  Omeka hasn't been designed to model those relationships, and we typically think of the software are a presentation tool where flat data is OK, rather than a robust storage tool where those hierarchical relationships can be important.

With that disclaimer, that doesn't mean that a workable solution is entirely impossible.  A goal of the Omeka's design is to make it easy to use, while offering different uses that are enabled by its extensibility.  It may be easier on your part to adopt another software solution which has this nested metadata as its primary focus, or if you're up for the challenge, perhaps this could be your own project to branch the development of Omeka and try out some things.  I don't think this is something we'd want in the core of the software, but perhaps there are ways that the core could become more agile to allow plugins to interact this way.

I'd encourage you to map out exactly what you're looking for in terms of nested metadata before taking this endeavor on, and use this developer list as a space to share your thoughts and get feedback from the group.

Best,

Dave

--

You received this message because you are subscribed to the Google Groups "Omeka Dev" group.
To post to this group, send email to omek...@googlegroups.com.
To unsubscribe from this group, send email to omeka-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/omeka-dev?hl=.