PRESERVATION OBJECT (BAGit) PROFILES

9 views
Skip to first unread message

Michael Peterson

unread,
Nov 16, 2012, 11:57:25 AM11/16/12
to ltd...@googlegroups.com
FYI - The idea of profiles is good.



Begin forwarded message:

Subject: [digital-curation] Digest for digital-...@googlegroups.com - 4 Messages in 2 Topics
Date: November 16, 2012 3:20:08 AM PST
To: Digest Recipients <digital-...@googlegroups.com>

Group: http://groups.google.com/group/digital-curation/topics

    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.

Reply all
Reply to author
Forward
0 new messages