Subject: [digital-curation] Digest for digital-...@googlegroups.com - 4 Messages in 2 TopicsDate: November 16, 2012 3:20:08 AM PSTTo: Digest Recipients <digital-...@googlegroups.com>Reply-To: digital-...@googlegroups.comGroup: http://groups.google.com/group/digital-curation/topics
- BagIt Profile Specification - request for comments/participation [3 Updates]
- fstat-manifest.txt [1 Update]
Mark Jordan <mjo...@sfu.ca> Nov 15 02:21PM -0800
Hi,
At the Access 2012 Hackfest in early October, a group of us spent the day hashing out a simple specification for expressing machine-readable BagIt profiles. We've made the proposed spec available at https://github.com/ruebot/bagit-profiles for your reading pleasure.
We're hoping this draft spec will generate some discussion among BagIt implementers and that the community will help develop the spec to a state where we can start sharing profiles for Bags created by or ingested by common repository platforms and for other shared applications.
Thanks, looking forward to the discussion,
Mark
Mark Jordan"Mark A. Matienzo" <mark.m...@gmail.com> Nov 15 10:48PM -0500
Hi Mark - I'm really excited to see this, because I've been working
with Bagger profiles and wondering how the best way to extend them
into something that might be actionable outside of the Bagger
application. One of the profiles that we've developed that's currently
in use can be found at [0]. A couple of quick thoughts follow based on
what my needs are.
* Ideally I would like to see any profile implementation have some
(optional?) identifying information within it, e.g. a brief textual
description, a listing of the maintainer/maintainers, etc.
* Does the profile itself need to contain the URI that identifies it?
I can imagine cases where I may like to store a copy of the profile
locally which would then be used to create/validate Bags using that
profile.
* Would it be of value to add versioning information to the profile,
e.g. a version number, or information about if a given version profile
has been superseded, etc.?
* I'd be interested in seeing a mapping against the Bagger profile
implementation.
* Eventually I'd also like to see Bagger to support this emerging
profile spec once it's set.
[0] https://github.com/yalemssa/bagger-profiles/blob/master/YUL_DISKIMG_ACCN_SIP_0.2-profile.json
Cheers,
Mark A. Matienzo <ma...@matienzo.org>
Digital Archivist, Manuscripts and Archives, Yale University Library
Technical Architect, ArchivesSpace
Mark Jordan <mjo...@sfu.ca> Nov 15 09:19PM -0800
Mark,
----- Original Message -----
> * Ideally I would like to see any profile implementation have some
> (optional?) identifying information within it, e.g. a brief textual
> description, a listing of the maintainer/maintainers, etc.
Great idea, something like this?
"bagit-profile-info": {
"description": "The best damn BagIt profile out there",
"maintainer": "Foo University Archives",
"version": "1.3",
"uri": "http://foo.edu/bagitprofiles/bar.json"
}
Actually, we may want to consider using the 'reserved metadata element names' identified in the section 2.2.2 of the BagIt spec to describe the profile, as long as they were wrapped in a specific JSON field, like 'bagit-profile-info' above.
> I can imagine cases where I may like to store a copy of the profile
> locally which would then be used to create/validate Bags using that
> profile.
We require a BagIt bag-info.txt tag 'Bag-Profile' containing the URI, but having the URI in the profile file itself makes a lot of sense. How about a new required field 'uri' (see example above).
> e.g. a version number, or information about if a given version
> profile
> has been superseded, etc.?
Yes - also see above, but please suggest more detail if you want.
> implementation.
> * Eventually I'd also like to see Bagger to support this emerging
> profile spec once it's set.
I'm not that familiar with Bagger, but if we are going to use Bag profiles, ideally we should make them work with as many tools as possible.
Thanks for the feedback, keep it coming! Also, thanks for the formatting improvements to the spec document, I've merged them in.
Mark"Littman, Justin" <jl...@loc.gov> Nov 15 07:38AM -0500
You might want to look at Digital Forensics XML (http://www.forensicswiki.org/wiki/Category:Digital_Forensics_XML).
--Justin
-----Original Message-----
From: digital-...@googlegroups.com [mailto:digital-cura...@googlegroups.com] On Behalf Of John A. Kunze
Sent: Wednesday, November 14, 2012 4:09 PM
To: Digital Curation
Subject: Re: [digital-curation] fstat-manifest.txt
Keith Johnson brought up the concept of storing the inode/fstat info about the time that the bagit spec was stabilizing. Good for forensics and more.
He thought the container might be called a "baggie". A comprehensive approach to filesystem-level info across platforms was challenged by pretty divergent practices, eg, consider the rich file-level metadata found on Mac OSX filesystems. That might be part of a case for just looking at a subset of the file "metadata" (eg, ctime, mtime, ...).
-John
--- On Wed, 14 Nov 2012, Dan Chudnov wrote:
--
You received this message because you are subscribed to the Google Groups "Digital Curation" group.
To post to this group, send email to digital-...@googlegroups.com.
To unsubscribe from this group, send email to digital-curati...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/digital-curation?hl=en.You received this message because you are subscribed to the Google Group digital-curation.
You can post via email.
To unsubscribe from this group, send an empty message.
For more options, visit this group.
--
You received this message because you are subscribed to the Google Groups "Digital Curation" group.
To post to this group, send email to digital-...@googlegroups.com.
To unsubscribe from this group, send email to digital-curati...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/digital-curation?hl=en.