5 ms·

Err isn’t this a problem remembering your file hierarchy as well? Search is the answer in both scenarios.

mthoms 7y ago
Well no, the point of a file hierarchy is that it should be well, a hierarchy. In other words each level should sub-divide your files into further obvious (whatever that means to you) subcategories.
- RaiseProfits 7y ago
  Sure, but that doesn’t explain how you magically remember where you stored the file. I suppose it does help with making you unable to store files in the root directory and forcing you to store it somewhere with some meaning. This seems like it would just resolve into a documents directory and you’re back where you started with a flat bag of files that you need to organize arbitrarily. Also, you can use hierarchies with tags too, it’s just a matter of interface. Example: click “photos”, and see all the other tags that are associated with photos, and in a separate view all the files with all the previously clicked tags. You can drill down this way. Order top level tags by number of files using it. I have never seen this implemented but it seems like it would be fun. I also imagine “photos” itself would be a special file type metadata tag. EDIT: posted before fleshing out idea, it is fleshed out now.
  - romwell 7y ago
    >I have never seen this implemented Great argument for tags! Sure, it's never been done, but it's possible that someone will re-implement the inherent properties of filesystems with tags in the future, so let's take your filesystem away now!
    - RaiseProfits 7y ago
      Hey I am just describing interfaces, I don’t care about how it hits the disk. Filesystems are certainly nothing to get excited about; links are a dirty hack to get around a forced tree anyway.
- dredmorbius 7y ago
  Very few classification schemes are unambiguously DAGs. We're used to them for use with physical objects, which can only occupy a single space. When the search interface is the representation (as with files or data stores), cross-referencing across categories is readily facilitated, and (in the extremely rare instance of well-designed ontologies), useful. I've created several collections using extensive tagging schemas, and not infrequently run out of tags. I've also been looking at various ontologies suggested over the years, dating to Aristotle, Francis Bacon, Diderot, and more recent (often library or encyclopedia) schemas. Some are useful, none are perfect, all incorporate biases and anacronisms. Another feature of folders (directories), or physical storage locations (for physical items), is that the classification / relation is created automatically by virtue of where an item or file is located. For tagging systems, you've got the additional overhead of specifying (or creating a rules-based tag-generating system) to apply tags to content. Otherwise you end up with a morass of "My Document0012811.docx", "untitled", "unclassified", "misc", etc., content. Cataloguing itself is a role, process, and step, and requires maintenance. Even within library science, the tendency has been to move toward self-describing works, full-text search, and imputed relationships.

Well no, the point of a file hierarchy is that it should be well, a hierarchy. In other words each level should sub-divide your files into further obvious (whatever that means to you) subcategories.

RaiseProfits 7y ago
Sure, but that doesn’t explain how you magically remember where you stored the file. I suppose it does help with making you unable to store files in the root directory and forcing you to store it somewhere with some meaning. This seems like it would just resolve into a documents directory and you’re back where you started with a flat bag of files that you need to organize arbitrarily. Also, you can use hierarchies with tags too, it’s just a matter of interface. Example: click “photos”, and see all the other tags that are associated with photos, and in a separate view all the files with all the previously clicked tags. You can drill down this way. Order top level tags by number of files using it. I have never seen this implemented but it seems like it would be fun. I also imagine “photos” itself would be a special file type metadata tag. EDIT: posted before fleshing out idea, it is fleshed out now.
- romwell 7y ago
  >I have never seen this implemented Great argument for tags! Sure, it's never been done, but it's possible that someone will re-implement the inherent properties of filesystems with tags in the future, so let's take your filesystem away now!
  - RaiseProfits 7y ago
    Hey I am just describing interfaces, I don’t care about how it hits the disk. Filesystems are certainly nothing to get excited about; links are a dirty hack to get around a forced tree anyway.
dredmorbius 7y ago
Very few classification schemes are unambiguously DAGs. We're used to them for use with physical objects, which can only occupy a single space. When the search interface is the representation (as with files or data stores), cross-referencing across categories is readily facilitated, and (in the extremely rare instance of well-designed ontologies), useful. I've created several collections using extensive tagging schemas, and not infrequently run out of tags. I've also been looking at various ontologies suggested over the years, dating to Aristotle, Francis Bacon, Diderot, and more recent (often library or encyclopedia) schemas. Some are useful, none are perfect, all incorporate biases and anacronisms. Another feature of folders (directories), or physical storage locations (for physical items), is that the classification / relation is created automatically by virtue of where an item or file is located. For tagging systems, you've got the additional overhead of specifying (or creating a rules-based tag-generating system) to apply tags to content. Otherwise you end up with a morass of "My Document0012811.docx", "untitled", "unclassified", "misc", etc., content. Cataloguing itself is a role, process, and step, and requires maintenance. Even within library science, the tendency has been to move toward self-describing works, full-text search, and imputed relationships.