Difference between revisions of "Multi criterion file system"
From apm
m |
m |
||
| (One intermediate revision by the same user not shown) | |||
| Line 36: | Line 36: | ||
* [[Manumatic update distribution]] | * [[Manumatic update distribution]] | ||
* [[Backward button unscalability]] – (Example: The horror called "video editing") | * [[Backward button unscalability]] – (Example: The horror called "video editing") | ||
| + | |||
| + | [[Category:Information]] | ||
| + | [[Category:Programming]] | ||
| + | [[Category:Software]] | ||
Latest revision as of 09:40, 5 May 2024
A concept for a "file system" which allows to sort "folders" in multiple "super-folders" (no asymmetries)
(wiki-TODO: elaborate on the problems and opportunities)
Contents
The bad
The "solutions" that are none
File system links (soft and hard), Tags, Metadata, indexed search, ... are all hacks that only mend the symptoms of the core problem.
Link embedding vs data embedding
- (wiki-TODO: use incscape and scribus as examples)
The good
- same data in multiple projects – manumatic update distribution
- Orthogonalized: locality management, importance management (backup degree), ...
- reconstructability of lost paths to files
(wiki-TODO: elaborate on "backward hierarchical multi project image preview.")
Wikis
Wikis come closest to a solution but:
- they don't integrate media well - no spontaneous scribble & free drag-and-drop like in linear note taking software
- they are not fine grained enough - not for files.
- they are not low level enough. They do not form a file system (proliferation of abstraction layers).
- General software issues
- Emergent concept detection
- Manumatic update distribution
- Backward button unscalability – (Example: The horror called "video editing")
