It Is A Mystery…

So I’ve returned after some time at MIT where I was getting a bearing on where I’m going next with my part in the TAMI project, and I’ve come out with a few goals:

• Finish tinkering and profiling the current TAAC setup.  This has already resulted in some interesting results, namely, that the planned OpenID setup is really slow.  To be fair, I’ve also only tested it with one physical setup, so I need to test a couple other servers, and so on. Unfortunately, it seems that the number of round-trips needed to get the FOAF file, get the OpenID identifier, and then establish a shared secret with the OpenID provider takes way too long. We can cache some of this (especially the former two), and can even avoid it all with a cookie established at the end of the first authentication, but the first sign-on takes entirely too long to process on this VPS.
• Examine other authentication methods.  Since the key right now is shortening the time needed to authenticate against one’s FOAF URI, there are several other methods out there that may cut out the authentication issues, including RDFAuth and Toby Inkster’s FOAF+SSL.  The former has less round-trips (as there isn’t the cost of setting up the SSL connection), but the latter doesn’t require the maintenance of a PKI, and can be done with self-signed certs.  I hope to be talking with Toby and Henry Story, among others, to see what’s been done with FOAF+SSL, and to see how we can work that authentication method in.
• Get a better idea how the reasoner engines work for the AIR reasoner. Seeing as my understanding is not terribly good at their reasoning methods, I’m going to be trying my hand at reimplementing a Rete system, a TREAT system, and a backwards chainer…  In Erlang (or at least do such for a Rete).  Why Erlang?  I think it will give me a good idea about not only how the system’s productions are called (as a network of alpha and beta nodes is rather nicely done in a functional framework), but it will give me a better understanding of the problems with trying to make a Rete concurrent (and why TREAT is ostensibly better at concurrency).  With Erlang’s BUILT-IN concurrency and light-weight threads, rather than a lock-based concurrent framework like in the Python we’re currently using, there’s no additional cost to making the functions concurrent if I take the time to do it in Erlang.  Luckily for me, I’ve worked with the Mozart Programming System in my programming languages class, and Erlang isn’t too different from that…  Plus, it’s another programming paradigm/language under my belt.
• Implement cwm built-ins into the AIR reasoner.  Yosi and I have already discussed some of the issues with doing so, so it’s just a matter of my understanding the code that’s standing in the way of my adding such.  Thus the reason for the above, and studying the existing code.