Tom Cloyd
12/23/2008 12:54:00 AM
Robert Dober wrote:
> Sounds like a marked graph to me, and not directed at all, or did I
> miss the arrows? That of course is a very general
> thing, I therefore doubt that this statement is helpfull.
> I do not understand with what you mean that a node can be connected to
> a group of nodes?
> Do you mean that if the nodes are e.g. lower case letters, there might
> be an edge X in e(a,{b,c}) (X being the marking)
> without implying that there is X in e(a,b) and X in e(a,c)?
> If that is the case you still have just a general graph only that you
> have to expand the nodeset to its powerset.
>
> Cheers
> Robert
>
>
Robert,
I apologize for my mathematical illiteracy. I don't understand your
question, because I don't understand your symbolic representation. Sorry.
So, allow me to explain it in terms I do understand - in the terms I'm
using to work out the problem as I program the solution. Please realize
that this may or may not well relate to the structure Simon's interested
in. I think it does, but that's for him to say. For me, it's a practical
problem in highly flexible information storage and retrieval, and a good
chance for me to advance my Ruby skills. Here's a fundamental
specification for the model I'm implementing:
* A "node" is a unit of information. It can be anything: a word, phrase,
number, equation, pointer to something else - anything. It's just
something that can be connected (related) in some way to another node.
* I indicate a node like this: .n {information}
* The node indication begins with the first character after the space
following node indicator, and ends when another indicator or an EOL/CR
is read,
* I indicate a relationship similarly: .r {information}
I now can specify node relationships. Some examples:
n Tom .r is a .n poor programmer
n apple r. is not .n bridge building material
n e=mc**2 .r could be .n true
Obviously, these aren't sentences, so we do not use articles,
conjunctions, and the like.
Simple enough. Now, consider this:
I start with a database of nodes, and of relationships - note that each
gets a unique ascension number:
n1 {}
n2 {}
n3 {}
...
r1 {}
r2 {}
...
When I specify a relationship with a node not in the database of nodes,
it gets inserted there; ditto for relationship types (NOT to be confused
with relationships - which are sets of two nodes linked with a
relationship of a given type).
Relationships ALSO go in a database, and each also gets a unique
ascension number.
Here's three complex relationships, each with its number (I preface
relationship ascension numbers with a lowercase L - for link):
l43 n1 and n2 and n3 .r are .n true
l44 n4 and n5 and n5 .r are .n not true
l45 l44 and l43 .r are .n true
The last one is the form of a line detector in the human eye, a simple
but vital element or our brain. That's not my interest, but I AM
interested in being able to build structures LIKE this, and I think this
sort of cascading complexity is what Simon is getting at. I think of it
as a sequential sparse matrix, but what do I know? I probably have that
all garbled, but the logic itself I'm sure of. This WILL work, though it
well may not be optimal in my specification of it. I'm simply trying to
follow the maxim of 'get it to work, first', then 'get it to work well,
later'.
So, I'll stop here, and wait for comment, if any.
t.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~