Ethan, Thanks for the kind words regarding CollectiveAccess!
As for XML/XForms vs. databases, I think you're conflating a specific form of data representation (XML) with the operations you wish to perform on your data. You can indeed handle hierarchies, loosely typed data, repeating and complex values, etc. in a relational database. And you can implement modern and innovative discovery tools with relationally stored data. As with most tools there's a trade-off - in this case between a variety of things including ease of use, perceived reliability and performance. Despite the attractions of XML-based models, relational databases are still relevant because they're well understood, scale well and generally provide good performance. For most uses they are firmly in "good enough" territory. That's not to say handling hierarchies and repeating values in a relational database is particularly fun, any more than fiddling with XPath is fun. But it can be done, it works, and being able to deploy using well supported and widely available software stacks is a huge advantage. And you can always output a representation of your data in an XML format if need be. The next update to CollectiveAccess can be automatically configured at install-time with a schema implementing CDWA. (Other standards are supported too, including DublinCore, DarwinCore, PBCore and SPECTRUM along as well as a collection of user-developed schemas for specific use cases). It can also use SOLR as its search engine, although we're not taking advantage of all SOLR has to offer at the moment. We're not using XForms yet but there's nothing to prevent us from going in that direction in the future. I look forward to the day when all widely used browsers provide built-in XForms support. Seth Kaufman CollectiveAccess developer On Dec 4, 2009, at 3:19 PM, Ethan Gruber wrote: > Hi G?nter, > > Thank you for the interesting set of questions. To address the first: yes, > you can create XML from scratch or open pre-existing XML documents and save > them back to a repository. > > The second issue is more complex. I assume by "pre-existing structured > data" you mean a database? XForms doesn't do this directly, but the > enterprise software application, Orbeon, which is designed to address low > level information management issues for XForms applications, can communicate > with any web service through REST or SOAP. Hypothetically, you can build an > XForms app on top of a traditional database, but that is not really the > intent of the standard. > > Databases and XML both have their strengths and weaknesses. XML is very > good for describing highly hierarchical information, complex contextual > information, and optional and repeatable elements. Databases tend to > struggle to encapsulate this information efficiently, yet databases form the > backbone for the content management systems that museums use. The reason is > that since flat databases are much more simple, it is easier to program > forms to create, edit, and delete records. The technology for performing > the same operations on complicated, hierarchical XML files (like CDWA or > EAD) simply wasn't available until very recently. XForms apps, and Orbeon > for delivering them, have advanced in the last two or three years to the > point where they are now. Currently, many libraries and archives are > developing XML manually in text editors (and even Microsoft Word!). This > presents a dilemma for the museum community, which is heavily invested in > proprietary databases that require licensing fees. This is in contrast to > libraries and archives, which are increasingly involved in the use and > development of open source applications for providing access to > collections. > > XML standards such as VRA Core and CDWA would enable more robust metadata > description for art and artifactual collections than databases. As a > result, one can create more useful discovery tools and user interfaces than > those that currently exist. As far as open source solutions go, > CollectiveAccess is a great step forward, though I believe it could be even > better if the underlying data was CDWA that can be managed with an XForms > backend and delivered with a front end that takes advantage of what the XML > has to offer, including the use of Solr for faceted search. > > In summation, if an institution's core data is contained in a database, > XForms would not be of much use. The subscription model for proprietary > software is dying in the library realm, so I would encourage museum > professionals to take part in a dialog on the future of information > dissemination in the museum field. The more institutions that adopt open > and free solutions, the more money those institutions will save in the long > run. That is money better spent on collections building, conservation, and > staffing to improve services and existing metadata. > > Ethan Gruber > University of Virginia Library > > On Fri, Dec 4, 2009 at 12:16 PM, Waibel,Guenter <waibelg at oclc.org> wrote: > >> Hi Ethan, >> >> I have to admit, I don't have any working knowledge of XForms, but after >> making myself as smart as spending a couple of minutes online and a brief >> chat with a colleague can make you, I have a couple of working assumptions >> and questions I'd like to run past you. (If I am wrong, I trust that you'll >> correct me.) >> >> What I think I've learned: >> You can use XForms to store keyed data in an XML format of your choosing. >> However, you can't use XForms to transform pre-existing structured data >> into XML. >> >> In other words, in the context of descriptive metadata, it seems to me that >> XForms would only be useful in an instance where you are cataloging from >> scratch. From my vantage point, the most pressing issue in museums is to >> transform existing data housed in collections management systems into XML, >> and from what I've learned so far, XForms is not applicable to that task. >> >> So in the end, my key question is the niche which XForms could fill in a >> museum context: how do you envision XForms could help an institution whose >> core information system is a database? In other words, what would a use case >> for a CDWA Lite editor be? How would a museum use XForms to create metadata >> when the main investment in creating that metadata is the collections >> management system? >> >> Cheers, >> G?nter >> >> *** >> >> G?nter Waibel >> OCLC Research >> voice: +1-650-287-2144 >> G?nter blogs at ... http://www.hangingtogether.org >> >> >> >> >> -----Original Message----- >> From: mcn-l-bounces at mcn.edu [mailto:mcn-l-bounces at mcn.edu] On Behalf Of >> Ethan Gruber >> Sent: Thursday, December 03, 2009 5:18 PM >> To: Museum Computer Network Listserv >> Subject: [MCN-L] Fwd: [CODE4LIB] new mailing list for XForms in libraries >> >> Hi all, >> >> I don't know the extent of the museum technologist community's >> experimentation with XForms in the creation of metadata, but in the >> research >> library community, there is an increasingly strong demand for tools used in >> the creation of MODS, METS, VRA Core, and EAD files. I am currently >> working >> on an EAD editor (http://code.google.com/p/eaditor/), dabbled with a VRA >> Core editor, and have contemplated starting work on a CDWA editor. I >> firmly >> believe that XForms applications represent the future of metadata creation, >> with database-related options eventually fading away, for a wide variety of >> reasons. >> >> I am forwarding this email from code4lib. I encourage technologists and >> museum professionals that have a vested interest in metadata creation to >> subscribe to the listserv described in the email below. I am personally >> interested in the adaptation of common library software tools to museums >> and >> other cultural heritage institutions, so I think that museum professionals >> should play a role in engaging in a dialog with library professionals in >> developing these sorts of tools. >> >> Ethan Gruber >> University of Virginia Library >> >> ---------- Forwarded message ---------- >> From: [Your Name] <ajs6f at virginia.edu> >> Date: Thu, Dec 3, 2009 at 12:48 PM >> Subject: [CODE4LIB] new mailing list for XForms in libraries >> To: CODE4LIB at listserv.nd.edu >> >> >> There's been some interest lately on this list in the use of W3C XForms for >> library metadata (e.g. MODS, EAD, VRA Core...). Several institutions have >> committed in one degree or another to their use, and many more are >> investigating the possibility. To provide a venue for more specific >> discussion (implementations, code sharing, etc.) I've created a list at: >> >> https://list.mail.virginia.edu/mailman/listinfo/xforms4lib >> >> I hope we can generate some useful discussion there, and perhaps even some >> partnership-building. As my colleague Ethan Gruber has pointed out to me, >> there are at least four or five institutions implementing MODS editors >> alone. It would seem that there's a lot of room to help each other. >> >> --- >> A. Soroka >> Digital Research and Scholarship R & D >> the University of Virginia Library >> _______________________________________________ >> You are currently subscribed to mcn-l, the listserv of the Museum Computer >> Network (http://www.mcn.edu) >> >> To post to this list, send messages to: mcn-l at mcn.edu >> >> To unsubscribe or change mcn-l delivery options visit: >> http://toronto.mediatrope.com/mailman/listinfo/mcn-l >> >> The MCN-L archives can be found at: >> http://toronto.mediatrope.com/pipermail/mcn-l/ >> >> >> _______________________________________________ >> You are currently subscribed to mcn-l, the listserv of the Museum Computer >> Network (http://www.mcn.edu) >> >> To post to this list, send messages to: mcn-l at mcn.edu >> >> To unsubscribe or change mcn-l delivery options visit: >> http://toronto.mediatrope.com/mailman/listinfo/mcn-l >> >> The MCN-L archives can be found at: >> http://toronto.mediatrope.com/pipermail/mcn-l/ >> > _______________________________________________ > You are currently subscribed to mcn-l, the listserv of the Museum Computer > Network (http://www.mcn.edu) > > To post to this list, send messages to: mcn-l at mcn.edu > > To unsubscribe or change mcn-l delivery options visit: > http://toronto.mediatrope.com/mailman/listinfo/mcn-l > > The MCN-L archives can be found at: > http://toronto.mediatrope.com/pipermail/mcn-l/
