Adapt Introduction

i had a quick question regarding this. i know that you guys have said that MyCroft is a cloud based solution… with MyCroft, how much cloud based storage will each person get per account? something that i think might help in the reguard of “State-Full Intent Memory” would be to have a running log file which states UserName::Object/Subject::Intent::Outcome… and put it in a way that certain key words, will cause MyCroft to look in the “History” or log file for the past say 10 commands for object/subject verification. then what could be done, on the server end, is set up something like a cronjob with log rotate to move the current days MyCroft use history to History.1 file. and then after about say 4 files like that the oldest could be deleted. or depending on customer choice, they could elect to keep the file for longer. for the log, you could also timestamp each history log entry, and put a process ID UID GID number next to it. would that be usefull at all?

also the reason why i was asking about cloud storage size, these would have to be stored in each user accounts directory, as storing them in someplace like /var/log/ or even /var/mycroft would clog up the servers on the cloud end. so i would recommend having say a 5 gig space for each user. enough to record voiceprint ID / Verification, a preferences file, a AI personality “Brain” file, and history logs. that way, each space would belong to the user, and they could have a way of logging into their own account to delete files or history that they wanted. just a thought. also if they deleted the files, MyCroft would go back to the generic personality, just like it is out of the box.

@seanfitz i thought i would pass this along to you, as the (BDI system) adapt is very simular in concept to what SRI did for siri’s system “Spark” here is a link to the source code so you can take a look at it for ideas to glean from: basicly it is a Belief Decision Intent engine which sits ontop of Jython. i thought it might give some help, with seeing how they set things up in their engine that would could use in Adapt.

@seanfitz @ryanleesipes
ok so i had some questions about the implamentation of Adapt scripts.
i was looking in the examples at the

i am playing with altering the script to get more cities and what not…

weather_keyword = [

for wk in weather_keyword:
    engine.register_entity(wk, "WeatherKeyword")

weather_types = [
    "earth quake",
    "pollen index",
    "alergy warning",
    "heat index alert",
    "heat wave",


for wt in weather_types:
    engine.register_entity(wt, "WeatherType")

locations = [
    "San Francisco",
    "Oklahoma city",
    "Oklahoma Norman",
    "Oklahoma Tulsa",
    "Oklahoma Peidmont",
    "Oklahoma Moore",


it appears to regiester when i run the script, this is the out put:

(myvirtualenv) mycroft@mycroft:~/Bin/myvirtualenv/src/adapt-parser/examples$ pwd
(myvirtualenv) mycroft@mycroft:~/Bin/myvirtualenv/src/adapt-parser/examples$ ls
(myvirtualenv) mycroft@mycroft:~/Bin/myvirtualenv/src/adapt-parser/examples$ python ./ "What is the weather like in Oklahoma City?"
    "intent_type": "WeatherIntent", 
    "WeatherKeyword": "weather", 
    "Location": "Oklahoma city", 
    "confidence": 0.47619047619047616, 
    "target": null
(myvirtualenv) mycroft@mycroft:~/Bin/myvirtualenv/src/adapt-parser/examples$ 

so now my question is, what service or app would i connect this too? is there a internal app to MyCroft that it would connect to, OR is it connecting to a service from say like NOAA, or Underground Weather? AND if it is, would those apps, handle finding the location in question? or would i need to create a mini CVS type database with country:state:city:zipCode:areaCode: ? also i should ask, as we have not seen the full source code yet for Mycroft, have you guys already implamented this? basicly i was working off the code in the script. would that script be able to referance an expernal CVS DB file in order to parse the city information? or would the be too process intinsive for the system to do? sorry, i am still trying to get a feel for how all of this fits together in the end.

I believe I was actually around SRI when Spark was being developed/used (papers written in '04, I was there in '07/'08). I do happen to know that Siri did not use Spark (at least as of 2010, and post-Apple acquisition it seems unlikely).

History fun-facts aside, there are certainly commonalities between Adapt and prior art in the space; as a software engineer (and not an ML specialist), I focus on practical engineering designs and rules-based systems (which Adapt clearly is). Spark certainly has some of that, as did early iterations of Siri. Adapt (in itself) does not support learning of new beliefs; I have some side projects that did just that, but incidents like Tay make the idea of a globally trainable fact store… unpalatable. Prior implementations in this space have isolated “learned beliefs” to the user that taught them; it makes the surface area of an exploit much smaller, but also makes it difficult to learn from the broader knowledge available from the community. #hardproblems.

As I’ve stated a few times before, I built Adapt with some very specific goals; pure python (for portability), lightweight (to allow for running on devices as low powered as a raspi B+ at time of original writing), and declarative (to be extremely straight forward for developers). The core concepts of Adapt aren’t particularly original, but I think that the implementation (and the constraints surrounding it) are, at least enough to keep me interested :slight_smile:.

I’ll let @ryanleesipes add more detail if he wants, but in short, we’re using OWM for weather data, and it provides location search such that we do not have to maintain a canonical database of locations.

wow thats really cool :slight_smile: i actually asked them if i could use the spark engine in teh project i was working on “Butlerbot” as it was i was writing it in python as a AIML chatbot. that is really funny about Tay hahaha, but ya its probably not such a good idea to make it openly trainable like that lol.

ahhh ok, ya i was thinking about using that as a base for somekind of emergency services type system, say like if a tornado is coming in, MyCroft could pick up an alert, and tell the people in the house to seek shelter, or could call police / fire station / hospital if there is a break in or someone has a stroke or heart attack. i’m not totally sure though, on how one would go about testing these type of services, and not get into trouble if it spams 911 or other emergency hotlines over VoIP. i was looking at foremost, tornado, hurricane, flood, warnings.

@betzelel These types of systems always tend to have a human in the loop somewhere. I mean, it’s okay to passively recieve and relay information about weather events, etc to the user, but allowing it to actively make calls to 911/999 is asking for trouble (at least with the current level of technology).

A better idea might be for it to call a relative, who could assess the situation themselves and call the emergency services if they deem it necessary. This would have the 2 benefits: 1) the emergency operator probably wouldn’t believe a robocaller anyway, and 2) spamming a relative because you miscoded it slightly probably won’t result in jail time!

ya that sounds like a really good idea… maybe what is needed is a emergency call list of people that you can add to it when you set up MyCroft for the first time. it would be good too if i can record the conversations and upload it to your personalized cloud system. i wonder if when setting up MyCroft, if there is a web based setup walkthrough for setting up your accounts and what not, and what all information you will be able to enter.