4 Responses to “Working with MODS”

  1. Clay Redding Says:

    Hi Winona,

    I think all of us that are working on a MODS form need to slow down production and simply chat. Let’s (very soon) compare notes and see where each of our developments stand. We’re all hacking away on the same issues, and I’m starting to think that we could be dividing up some of the labor. I’m currently working on mods:subject now too (but actually starting to move toward solving this with creating MADS authorities and inserting those MADS values into MODS simply through XQuery).

    One of the things that has become abundantly clear is that, perhaps moreso than METS, MODS needs profiling on a project level. Creating a general, all purpose MODS XForms editor is simply too time consuming because MODS is deceivingly complex with recursiveness and attribute values. I’m not sure how MODS works at UVM, but I know at Princeton we didn’t really have project-specific templates. Luckily at LC, by and large we do. What I’ve been doing here is working from pre-defined project templates and vocabularies, and that is working much faster.

    I’ve created a schema solely for mods:subject to aid in generating the subject parts: http://exist.monarchos.com/db/schemata/mods/subject.xsd.

  2. wsalesky Says:

    Hi Clay,
    I think it would be a great idea for us to chat, we should include Parmit from Princeton, I’m not sure who else is actively working on a MODS form, but if you know anyone else who wants in on the discussion I think that would be great. I think splitting up the work would also be a good idea, it doesn’t make sense for us all to be duplicating work.

    Most of what I’ve been working on has been a way for me to really explore XForms, find its limitations and strengths. Dublin Core is so simplistic it didn’t really force me to use anything more than the most basic XForms features.

    As for MODS at UVM, it doesn’t currently exist. I can’t implement MODS without some sort of interface for metadata creation (although we are now looking at the Archivist toolKit as a possibility). I agree that creating a general all purpose MODS form might be more time consuming than is useful, but I think using something like the DLF Aquifer guidelines is a good starting point, for more generalized form. I also think it would be possible to have a form that is configurable by users, but not using XForms 1.0 specs.

    Anyway, the XForms wiki is meant to serve as a collaborative workspace if you want to start working on something together.

  3. Parmit Says:

    Hi all,

    Yeah it would be great to talk since we’re all tackling the same problem! I’ve been away and haven’t had a chance to post our working code, but it’ll be up on the wiki soon.

    Our editor has started off as something that works best for our local needs, but we hope that people will be able to customize it to suit their own projects. We are also closely following the DLF guidelines. This project is becoming a priority for us and we will make more progress in the next few weeks, but would be happy to get the discussion going with others who’re doing the same thing.

    Winona, we faced the same problems with nested insert/delete which you’ve mentioned. But, since Orbeon makes use of xforms1.1 features the implementation was a bit easier. The key is in using the context and origin attributes on insert and referencing the nested repeats properly. (I can post a detailed example if others are considering using xforms1.1).

    Clay, we’re certainly interested in making use of MADS and it has come up in our discussions often, but I haven’t had a chance to look at it in much detail yet.

    Anyway, will keep you posted on our progress on the xforms wiki and it’d be good to see how we can further collaborate.

  4. Clay Redding Says:

    How should we best proceed, then? Let’s try to arrange a conference call or something. I’m pretty free the next few weeks.

    I’m actually strongly leading toward taking the subject component out of my MODS editor, and instead making a separate general authority editor. One less recursion headache to avoid in MODS. That authority editor would allow for fielded entry, freeform entry with MARC mnemonics, or harvesting in from OAI or the like (transformations out to MADS and EAC would be a plus, too). Then I’ll save what’s generated from this form, and the MODS editor can have an enumerated list of the saved authorities to pull from with a simple xf:select.

    I guess we’ll have to aim for a “target” platform for our joint XForms devel work. Firefox or Orbeon?

Comments are closed.


%d bloggers like this: