Shorten location names for Alexa to say

[eBucher]

As of right now, there are long location names being stored in the database and different versions of the same name. For example, here are ways that the Green Music Center is listed in the database:

• Green Music Center | 1141 (Musician's Lounge), Green Music Center | Joan and Sanford I. Weill Hall, Green Music Center - Weill Hall Lobby
• Green Music Center | Joan and Sanford I. Weill Hall, Green Music Center - Weill Hall Lobby
• Green Music Center | Schroeder Recital Hall Lobby, Green Music Center | Schroeder Hall

They are slightly different, but the user is probably only going to care about the event being at the Green Music Center and would not want to hear the entire location being read (especially since some are repetitive). On the other hand, for some buildings, the user would probably want to know the specific location listed, such as whether something is in Ives 76 or Ives 101.

The goal is to come up with a way to shorten long names to what the user would likely want to hear. Not all location names should be shortened, but some (like the green music center example) should be. See the suggestions listed below for doing this.

[eBucher]

Possible solutions:

• Add a new column or lookup table to the database to store the way Alexa should say things. We would manually have to enter the way we want her to say location names, but since there are a limited number of locations around the campus, it would probably be low maintenance in the future once most of them are stored.
• Create a method to look at the location name, and if it contains a certain string, then replace the entire name with the simplified name before Alexa says it. For example, it could look through the location to see if it contains "Green Music Center", and if it does, just replace the entire string that will be used as part of our response with "Green Music Center".

[ghost]

This functionality would ideally be implemented in the database in order to minimize the latency of our responses. The additional table or column approach would be fairly straightforward, but the search and replace method might be more appropriate or scalable.

I'm in the process of checking what language extensions I can install on Amazon RDS to make the task more approachable.

[ghost]

Another thing that comes to mind on this is that I noticed some of these locations are actually a comma-separated list of different rooms at the same location. We could potentially break the locations down into buildings and rooms, by altering the schema as such and tweaking the scraper to break the field apart for us.

[ghost]

I think creating columns for SSML marked-up versions of the locations (as well as event types and categories eventually) would be easiest, at the possible expense of some duplication of information.

On the other hand, a series of transformations approach could transform a location into something sensible and the result of that could pass through a function that transforms words Alexa has trouble with into SSML marked-up versions. The "pronunciation function" would be reusable for any field, and different versions of the first function could be made for any field.

For example, to apply the same process to the event descriptions, we would make a function that strips the HTML tags (and any other transformations we need to get a presentable string), then that string would pass through the pronunciation function.

The decision can be up to whoever wants to tackle the problem, but I suspect the latter is more challenging and more interesting. The first solution would be tedious but simple enough.

We should get the rest of the calendars in the database before deciding either way, so this issue is blocked by #5

[pineda756]

Shortened responses where necessary.

[ghost]

This was merged as #74