Skip to content
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

store full original path as archival record #178

Open
cccs-ip opened this issue Oct 11, 2014 · 4 comments
Open

store full original path as archival record #178

cccs-ip opened this issue Oct 11, 2014 · 4 comments
Assignees
Labels

Comments

@cccs-ip
Copy link
Member

cccs-ip commented Oct 11, 2014

the path is useful as an archival record. otherwise, we would store directory names as attribute tags and perhaps eventually change the folder structure

@pwhipp
Copy link
Contributor

pwhipp commented Oct 14, 2014

Any document can have an arbitrary number of filenames associated with it in its metadata.

@cccs-ip
Copy link
Member Author

cccs-ip commented Oct 14, 2014

Cool, and thanks. After we run the sha process, can we compile all the different names into all manifestations of the same file?

@pwhipp
Copy link
Contributor

pwhipp commented Oct 14, 2014

We can easily run a process that deletes the duplicate files and collapses the documents down to one with the other filenames recorded within it. If we do that, the hard bit will be deciding which categorization we keep.
If the categorizations are all valid, these could be added to the document, making the one we choose to keep arbitrary.
For example, if /a/foo.pdf and /b/bar.pdf are identical files, We could end up with one of the following metadata blocks:

  1. {filenames: [/a/foo.pdf, /b/bar.pdf], categories: [a, b]}
  2. {filenames: [/a/foo.pdf, /b/bar.pdf], categories: [a]}
  3. {filenames: [/b/bar.pdf, /a/foo.pdf], categories: [b]}

(1) seems to be the logical choice.

This does not consider the possibility that other metadata could differ (e.g. through a spreadsheet import). If that is the case then both metadata blocks should probably remain (as an optimization, they could be modified to point at the same actual s3 file).

@cccs-ip
Copy link
Member Author

cccs-ip commented Oct 14, 2014

Thanks, Paul. Option 1 and the multiple metadata files where information is conflicting sounds like the way forward.

pwhipp added a commit that referenced this issue Oct 14, 2014
pwhipp added a commit that referenced this issue Oct 14, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants