Files, Metadata, and Transportable Keywords.
The following is a crackpot rambling, continue if you dare
It would be these keywords mean this idea to this person. "This Text File has this meta data, and one of them is the keywords. But each set of keywords is tied to a certain user," thus, the user has to registered, each user registers with a database, allowing people to download and exchange files, attach their own keywords which are more meaningful to them.
The whole idea is boiling down to say, a group project. I create a graphic for the project. I save it, while choosing the option to attach keywords.
When someone is searching for files, a giant list comes up, and if they have not added their own keyword preference to the item, the file will come up, with my name next to it. Saying the only reason that the file is there is because it is searching for files with keywords from all users.
What this means? So what? Finding files, exchanging files, making things that are more meaningful to a person. No more folders. So, keywords that are attached to each user. Because, what I might consider interesting is totally different from what another person is.
So, back to the group project. Let's say I am working with three other people on paper about the environmental impact that urban development has had on the potomac river. I have created some really nice looking and informative tables and charts (they are in SVG or PDF format, allowing for the text inside the images to be read easily), and I send them to my group members over e-mail. They receive the files, download and save them onto their disks, and are going to open them.
Now, opening them, they don't know where they are saved, and they are only sure of one thing: Saved Keywords that they subscribe to. Because we are all working in a group, I decided to make an online database of keywords that we would all use to associate with our work. Their machines check for updates to their Subscribed keywords when they receive a new file with unknown keywords, AND their machines will check the subscription that is associated with the keyword group. This allows for them to search not only by keywords but by keyword creator.
So, I created a keyword group named "Potomac River Enviro Impact." This is just as if I created a new user whose name was PREI. They have a search list that updates automatically, with the criteria of listing all files of the keyword creator "Potomac River Enviro Impact." So, they find the newly downloaded file, and open it, easy as that. If they were to further refine the search, they would find that not only was the kind of file was a graphic, but that the type of file was a chart.
The whole problem with this, however, it attaching the keywords, it need to be simpler to attach keywords with minimal user input. So, when the user saves the file, gives it a Name (human readable, because we no longer need short indecipherable file names, the UI decodes the metadata Name and displays it instead of the six character jumble of constants.), it also gives it a parent. The parent can be "school work," or "Potomac river project." This is a lot like current folder hierarchy, but without the hierarchy. All the files lie flat, and can be grouped upon command.
If I am looking for all my school work done in the past week, it is very simple. I type "school work past week," and the meta data of Parent (school work) and last modified (past week) help my search. But, let's say that I saved the file with a parent of "Potomac river project," no problem. "school work past week," will turn up items in "Potomac river project" because "Potomac river project" was called a child of "school work." So simple, children can be parents, and parents can be children. A very nice descendant chain of file control, each getting more precise. When saving my chart, I typed "Potomac river project" as a parent, and it asked if this parent of the file was a child of any of my current groups. I get to choose, or type, from a list of parents, going down hierarchal.
The problem with this comes when transporting the file. This is where the transportable keywords come in. The file will come up on another computer, with my unique ID (translated into a human readable name) so the user sees that he is not the creator, and why the file came up in a search. The file would carry meta-data such as creator, and the creator would carry a (virtual) location tag. Persons, groups, and institutions could register for creator unique IDs, local social security tags to make shure people don't try to create files saying that their did it themselves (maybe there is a national database of online unique IDs already)
So, the file can also have multiple parents, and each parents can be descended from another parent. All my "school work" stuff is in "work" which has two children: "school work" and "job work." But "work" is not a descendant of any other ancestry. This makes it easy to associate a file to a larger group with just associating to a more precise group. If "Potomac river project" is under "environmental studies" which is under "college courses" which is under "school work," making my chart a child of "Potomac river project" gives it a long line of ancestry to be associated with.
Imagine a bunch of children at school playing on a playground. A teacher yells for all the Anderson kids over 10 to come in, their mother wants to talk to tell them how to reach her this afternoon. The anderson kids over 10 are not playing by themselves in a little pen. Maybe one of the Anderson kids is playing kickball, and another is eating some dirt with younger kids. They are playing among all the other kids, but when the teacher yells out for them, they perk up and come running.
Apply this idea to files, and you have a great file system. Each file knows certain information about itself that makes it easy to search for it. Making each file aware of itself makes the filesystem that much more efficient of finding a file.