18. Re "dot entries": I not only have such entries for the more specific files "pp" in "p", but also for any external files that I need again and again, in such a context, i.e. a .pdf with reference data, an Excel table with important data, etc.
I.e., I not only have all those external files within my p/pp sub-folders, but external files to which I need regular access, are referenced in these first / "p" level .ao files, my macro checking for the leading dot, then for the very first possible space, as said, and all the rest is the file name and the suffix, so the same macro will process every possible file I put into my "p" level .ao files.
I also could do "real" links, since AO offers those, as does almost any outliner, but I don't see any sense in doing so since my "preceding dot" encoding is exportable and re-importable from and to any such IMS, whilst those "links" any such outliner offers, would not be that easily exportable / importable into any other such system of my possible ulterior choice. Thus, individual coding of things is transferrable to competing sw in case, whilst in-built functionality is possibly not. And on top of this, as detailed above, my system allows for (permanent or just temporary, "To-Do"-) comments, whilst almost any inbuilt reference system only allows for the strict filename in question.
19. There is another aspect of my putting particular files (only) into my main system (= the AO system): I only put such "links" into that very first level, the "working / overview" level, of my system, i.e. NOT into the detailed files: in the "c" file yes, into the "ci" or the "cf" file, no! As said before, my about 10 such first-level files are always open, always readily available, whilst most particular .ao files are only loaded when needed. So, in order to prevent chaos or problems or just too much fuss, I simply refrain from referencing external files from particular, "detail" files, and whenever I rename such an external file, or even move it, I simply check within the according "c" file (which is open anyway and can be checked immediately, and this could even be automatted), instead of running my external search tools in order to know if perhaps I had referenced this external file in some of my remote detail files I don't remember of.
I know that for your global UR system, these considerations don't apply in theory, because of your internal, global, indexed UR search, but in practice, when using UR last year, I often had "words" and such that weren't indexed by UR, so I doubt that an expression as ".pp123.xml" would correctly be indexed within UR - but perhaps that's possible with some tweaking. If this is the case, you don't need to refrain from referencing external files even from the depths of your system, of course, but again, an IMS where you wouldn't have perfect order - as described above - within your file system, too, but in which you'd rely solely on your external file entries within your big UR file, doesn't seem easily manageable to me, so the above-mentioned system of synchronicity down to level 2 (but not beneath) between UR and your file system seems preferable to me, even when in theory, you could entirely rely upon your entries within UR - but are you really, really sure you immediately update these entries in UR EVERY time you add any new external file to your folder structure, and that you update them EVERY time you move or rename (let alone delete, sometimes) any such external file?
Thus, my system of synching the file structure down to a level, but then relying ON that file structure, for external files, instead of relying on entries in UR (that may be present or not, up-to-date or not), seems much more reliable - and for any external file you need again and again, just reference it into your UR structure, on top of that (and perhaps encode the file name, what about "filename,.suffix" or such, for such entries, in order to know you must update them whenever you "touch" these files within your folder structure). Remember, it's all about the ONE-KEY access, by macro, from any UR ".c" or ".ci" entry, to the corresponding folder: As soon as you get such one-key access, you'll HAVE those at your fingertips, so there is no need, for access considerations, for doubling any such individual external files within UR - except, perhaps, for searching, which is another aspect here and in which UR excels.
Of course, this is a "philosophical" question, as is, "do you really want another web browser, WITHIN your main system?" Again, as soon as you use two screens, you answer would tend to be NO, I presume... And as for searching, do you really want hits from external files like .pdf's interwoven with your internal hits, from UR? My system MUST rely on external search tools, so my judgment is biased, but I suppose that if I ever come back to UR, I would continue to search external files by external tools altogether... supposing is not taking the oath, though.
|