 |
 |
Well, DC is kind of supposed to be such a standard in the first place, right? DC is supposed to be like a lowest-common-denominator metadata vocabulary. MODS and MARC can certainly be easily 'dumbed down' to DC. (Via 'crosswalk', as they tend to say in our field). Of course, DC isn't always sophisticated enough for what you need, it's the nature of the beast at the moment. Metadata compatibility and standardization is definitely a tricky problem in a number of differnet ways, with ongoing work towards improving things. But maybe you were just kind of joking. 'use attributes' is a Z39.50 thing, right? --Jonathan > The cross-searchability that Art is suggesting would depend on > consistency in naming fields. Do we need a standard for field names for > DC, MODS, MARC, etc.? Or should we abstract the fields; we could give > them numbers instead of names, and call them "use attributes"... yeah... > > > Peter > > > > -----Original Message----- > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > Art Rhyno > Sent: Wednesday, May 31, 2006 12:06 PM > To: [log in to unmask] > Subject: Re: [CODE4LIB] fun with kinosearch > >>The developer of KinoSearch and the >>developer of Ferret (the Lucene port for Ruby) are teaming with one of >>the developers of Lucene to make Lucy (which is a 'shared core' for >>Lucene) which would then make it easier to write interoperable code >>between these languages (at least, I presume that's the goal). >> > > Lucene seems to be emerging as a common index format for many languages, > platforms, and projects. The availability of a common index format would > have some really nifty possibilities for libraries. For example, if > there were a lucene index for a citation database and the library's > holdings were also indexed by lucene, it might be possible to leverage > the same format to limit searches to materials that are immediately > available, rather than the "click and hope" model offered by resolvers > now. Or even arbitrary mixing and matching of databases at the index > level without having to replicate the content locally. My only quibble > with lucene is indexing throughput for very large databases but I am > told it can accommodate massive parallelization, in which case there > might be a new purpose for all of those library workstations that sit > empty in the wee hours... > > art >