I'm trying to use freebase to return a cities related country ISO code.
I have this MQL which works but it doesn't work on certain cities and there's probably a more straight forward way to do the same thing?
{
"id": "/en/amarillo",
"/location/location/containedby": [
"/location/country/iso3166_1_alpha2": null,
"type": "/location/country"
]
}
It doesn't work occasionally for smaller cities. Even better would be a way to use the Freebase suggest (which I use to gather the city) to return the ISO code in the same request?
jQuery ->
$("#city_name")
.suggest(type: "/location/citytown")
.bind "fb-select", (e, data) ->
$("#city_freebase_id").val data.id
That's basically how I'd do it, but, as you've discovered, the data isn't incredibly fully populated. One tweak that you could make to improve your odds of finding something would be to go up an additional level in case, for example, the city is contained by a state which is contained by a country. You're also missing a set of curly braces in your subquery which will probably cause your query to fail in the API (the query editor silently fixes up stuff like this).
A revised query that goes up an additional level and fixes the braces would look like this:
{
"id": "/en/avondale",
"/location/location/containedby": [{
"/location/country/iso3166_1_alpha2": null,
"type": "/location/country"
}],
"l2:/location/location/containedby": [{
"id":null,
"/location/location/containedby": [{
"/location/country/iso3166_1_alpha2": null,
"type": "/location/country"
}]
}]
}
The search API has an mql_output parameter that could be used to do what you want, but I'm not sure it's used by Freebase Suggest. It's not documented to be available. If it's not in the code either, it wouldn't be too hard to hack the widget to add this.
Related
First off, I do not want to use AMAZON.Literal as it is for US only (I'm UK based) and I doubt it will be supported much longer.
I need a wildcard slot to allow users to say a place name (name of a shop for example), followed by the city.
City is easy, no problem.
The issue is the place name. I have a custom slot, but I can't list every shop in every city in the values.
I put a value of any in, which kind of works, but in my response, I'm only getting the last word if the user says a name that contains a few words e.g. Pound Land would just return Land.
Has anyone managed to do this?
As of 2018, you can use phrases to get user input that you may not be able to predefine.
{
"intents": [
{
"name": "SearchIntent",
"slots": [
{
"name": "Query",
"type": "AMAZON.SearchQuery"
},
{
"name": "CityList",
"type": "AMAZON.US_CITY"
}
],
"samples": [
"search for {Query} near me",
"find out {Query}",
"search for {Query}",
"give me details about {CityList}"
]
}
]
}
https://developer.amazon.com/blogs/alexa/post/a2716002-0f50-4587-b038-31ce631c0c07/enhance-speech-recognition-of-your-alexa-skills-with-phrase-slots-and-amazon-searchquery
When using custom slot types, AWS may return values from outside of the list yet it will try to map to the values. You can "hack" this behavior by providing a huge list of possible values. Maybe try to scrap a list of places and use that. I once tried with a list of 3000 landmarks and it was definitely returning slot values that were not in the list. The recognition was not great but I had an acoustic similarity function that allowed me to retrieve items from the list when needed. That was a while ago when they first talked about deprecating Amazon.LITERAL but eventually left it so I didn't have to worry about this.
I am using the google cloud vision api to analyze pictures. Is there a list of all the possible responses for the labelAnnotations method?
The API reference of Vision API gives an overview of all the possible JSON responses for the different image annotation requests.
The labelAnnotation request returns a generic EntityAnnotation response, you can find the JSON representation here, also containing more information about the JSON representation of BoundingPoly, LocationInfo and Property:
{
"mid": string,
"locale": string,
"description": string,
"score": number,
"confidence": number,
"topicality": number,
"boundingPoly": {
object(BoundingPoly)
},
"locations": [
{
object(LocationInfo)
}
],
"properties": [
{
object(Property)
}
],
}
I think you're asking whether you can get a look at the list of possible labels/entities that the Cloud Vision API will detect. If that's the case, the short answer is no, not in any manageable way.
The more complicated answer is sort of, since most labels will have a property for the knowledge graph entry (e.g., {desc: 'dog', mid: '/m/0bt9lr'}). This means that you can look-up more information about the label/entity using the Knowledge Graph API.
While you can't "store a copy" of Google's Knowledge Graph as a list of choices in a drop-down on a page, you can use the API to do a look-up after the Vision API responds with an ID.
I have meteor application made up of "notepads", each containing an array of "notes" which can be inserted into at any position, deleted from or have rows edited. This array is contained within an object with a variety of other information (ex. name, users, etc). Each object in my primary document will contain one of these arrays. For example:
{
"_id": "1234",
"name": "NotePad123",
"notes": [ {note: "this is my first test note"},
{note: "this is my second test note"},
{note: "this is my third test note"} ]
},{
"_id": "4321",
"name": "NotePad321",
"notes": [ {note: "noteA"},
{note: "noteB"},
{note: "noteC"} ]
}
Is there any way I can pass the "notes" as its own collection to my client so that the client can directly edit it as if it were not embedded? I am worried about a performance hit if I need to be passing the full notes array to the server every time I want to update it as there may be many updates it could become quite large.
I realize that I could create a new document and reference it, as described here, but this could become quite hectic with many "notepads" as ordering is important and I will have many rows associated with each of my primary objects.
You can make a client-side collection that you put the notes in. Then, call a method to make the changes once you want to save.
Here's how you make a client-side collection:
var notes = new Meteor.Collection(null)
I currently use MySQL, after looking into Document DB it seems like it may be a good move. I do a TON (95%) of querying for single records. As my database gets larger, the time its taking to do this seems to be getting slower. Both reading and writing. I'm curious based on the (simplified) scheme below if it could be a good move to a DocumentDB, and what the layout would be for said schema (i'm a bit new to documentDB)
User
UserID
Username
CreatedDate
Tank
TankID
UserID REF User.UserID
TankName
Awards
Map
MapID
MapName
MapFIle
MapData
MapID REF Map.MapID
TankID REF Tank.TankID
Rank
Color
TimePlayed
Equipment
Everytime a player joins, the data from Tank,MapaData is Queried to gather a full tank object. Every time they die, win an award, kill somebody, or exit the game, the data is then written back out to tank,and mapdata.
The website queries the User table for login, which stores the username and a hash of the password. Once logged in the users are able to modify/delete/create new tanks on the website, which inserts records into the tank/mapdata tables.
The website also stores Top 25 in the World, t25 in map, t25 for each color, t25 for each color for each map.
That's about the only query patterns I can think of at this moment.
Based on the provided information you have the choice of several schema designs (with JSON as examples). I've made some assumptions, such as that more than one tank can be on one map and map data is only linked to a single map. You have to tweak it for your needs. I also try to provide some advantages and disadvantages of every solution.
Option #1 (Single collection)
This should be the easiest, but not the best solution. Here you put everything into one document with extreme "denormalization".
{
"mapname": "map1",
"mapfile": "mapfile1",
"data": {
"rank": "rank1",
"color": "color1",
...
"tanks": [
{
"name": "tank1",
...
"user": {
"name": "user1",
...
}
},
{
...
}
]
}
}
This solution works best when you do a lot of writes, rare updates and reads where you want to get all information together. On the other side it has a lot of disadvantages, such as storing user information directly into your application data (an example would be the password hash).
Option #2 (Two collections)
Put your user data into one collection and the other data into a second collection.
User collection
{
"id": 1,
"username": "user1",
"password": "passwordhash",
...
}
Data collection
{
"mapname": "map1",
"mapfile": "mapfile1",
"data": {
"rank": "rank1",
"color": "color1",
...
"tanks": [
{
"name": "tank1",
...
"user": userId
}
},
{
...
}
]
}
}
This option is a lot better than the first one. First you don't want to have sensitive user data (such as the hash of the password) in a collection with your other data. Also this works better for reads of the user object, because you just retrieve the information you need without skipping a lot of not needed fields. A disadvantage is that heavy write operations on the tank object can become a problem.
Option #3 (Three collections)
The next step could be to move the tanks out of the data collection into their own collection.
User collection
{
"id": 1,
"username": "user1",
"password": "passwordhash",
...
}
Tank collection
{
"name": "tank1",
...
"user": userId
}
Data collection
{
"mapname": "map1",
"mapfile": "mapfile1",
"data": {
"rank": "rank1",
"color": "color1",
...
"tanks": [
idOfTank1,
idOfTank2,
...
]
}
}
This works best for a lot of writes of single objects, such as the tanks, and reading tanks from their collection. This solution has its problems when reading a lot of data together, for example if you want to get a map and all the tanks in that map. In that case you have to resolve the dependencies of the tanks and the map data.
Summary
As seen, schema design is not easy in a document-oriented database. This is the reason why I asked for the query patterns. To come up with a good design you have to know most of the query patterns in advance. To get started, you should create a simple prototype with a design you think makes sense and test your query patterns with some test data. If that works, you can make minor changes to get even better performance. If not, rethink your query patterns and how a better design could look like. Keep in mind that you don't need a full-blown application for that. Most of that can be tested before a single line of code is written, for example with the administration shell of MongoDB or a simple console application in the case of DocumentDB.
I am trying to get the notable_for field for this person, which appears on the web site
http://www.freebase.com/m/01z7_f
but this query returns an empty field
[{
"type": "/common/topic",
"notable_for": [],
"mid": "/m/01z7_f",
"name": null
}]
Am I using the right query here?
notable_for is a "synthetic property" which can't be queried via MQL. It is included in the Topic API though, so that's the thing to use if you need this property.
EDIT: One additional note -- the notable_for and notable_type properties are included in recent Freebase data dumps, so they can also be accessed that way:
$ zgrep ns:m.01z7_f freebase-rdf-2013-06-30-00-00.gz | grep notable
ns:m.01z7_f ns:common.topic.notable_for ns:g.1258t0lp5.
ns:m.01z7_f ns:common.topic.notable_types ns:m.01xrzmg.