Main Area and Open Discussion > General Software Discussion

IDEA: Visual FileSystem

<< < (3/5) > >>

Perry Mowbray:
Actually Oshyan, I think the "real world" examples is what is breaking down in our digital environment. What did we use to catalogue before computers? Card Files and cross references?? Isn't that where GMail has freed people from having to put emails into folders??

I think that the underlying data is the very crux here. What we need is a database that holds the definitions and links between the filesystem objects. how that is used is upto the developers.

Document management systems vary a llittle, but generally what they are doing is adding keywords, tags, labels and indexes to files, and give a way to find things again (hopefully).

I guess what I was originally getting at is that on my computer the method of categorising my files is limited (by the file structure I guess) and I thought that a slightly more fuzzy way of getting at the files (including grouping and actions) would be helpful.

You know I have graphic files in my Photos folder, in my graphics folder, in my HTML folder, etc. Picasa (and others I guess) give me a nifty timeline, but there is a whole lot of other data there in those photos and jpgs that could be used. Other file formats also support information about the file, as does the filesystem. Being able to group or display by author, subject or any of the other metadata would be helpful... wouldn't it??

- Perry

JavaJones:
Absolutely. That's what I was getting at with the "database driven file system" - essentially universal, comprehensive meta data that is accessible in *every* file and maintained at the OS/file system level. Any program could read or write it, the file manager could do the same, and thus you could sort on any tag, field, or other piece of info in the meta data. You could search on it too, or use it in a more specialized app to organize. Mass tagging, etc. would be possible as well. Bottom line is I agree that more "fuzzy" methods are necessary and I think the only real way to do that *properly* is with a database-driven file system. The current approach is basically to bring *some* of this functionality to *some* file types, and usually only relevant and viewable when accessed through specific applications. Think of how many programs use the Windows GUI libraries, or DirectX. Now imagine if there was a similar set of hooks and data exchange components and whatnot that dealt with universal meta-data. It would be trivial for any application to support and deal with and be enhanced by such data. It's up to Microsoft to take the lead on this unfortunately and all indications are they dropped the ball with WinFS. :(

- Oshyan

Perry Mowbray:
It's up to Microsoft to take the lead on this unfortunately and all indications are they dropped the ball with WinFS. :(
-JavaJones (August 07, 2006, 01:12 AM)
--- End quote ---

I think this is where there is a real opportunity! All that we have to do is a proof of concept and get a significant ground swell for the idea and MS will buy the idea and incorporate it into the OS  ;)

Borrowing from another thread (bloat)... is it possible to implement the DB part of the file system outside of the filesystem with push and pull functionality. I'm assuming that the best functionality is when it is part of the FS because the data collection is controlled by the FS, but it could be collected by pulling the data (which is how cataloguers do it now I guess)?? So that would mean functionality could be provided for programmes to hook into so that they could push their data into the database, but because initially (and because not all programmes would add that functionality anyway) the same methods could be used to pull data into the database??

What's the best storage format? XML?

- Perry

JavaJones:
Yes, that's correct, it could be implemented in for example one of the current hard drive indexing tools (Locate, Google Desktop, etc.). It's really a matter of determining the best approach to this, considering all the existing meta data solutions (id3 tags, IPTC, EXIF, etc.), and then implementing it. The trade-offs between a centralized database accessed by all apps and separate files or actual embedded data need to be weighed. I would tend to favor a database approach with some export functionality. That way you don't need to always keep pairs of files together (file and meta data) and you don't need to get everyone to change the underlying format to include the meta data format, you just need to get people to support your DB. That's still a hard problem but if you make it indespensible and universal it will be supported. I think the way to do that is first to make it totally free, if not open source, then to have capability to import and index all existing meta data and translate back and forth between the (more expansive) DB-based meta data and whatever embedded meta data a given file/format might allow (mp3 with id3, etc.). This way people can leverage their existing tagging and meta data. You would also want to have importers, if not full exchange systems, for all the popular apps out there like Picasa, iPhoto, etc. Basically if you make it virtually effortless for people to incorporate it into their existing systems and at the same time offer significantly more functionality then it will have a high adoption rate.

I think you would need the following to really make it work and make people love it:
Excellent import/export support
A good plugin/hook system so that other apps can work with it, both reading and writing meta data and other info
A really fast, easy way to edit any meta data, transfer meta data around seamlessly, mass edit, etc.
A built-in "explorer" replacement that incorporated all the meta data, search functions, etc. - better yet an actual explorer replacement/addon that allowed this seamlessly in a familiar UI
A really fast database engine and low resource use

I think it's quite possible to do this with an application working above the file system, using its own DB. I'm frankly surprised no one has done it yet. But I imagine there's a lot of overhead, which is why the file system approach may be needed. For now a proof of concept based around an existing open source HD indexing system would do just fine.

I only wish I was a decent programmer...

- Oshyan

Perry Mowbray:
I only wish I was a decent programmer...
-JavaJones (August 07, 2006, 08:48 PM)
--- End quote ---

Ditto, so who's putting up their hand???

Interesting site:
http://www.seekafile.org/

- Perry

Navigation

[0] Message Index

[#] Next page

[*] Previous page