Hello Mike, interesting points you bring up. I don't object in general, as said there is no right or wrong here, just opinions. But I would like to reply to a few specific passages of your reply:
On Monday 23 March 2015 12:19:13 you wrote: > * how useful meta-tagging would be for most people? Some file formats > can embed metadata; if you're going to create it, it's nice to embed > it in the doc, but you'd have to duplicate it in an external DB to > support other file formats... complicated & a redundant duplication > of effort. Not at all. Meta data does not belong in a document. Most formats are unable to store such data anyway. The location of a file in a traditional file system is also not stored in the file itself. That makes no sense. Meta data is part of the storage layer because it describes how the document can be found. Therefore it belongs into the file system. Current file systems are more or less unable to do that, this is the reason why most people have problems following that idea. Indeed that is means (much) data and a more complex handling process. But is volume and complexity a problem for a computer system these days? Certainly not. Human time when interacting with a computer is. > [I used to work for the Department of Redundancy Department...] Em... sounds like a great job... :-) > But mainly, I just think most people won't take the > time/effort to maintain meta data... and of course tag > interpretation can change over time as much as directory hierarchies. Which basically says there is no disadvantage then compared to traditional file systems, since you can use the proposed system in exactly the same primitive way as a traditional file system allow today. But I disagree about the interpretation aspect: if you read my suggestion you will see that I wrote about using a synchronized hierarchy that is based on an ontology. The interpretation of relationships defined in such a catalog does not really change. > * filename parsing to automate metadata.... I use a file format that's > basically "Who_What_When"... those 3 separated by underscores. So > very often I could pick the date off the filename as everything > after the last "_". And what do you do if you are not looking for a data range, but looking for pictures you got from Gwendolyn that were taken in Africa? Near the coast? Your file hierarchy is completely useless for that. That maybe you can filter your file system by brute force and, after a huge effort, come up with some set is not the point. I only want to show with that example, that such a fixed scheme is obviously easy to use and powerful for specific and repetitive applications. But it completely fails per definition for anything that somehow leaves that beaten track. It is kind of one dimensional. Extremely limited. Another aspect: what do you do if you want to mix two collections of objects that are stored the way you prefer, in a strict naming pattern based structure but where that structure differs between both collections? You can't without expensive and lossy conversion. Without conversion you create chaos, I have learned that the hard way... An ontology not only allows that (one of the reasons why I started playing with it), it even removes limitations of current, flat tagging systems: synonym blindness and language barrier. Merging a collection of tracks played on a viola will be treated equally with those played on a Bratsche (German) or a "Alto" (French). It is the same information for the proposed system. Because the identity of the meaning of those tags is known to the ontology. I expect that tagging will be THE means of search in future. It will mostly replace brute force search because that becomes more and more inefficient, although we can search faster and faster. A question of complexity dimensions and math. And classical file systems the way we use today will become more and more tedious to use in further as we leave behind the "one computer per person relation". Christian Reiner (arkascha) _______________________________________________ User mailing list [email protected] http://mailman.owncloud.org/mailman/listinfo/user
