5 ms·

What do you do when files contain other files in a different 'standard'?

by Qz 16y ago

pyre 16y ago
Huh? I was talking about things like having a 'images' or 'photos' store where all photos can live. If you want to create a program that uses the photos, there can be a standard 'photo search' dialog rather than a 'file' dialog. This way all programs can access this store, and we can have dialogs that are tailored to the type of data that is being presented to the user. We could even make it possible for the user to search content if you had a 'docs' dialog that encompassed things like PDFs, text files, Word documents, etc. This would make it a lot easier if say, you had a 'project management' app (not in the 'supervisor' usage of the term). Say you were creating a collection of documents for a particular project and you wanted various types of documents like photos, PDFs, etc (maybe you're doing research for something). If you were trying to pull together some of these documents from existing sources (i.e. documents you already have) you could use the lightweight search facilities of a 'docs dialog' to search the content of the PDF that you're looking for rather than trying to put all sorts of context into the filename and/or directory structure.
- anamax 16y ago
  > Huh? I was talking about things like having a 'images' or 'photos' store where all photos can live. A single directory is a disaster as soon as you have a reasonable number of photos. And, if you have subdirectories of photos, you're back where you started, except that you don't know where the "root" of the photo directory is, so you can't use standard file tools to manipulate them. And, where do you put videos? Some people organize their photos and videos together (in part because they came from the same device) while others keep them separate. And if I take notes about my photos, where does that file go? I really want to be able to keep related things together so I can easily provide them to someone else. There are lot of easy answers, but getting one that covers a large fraction of the use cases is hard.
  - pyre 16y ago
    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).
    - Qz 16y ago
      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.
      - pyre 16y ago
        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.

What do you do when files contain other files in a different 'standard'?

by Qz 16y ago

What do you do when files contain other files in a different 'standard'?

pyre 16y ago

Huh? I was talking about things like having a 'images' or 'photos' store where all photos can live. If you want to create a program that uses the photos, there can be a standard 'photo search' dialog rather than a 'file' dialog. This way all programs can access this store, and we can have dialogs that are tailored to the type of data that is being presented to the user. We could even make it possible for the user to search content if you had a 'docs' dialog that encompassed things like PDFs, text files, Word documents, etc. This would make it a lot easier if say, you had a 'project management' app (not in the 'supervisor' usage of the term). Say you were creating a collection of documents for a particular project and you wanted various types of documents like photos, PDFs, etc (maybe you're doing research for something). If you were trying to pull together some of these documents from existing sources (i.e. documents you already have) you could use the lightweight search facilities of a 'docs dialog' to search the content of the PDF that you're looking for rather than trying to put all sorts of context into the filename and/or directory structure.

anamax 16y ago
> Huh? I was talking about things like having a 'images' or 'photos' store where all photos can live. A single directory is a disaster as soon as you have a reasonable number of photos. And, if you have subdirectories of photos, you're back where you started, except that you don't know where the "root" of the photo directory is, so you can't use standard file tools to manipulate them. And, where do you put videos? Some people organize their photos and videos together (in part because they came from the same device) while others keep them separate. And if I take notes about my photos, where does that file go? I really want to be able to keep related things together so I can easily provide them to someone else. There are lot of easy answers, but getting one that covers a large fraction of the use cases is hard.
- pyre 16y ago
  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).
  - Qz 16y ago
    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.
    - pyre 16y ago
      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.