wintermute-psych team mailing list archive

["danteashton@xxxxxxxxx" <danteashton@xxxxxxxxx>]

On 23 August 2011 11:25, Jacky Alcine <jackyalcine@xxxxxxxxx> wrote:

> **
>
> It's been a while since we, as a team, sat down (so to say) and chatted
> about Wintermute.
>
A bit of a forewarning, this message gets a bit technical, as I'm trying to
> get as much detail out about Wintermute. I was writing this to Dante,
> initially, but then I figured that this is stuff everyone should know. I (as
> you know) am using Kubuntu, switched to it before my eminent fall off from
> the digital world. I would have made a bit more progress if I were to be
> online, but the amount of progress that I've been able to make offline
> surprises me still. I haven't realized it then, but I've somehow
> reimplemented a natural language parser that works similarly to LinkGrammar
> (try their online interface). What does this mean? Well, if I wanted to, I
> could create a little Perl script that would convert LinkGrammar definition
> files into something Wintermute could read. Of course, that would be silly
> (in my opinion). Ever since I've been on the K desktop, I've noticed and
> realized why you chose it for the standard desktop environment for
> Wintermute (aside from the fact that GNOME is wicked!). It's orbiting
> heavily around modularity; and that's something I strive to get with
> Wintermute.
>

It wasn't just the modularity of KDE I found beneficial; it is also the
large amount of technology that 'Just Works'; take Okular, KDE's document
viewer. It has support for a HELL of a lot of document files; Evince, it's
GNOME counterpart, can only handle PDF files. It's as much that as the
developmental mindset behind it. The interface will have to be radically
changed, of course; we're dealing with a system where the psychological
effect is far more pronounced, and where most of the work you do with said
system won't be done sitting in front of the computer for hours.


> It can read lexical data in different formats, but I'm hoping to implement
> plug-ins that can get it from different sources, possibly remote (from the
> S.I.I server) or via a transaction via another Wintermute (I'll get into
> detail about the AngelNet in a few). I'm hoping that with the new plug-in
> system, people will be encouraged to add ways to obtain data in different
> formats from different sources; that'd promote more data for Wintermute.
>

Side-note: with more data pouring into Wintermute, the more useful (and
indeed, hopefully, the more correct) the system will be.


> I'm also working on a visualiser for said data, so it'd be not only easier,
> but faster for people to create linguistics packs of information. Only
> problem with that is that the ontology may be required for that; and as far
> as I know, there isn't such a thing as an (non-Java, non-Tcl/Tk) ontology
> viewer. It's expensive, memory-wise; I don't even know how it holds with
> graphics.
>

A primary concern of mine is not only having an Ontology, but also tools
which can automate it's continued development. If you were to build a bot
with the whole of DBPedia in itself, and get it to run
and categorize natural language articles on Wikipedia; it would get
continually more proficient, requiring less and less human interaction to do
it's job; the trouble there is such a task is computationally expensive;
I've seen it done with machines that cost $30,000, and it took about 6
months to fully 'digest' a single article from Wikipedia.
The alternative method is we simply enter that data manually. The CYC
project has been doing just that, with minor automation support. They've
been at it for almost 40 years (They've gotten some very interesting
statements, too, like "Am I a human?" from the system, apparently) and they
still have a looonnng way to go...so yeah, I think automation is needed
here...


>
>
> Initially, I imagined the AngelNet as being this pseudo-network that
> spanned across previously existing networks and specialized ones that had
> Wintermute processes communicating in an ad-hoc function. That's how I
> understood from what Dante had described to be an invisioning. When I think
> of it now, that might be possible; but we'll need someone more familiar with
> network programming (which is something I wanted to do when I first started
> programming) to handle this. Wintermute currently runs as one process, but
> I'm hoping to have it work in a Chrome-like manner by using D-Bus. I'm
> referring to how Chrome has individual processes for each tab and each
> extenstion (well, an extenstion is loaded as a special tab, so it's just
> tabs, I guess). This requires that our IPC is top-of-the-line and that the
> WntrNtwk (mainly for the ArchAngelNet) and WntrData have D-Bus exposure so
> that Wintermute doesn't duplicate crap-loads of data. I really need someone
> to sit down and look at IPC for Wintermute because if we want it to move
> quickly without the weight of each loaded plug-in, then IPC is definitely
> needed. (IPC stands for Inter-Process Communication, for those who were
> wondering :]).
>

Just a reminder: 'AngelNet' is a localized network of Wintermute systems.
The term would apply to systems in one network, one neighborhood, and one
country. The entire complex of AngelNet networks is referred to as the
'ArchAngelNet'; which, should everything work as planned, be a global
network, Each AngelNet could, in theory, form a node of computational
resources (with the owner's consent) which the ArchAngel network could use
to help process information. Think of it as a cross between
a miniature internet and distributed computing project (which would mean we
would not require a server farm to deal with the flow of information to
Wintermute's developmental models)


>
>
> Now, the current, biggest pet-peeve. Right now, we're using Soprano (or
> QRDF) to parse, query and possibly manipulate ontologies (since the one
> we're going to work with for now is in the Web Ontology Language [OWL]).
> It's a pain in the ass to somehow get this giant (it's nearly 180,000 lines
> of sparsely documented XML code) document to represent concepts that can be
> used with the currently stable-ish linguistics system. Once this is done; I
> can really be beyond confidient that Wintermute is headed to see brighter
> days.
>

Well, I honestly don't know what to say to that; I do believe I am bursting
with joy, and pride at the very idea, however :-)


>  The moment we're able to have Wintermute find the ontological and semantic
> linking of a sentence, we can work on the next bit of Wintermute (all of
> this I've been thinking up and attempting to implement); and that's the
> action core. This bit of code is going to be the game-changer, in my
> opinion, but it's too early to adquetely guess. It has to represent the
> action that one would take in order to fulfill the action described in a
> sentence. Typically, people would attach a word (in this case, a verb) to
> hundreds of actions. I thought of it in a different manner. Why not have the
> actions attached to the object themselves? When it needs to 'open' a
> folder, an instance of the ontological class 'folder' can be found and the
> action 'open' can be invoked. Any extra arguments would be passed along as
> links to the passed instance and queried for instanteously. A lot of
> contextual work has to be done (getting permissions to access a file,
> detecting if the file exists, etc), but the load may be small for the simple
> fact that ontologies are mainly object-orientated (as far as I know) and
> because of that, the idea of inheritance and polymorphism come into play. A
> folder could inherit all of the properties of an object on a computer, a MP3
> could inherit from an audio file, that from a binary file, and so on. This
> allows bits and parts of the object to be pre-defined and saves us a crap
> load of work.
>
>
>
> When that's all and said and done, the one thing that I think might be
> difficult to really grasp is Wintermute's memory. I call it memory and not
> settings, because settings are more or linear in the sense that they
> (typical computer settings) don't the semantic connection that settings in
> Wintermute would have. Its memory (as mentioned very early in the game)
> would be an meta-ontology. It'd link to multiple ontologies, some local
> (COSMO, personal) and some remote (DBpedia). This brings up the mentioning
> that if Wikipedia generated or had RDFs of each Wiki page, or just MediaWiki
> had such a capability in general, then Wintermute's knowledge could be
> limitless and easily created as well as corrupted.
>

According to the Ubuntu repo; there is a 'semantic' media-wiki
system available. Don't know anything more about that, though.

>
>
> Developers! Where art thou! If you haven't noticed yet, we've moved the
> current working branch to GitHub and we now maintain an organization on
> GitHub (https://www.github.com/wntr). I've backported the current code as
> imports to Bazaar, so that shouldn't be too much of a drastic change for
> people. Download! Build Doxygen! Check the TODO and BUG pages! HELP!
>
>
>
> This part is targeted at Dante, and it's in question to the AngelNet. I was
> looking in my local repository listings for something that already exists
> that we can use to expand the AngelNet from. It took a moment to realize
> that we're not building a network. We're building a layer over a network,
> over many layers. Can it be called a psuedo-layer?
>

I think a 'meta-layer' is a more apt term, as the term pseudo indicates
falseness; a pretend, empty, shell. whereas 'meta' establishes it as a layer
of a sort.


> It doesn't exist, but yet there it is. The largest issue I see so far is
> having Wintermute processes find each other.
>

Apparently, Mac OS's 'Chat' application automati


> I wanted this to be done with the littlest amount of effort, and for the
> process to be totally secure
>

I CANNOT overstate how important security is; Wintermute's AngelNet complex,
if it came under the control of undesirable characters, is practically a
pre-made bot-net. I don't need to go into detail about what would happen if
someone had less-then-admirable intentions should they somehow gain control
over an AngelNet node.


> so I figured to use something that we're familiar with and is becoming a
> growing trend: GPG.
>

This would have to be completely transparent to the user; something a user
does not have to deal with.


> Simple signed and encrypted messages could be used, and a central keyserver
> is all that's needed. Of course, Wintermute wouldn't have to generate a new
> key (only if the person doesn't have one or chooses to have a special one
> for WIntermute)
>

So, basically we're looking at a account system, like those found on
websites, hm?


> . It may need a set of keys (all of which are done "on the low"), it'd need
> a SSH key, private key, and a public key. I still have yet to implement this
> into a simple API (or merely just use the programs in the systems), but with
> our plug-in system, we can use this as ONE of the ways to perform
> authentication.
>

We'll have to look at others, of course.


>  I've noticed in the repository an interesting set of libraries, all of
> them designed for authentication for the PAM module. Apparently,
> authentication can be done via Bluetooth or physical USB devices.
>

Security keys; it beats the hell out of remembering a 256-character length
password...but it can be stolen, or spoofed (done incorrectly)



>  This struck me and made me realized the beauty of modulariy again. We
> could (and should) work with GPG for now, but when we go mobile (or head to
> OS status)
>

I have been crunching the numbers here; the only way for us to
do Wintermute properly is if we have complete control over
the environment Wintermute will operate in. If we build it as an
application, then we are looking at limited usefulness as we simply cannot
intergrate Wintermute with every application a computer can house.


> , I can see the USB device authentication being super nifty (just hope that
> you don't lose your device, unless we can add a password prompt to be
> entered on the device to validate its authentication request).
>

>
> That's all, folks; thanks for listening to me ramble! Oh, and thank God for
> Qt! Wintermute depends insanely on it now.
>
> --
>
> Jacky Alcine <http://www.jackyalcine.co.cc>
>
> --
> Mailing list: https://launchpad.net/~sii
> Post to     : sii@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~sii
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 

-Danté Ashton

Vi Veri Veniversum Vivus Vici


Sent from Ubuntu