How can a bag declare which profile it is using?

[stain]

Presumably a header in its bag-info.txt?

I would suggest:

BagIt-Profile: http://example.com/exampleProfile/v1.0

Multiple profiles can be provided by multiple BagIt-Profile: lines. The URI that identifies the profile SHOULD be versioned. Resolving the URI with Accept: application/json MUST provide a BagIt Profile.

[mjordan]

Current implementation is that bag-info.txt must contain the tag 'BagIt-Profile-Identifier', with a value of the URI of the JSON file containing the profile. Within the JSON profile file, there is a "Version" tag. Thanks for the note about resolving the URI - we'll make that explicit.

What would the function of multiple identifiers be?

[stain]

OK. Is it permitted to have multiple profiles?

Profiles don't have an inheritance system. So say I define a BagIt profile

http://example.com/strict-transfer.json

   "Manifests-Required":[
      "sha1"
   ],
   "Allow-Fetch.txt":false,
   "Serialization":"required",
   "Accept-Serialization":[
      "application/zip",
   ],
   "Accept-BagIt-Version":[
      "0.98"   ]

which tools rely on to be sure they have a reliable way to parse the Bag.

Then there is a second profile (say by a second author), which is for making a research object:

http://example.org/research-object.json

   "Allow-Fetch.txt": true,
   "Serialization": "required",
   "Accept-Serialization":[
      "application/zip"
   ],
   "Tag-Manifests-Required":[
     "md5", "sha1"
   ],
   "Tag-Files-Required":[
     ".ro/manifest.json"
   ]

These profiles are compatible - a bag can be both of these by being 0.98 bag in a ZIP file, NOT use fetch.txt, use md5 and sha1 manifests and include the tagfile .ro/manifest.json.

I don't want to make my own third profile to combine those three, e.g. http://example.net/strict-research-object.json - as I don't have a way in the profile to say that this also implies the other two - and then consumers seeing:

BagIt-Profile: http://example.net/strict-research-object.json

.. would not know that this is also compliant with http://example.org/research-object.json (which they might have custom code to support) or http://example.com/strict-transfer.json (which they might require in order to reliably parse the bagit at all).

I think however I should be able to say

BagIt-Profile: http://example.com/strict-transfer.json
BagIt-Profile: http://example.org/research-object.json

meaning that the bag claims to conform both profiles.

Obviously it is possible to make impossible combinations here, but this should be much easier on a bag-level than in trying to build a class-like hierarchies of bagit profiles - as you can simply check the bag against each profile separately.

[mjordan]

Interesting thought but I'm not clear on why we'd need inheritance or a hierarchy. Could we not just indicate that a Bag conforms to multiple profiles as long as they are not incompatible?

Both @ruebot and I are at a conference right now and we're both fairly busy, so may not respond for a while.

[stain]

Yes, that is exactly what I would propose.. no need for inheritance or hierarchy, so when adding the section about BagIt-Profile within a supposedly conforming bag, we can just say there that it can be repeated for conformance with multiple profiles.

[jscancella]

This is solved in the current specification where it says

Bags complying to a BagIt Profile MUST contain the tag BagIt-Profile-Identifier in their bag-info.txt, which value is the URI of the JSON file containing the BagIt Profile it conforms to. This tag MAY be repeated if the Bag conforms to multiple BagIt Profiles.