3 ms·

It is not knowledge classification. It is association (like this PDF file is associated with this project). But association can be used for classification (thi

It is not knowledge classification. It is association (like this PDF file is associated with this project). But association can be used for classification (this PDF file is associated also with THAT topic). Which is exactly my point. Hierarchical filesystems can be used for classification (create folders for classes, put things in right folders). But the issue is that the user has to perform classification to even be able to store the file and you can only put the file in one class so if you do that poorly you will have hard time finding it later (a condition which I call disorder). Association lets you overcome that problem by allowing you to associate the item with multiple classes. If your aim is to be able to find it later it is better to put the item in too many classes. A filesystem that only allows you to put the item in one class requires you to make a good decision immediately. Additionally, there is low cost of making a mistake when adding another association but there is comparatively larger cost of changing the classification by putting the file in another folder.

dredmorbius 5y ago
You're using the case of some directed relationships to argue for exclusively directed relationships. That is a false generalisation. Using a directed graph (exclusively) requires that classification assocations be strictly directed. That's simply not the case. It can appear that way in certain instances --- an author writes a book, a book doesn't write an author. But books influence authors, and multiple authors (as contemporaries) can influence one another. Topical classifications may descend through one of several directions: a history of a technology developed in a place by a specific person might have points of entry by date, location, biography, technology, application(s), or consequences. There's no single "home" for that concept, but a web (a non-directed, potentially cyclic) graph with multiple relationships, many bidirectional. That leaves you with a few options: - You can abandon the directed graph and utilise an indexing and search schema which more accurately describes the relationships. - You can abandon strict accuracy and settle on a useful directed graph which imposes an arbitrary (and incorrect) hierarchy over the subject. Where physical storage is based on topicality, the requirement of a single locality imposes this requirement. - You can find an alternate basis for defining location, and conceptually map that by other means. Here a key issue is (as I've described in several earlier comments) that position alone is neither a guide to the content (adjacent documents may be utterly unrelated), the researcher (there is no streightforward exploration path to a specific record or concept), nor the curator (topics must be specifically assigned and aren't inherent or evident by position). In declaring that "it is not about knowledge classification", you've attempted to change the scope of the discussion. Even in the example you give, the case falls apart. A project may be associated with multiple PDFs, and a PDF may be associated with multiple projects. How do you describe that set of relations in a directed graph? Are you assuming your graph is acyclic?
- lmilcin 5y ago
  > Are you assuming your graph is acyclic? No. I made a small PoC and one of the things I tried to learn was if it is possible to basically disallow creating cycles (because they are a headache). I found that preventing cycles completely was irritating to me as a user as it would occasionally prevent me from making a change and require to fix the structure somewhere else before I could do whatever I wanted to accomplish in the first place.
  - dredmorbius 5y ago
    OK, I can agree to that. Now for directed: Is a work an attribute of an author? Or is an author an attribute of a work? Are these seperate relationships? Because it seems to me they're not. Is the work-author relationship inherently directed or not? Because it seems to me you're claiming it is. I ... would disagree. (We could pick other relations, that's a fairly simple, straightforward, and common case.)
    - lmilcin 5y ago
      Let me explain a little bit different way. My first run in with the idea was when I started using Ultra Recall for GTD, many years ago. https://www.kinook.com/UltraRecall/Manual/multilinking.png https://www.kinook.com/UltraRecall/Manual/multilinking.png Ultra Recal is an app for managing personal information that uses SQLite internally to store a tree of objects. Look at Data Explorer. It has various types of nodes, you can define new types of nodes, and there is no restriction on how these nodes can be nested other than they form a tree. I used Ultra Recall for couple of years for my personal workflow. In a normal hierarchical filesystem you have this restriction that files are placed in folders and that's about it. You can have multiple types of files but folders are just bags for files with not much additional data (other than folder name) and you can't have files nested below other files. In Ultra Recall every object regardless of type accepts child objects. I found this to be very powerful, for example, I could have an email but then write a note being a child object of the email. Or I could create an object that was an actual working reminder. Then I could move that email to be nested under some task object and Ultra Recall had facility called "saved search" which allowed you to define a search for example for all projects that don't have next actions under them or all tasks that have deadline within next week. Some other types of nodes are actual files -- you can put a webpage or a document and these become just part of the tree. One problem with this is that when you try to add an object you need to figure out a location. As Ultra Recall is a tree (there is always one parent), when you are adding items you need to decide location (ie. what the parent is) even when this is not strictly meaningful or when there are multiple potential candidates. For example, sometimes you have something you have vague idea you want to preserve but you just don't have time now to decide. Or an item could potentially be useful for multiple projects. But sometimes you can be sloppy with this. For example, Ultra Recall offers full text search so you are free to just dump some of the stuff in a folder and forget. When you need it you just run a search for any part of the document or its properties (tags) and it gets brought up. So I created couple of "dump" folders where I could just throw stuff in (like "read later"). I started writing keywords at the top of documents and I could then more or less ignore when the document was placed if I could not find a good location for it. Deciding where to put stuff is a chore when you create a lot of documents and rely of classification to find them later. But this only solves the case when you have no immediate parent candidate. What if there are multiple parents that you would like to use? For example, the parents are various projects and the child is an email that is related to those multiple projects. I would like to be able to have multiple parents (projects) to which the item (email) is attached. So I was toying with the idea of making a little better Ultra Recall by relaxing the requirement that an item has only a single parent node. In effect, this creates a graph where any item can have multiple incoming relations (children) and multiple outgoing relations (parents).

dredmorbius 5y ago

You're using the case of some directed relationships to argue for exclusively directed relationships. That is a false generalisation. Using a directed graph (exclusively) requires that classification assocations be strictly directed. That's simply not the case. It can appear that way in certain instances --- an author writes a book, a book doesn't write an author. But books influence authors, and multiple authors (as contemporaries) can influence one another. Topical classifications may descend through one of several directions: a history of a technology developed in a place by a specific person might have points of entry by date, location, biography, technology, application(s), or consequences. There's no single "home" for that concept, but a web (a non-directed, potentially cyclic) graph with multiple relationships, many bidirectional. That leaves you with a few options: - You can abandon the directed graph and utilise an indexing and search schema which more accurately describes the relationships. - You can abandon strict accuracy and settle on a useful directed graph which imposes an arbitrary (and incorrect) hierarchy over the subject. Where physical storage is based on topicality, the requirement of a single locality imposes this requirement. - You can find an alternate basis for defining location, and conceptually map that by other means. Here a key issue is (as I've described in several earlier comments) that position alone is neither a guide to the content (adjacent documents may be utterly unrelated), the researcher (there is no streightforward exploration path to a specific record or concept), nor the curator (topics must be specifically assigned and aren't inherent or evident by position). In declaring that "it is not about knowledge classification", you've attempted to change the scope of the discussion. Even in the example you give, the case falls apart. A project may be associated with multiple PDFs, and a PDF may be associated with multiple projects. How do you describe that set of relations in a directed graph? Are you assuming your graph is acyclic?

lmilcin 5y ago
> Are you assuming your graph is acyclic? No. I made a small PoC and one of the things I tried to learn was if it is possible to basically disallow creating cycles (because they are a headache). I found that preventing cycles completely was irritating to me as a user as it would occasionally prevent me from making a change and require to fix the structure somewhere else before I could do whatever I wanted to accomplish in the first place.
- dredmorbius 5y ago
  OK, I can agree to that. Now for directed: Is a work an attribute of an author? Or is an author an attribute of a work? Are these seperate relationships? Because it seems to me they're not. Is the work-author relationship inherently directed or not? Because it seems to me you're claiming it is. I ... would disagree. (We could pick other relations, that's a fairly simple, straightforward, and common case.)
  - lmilcin 5y ago
    Let me explain a little bit different way. My first run in with the idea was when I started using Ultra Recall for GTD, many years ago. https://www.kinook.com/UltraRecall/Manual/multilinking.png https://www.kinook.com/UltraRecall/Manual/multilinking.png Ultra Recal is an app for managing personal information that uses SQLite internally to store a tree of objects. Look at Data Explorer. It has various types of nodes, you can define new types of nodes, and there is no restriction on how these nodes can be nested other than they form a tree. I used Ultra Recall for couple of years for my personal workflow. In a normal hierarchical filesystem you have this restriction that files are placed in folders and that's about it. You can have multiple types of files but folders are just bags for files with not much additional data (other than folder name) and you can't have files nested below other files. In Ultra Recall every object regardless of type accepts child objects. I found this to be very powerful, for example, I could have an email but then write a note being a child object of the email. Or I could create an object that was an actual working reminder. Then I could move that email to be nested under some task object and Ultra Recall had facility called "saved search" which allowed you to define a search for example for all projects that don't have next actions under them or all tasks that have deadline within next week. Some other types of nodes are actual files -- you can put a webpage or a document and these become just part of the tree. One problem with this is that when you try to add an object you need to figure out a location. As Ultra Recall is a tree (there is always one parent), when you are adding items you need to decide location (ie. what the parent is) even when this is not strictly meaningful or when there are multiple potential candidates. For example, sometimes you have something you have vague idea you want to preserve but you just don't have time now to decide. Or an item could potentially be useful for multiple projects. But sometimes you can be sloppy with this. For example, Ultra Recall offers full text search so you are free to just dump some of the stuff in a folder and forget. When you need it you just run a search for any part of the document or its properties (tags) and it gets brought up. So I created couple of "dump" folders where I could just throw stuff in (like "read later"). I started writing keywords at the top of documents and I could then more or less ignore when the document was placed if I could not find a good location for it. Deciding where to put stuff is a chore when you create a lot of documents and rely of classification to find them later. But this only solves the case when you have no immediate parent candidate. What if there are multiple parents that you would like to use? For example, the parents are various projects and the child is an email that is related to those multiple projects. I would like to be able to have multiple parents (projects) to which the item (email) is attached. So I was toying with the idea of making a little better Ultra Recall by relaxing the requirement that an item has only a single parent node. In effect, this creates a graph where any item can have multiple incoming relations (children) and multiple outgoing relations (parents).