An interesting post, and one I enjoyed reading.
I wish I had the capacity to help you with the answers,
but I wish even more that I had the ability to understand
What I got from your message:
* You have a system that aims at unifying and extending
both RDF and Topic Maps, while solving some problems
* But at the same time, there are representational issues
that you don't quite know how to solve.
* Those issues seem to revolve mostly around "nested"
a) X is true.
b) Y believes "X is true".
c) Z thinks that "Y believes X is true" is false.
Is that about it?
> This might be a tad off-topic for some members of this list, so I
> in advance. It is also a bit long.
> I was wondering if someone could help me with my thinking on the
> matters, to let me know if I'm talking rubbish or not. I'm not a comp
> 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
> 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
> that things were getting murky in that line and I was unable to divine
> agendas driving that clearly. Then I sought to generalize from RDF and
> Maps to a completely arbitrary graph that I hoped could represent both
> much more besides.
> Now the reason I've resurrected mention of SIX on this list is Lee
> 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
> 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
> 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
> 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.
> 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
> structure for attaching properties.
> Then there is the small matter of reification. How do I distinguish
> 1) "African elephants are grey" and,
> 2) "John thinks African elephants are grey".
> 3) "John thinks the statement, 'African elephants are grey,' is
> 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
> 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
> and then find some way to define a nifty operator (e.g. 'is-F' and
> 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
> tree overall? Are there any huge problems I'm missing?
> Another nifty thing I had in SIX was grouping. So wherever John is, or
> 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) ) )
> and also,
> 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.
> But compare,
> in-namespace( 'Third Planet', believes(group (John, Mary, Mungo,
> 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
> 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
> <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
> 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
> here and in the SIX spec might break when functions and rules are
> 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,
> Yahoo! Groups Sponsor
> [Check out great fares at Orbitz!]
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-IIemail@example.com
> Unsubscribe: unrev-IIfirstname.lastname@example.org
> List owner: unrev-IIemail@example.com
> Shortcut URL to this page:
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIfirstname.lastname@example.org
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 : Wed Jun 27 2001 - 13:53:27 PDT