I think that the issue here is that you're still thinking of "How will this fit into a directory structure?" or "How does this map to the current paradigm?" I'm suggesting a completely different paradigm that is coming more from the perspective of a database-ish approach (either 100% DB or a mix of DB and filesystem).

What I was getting at is what happens when you get things that don't fit neatly into a database slot. For example, if you have a database that can store photos and text files, what to do with a document that has text and photos in it (like a newspaper article) -- store the text in the text DB and the photos in the photo DB? How does the DB associate the text with the proper photos?

The point being, electronic media is by its nature something that tends to defy whatever categorical schemes we come up with for organizing it, whether they be flat, tree-like, database-oriented, tags, or whatever.

NoSQL document-based rather than relational-based databases could deal with this. I admit that there are caveats to such an approach. From a high-level look at the idea, it seems that all of these things could be ironed out.

For example, you don't need to separate the text and the images of a document. For the most part, you could just 'store a MS Word document in a DB BLOB.' The idea would be that the DB (or some sort of external indexing) is aware of how to parse the MS Word document so that it can be searched insofar as the text is concerned. It might get more complex if you wanted to have the images tagged as well, (thought there may be a way to have the indexes extract tags from the image metadata, or from the original location that the image was imported into the document from).

Remember that the entire purpose of this is just to do a couple of things:

  1. Classify data by type and/or format ('image','PNG','PDF','document')
  2. Provide a way of easily accessing that data.

For specific types of data like Photos, you could have a more specific (optimized?) store. For more general types of information you could have a more generalized store. For information where the content has no practical value as far as indexing goes (e.g. SolidWorks files), you could just have a generic metadata attached to the file information (name,description,tagging).

You could have a 'general docs dialog' that does the generic searching by metadata (document name, type, tags, content if index-able).

Then when you open apps you are displayed with the content right in front of you (ala iPhoto). Rather than an empty window that wants you to open content. For example, you open SolidWorks, and it shows you all of your SolidWorks documents with thumbnailed previews.

There could also be defined 'meta-documents' which are just collections of pointers to other documents. You alluded to this in your post, but you were using the idea in the wrong fashion. If you were creating something like an article with embedded images, that would be a document in it's own right. A 'meta-document' would be a collection of disparate type of multimedia in a 'collection' (e.g. taking a bunch of documents -- pdfs, images, etc -- related to a project and stuffing them in a folder or a zip file). [ Though this would depend on the implementation, b/c they could just be implemented as cross-content tags unless you wanted to be able to attach specific meta-data to the meta-document, but not the individual documents ]

As wonderfully complex as all this seems, it could be presented to the user in a simple fashion. The user would have no idea what a meta-document is. They would just know that the open up their scrap-book program and they can create scrapbooks, for example. The underlying implementation of the scrapbook could be a multi-page document, or a meta-document.

I think you're on the right track, and a 'document' oriented interface is what I think the next step will be, as opposed to Apple's dead-end app-oriented interface. Your meta-document is similar to something I have been envisioning... the current way things work is that you can either:

a) put some photos in a folder, and to view one you open it which launches the default application to view it.

b) open up your photo application, which either knows where the photos are, or asks you to point it to where the photos are.

I think the future is where the folder becomes the 'application' by the mere act of putting a bunch of photos in it. But it wouldn't be an application in the current sense, but rather a collection of separate and customizable ways of interacting with photos. The average user might just want some buttons to print photos or email them to friends, but for a web designer you could extend the meta-document by adding commands to resize images, change formats, crop, etc -- not by buying something massive like photoshop, but simply by downloading (or creating) mini-extensions that do exactly what you need to do.

So yeah, the way I see it, we'll move away from some shell which organizes files and applications that interact with the files, towards a system where the 'shell' itself evolves into whatever 'application' you need it to be.

Huh? I want to group related things together so I can easily do things like show/give someone all related things, regardless of their datatype.

Grouping by datatype isn't "database-ish" unless you think that data type is the only interesting relation, and it isn't. In fact, it's one of the least interesting relationships.