I do agree they are separate, my advice is simply that once have your hands under the hood in the METS Packager it would be a great opportunity to just take into consideration (2) when your making your changes so that we separate the processing of the mets file from the packager itself so it will be easier to understand and adapt in the future.
Mark On Thu, Mar 10, 2011 at 10:13 AM, Tim Donohue <tdono...@duraspace.org> wrote: > Mark & All, > > Although I agree with the ideas of Mark D's proposal, I'd like to point out > that there are two separate tasks here, which are only loosely related. So, > the person or persons volunteering for one, need not be responsible for the > other. > > The two tasks are: > > (1) Update/Create METS Profiles to sufficiently describe our current METS > usage (SIP, AIP, DIP?), based on the METS Profile standards described here: > http://www.loc.gov/standards/mets/mets-profiles.html > > (2) Update/Refactor the actual Packager code to better handle various file > types. This is unrelated to defining METS Profiles (as it doesn't call for > changes to the actual METS file structure), but it is also a good idea. > > Just wanted to clarify that there are two separate projects here. Both > could use a volunteer, but the projects themselves are really not dependent > on one another and could be completed separately. > > - Tim > > On 3/10/2011 12:05 PM, Mark Diggory wrote: >> >> Tossing in my $0.02, I've worked on the the following proposal for >> adjusting the Packager Architecture, I think it has a similar vein. >> Please fee free to grab this proposal and mutate it to your needs. >> Our goal is to get the File type (zip, ta, gz, pdf, etc) of the >> package separated from the crosswalks of its metadata manifest to >> DSpace objects. >> >> We have a project in planning right now that would simply produce yet >> another manifest based packager, but I thought this would be a good >> opportunity to review the actual packager architecture a little >> further. >> >> >> https://wiki.duraspace.org/display/DSPACE/Refactor+Packagers+to+support+Chain+of+Command >> >> Cheers, >> Mark >> >> On Thu, Mar 10, 2011 at 9:54 AM, Tim Donohue<tdono...@duraspace.org> >> wrote: >>> >>> All, >>> >>> (I sent a message to this same effect to both Robin Taylor& Bill Hays) >>> >>> I'd encourage someone to make updates or draft a new version of this >>> DSpace METS SIP profile. I'd love to be kept in the loop, but may not >>> have any significant time in the near term to devote towards this work. >>> So, I'd appreciate it if a volunteer or volunteers could step forward to >>> take this on. >>> >>> The existing DSpace METS SIP profile (version 1.0, from 2005) has been >>> posted to: >>> http://static.duraspace.org/dspace/mets/profiles/metssipv0p9p1.xml >>> http://static.duraspace.org/dspace/mets/profiles/metssipv0p9p1.pdf >>> >>> As Robin noted, it's also generally described on the DSpace Wiki at: >>> https://wiki.duraspace.org/display/DSPACE/DSpaceMETSSIPProfile >>> >>> I'll also note that I had planned to create a separate DSpace METS AIP >>> Profile for the DSpace 1.7.0 AIP work. Unfortunately, I never got around >>> to it for 1.7.0, though I hope I can eventually get back to that. >>> >>> Currently the AIP's METS structure is just defined/described via >>> examples in the Documentation (see links below). But, it too should >>> eventually be *formalized* into a METS Profile. >>> >>> https://wiki.duraspace.org/display/DSDOC/AIP+Backup+and+Restore >>> https://wiki.duraspace.org/display/DSDOC/DSpace+AIP+Format >>> >>> I'll admit, I'm not sure how much overlap there is between the METS SIP >>> profile v.1, and the AIP structure. The reason I don't know the answer >>> to this question is that the METS SIP profile was "lost" for a period of >>> time, until Bill managed to locate at copy at MIT. At that point, I was >>> already deep into the development of the AIP work, so I've never >>> actually compared the two METS formats. >>> >>> In general, though, I think we should formalize all of our METS usage >>> into a series of METS profiles (e.g. an updated DSpace METS SIP Profile, >>> a DSpace METS AIP Profile, etc.). This will ensure we are fully >>> documenting the METS structure based on METS community standards. >>> >>> So, if there's anyone out there who'd like to volunteer to tackle >>> updating these various DSpace METS profiles, please get in touch with >>> either Bill Hays or Robin Taylor. We could definitely use the help in >>> getting these up-to-date! >>> >>> - Tim >>> >>> On 3/4/2011 7:41 AM, Robin Taylor wrote: >>>> >>>> Hi all, >>>> >>>> There is currently one Mets profile for DSpace that I know of >>>> https://wiki.duraspace.org/display/DSPACE/DSpaceMETSSIPProfile. >>>> Unfortunately its been widely abused in the sense that it specifies that >>>> the metadata will be in MODS, but DSpace exposes and exports data >>>> claiming to adhere to the profile but with the metadata as EPDCX or even >>>> DIM. I would like to document a couple of new profiles that look exactly >>>> the same but refer to these other metadata schema. Why ? My interest is >>>> Sword. When sending a package to the Sword server I need to know exactly >>>> what package formats the server supports, including what metadata >>>> schema. >>>> >>>> Any objections ? >>>> >>>> Cheers, Robin. >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> What You Don't Know About Data Connectivity CAN Hurt You >>>> This paper provides an overview of data connectivity, details >>>> its effect on application quality, and explores various alternative >>>> solutions. http://p.sf.net/sfu/progress-d2d >>>> _______________________________________________ >>>> DSpace-tech mailing list >>>> DSpace-tech@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech >>> >>> >>> ------------------------------------------------------------------------------ >>> Colocation vs. Managed Hosting >>> A question and answer guide to determining the best fit >>> for your organization - today and in the future. >>> http://p.sf.net/sfu/internap-sfd2d >>> _______________________________________________ >>> DSpace-tech mailing list >>> DSpace-tech@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/dspace-tech >>> >> >> >> > -- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Technologielaan 9 - 3001 Heverlee - Belgium ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
