|
Description
Database-oriented filesystems is the future of file storage & management. These are filesystems, that use tags instead of (or in addition to) hierarchical directory structure.
This is more flexible and rather more natural way of storage and managing documents in the digital environment.
It moves away from obsolete imitation of paperwork and opens great powers of digital environment, that was still covered by society thinking inertia.
It it does not treat digital documents as material objects. It does not accent on document's place, but accents on the document itself, giving user the ways of control documents without unnecessary intermediaries.
Example of flexibility: you have some multimedia file, for example video, that contains music track. In classical fs you need to choose between your music & video folders, or make links. In datsbase fs you just tag it with both, add titles... in result, dualistic nature of that file is no more a problem, but fully reflected in filesystem.
...or if you want quickly browse photos & videos, along with texts, made between 1st July and 2nd August, related to your vacation, but in Rome, not Paris, and about night parties?
And every file with its metadata is portable!
Some you-know-which commercial OSs working in this direction with their "WinFS" & "Spotlight"...
We have a chance to win the race!
dbfs is now in development...
*And it already has a KDE interface!*
So it would be great if Ubuntu support it & help with development!
Further info & "kdbfs" interface is here:
http://tech.inhelsinki.nl/dbfs/
Screenshot:
http://tech.inhelsinki.nl/dbfs/kdbfs.png
Tags:
(none)
Attachments
No attachments.
Duplicates
Comments
|
Psycho_zs wrote on the 6 May 08 at 20:29
| |
Oops... moderators, would you correct misprint in the title, please!
|
|
Manas_ubu wrote on the 6 May 08 at 21:04
| |
Hail 2 DOF!
|
|
steve196 wrote on the 6 May 08 at 22:00
| |
Your text doesn't show me a concrete advantage of this over classical filesystems yet.
|
|
Mojo wrote on the 7 May 08 at 01:25
|
I think that both paradigms are usefull... you are basically talking about organisation by place versus organisation by description or content, right?
Oh man this is hard to type on... I get white text on a light grey comment box.... Good thing I can touch type. Anyway, I digress...
For the notion of finding things by meta-data, or context, or content, how ever you approach it... Isn't this what Beagle and the like are intended to do?
For a user, how would the experience of using Nautilus or some other file browser in a "dbfs" mode be any different than Desktop Search tools like Beagle?
How do you do file management on such a system? How do you discover files in your "filesystem" if you don't know about their tags, or whatever? At lest in a place-oriented hierarchy you can see what's there and spot things that are out of place, if you look around. Also, how do you manage and deal with the physical back end (storage media like disk partitions, usb disks, network shares, etc.)??? How do you easily control which content is stored where, and move it around when needed? A dbfs sounds to me more like a big pool with no clear boundaries.
I am not arguing against the idea of being able to organize and locate data based on tags and what not... I think it can be a god-send and I am interested to see advancement in that area. But placement has it's place too. I will offer that there are good reasons I have already found to be able to have multiple views on the same set. Managing a large library of music files, for instance. The hierarchy-based system does limit you to your initial organisational choices.
For instance, I have music by artist/album/track but sometimes i would like a view organized by file type, such as flac vs. ogg or mp3. Or at least a way to separate them out. I have recently discovered unionfs which is very powerful, and am thinking of trying to figure out how to use it so that I mantain a union tree /artist/album/track with all the music files, made from separate trees such as /mp3/artist/album/track, /ogg/artist/album/track, and /flac/artist/album/track. Not having investigated enough, though, I am not sure if I have to manually put the files in the sub-trees by hand according to type, or if unionfs could automatically put files of certain types in the proper sub-tree.
Could dbfs offer me a query-based directory result, showing me a virtual /artist/album/all-tracks or /artist/album/mp3-tracks? Or would I only get non-hierarchical results like /all-mp3-tracks or /all-gratefuldead-flac-tracks? The flat query results would be very helpful in many cases, but hierarchical systems have their place because many things are quite naturally organized like that. And it just helps to be able to approach collections in a standard organization. The biggest draw back is of course when some things could benefit from multiple views.
Also, how does a dbfs deal with different versions or copies of basically the same content? If all the meta-tags are the same, and the content basically is the same, how does it differentiate or present them to you so that you can choose which version?
Well enough brain dump from me. I am intrigued but curious as to how it will all play out in day to day use. For the most part, I see it as the same ideas that Beagle et al put forward. I don't know exacly how those programs work. I am sure they keep a central index of the context data so it can be searched and presented; but I am unsure if extra "tags" are stored with the files (and travel with them), or if the tags and other meta-data are physically separated from the files they point too. I like the idea that the central index is there for lookup speed but that the actual tags stay with the files that they belong to, so that the index could always be rebuilt from the files or follow them as they are moved/copied to other sytems. This seems to me to get into the realm of resource-forks like Macs used to do. I think some filesystems do have similar facilities for attaching metadata to the file entries. But I have not read up on this before posting here
//end of line//
|
|
nivus wrote on the 7 May 08 at 08:32
| |
Maybe, there is sense to look at OpenBeFS?
|
|
kthijskeb wrote on the 7 May 08 at 12:03
| |
I don't see any advantage in this approach. Easier would be to just have the ability to tag all files and search the tags. Basically that's just what this does, but I think it would be better to use this idea as an extra not as a filesystem.
|
|
Psycho_zs wrote on the 8 May 08 at 05:52
|
files with their metadata tags should be portable together, as easy as just one file.
Metadata of specific filetypes (id3, exif, etc) lacks universality, but is a good source of information to fill in on some universal filetype-independent metadata container, like database- or facet-based filesystem.
Generally, every such open filesystem should be taken into consideration.
|
|
Endolith wrote on the 15 Oct 08 at 05:02
| |
I want tags to be available and accessible by every program. If this requires DBFS then I support this, but I am not sure that is required.
|
Post your comment
|
