Spotlight can do the same thing, no ?
https://en.wikipedia.org/wiki/Spotlight_%28software%29
TMSU: a tool born out of frustration with the hierarchical nature of filesystems
71–80 of 131 posts
Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems
#72Earlier quoted context omitted.
Big proofs. Conceptual categorization is a big part of how we humans comprehend and analyze the world around us, and it relies on a hierarchy of defining attributes, from abstract model to concrete specimen: https://en.wikipedia.org/wiki/Prototype_theory#Basic_level_c... https://en.wikipedia.org/wiki/Stereotype#Cognitive_functions https://en.wikipedia.org/wiki/Concept_learning Maybe less abstract: if you try to remem…
I actually wnt to believe you because it accords with my own intuition but I don't trust my intuition on this! Conceptual categorisation + language + ? is totally how we humans comprehend and analyze the world around us, granted. (The devil is in the details of course.) But I don't see how we can go from there to "it relies on a hierarchy of defining attributes" I don't buy your example because the concepts in our he…
Glad to be of (some) help :)
I'm not a developmental psychologist btw, just have an interest in cognitive development. The proof you're looking for would be more the field of cognitive neuroscience.
There definitely are graph-like connections between concepts all over the brain, I didn't mean to suggest that our brains work hierarchical only, to the exclusion of all other relations. As an example: if our brains were strictly hierarchical, we would be unable to see the similarity in colour between a grey table and a grey hare. I just meant to explain my thinking on how abstract thought is tied to a attribute/property hierarchy, not proclaim that I know how the brain works.
(edit: snipped on-topic content, best reserved for a separate post)
Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems
#73I'm actually not frustrated with the hierarchical nature of filesystems. I'm most frustrated with the state of filesystem search these days. I don't want to tag and curate my files. I want to search them. I've strung together something using bleve full-text search and some OCR libs to scratch my particular itch but it still doesn't quite get all there.
I'm not a big fan of semantic search itself, nor do I enjoy meticulously tagging my files. But I would love to have different views of my files, based on different metadata.
I know that I'm not always searching for files along the same hierarchy: sometimes I want to search along a timeline, because I know that I edited two files around the same time. Or I remember where I was when I wrote something, and I'd like to search on geolocation. Sometimes I know that I've implemented a similar feature for a different project, and want to copy/review what I did then.
All these searches still have hierarchical components in them: in the "date" case, I would expect to browse to a generic "N weeks ago" directory, look at a few specific items to get my bearings, and start browsing deeper to narrow my date range, or move forward or backward in time. In the geolocation case, I'd want to pull up a map, click on a country, then a city or area, and look at the files I accessed while there. As for the project example, I probably have the project files lying around in a hierarchical directory already. But I'd want to access only the relevant feature file, not browse the entire project structure again.
For me, the problem with non-hierarchic interfaces isn't just the lack of metadata: it's a lack of tools for visualizing non-hierarchic matches. Every search I described above requires its own GUI...
Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems
#74Earlier quoted context omitted.
You have to realize though that this software doesn't take away your heiracichal system, it just gives you another way to look at it. Recently I've been cleaning up my music library and I'm seeing some of the shortcomings of the current system. What do you do with a compilation album? Have a folder for each artist or put them all together, (Which would separate them from others works by the same artist)? iTunes or wh…
That iTunes view is still a hierarchy, though. More accurately, it's still a DAG. The hierarchy is not the problem here, it's the rigidity of trying to put something in only one part of that hierarchy.
Spot on, for file system now it should not be a problem to have links in different places in hierarchy. You can have "favoriteSong.mp3" in catalogue with artist name and use links to put it in catalogue with "ultimate super songs". But I think people are not aware of possibilities.
Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems
#75Very cool attack on the problem.
I've been working on ideas for managing filesystems and tools for thought for a while off and on, it's starting to coalesce into a set of design ideas as well as prototypes.
What I won't do is set up a filesystem: I don't think that adds value to me; it mostly sounds technically complex and hard to figure out. And, I think that driving the whole business through manual tagging is a lost cause. Manual tagging can be _useful_, but actual attempts to derive semantic knowledge will be _more_ useful. I have many thousands of documents - manual tagging ain't gonna happen.
I need _semantic_ search and _semantic_ cross-referencing; something like a Xanadu or a (much better) wiki/hypertext system.
Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems
#76I could see where a tool like this would be a huge help to legal and compliance departments.
There is a frequent need to produce documents for discovery purposes. However, you generally have to review the documents or send the to outside counsel first for review before they are produced. This can take hundreds of man hours and cost thousands of dollars.
Building something on top of TMSU could be a great solution for this task.
Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems
#77Earlier quoted context omitted.
"It's backed by a powerful Artificial Intelligence." Ahhhhhhh! You're tackling a laudable goal, but it would help to link to a page with more technical details.
Haha, I don't want to go too much off topic of this thread, but essentially we can analyze actual file contents, source and metadata to find patterns between file structures and associate them to user and "common" labels. On top of that we try to get further accuracy by using user information to help us find the context. We call it a Personal System, a repo of knowledge and learned preferences heavily tailored around…
I put my email down to spy on you:)
My personal feeling is that (A) you're totally right that we need better _personal_ organization systems, but (B) the bottom layer (tagging, schemaing, relationships) should not involve fuzzy processes but should be totally understandable by the average user.
I know (B) is a weird opinion though so I look forward to seeing how far you can get with (A) plus machine learning & whatever other tricks you guys plan:)
Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems
#78The reason hierarchical structures are used in file systems is because they are a pretty intuitive and, most importantly, generic way of classifying and storing information. For the most part, just about any file you have on your computer can be stuffed into some sort of folder structure.
Specialized files like music, movies and images are a solved problem. iTunes and other software do a great job at organizing this information and making it easy to use. There's also software like Quicken for dealing with the other common mountain of data people have.
What might be useful is a piece of software that is capable of extracting and managing metadata automatically. Think of a tool like iTunes that you feed it a collection of files and it uses some form of ML to extract and create a database build logical ontologies for this data. The big problem with this kind of tool is finding a large, complex dataset that an individual has, but that has not been organized by a specialized piece of software. I doubt these exists in numbers significant enough to justify creating a project.
tl;dr: Directory structures are low-effort, generic, and discoverable ways of dealing with files that are not managed by other applications. It will be hard to improve on them without sacrificing one of those three attributes.
Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems
#79Earlier quoted context omitted.
Tags are a subset of hierarchies + symlinks. If you have a one level hierarchy, you have the equivalent of tags.
I'd argue that tags provide a more graph-like structure, of which a hierarchy (tree)[1] is just a subset. Symlinks provide an "escape-hatch" to hierarchical systems allowing objects to appear to be in more than one directory. [1] https://en.wikipedia.org/wiki/Tree_(graph_theory)
How so? Unless you can tag tags, you can't represent a tree with them. If you can tag tags, you get an arbitrary graph, with all the problems that represents.
I don't think I've seen tagging systems that let me tag tags out in the wild.
Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems
#80Earlier quoted context omitted.
You have to realize though that this software doesn't take away your heiracichal system, it just gives you another way to look at it. Recently I've been cleaning up my music library and I'm seeing some of the shortcomings of the current system. What do you do with a compilation album? Have a folder for each artist or put them all together, (Which would separate them from others works by the same artist)? iTunes or wh…
That iTunes view is still a hierarchy, though. More accurately, it's still a DAG. The hierarchy is not the problem here, it's the rigidity of trying to put something in only one part of that hierarchy.
It's multiple, interwoven hierarchies, which you can look at by "seeing" a particular DAG (a subset of the actual graph).
You can see this twin representation conceptually as Artist->Album->Song and also as Compilation->Artist->Song, the latter being a small folder with symlinks to the actual song directly.
It's really just two different trees.