Use Case: compatible with BagIt

[eocarragain]

As a repository manager, I want a well-defined way of to creating a BagIt bag from an RO-Crate so that I can leverage existing tooling to track fixity the object payload and metadata over time

See, for example, bagit-ro (https://github.com/ResearchObject/bagit-ro), BDBags and the way in which DataCrate distinguishes Working DataCrates from Bagged DataCrates

@stain, is this what you mean by the "json-in-Github" scenario?

[ptsefton]

See my comment on #16 - Bagit support is pretty easy to specify but we should also consider other use-cases As a repository manager I want a way to create X packging form from an RO-Crate

where X = OCFL Object | Frictionless Data Package | SWORD wrapper | etc.

[ThomasThelen]

Just to add to this use case.

As a repository manager I want to [create a bagged RO-Crate/create a bag containing an RO-Crate] for enhanced interoperability.

A little more background,

Our service is exporting BagIt archives and it seems that we have a few possibilities when it comes to integrating RO-Crate, shown below.

The data exported as a bag looks like the following

zip_name/
   bag-info.txt
   bagit.txt
   fetch.txt
   manifest-md5.txt
   manifest-sha256.txt
   tagmanifest-md5.txt
   tagmanifest-sha256.txt	
   data/
      workspace/
         analysis.R

Adding support for RO-Crate can be done by specifying the RO-Crate Root as the root of the bag, shown below. In this case, the artifacts from our system are placed in data/. This is equivalent to calling the artifact a bagged RO-Crate.

zip_name/
   bag-info.txt
   bagit.txt
   fetch.txt
   manifest-md5.txt
   manifest-sha256.txt
   tagmanifest-md5.txt
   tagmanifest-sha256.txt	
   ro-crate-metadata.jsonld
   data/
      workspace/
         analysis.R

We can also place the RO-Crate metadata file in the bag payload, shown below. This is equivalent to calling the artifact a bag of an RO-Crate.

zip_name/
   bag-info.txt
   bagit.txt
   fetch.txt
   manifest-md5.txt
   manifest-sha256.txt
   tagmanifest-md5.txt
   tagmanifest-sha256.txt	
   data/
      ro-crate-metadata.jsonld
      data/
         workspace/
            analysis.R

Are there any recommendations on which method is preferred? I have more details here

[ptsefton]

The DataCrate format which informed RO-Crate explicitly stated that the metadata should be in the root directory, but RO-Crate is agnostic on this point - you can do either. The first approach means that: Metadata (including the ro-crate-preview.html file you have not shown) is more discoverable when someone opens the bagit archive You can change the metadata without changing the payload / checksums The second gives you more assurance that the files are as expected as the metadata and preview files have checksums. We should write this up in an implementation note.

…

On Wed, 30 Oct 2019 at 07:26, Thomas Thelen ***@***.***> wrote: Just to add to this use case. Our service is exporting BagIt archives and it seems that we have a few possibilities when it comes to integrating RO-Crate, shown below. The data exported as a bag looks like the following zip_name/ bag-info.txt bagit.txt fetch.txt manifest-md5.txt manifest-sha256.txt tagmanifest-md5.txt tagmanifest-sha256.txt data/ workspace/ analysis.R Adding support for RO-Crate can be done by specifying the RO-Crate Root as the root of the bag, shown below. In this case, the artifacts from our system are placed in data/. zip_name/ bag-info.txt bagit.txt fetch.txt manifest-md5.txt manifest-sha256.txt tagmanifest-md5.txt tagmanifest-sha256.txt ro-crate-metadata.jsonld data/ workspace/ analysis.R We can also place the RO-Crate metadata file in the bag payload, shown below. zip_name/ bag-info.txt bagit.txt fetch.txt manifest-md5.txt manifest-sha256.txt tagmanifest-md5.txt tagmanifest-sha256.txt data/ ro-crate-metadata.jsonld data/ workspace/ analysis.R Are there any recommendations on which method is preferred? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=AAFYTWD62DFN2NMRRW3LP4LQRCL7BA5CNFSM4HLXVD72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECR6YZY#issuecomment-547613799>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFYTWFC4FF6YB7GOMJIXUDQRCL7BANCNFSM4HLXVD7Q> .

-- Peter Sefton +61410326955 pt@ptsefton.com http://ptsefton.com Gmail, Twitter & Skype name: ptsefton

[ThomasThelen]

Just to clarify,

You can change the metadata without changing the payload / checksums

I think that ro-crate-metadata.jsonld would be defined as a BagIt tag-file so you'll see changes in the tagmanifest-md5.txt and tagmanifest-sha256.txt files.

[stain]

Closing this as https://www.researchobject.org/ro-crate/1.1/appendix/implementation-notes.html#adding-ro-crate-to-bagit has been part of the specification -- it does however have ro-crate-metadata.json inside data/ (which becomes RO-Crate Root) rather than in metadata/ -- see also #78 .