I think this got off on a tangent, but theres important points here to our discussion that ultimately might be enlightening to Dorotheas original question about pitfalls in switching to the use of METS packages
On May 14, 2008, at 10:29 PM, Stuart Lewis wrote: > > On 14/05/2008 22:54, "Tim Donohue" <[EMAIL PROTECTED]> wrote: > >> 'dspace-sword' module implements a SWORD Server for DSpace. This >> SWORD >> Server *does* use the DSpace Packager framework. But, by default it >> expects you to send a METS file (actually a zipped up METS file) with >> EPrints DC XML metadata in it. There are some basic configs in >> dspace.cfg to allow you to specify a different "crosswalk", but it >> uses >> EPrints DC XML by default (as that is the "recommended" supported >> metadata format by SWORD). Technically a SWORD Server can support >> *multiple* metadata formats (or METS profiles), but it looks like >> 'dspace-sword' only supports one at a time right now. > > That is correct. One of the things we struggled with when > developing SWORD > was deciding how SWORD can 'describe' the package and what's in it > (and > therefore give a hint to the repository about how to process it). > > I don't necessarily think that SWORD clients would need to be > extended and > made DSpace specific in order for them to pass a more granular > description > of the package than is currently possible (by using the mime type and > X-Format-Namespace header). This problem will be affecting all SWORD > repository implementations so needs to be addressed at the protocol > level. > > As it happens, we are soon to be revisiting the SWORD specification > as we > have received some more grant funding to work on it. If as a DSpace > community we can collect a 'wish list', we'll gladly take that > along. And if > anyone would really like to be involved in the next stage of the > specification process, we'll make sure you get added into the > discussions. > > Thanks, I wasn't critiquing the descriptive metadata format... I was critiquing that there is a severe overhead to manufacturing SIPs in the first place because of the amount of mapping/guessing that has to go on between where to put things in METS to get a desired result in DSpace. It doesn't much matter what goes into the descriptive metadata, with the default METS ingester implementation in DSpace, if your not using the the "DSpace METS SIP" profile for a METS package being ingested... DSpace is not going to accept it... So I assume that SWORD is reusing this implementation and thus providing the "required profile" rather than taking a more implementation agnostic approach... Is the "DSpace METS SIP" profile being reused for EPrints SWORD implementation as well? And others? (If any of you have been lurking in the ORE group... you recognize this nightmare from my last thread there...) http://groups.google.com/group/oai-ore/browse_thread/thread/ fb63e73ea660bc22 <snipped from that thread to make the specific point> > I think its also very important to take into consideration what is > missing from our Items in DSpace (and the larger community) is a > more controlled and widely accepted set of Content Types (I.E. > Thesis, Book, Journal Article) and what is holding projects back from > sharing content is a standardized set of these models. If you look > at METS, I really thing the IR's originally took this in a very wrong > direction... METS should have been about nailing down actual Concrete > classes of Content Types. I.E. the approach that Patricia Galloway > has taken to having students generate METS Profile for specific > Complex Objects in her 2006 class. > > https://pacer.ischool.utexas.edu/handle/2081/2066/browse-date > > And not... the DSpace Submission Information Package Profile or the > Fedora METS Profile... this just replicated the interoperability > problem even further into logically mapping data structures in their > services. > > http://www.fedora.info/download/2.1.1/userdocs/digitalobjects/ > rulesForMETS.html > http://wiki.dspace.org/index.php/DSpaceMETSSIPProfile > > We really need stronger, centralized "content types" that we all > start to share. > > If all that ORE really ends up doing is providing is a way to harvest > ORE Aggregations, this bears little difference to exposing an OAI-PMH > gateway of METS instances... There is still the impedance mismatch of > the varying "profiles" of METS left to interpret and resolve by the > application. For instance, We still have to implement a special > Fedora METS profile ingester for dspace to map mets Objects into > DSpace Items. The same problem will happen again for ORE if we are > not careful here. If the profiles are an agreed upon and very > specific "Content Types", it would require less localized > customization. I hope there is a way to avoid this with ORE and why > I think the concept of "Profiles" is dangerous form of customization > here. I say the same holds true for SWORD... and likewise LNI. Unless our application model and ingest processes are made generic enough to support "ANY METS INSTANCE" or "ANY ORE AGGREGATION", then we the application engineers are just introducing more barriers to interoperability... we're really our own worst enemy when it comes to this and it points to why we need neutral standards bodies to hammer this out! Even then, without enough attention, design mistakes are made. I think the whole METS profiles thing is a design mistake; Attempts to make something flexible just open a pandoras box of problems because the guidelines for usage are so vague and what has been produced as "profiles" just aren't in the right domain of application. Just look here... http://www.loc.gov/standards/mets/mets-registered-profiles.html the majority of these are all "service profiles" for IR/DL implementations, not "agreed" Content Types for submission/ dissemination packages... I really don't see the benefit because its not scalable to implement a DSpace Packager for each and every one of these. I guess my take home from this... I don't think there should be "any profile requirements" on METS based SIP coming into DSpace... that ultimately there just shouldn't "be" a "DSpace METS SIP" profile, if its METS, it should accept it, period. And this means that the the METS packager implementation in DSpace still needs work to make it accept "any profile" in the METS manifest of a SIP Cheers, Mark ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Developer and Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
