A beta tester suggested that heirarchical tags, when applied to an asset, could result in an actual directory being created in their library, and a symlink to the “best” variant of the asset (along with any sidecars) being added to that library.
Removing the tag would result in deleting that symlink.
As an example, by adding the Who/Doe/Jane tag to $library/2021/2021-03-13/IMG_1234.JPG, a new directory $library/Who/Doe/Jane would be created, and a symlink to $library/2021/2021-03-13/IMG_1234.JPG be added.
In some ways I like this… in others it scares me. I’ve not been comfortable with links being “robust”, especially when dealing with cross platform situations.
My greatest fear would be accidental deletion - as soon as links are involved, I get scared that I will accidentally remove the “real thing” when I think I’m removing a link (I’ve done it before :-)).
I think the folder name should be placed in the database as meta data for the photo IMO. This would provide searchability which is something I think that will be super important for a lot of folks.
Reason for searchability: photos are most useful when you can find them for a project or to print. Otherwise one’s mass of 300k+ photos is a jumbled mess.
So I like the general concept but not as tags, just searchable fields within the database and perhaps as exif data if possible without changing the sha hash
Sometimes having the data in directory structure gives you access to the information outside of this program, as opposed to the lock-in of it being in the database.
the file SHA won’t change (at least by default), as PhotoStructure writes updates to sidecars.