Comments on: BagIt http://inkdroid.org/journal/2008/06/06/bagit/ $pithy_personal_mission_statement Thu, 04 Dec 2008 00:35:40 +0000 http://wordpress.org/?v=2.6.5 By: Jim http://inkdroid.org/journal/2008/06/06/bagit/#comment-65445 Jim Tue, 24 Jun 2008 17:41:29 +0000 http://inkdroid.org/journal/?p=203#comment-65445 I was pretty pleased when LC suggested we use the spec to deliver NDIIPP content to them. Super low cost and easy to validate. Addressing Peter's comment regarding 'best before' dates, it's my suspicion that LC isn't in a position to fast-track data acquisition presently. That doesn't mean that the spec, as implemented by others, wouldn't benefit from a data associated with data. I was pretty pleased when LC suggested we use the spec to deliver NDIIPP content to them. Super low cost and easy to validate.

Addressing Peter’s comment regarding ‘best before’ dates, it’s my suspicion that LC isn’t in a position to fast-track data acquisition presently. That doesn’t mean that the spec, as implemented by others, wouldn’t benefit from a data associated with data.

]]> By: Peter Binkley http://inkdroid.org/journal/2008/06/06/bagit/#comment-64650 Peter Binkley Fri, 06 Jun 2008 21:32:25 +0000 http://inkdroid.org/journal/?p=203#comment-64650 We heard about this at the PASIG meeting in San Francisco last week - it looks very handy. I didn't pick up on the possibility of holey bags there, though. Given that this is intended for delivery rather than persistence, it might be helpful to allow a best-before date in fetch.txt (maybe per line). Since this will often be used to share ingestion-friendly files, which I may not want to leave lying around in web-accessible space, the date would let me say "get it by Friday cuz it may not be there next week". We heard about this at the PASIG meeting in San Francisco last week - it looks very handy. I didn’t pick up on the possibility of holey bags there, though. Given that this is intended for delivery rather than persistence, it might be helpful to allow a best-before date in fetch.txt (maybe per line). Since this will often be used to share ingestion-friendly files, which I may not want to leave lying around in web-accessible space, the date would let me say “get it by Friday cuz it may not be there next week”.

]]> By: Michael J. Giarlo http://inkdroid.org/journal/2008/06/06/bagit/#comment-64645 Michael J. Giarlo Fri, 06 Jun 2008 16:34:06 +0000 http://inkdroid.org/journal/?p=203#comment-64645 One quick response to gsf's query about fetch.txt, "one question: why aren’t URLs in the fetch.txt preceded by a checksum?" The checksums for files listed in fetch.txt are already listed in the manifest. I'm not sure how useful the length param is since the checksum is already recorded elsewhere, but I suppose it's a good way to -quickly- check if the content from a URL is what you're looking for. One quick response to gsf’s query about fetch.txt, “one question: why aren’t URLs in the fetch.txt preceded by a checksum?”

The checksums for files listed in fetch.txt are already listed in the manifest. I’m not sure how useful the length param is since the checksum is already recorded elsewhere, but I suppose it’s a good way to -quickly- check if the content from a URL is what you’re looking for.

]]> By: Gabriel Sean Farrell http://inkdroid.org/journal/2008/06/06/bagit/#comment-64642 Gabriel Sean Farrell Fri, 06 Jun 2008 13:47:58 +0000 http://inkdroid.org/journal/?p=203#comment-64642 One thing I'm struck by right away is the similarity of of BagIt to the DSpace Simple Archive Format, which I'll call SAF even though the DSpace docs fail to employ such a lovely acronym. The unfortunate URL for that section of the docs is http://www.dspace.org/index.php?option=com_content&task=view&id=144#itemimporter. Anyway, as you can see there, SAF consists of an archive directory with item subdirectories. Each item directory contains a dublin_core.xml describing the item and a "contents" file similar to the BagIt "manifest", but without the checksums. BagIt is obviously more flexible, and the fetch.txt is a banging idea (one question: why aren't URLs in the fetch.txt preceded by a checksum?). It occurs to me now that it would be simple to send an SAF item or bunch of items within a Bag, though I'm not sure what the gain there would be. In any case, that part of SWORD (i.e. converting from BagIt to something DSpace/Fedora/etc. can ingest) should be pretty simple, so you're probably right that the retrieval of "holey bags" will be the kicker. One thing I’m struck by right away is the similarity of of BagIt to the DSpace Simple Archive Format, which I’ll call SAF even though the DSpace docs fail to employ such a lovely acronym. The unfortunate URL for that section of the docs is http://www.dspace.org/index.php?option=com_content&task=view&id=144#itemimporter. Anyway, as you can see there, SAF consists of an archive directory with item subdirectories. Each item directory contains a dublin_core.xml describing the item and a “contents” file similar to the BagIt “manifest”, but without the checksums.

BagIt is obviously more flexible, and the fetch.txt is a banging idea (one question: why aren’t URLs in the fetch.txt preceded by a checksum?). It occurs to me now that it would be simple to send an SAF item or bunch of items within a Bag, though I’m not sure what the gain there would be. In any case, that part of SWORD (i.e. converting from BagIt to something DSpace/Fedora/etc. can ingest) should be pretty simple, so you’re probably right that the retrieval of “holey bags” will be the kicker.

]]>