This might be a tad off-topic for some members of this list, so I apologise
in advance. It is also a bit long.
I was wondering if someone could help me with my thinking on the following
matters, to let me know if I'm talking rubbish or not. I'm not a comp sci
grad, I drifted into I.T. as an auto-didact from other spaces.
Once upon a time not so long ago, in venting frustration regarding certain
matters, I wrote a specification called SIX
(http://www.inpreparation.com/six/). It was a sketch (and possibly even a
bad sketch at that). Essentially I was trying to do three things. One was to
free conceptual graphs in XML from the idea of domain-specific syntax, as in
RDF, and from all the reasons that went into making that aspect of the
syntax of RDF like it is, as I saw that aspect as a bad thing. The other was
to break down and make explicit all the relations in Topic Maps and
represent them at a single uniform level, exposing them to uniform
processing, because my experiences with XTM at the time led me to believe
that things were getting murky in that line and I was unable to divine the
agendas driving that clearly. Then I sought to generalize from RDF and Topic
Maps to a completely arbitrary graph that I hoped could represent both and
much more besides.
Now the reason I've resurrected mention of SIX on this list is Lee Iverson's
desire to be " able to reuse data in a potentially arbitrary set of
contexts" (see his mail re: Topic Maps, Ted Nelson, Virtual Files...). I had
hoped that SIX would be quite good for this sort of thing if a certain
approach to processing were taken. However, I've kept quiet on this matter
because I needed to time to figure out whether or not that was the case. I
now think my poor brain isn't quite up to the task and I need help. So what
follows is some ideas about processing SIX, and in particular about
inclusion and reification that I'm hoping someone will start discussing with
My vision of how one possible processing model for SIX works:
The core ideas in SIX: atoms, list of atoms, subject-predicate-object
statements, scopes/namespaces, and references. Take the sentence, "Jack Park
has a website". And let's conceptually create a namespace like this:
Universe < Milky Way Galaxy < Our Solar System < Third Planet
where < means the 'is a subscope of ' predicate. So then I can take the
scope 'Third Planet' and make assertions like,
in-namespace('Third Planet', is-a(person, life-form) )
in-namespace('Third Planet', is-a('Jack Park', person) )
in-namespace('Third Planet', has-a('Jack Park', website) )
So far so good. But now, as is traditional in such matters, I also want to
be able to say things like,
"Jack Park has a website called 'Thinkalong'."
And the way I thought about doing this was by the creation of system
references that behaved in certain ways depending on their namespace. So,
SREF#123 << in-namespace('Third Planet', has-a('Jack Park', website) )
in-namespace(SREF#123, is-called(website, Thinkalong) )
where the SREF provides a mechanism for declaring that the namespace of this
new statement is the previous one, and that creates the correct association
structure for attaching properties.
Then there is the small matter of reification. How do I distinguish between,
1) "African elephants are grey" and,
2) "John thinks African elephants are grey".
3) "John thinks the statement, 'African elephants are grey,' is false".
My guess for (3) was:
SREF#456 << in-namespace('Third Planet', colour('African elephant', grey) )
in-namespace('Third Planet', believes(John, is-false(SREF#456) ) )
Then for (2),
in-namespace('Third Planet', believes(John, SREF#456 ) )
The problem with my solution for (3) is that 'is-false(SREF#456)' is another
statement in its own right, and that true and false beliefs are mental. So I
would have to say something like,
SREF#678 << in-namespace( 'Human Thought', is-false(SREF#456) )
in-namespace('Third Planet', believes(John, SREF#678 ) )
Another alternative is just to declare every statement to be in the
namespace of 'Thought' automatically,
Thought < Universe < Milky Way Galaxy < Our Solar System < Third Planet
and then find some way to define a nifty operator (e.g. 'is-F' and 'is-T')
and its attachment to certain predicates like 'believes'.
in-namespace('Third Planet', believes(John, is-F(SREF#456) ) )
Now, are my beliefs about reification correct, and am I barking up the right
tree overall? Are there any huge problems I'm missing?
Another nifty thing I had in SIX was grouping. So wherever John is, or ends
up, I can effectively say,
in-namespace( group('Third Planet', Heaven, Hell), believes(John,
is-F(SREF#456) ) )
in-namespace( 'Third Planet', believes(John, is-F(SREF#456) ) )
in-namespace( Heaven, believes(John, is-F(SREF#456) ) )
in-namespace( Hell, believes(John, is-F(SREF#456) ) )
in-namespace( 'Third Planet', believes(John, group(is-F(SREF#456) ,
is-T(SREF#654) , is-T(SREF#777) )) )
=> John has several distinct beliefs in the same namespace.
in-namespace( 'Third Planet', believes(group (John, Mary, Mungo, Midge),
group(is-F(SREF#456) , is-T(SREF#654) , is-T(SREF#777) )) )
=> Each person in the first group holds the set of beliefs in the second.
Now assuming all of that is fine and dandy, I then want to ask, is it
possible in logic programming to define functions/rules (and here I'm
thinking of reaching for a different syntax for such definitions - see the
<ruledoc> element in SIX) to only operate within certain scopes, in much the
same way as I've indicated the validity of the statements above?
I'm heading in the direction of the graph being everything (XML syntax being
almost nothing - the barest of bones), and encapsulation, property
assignments, etc. all being controlled by the namespace mechanism.
Crucially, I am worried that the SREF + namespaces mechanism I've outlined
here and in the SIX spec might break when functions and rules are brought
into play on the graph (even though I haven't spotted any problems yet) so
if anyone has direct insight into that I'd like to know.
I'll leave the mechanism of <wcvar> to one side for now.
Any help from anyone, or anyone you know, much appreciated.
Thanks in advance,
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIemail@example.com
Shortcut URL to this page:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2b29 : Sun Jun 03 2001 - 12:04:05 PDT