 |
 |
 |
|
 |
 |
|
 |
 |
| Firstly an introduction MUSINGS OTHER PEOPLE'S ESSAYS |
16feb1999
metadirk
"Here's one for you Matt - I think you should implement meta-dirk, which would allow comments on links in dirk. -HB" and "meta-dirk enables you to connect meta-dirk nodes to dirk connections. Thus, comment/ criticism of dirk connections is enabled as well as providing dirk with further link semantics and clustering info."
I've been thinking about something similar but wasn't quite sure how to get started. This is definitely a step in the right direction.
The next version of DIRK will therefore allow commentary to be made on links, and expand the abilities of DIRK for filing more forms of information.
If you'd like to know how I came to the conclusion of that simple sentence above, please read the rest of this article. It's long, it's stream of consciousness, but it does put the ideas behind DIRK in some kind of order and puts forward what the next steps should be.
Here are a number of points, in no particular order, about what the next DIRK should do:
Currently the database allows any number of objects to be connected with a single connection. This is a feature that was put in right at the beginning but never implemented in the front-end, to keep things simple. Despite this, there's never been any compelling reason to drop the ability. Indeed, it would seem necessary in some cases (eg the objects CAT, SAT, and MAT would be joined by 'The cat sat on the mat').
But - and here's the thing - if we treat connections and objects in the same way then any greater than three body interaction can be treated as being a combination of only three body ones. In this case the four items about can be joined by any two groups of three items.
There's a mathematical foundation this can be put on, but I'll go into that at another time because it needs some work still.
I know this seems unnecessarily complicated for what is essentially a game, but by putting the back-end of DIRK on a sound basis a more complicated structure can be built up that still makes sense.
Secondly, in any knowledge/information net the most important information contained in not in the objects themselves but what they are connected to. This is important: It isn't the things but the gaps between them.
[note: another way of looking at this is to understand that a chair is only a chair because everything else in the universe is not a chair. If absolutely everything in the universe (including everything that could be imagined) were blue, we wouldn't have the word/concept 'blue'. Differences are important. This has some marvellous consequences, but I won't go in to them right here, right now.]
Illustration - the items of information of a telephone number and a name mean nothing until they are connected together.
Further illustration - DIRK (the program) and DIRK (the Scottish short sword) are two completely different things. They shouldn't be the same node in the database, and their meanings are determined by what they are connected to. The problem is that if DIRK (the program) isn't to assume that two objects are the same just because they share a name, how is it to know? Two possible answers spring to mind:
1 - It guesses, or we have to tell it manually. It looks for second-degree connections, or the user indicates how to make the connection. The 'from' connection is known for definite anyway, why not specify the 'to' object too? Problem being, the interface becomes a lot more complex.
2 - It doesn't know. DIRK maintain a database of 3-body connections. By looking at second/third/etc-degree connections clusters are found and these are organised into the DIRK nodes. Problem? It's incredibly calculation intensive and looking for clusters is very difficult (and slow). Believe me, I've been playing with it recently - although if anyone has any ideas about short-cuts please get in touch.
So this element can be summed up as - nodes should not automatically be assumed to be the same because they share the same word labelling them.
Next... Each node contains a piece of information. Sometimes it is just a word, or perhaps a sentence linking together two other words. In other cases it is a comment or short article and the two objects it links act as its keywords. In all of these cases the piece of information IS the node, and adds weight to the idea that objects and connections are fundamentally the same.
What about if the node, as well as carrying the label that DIRK identifies it by, contains a pointer to the actual information content - this could be just a word or sentence carried in DIRK's internal database, or perhaps a link to another article or somewhere on the web. I'm currently working on something like this as a Links Engine.
DIRK currently does something like this by highlighting http links, but this is just putting the relationship between node and information on a more understandable footing.
Building on the idea of DIRK nodes carrying pointers. Since this elimates the space problem (ie connections currently have to be quite short) entire articles can be placed in the database. Articles that can't be updated would be rather limiting, so entries should be able to be edited (thank you HB). Automatic keywording from article parsing based on the DIRK database would enable automatic linking... but I'm getting ahead of myself this is for the future.
Also for the future: Dynamic links. Why shouldn't objects be able to operate on objects they're connected to through a short script contained in the connection? A short script connected 'time' and 'gmt' could have the label being the current time at GMT, and a pointer to the contained information, ie the script.
Another item: a personal DIRK notebook. What about using DIRK as a knowledge database, having levels and privacy and being able to build your own database? What about storing it on your own computer?
These are all pie-in-the-sky ideas, probably all being rolled in to Windows 2000 anyway (yup), doable with other products, etc etc, but who cares? The point is, what can be done at the moment?
The next version of DIRK will treat connections as objects, so that commentary can be made directly about links. Obviously the interface will have to be juggled a little to allow this. Here's a thing: commentary about a link to the object 'DOG' and 'CAT' could be linked to the above mentioned 'dog-cat link' and 'COMMENTARY ABOUT DOG-CAT LINK'. The object 'COMMENTARY etc' could be linked to both 'DOG' and 'CAT' with the reasoning 'commentary about the links etc is contained in here'. Thoughts?
The next version of DIRK should also allow much larger links and commentaries - article length in fact - and an alternative front end that allows you to pick out just the articles. How to present these articles... pop-up windows anyone?
This article, though, is far too long and far too muddling. Editing and commentary would be most helpful, but I can't be bothered to do any editing (it's only Musings, after all) and I've no feature for direct commentary on this article - apart from email of course. Comments are helpful, welcome and indeed appreciated.