3 ms·

> 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 cy

> 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
    Just commenting to note that I'm finding this interesting and provocative. Not necessarily convincing, though I'm thinking my way through questions and concerns. I'll throw one thought out just for grins: why do we bother with documents and records at all, and what is the value in going through old records. (I'm asking far less because I doubt any value, somewhat more because I've been put this question (by someone whose sanity and motives I very much doubt, and for whom no response seems sufficient), and because I think it nudges at some very-frequently unquestioned assumptions and motives about this whole endeavour.) That said, I'll try to return to and respond to your comments more directly.
    - lmilcin 5y ago
      > why do we bother with documents and records at all We bother because from a developers' perspective, if you are interested in interoperability with other software, it is convenient to store information in files that can be passed by name to another piece of software. Nowadays we have a lot of webapps that do not store information in files (the databases behind them use files but this is not important for the user). If you notice, interoperability is pretty bad and has to be developed separately, every single time for every single use case. You can't take your "facebook file" and grep it for the contacts you are interested in or pass it to some other program. You can't make a backup by creating the copy of the file, and so on. But I digress. The issue isn't about files being a problem (I don't think they are). The problem is about organizing them. There simply isn't any good organization idea implemented in practice. People say files are too hard for normal users but what they really mean is that users are lost in a normal filesystem or they are going to be lost after they have created enough files without being super tidy. I would be glad if files themselves vanished completely from the users' view and only stayed there as an intermediate storage layer.
      - dredmorbius 5y ago
        Thanks for that, though I suspect developers aren't the only user-community for documents ;-) If I can paraphrase your statement about files: they solve a technical problem in computer space, but don't reflect how people want to and/or need to access information. I'm reminded somewhat of mainframe DASD storage, which has a few characteristics: - A largely flat directory structure. There can be directory equivalents, but to a limited depth (1 or 3 maximum IIRC, possibly depending on OS release). - Structured files. That is, the concept of a "flat file" or a "binary file" doesn't exist (or is rarely used), rather files are specifically structured, into records (~= lines or rows) and fields (~= individual values), with a record type indicator as the first few bytes of each record. A file could contain (and most often did) multiple different record types, as a hierarchical data file. - Specific programmes to read each file type. (At one point I worked in writing code to read data files, including IBM mainframe files. That was many moons ago and much of the work was not on IBM mainframes themselves, though some was. I've suppressed much of the trauma....) These days we tend to use an RDMBS database structured as rectangular tables with columns and rows (also invented at IBM, and available on mainframes, though not often part of my previous life). Funny thing: SQL was originally pitched as a query language that could be taught to secretaries and administrative staff to directly run queries against databases. Either admin staff were much more brilliant then, or that was an ambitious vision.... Or ... we have various structured data formats that aren't rectangular: XML, JSON, HTML itself, amongst others. These have a structure and can be picked apart, though they're still fairly complex. What I've seen over a career of 30+ years is that the vision of some single universal data format keeps getting pitched ... and keeps not materialising. Because Reasons a specific application has its own needs, and/or the "standard" is so complex that it is never implemented the same way twice. Data interchange always needs to be specifically structured and engineered. For mostly-textual information, which is where I think of tagged systems being most appropriate, the internal structure of documents is ... fairly loose. Metadata + bag of bits, mostly ASCII / Unicode. But that still leaves us with the problem of sorting out what's where and how to access it. I'd argue that most present filesystems are inadequate to the task of and by themselves, though they might be extended. An interesting and fairly simple example is the maildir format for storing email. It lives on a standard filesystem, and its naming convention is opaque (email message IDs). The file structure itself, based off RFC 822/2822, includes a set of defined and structured fields (headers) providing metadata. A special access program, a mail reader, provides access to the mailbox(es), though other tools can provide more programmatic process. Principle organisation is by data, though other metadata aspects can be used. As a rough proxy of what a document store might look like ... this isn't a completely bad start, and it might offer guidance to how a more generalised document-oriented filesystem might be structured.

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
  Just commenting to note that I'm finding this interesting and provocative. Not necessarily convincing, though I'm thinking my way through questions and concerns. I'll throw one thought out just for grins: why do we bother with documents and records at all, and what is the value in going through old records. (I'm asking far less because I doubt any value, somewhat more because I've been put this question (by someone whose sanity and motives I very much doubt, and for whom no response seems sufficient), and because I think it nudges at some very-frequently unquestioned assumptions and motives about this whole endeavour.) That said, I'll try to return to and respond to your comments more directly.
  - lmilcin 5y ago
    > why do we bother with documents and records at all We bother because from a developers' perspective, if you are interested in interoperability with other software, it is convenient to store information in files that can be passed by name to another piece of software. Nowadays we have a lot of webapps that do not store information in files (the databases behind them use files but this is not important for the user). If you notice, interoperability is pretty bad and has to be developed separately, every single time for every single use case. You can't take your "facebook file" and grep it for the contacts you are interested in or pass it to some other program. You can't make a backup by creating the copy of the file, and so on. But I digress. The issue isn't about files being a problem (I don't think they are). The problem is about organizing them. There simply isn't any good organization idea implemented in practice. People say files are too hard for normal users but what they really mean is that users are lost in a normal filesystem or they are going to be lost after they have created enough files without being super tidy. I would be glad if files themselves vanished completely from the users' view and only stayed there as an intermediate storage layer.
    - dredmorbius 5y ago
      Thanks for that, though I suspect developers aren't the only user-community for documents ;-) If I can paraphrase your statement about files: they solve a technical problem in computer space, but don't reflect how people want to and/or need to access information. I'm reminded somewhat of mainframe DASD storage, which has a few characteristics: - A largely flat directory structure. There can be directory equivalents, but to a limited depth (1 or 3 maximum IIRC, possibly depending on OS release). - Structured files. That is, the concept of a "flat file" or a "binary file" doesn't exist (or is rarely used), rather files are specifically structured, into records (~= lines or rows) and fields (~= individual values), with a record type indicator as the first few bytes of each record. A file could contain (and most often did) multiple different record types, as a hierarchical data file. - Specific programmes to read each file type. (At one point I worked in writing code to read data files, including IBM mainframe files. That was many moons ago and much of the work was not on IBM mainframes themselves, though some was. I've suppressed much of the trauma....) These days we tend to use an RDMBS database structured as rectangular tables with columns and rows (also invented at IBM, and available on mainframes, though not often part of my previous life). Funny thing: SQL was originally pitched as a query language that could be taught to secretaries and administrative staff to directly run queries against databases. Either admin staff were much more brilliant then, or that was an ambitious vision.... Or ... we have various structured data formats that aren't rectangular: XML, JSON, HTML itself, amongst others. These have a structure and can be picked apart, though they're still fairly complex. What I've seen over a career of 30+ years is that the vision of some single universal data format keeps getting pitched ... and keeps not materialising. Because Reasons a specific application has its own needs, and/or the "standard" is so complex that it is never implemented the same way twice. Data interchange always needs to be specifically structured and engineered. For mostly-textual information, which is where I think of tagged systems being most appropriate, the internal structure of documents is ... fairly loose. Metadata + bag of bits, mostly ASCII / Unicode. But that still leaves us with the problem of sorting out what's where and how to access it. I'd argue that most present filesystems are inadequate to the task of and by themselves, though they might be extended. An interesting and fairly simple example is the maildir format for storing email. It lives on a standard filesystem, and its naming convention is opaque (email message IDs). The file structure itself, based off RFC 822/2822, includes a set of defined and structured fields (headers) providing metadata. A special access program, a mail reader, provides access to the mailbox(es), though other tools can provide more programmatic process. Principle organisation is by data, though other metadata aspects can be used. As a rough proxy of what a document store might look like ... this isn't a completely bad start, and it might offer guidance to how a more generalised document-oriented filesystem might be structured.