<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Jul 21, 2008 at 11:08 AM, Ryan Meador <<a href="mailto:ryan.d.meador@gmail.com">ryan.d.meador@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">matt joyce <matt.joyce@...> writes:<br>
> Ryan, what approach have your efforts taken already?<br>
> Any interesting insights to the problem?<br>
><br>
> Matt<br>
><br>
<br>
</div>My efforts as far as applying my inference engine to the OpenMoko platform<br>
basically consist of a few ideas rattling around in my head -- nothing concrete.<br>
I'm not a professional at this stuff, just an enthusiastic amateur trying to<br>
follow in the footsteps of some of the very interesting early AI research<br>
projects (most inference-based approaches to AI died out in the 80's, but a few<br>
are still around). To that end, most of my work has been focused on things not<br>
directly useful to a phone platform.<br>
<br>
I think it's important that we use an existing general-purpose platform such as<br>
Prolog (at least, it's about as general purpose as logic programming gets...).<br>
This saves us from reinventing the wheel and also prevents us from thinking<br>
ourselves into a corner -- a general purpose system will likely be much more<br>
extensible and flexible for powerusers (and with this device, who isn't?) than<br>
something we dream up. Taking an inference-based approach to setting up the<br>
rules in the phone could allow us to create rules that are more abstract than<br>
most of the examples I've seen on this list. Instead of telling it "don't use<br>
the ringer when I'm at the office", it could be "don't use the ringer when I'm<br>
doing work". "Work" would be defined by other rules, such as your proximity to<br>
the office, whether or not you've scheduled an appointment in the calendar with<br>
contacts from work (think lunch meeting), and if you have a deadline that isn't<br>
marked as complete and it's only an hour away (you're probably workign furiously<br>
to meet it). That's just an example I created just now, and not particularly<br>
good -- good examples are hard to think of, but that's largely because the<br>
possibilities are endless. As one other person on the mailing list noted, the<br>
possible configurations of the rules engine that are nonsensical outnumber the<br>
meaningful ones by millions to one :)<br>
<br>
That babbling probably wasn't very helpful to anyone, but maybe it will at least<br>
build enthusiasm. I think the gist of it was mostly this: make it more flexible<br>
than it needs to be, and also make the rules capable of building on top of each<br>
other to create more complex conditions. Just my $0.02 :)<br>
<font color="#888888"><br>
Ryan<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br></div></div></blockquote></div><br>I find myself in a real quandary about this.<br>On the one hand I want more flexibility, more inputs, more actions and such, because I feel creative uses will emerge from that.<br>On the other hand my experience as an IT practitioner and technologist, instinctively tells me to keep it simple. I've spent most of my IT career trying to remove or prevent unnecessary complexity.<br>
<br>Matt<br><br><br><br><br></div>