-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What if my content includes files called inventory.json
or inventory.json.sha512
?
#230
Comments
I think this is a problem, but I'm not sure how big a problem it is.
If we have to address it, though, I would go with option 2. |
Maybe call it |
I agree that if we were to adopt option 2 then |
...or make the name ocfl_inventory.json etc. to make it a minimal chance of collision and just say they are reserved and you can't have them. |
@neilsjefferies that might get a bit messy if we're wanting to handle arbitrary content from someone's HD. Especially if they've adopted OCFL as a way of organizing their content. :) |
That would be archivists just being silly. If that is what you are doing then packaging is really the way to go. |
It is probably important that we support the case of someone's content having the same name as OCFL administrative metadata files. |
I lean toward having an extra |
Since the inventory already has a mechanism for separating logical path in the object from actual path on disk, isn't this really just an Implementation Note. Since you can't have those names on disk, rename them - they can still have the name in the inventory. The system we have can handle it already, why introduce a change for a small corner case? |
TBH, having the inventory in the same directory root as content has never really sat well with me. I just wasn't able to say why. It seemed like we were mixing administrative and content data. |
@rosy1280 @julianmorley pretty please could we have some input on this so we can move it along? |
i think it would be cleaner and more human readable if their was a content directory and we put the content files in them. there is a reason that bagit and moab do this. so lets not reject use cases because we don't think people should do them. |
Yeah, having a content directory makes a great deal of sense. It enables a clean nesting of OCFL objects inside OCFL objects. |
also when you start to think about distributed digital preservation (which i don't want to broach, but...) if Emory's repository implements OCFL and sends their content to Chronopolis that has implemented OCFL you may end up with clashing |
Per https://github.com/OCFL/spec/wiki/2018.10.17-Editors-Meeting agreed to use |
if it wasn't clear by the assignments, I'm currently working on a PR to this effect |
Q: Do the 'logical' filepaths also omit the 'content' part? |
@ahankinson : it would make sense to me that |
👍 |
Also, are |
Fixes #230 Per speedy-mode... merge on 3!
I see two options:
data
) so that there is clean separation:The text was updated successfully, but these errors were encountered: