very interesting! I would like to know more about the voice assistant technology and the cobot logic.
8 karma · joined November 30, 2015
I feel that realizing a chatbot - in a specific programming language, - with a standard framework (Rails), - for a specific channel (Messenger), is an ERROR, in the log terms.
BTW, I realized naif, my personal micro framework just to build chatbots in Ruby (see slides: https://github.com/solyaris/naif),
Nevertheless, I decided to NOT publish the code and no more deepen that "hard-coded" way, instead I suggest to use and support a chatbot scripting (meta)language. About rationales, I wrote a bunch of articles: www.medium.com/@solyarisoftware
I support opensource great ChatScript (https://github.com/bwilcox-1234/ChatScript/) and BTW I wrote simple client in Ruby (https://github.com/solyaris/rChatScript/)
My two cents giorgio @solyarisoftware
I feel that realizing a chatbot
- in a standard programming language (Ruby),
- with a standard framework (Rails),
- for a specific channel (Messenger),
is an ERROR, in the long terms.
BTW, I realized naif, my personal micro framework just to build chatbots in Ruby (see slides: https://github.com/solyaris/naif), nevertheless, I decided to NOT publish the code and no more deepen what I call the "hard-coded" way,
instead I suggest to use and support a chatbot scripting (meta)language. About rationales, I wrote a bunch of articles: www.medium.com/@solyarisoftware
I support opensource great ChatScript (https://github.com/bwilcox-1234/ChatScript/) and BTW I wrote simple client in Ruby (https://github.com/solyaris/rChatScript/)
My two cents
giorgio @solyarisoftware
To maintain persistence of your comments, please reply on stackexchange too (an vote there the question tehre maybe)
Thanks for your attention
giorgio
Baed on Alexander's work, myself I realized a github project to show how to use webhooks integration:
That's an AIML alternative that seems a bit better (no XML!), but I do not yet understood if I can do with rivescript a "simple" ecommerce "script" worflow I explained in my comments and on the github doc. I have to investigate.
giorgio
I'll investigate and study to understand about "pragmatic" and semantic understanding; thanks.
But let me do some more notes:
1. my raugh and crippled code proposal at http://www.github.com/solyaris/dialogs is to consider a "framework" where dialog are composed/nested as "elemental dialogs" (archetypes or "abstract classes") to be instantiated as subclasses, and of course there is not a real NLP. The semantic understanding is "delegated" to an external engine (see the interpret() method).
2. In my modest opinion the BIG trade off is between a system that really do a semantic interpretation and a system tha quickly supply a service to a user (buyer) in a DETERMINISTIC/fast workflow.
Please let consider the usual example I propose: an ecommerce shopping: I call this a bussines service, that "have to" bring user to purchase something as goal, "as talking by phone" with the buyer (BTW I worked a bit on a proximity ecommerce project http://www.rosposhop.com, where buyer and seller live in the same area and know each other personally).
So the state-machines composistion I proposed is maybe naif but focus on a deterministic workflow, to achive some business goal/task.
To be pragmaticals: There is some (open-source) NLP to already done to realize a "simple" task as a "ecommerce" text conversation" ? I'm looking forward for it :)
giorgio
I maintain a sort of microblog just about these topics: http://www.twitter.com/solyarisoftware
Me too I just discovered Chris Messina's definition of "conversational commerce", definition that I like.
About "personality":
Maybe some years ago we have called this just "user profiling".
In facts approach I suggested (modeling dialogs as a composition of state machines: http://www.github.com/solyaris/dialogs) is just a workflow framework indipendent by the personality/profiling implemenentation. - On one side personality/profiling could be delegated to to some "inerithed class" (of what I defined as "elemental" dialogs). - on the other side I'd delegate in the "interpret" method.
Let's consider the usual ecommerce workflow. This could be splitted in 2/3 successive dialogs:
1. compiling a shopping cart - dialog
2. setting the delivery address - dialog
3. setting the delivery time - dialog
So, by example, in the delivery address dialog, the chat bot (or "conversational agent") know the buyer person interacting (because he stored somewhere the buyer address in a previous "profiling" dialog ), so the chatbot could simply propose to use the stored address or submitting a new one.
Just to say, that, for business workflow, maybe the "personality" maybe is just a smart profiling. isn't it ?
giorgio
years ago I studied a bit AIML and also recently I see that Ruby language implementation is a bit obsolete.
My feeling is that AIML are not maintained / growing, but the principal point I a bit discarderd AIML is that it seems to me not faiseable to do a "deterministic" workflow (just let consider the e-commerce purchasing workflow I described in my project http://www.github.com/solyaris/dialogs)
giorgio
BTW, please consider: 1:https://github.com/solyaris/dialogs as a VERY VERY DRAFT / proof-of-concept 2:I'm a bad (Ruby) programmer. 3:I'm not a NLP expert. 4:please tolerate my long story/bad English.
Contributes/Collabroations on the open source project, are very welcome: a:comment here. b:email me (prefereed at first glance. giorgio.robino@gmail.com). c:open issues on github (perfect for share nd persistence).
Have a good reading. Thanks. giorgio http://www.twitter.com/solyarisoftware
Notes: I'm an ambient electronic music maker (and software maker too). I saw a lot of similar projects since Brian Eno's generative music project. I have been also interested in making algorithmic music (using some AI/artificial neural network schemas), using amazing Supercollider, for a while. I never achieved interesting results, in terms of "deep energy" instead "embedded" when music is made by "special" humans (so called "artists"). Full stop.
Experimenting soundscapes CREATION, in recent years I was back to what I call (along with Steve Roach): "analogic approach": sonic seeds as analogic waves (electro-acoustic) -> (digital) elaborations made by human(s) artist. No MIDI. No "samples" usage as-is. No presets.
I could call the musical secret as a case of human intelligence: "search and discovery" of unknown. Because, this is the point, music is discoveryng of mistery.
BTW, I do not want to enter in the loyality-free / real-time composition topic. So long discussed for so many years among electronic music communities! Good music, is like science inventions: come from "singularities".
That said, an interesting point, for me, is the fact Artificial Intelligence could help musicians to make music. Ok, but this is another story, another vision of what music is, for humans, for machines
respect giorgio
BOTServer is a simple project in Ruby language to manage many Telegram bots with a server webhooks routing 'architecture' (instead of a proliferation of processes doing long polling).
The project is very draft/alpha stage, I admit, but I publish also to share some possible innovative services enabled by Telegram bots. See also some ideas here: 'Innovative Chatbot Services with Telegram':
https://github.com/solyaris/BOTServer/blob/master/wiki/servi...
If you like the project, please star also on the github page. Please feel free to comment, and maybe open issues on github.
Thanks giorgio (twitter.com/solyarisoftware)
Yes! :)
I agree with Sam Saffron (thanks Sam for al your githubcode) about some perplexity using websockets as a panacea nowadays.
Nevertheless, I really appreciated Nchan structured approach, open to different available protocols (poll, SSE, websockets) :)
Documentation is VERY well done. publisher: Curl examples are perfect. subscribers: maybe some examples in a language ( Ruby? :-) ) could help dummies like me. I'll study and if I can I'll propose you
respect giorgio
good idea ;-) BTW, do you have any recent news about Telegram decisions about uploaded files persistence on their server ? https://core.telegram.org/bots/faq#can-i-count-on-file-ids-t...
> For the moment, file_ids for your bot's outgoing files may be recycled after several thousand files have been sent. This may be changed in the future. Inbound file_ids can be treated as persistent.
About searching on MusicBot (using web interface: https://web.telegram.org/#/im?p=@MusicCatalogBot)
I noted that:
1. inserting an author name, by example:
Alice Coltrane
?! :-)
I got all tracks related to any "Alice", by example
Moby - Alice some other Cocteau Twins track, etc.
no track related really to "Alice Coltrane", that's probably because you just do an OR on your query, ok, clear.
2. in the web client, in result track list, song names appear truncated... by example I'm not able to read the Cocteau Twin complete title track, in the above example.
As far as I know, Telegram is really really open (at the moment) with really few limitations.
For me, this is a very important fact. yes, is a big (and debated) topic; Pavel Durov express many times the point. See: http://techcrunch.com/video/pavel-durov-of-telegram-whatsapp...
BTW, For another story, I pressed Telegram to know if I could or not use bot apss for commercial business.I puplished on my microblog homepage: twitter.com/solyarisoftware the answer I got by https://telegram.me/botsupport (BTW it's an helpdesk/support center, by humans, see typo :-))
Now as I said in my previous comment, I'm me too an indipendent "artist" sharing my music in a compromise between free/no-free after long struggle with myself.
So MusicBot is great if used by artists/listeners fully aware about intellectual rights of posted contents. Long story. Generally, unfortunately, this is not the common case (awareness). The big risk I see, is that malicious (or simply ignorant/naif) users could post famous music (not necessarly good music), protected by copyrights. Boring Issues alla involving actors!
If I'm not wrong, quickly reading your beautiful synthetic python code, you store music in your server (as a MongoDB blob). ins't it ?
Smart. Superb I could say!
But a possible issue could be that you store music (possibly copyrighted) in your own server.
A possible workaround/proposal is to test your project, avoiding to store stuff in your server, but leaving digital contents in Telegram Servers! if I well remember, until now Telegram do not officially say when file will be purged after upload... Ok that's a "volatile contents" solution. Just an idea, maybe always interesting for sort of "auto-deleting" sahring, as secret messages (but could be wrong).
Another approach, could be, again to do not store anything in your server, no file upload/download, but just manage links to external repositories/specilized websites. An example ? just share links to youtube.com contents; in that way you "delgate" all copyrights possible issues to youtube censors ;-)
BTW, I quickly tested MusicBot looking for an artst and title, I noted that search functionality could be developed to understand better what user are looking for, but this is not a criticism of your excellent work, just a feature for a future implementation!
Thank again for sharing MusicBot respect giorgio
BTW, I'm an "indipendent music maker myself (http://solyaris.altervista.org) and I debate since many years about copyright/copy-left realms. I unfortunately think your good idea, could be abused easly, as someone pointed out :( I'll feedback you later in different comment about this hot specific point.
Anyway, I fully agree with you, when you say that:
>Telegram is amazing platform and I'm looking forward for their next moves.
Absolutely! I think Telegram is moving really great designing the big picture "communication" architecture including: 1- p2p chats 2- groups & supergroups 3- channels 4- bots 5- bots integration in groups and channels
In my opinion this integration of bots INSIDE groups and channels (humans), open new services scenarios, not games! Instead service apps useful for people, in business/application scenarios A real revolution: integration of robots and humans services. I'm serious about it and my twitter microblog: www.twitter.com/solyarisoftware is about that. I wote some ideas about in my draft/raough doc here: https://github.com/solyaris/BOTServer/blob/master/wiki/servi...
> I must admit, that the current generation of bots is quite dumb and we need to move towards natural languages and learning.
I fully agree!
> I also don't think that bots are viable "app platforms". Bots should either be interfaces to bigger services or stand alone smart assistants.
Yes, but: I feel nowadays visual-paradigma/web-interface based/mobile apps are in many cases poor in suppluing real services. I'm basically perplex regarding nowadays glorification of (mobile) web interface as "THE way" (to communicate/to get services/make business). I feel instead that next generation(Telegram) bots could be instead a real revolution in man-machine interfaces for services apps: the (Telegram) chat as prevalent way to communicate for users (see very young people habits...). Now as a text-based chat, in a near future, I see phone-calls + video-calls as front-end (along with text-based chats).
What I mean, and I think I agree with you, is that a possible very interesting world is build-up "intelligent chatbots" machine-learning enabled, astep forward nowadays dumb bots that responds to basic /commands or enabled by some finite state machine dialogs (my project now).
What do you think ?
respect giorgio