This is not so much a specific programming related question but more on the planning part.
So I have posts in my DB that look like the below:
{
"_id": "57f88bb94b5342b2025d5646",
"postID": "12345",
"profileID": "12345678",
"title": "testT",
"description": "testD",
"views": 0,
"dateCreated": "2016-10-08 06:01:29",
"categories": [],
"__v": 0
}
Now, I am creating the front-end part for it and I need to create the categories from a dropdown list or something similar.
I know I can just populate it or get it from from the DB but where does the list actually come from? I mean say I need to create a post about Lamborghini, it comes under brand and automobile categories.
What I am essentially after is a place where I can grab these categories and their sub-categories.
Does anyone know of such a service/API? Is there another way?
By the way, I am on the MEAN Stack.
Thanks,
Shayan
In the end, I just created the list from all sorts of different sites and made it into one list.
Sadly, it looks like there is no such API service for this.
Related
We have stumbled across a bug that I can only assume is a bug with the JSON API code. This is for the old laravel JSON API (in my composer.json file its "cloudcreativity/laravel-json-api": "^2.0")
The issue is when a resource is included multiple times (in different ways), it is possible to not get all the include information you asked for.
In my example, I am dealing with timesheets. Timesheets belong to a user. They are also approved by a user. Those users are usually different users, but not always. If I want to include both, I would add include=user,approved-by, and this works great.
The front end also sometimes needs to know the employeeType of the user, so we instead use include=user.employee-type,approved-by, and again this works, we get the employee type info for the user. The issue arises when the user is the same as the approver. It appears that JSON-API gets the approved-by user (without the employee type include data), then when it tries to get the timesheet user, it sees that is has already grabbed that user, and just stops there.
The difference in the output is:
The include with the related in
"employeeType": {
"data": {
"type": "employee-types",
"id": "1"
},
"links": {
"self": "link url",
"related": "link url"
}
},
Vs the include without all the related info
"employeeType": {
"links": {
"self": "link url",
"related": "link url"
}
},
We have a work around, where we need to include the employee type of the user and a the approver, but that seems cumbersome and annoying.
I was wondering if anyone knows if there is any good fix for this? Or if this has been fixed in the more recent version (could be the kick in the pants we need to actually migrate to the most recent version of the library)
When generating a Dispatch model using the CLI, it doesn't pass the Entities from the Luis app in reference. This drastically affects the accuracy of the dispatch app.
For example, for the utterance "My [iPhone] isn't working", iPhone is attached to an entity list name CellPhoneType. There are three items in the list iPhone, Samsung, Smartphone.
In the bot emulator, using the Dispatch, if I write "my iPhone isn't working", the dispatch model passes it to Luis, as it should. However, if I write "my smartphone isn't working", the dispatch tool sends it over to QnA Maker.
I checked the model, and the entities are not passed in reference. I also tested with simple entities, they do not work as well.
I have the most recent version of the CLI installed.
Is this normal, is this a bug? Is there a work around to fix this?
So a couple things to address here with how you've built your LUIS model and what to expect from dispatch. Skip down to 2.) if you're a user who's reading this post and already has entities working in child LUIS models beautifully. #AlexandreViegas, read point 1.) to help properly build your LUIS model to detect intent properly in dispatch.
1. Use a Simple Entity + Phrase List to take Advantage of LUIS's machine learning--not List Entity
Right now it seems like your choice of using a list entity is not the best way to go here, and not how it's intended to be used. Instead list entities are used for terms that might have multiple ways of referring to the same thing.
Examples of When You Would Want to Use a List Entity
For example, California, Cali, CA, and The Golden State are all terms that refer to the same thing (a state). You can create a "States" list entity, include all 50 U.S. states and their nicknames. Now since this is a closed, explicit list, there is no machine learning when you use a list entity--LUIS will only detect "States" list entity if there's an exact text match.
Another example of when you would want to use list entities would be say with "Departments" for a school. You could have "chemistry", "CHEM142", "chem", etc. all meant to refer to that specific department, and do so with the rest of the departments in the school.
Why you want to use a Simple Entity and add a Phrase List
You can refer to this other StackOverflow answer I wrote, regarding how to create a simple entity and boost the signal of the entity using a phrase list.
To not completely duplicate the answer given in the link above, in essence, you want to use a simple entity, so LUIS can properly predict terms as CellPhoneType entity, even though you did not explicitly include it in your model.
For example you could have a Phone intent with utterances labeling various words as CellPhoneIntententity.
When I go to the Test panel, I type in "sunflower" and "moonstone" as made up mobile phones (maybe some phone company in the future creates phones with these names as their models):
Above you can see LUIS correctly predicts Phone intent and correctly extracts sunflower and moonstone as CellPhoneType entities.
However if I enter in brand names of mobiles that don't exist in the English language--for example Blackberry's "Z3" or T-Mobile's "G2X", LUIS cannot detect this with our model as is right now. (See 2 most recent utterances).
Above you can see utterances "i'd like to order a z3" and "my g2x is broken" do not properly predict as Phone intent, nor do z3 or g2x get detected as CellPhoneType entity. This is where phrase lists come in. As specified in the docs, phrase lists are good for boosting the signal of what a cell phone type may look like, as well as adding proprietary or foreign words to your LUIS model, such as the "made-up" words of many cell phone models. Again, refer to the StackOverflow answer I linked to, if you need guidance on how to create a phrase list.
After adding different names of cell phone models to phrase list
2. Query the endpoint of the LUIS model that was created by dispatch directly
Clarification:
When you add a child LUIS model to dispatch, even if that child LUIS model has entities in it, it will not show up in the model of the parent LUIS model created by dispatch.
the exception to the above bullet would be if you labelled an entity in a pattern
Why entities do not need to be labelled in the parent LUIS model, is because when you call the endpoint of the parent LUIS model, it does sort of a shared call, under the hood, so it doesn't have to ping LUIS twice.
You see the entities labelled from the child LUIS model in the connectedServiceResult property
How to extract entities from child LUIS model, using your parent dispatch LUIS app
Make sure to publish both the child LUIS app and the parent dispatch app.
Going to your parent dispatch-created LUIS app, go to Manage > Keys and Endpoints > click "Endpoint" to open a browser tab where your can query the parent app in the URL after q=
type in your utterances in the URL, after q= to see the entities and intents extracted from the child LUIS model under connectedServiceResult
https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx?verbose=true&timezoneOffset=-360&subscription-key=b7xxxxxxxxxxxxxxxxxxxxxxxxxxxx67&q=my%20iphone%20is%20broken
{
"query": "my iphone is broken",
"topScoringIntent": {
"intent": "l_Reminders",
"score": 0.99594605
},
"intents": [
{
"intent": "l_Reminders",
"score": 0.99594605
},
{
"intent": "None",
"score": 0.002990469
}
],
"entities": [],
"connectedServiceResult": {
"query": "my iphone is broken",
"topScoringIntent": {
"intent": "Phone",
"score": 0.9658808
},
"intents": [
{
"intent": "Phone",
"score": 0.9658808
},
{
"intent": "Calendar.Add",
"score": 0.0142210266
},
{
"intent": "Calendar.Find",
"score": 0.0112086516
},
{
"intent": "None",
"score": 0.009813501
},
{
"intent": "Email",
"score": 0.0025855056
}
],
"entities": [
{
"entity": "iphone",
"type": "CellPhoneType",
"startIndex": 3,
"endIndex": 8,
"score": 0.998970151
}
]
}
}
Above you can see that the parent LUIS app created from dispatch properly identifies iphone from the utterance my iphone is broken as a CellphoneType entity.
Note: you will not see results from the child LUIS model in the Test panel of the parent dispatch, because the UI does not show connectedServiceResult
In LUIS, on the intent page, I have 5 utterances that use the same entity in each. Under the utterances is the list of entities used in the intent. As you can see from the attached image, it lists the entity I have used and the correct count (5), but it also lists another entity that I have not used and says there are 2.
I have refreshed the page and trained and it is still showing the incorrect number of entities. I am concerned this error will affect the results. Is it a known issue, and can it be fixed?
The suggestion to export and reimport the app into a new app did not solve the problem, but when I looked at the export file I figured it out. Actually both of the entities were there in some of the utterances, just hidden one on top of the other, so they didn't show up in the interface.
example utterance:
{
"text": "how much will i be charged for my clonazepam",
"intent": "PHARMACY_DRUG_INQUIRY",
"entities": [
{
"entity": "Prescription",
"startPos": 34,
"endPos": 43
},
{
"entity": "Procedure",
"startPos": 34,
"endPos": 43
}
looks more like a portal glitch to me. Have you tried following
1) Logging out of the portal and logging in again to check?
2) If yes, please try to export and reimport the app definition in a new app.
Let us know your observations
I'm currently working on a project in which we perform "Nearby" queries for places using keywords, and then we make follow-up "Detail" requests to obtain more information about specific places of interest.
With Google's new pricing model in the works, the documentation warns about the cost of the Nearby search, but the warning seems to imply that the follow-up detail request will no longer be necessary because our original search should give us everything we need:
By default, when a user selects a place, Nearby Search returns all of
the available data fields for the selected place, and you will be
billed accordingly. There is no way to constrain Nearby Search
requests to only return specific fields. To keep from requesting (and
paying for) data that you don't need, use a Find Place request
instead.
However, I'm not seeing this. When I run a sample request, the results from my Nearby request contains only minimal data related to the places Google finds. To get details, I still have to do a follow-up detail request.
Does anyone know if there's something I may be overlooking? I'm including my request URL (sans API key).
https://maps.googleapis.com/maps/api/place/nearbysearch/json?key=xxxxxxxxxx&location=30.7329,-88.081987&radius=5000&keyword=insurance
And this is an example of one of the results I received:
{
"geometry": {
"location": {
"lat": 30.69254,
"lng": -88.0443999
},
"viewport": {
"northeast": {
"lat": 30.69387672989272,
"lng": -88.04309162010728
},
"southwest": {
"lat": 30.69117707010728,
"lng": -88.04579127989273
}
}
},
"icon": "https://maps.gstatic.com/mapfiles/place_api/icons/generic_business-71.png",
"id": "53744cdc03f8a9726593a767424b14f7f8f86049",
"name": "Ann M Hartwell - Aflac Insurance Agent",
"place_id": "ChIJj29KxNZPmogRJovoXjMDpQI",
"plus_code": {
"compound_code": "MXV4+26 Mobile, Alabama",
"global_code": "862HMXV4+26"
},
"reference": "CmRbAAAAcHM1P7KgNiZgVOm1pWojLto9Bqx96h2BkA-IyfN5oAz1-OICsRXiZOgwmwHb-eX7z679eFjpzPzey0brgect1UMsAiyawKpb5NLlgr_Pk8wBJpagRcKQF1VSvEm7Nq6CEhCfR0pM5wiiwpqAE1eE6eCRGhQPJfQWcWllOVQ5e1yVpZYbCsD01w",
"scope": "GOOGLE",
"types": [
"insurance_agency",
"point_of_interest",
"establishment"
],
"vicinity": "70 N Joachim St, Mobile"
}
I thought about deleting this question, but I guess I'll leave it up in case anyone else is confused like I was.
It turns out the extra detail fields I was looking for in the Nearby Search results were there...sort of.
Google's new pricing model categorizes place data fields into three tiers: Basic, Contact, and Atmosphere (Basic data is free, but the other two add to the cost).
As part of these changes, Place API calls have been expanded to allow users to specify the data fields they want so that they don't have to pay for that extra data if they don't need it.
The Nearby Search query, as per the note in the question, includes all the data fields available, and doesn't support a parameter for controlling the data -- it's always going return data that falls into the [Basic + Contact + Atmosphere] bucket.
So far, that's all well and good.
Where things became confusing to me, though, is the specifics of what is included in the different data tiers. I skimmed through these notes several times before I noticed the contents were different.
This is how the fields break down with the Places details request:
Basic
The Basic category includes the following fields: address_component,
adr_address, alt_id, formatted_address, geometry, icon, id, name,
permanently_closed, photo, place_id, plus_code, scope, type, url,
utc_offset, vicinity
Contact
The Contact category includes the following fields:
formatted_phone_number, international_phone_number, opening_hours,
website
Atmosphere
The Atmosphere category includes the following fields: price_level,
rating, review
And this is how it looks for the Places search request:
Basic
The Basic category includes the following fields: formatted_address,
geometry, icon, id, name, permanently_closed, photos, place_id,
plus_code, scope, types
Contact
The Contact category includes the following field: opening_hours
(Place Search returns only open_now; use a Place Details request to
get the full opening_hours results). Atmosphere
The Atmosphere category includes the following fields: price_level,
rating
I haven't found documentation for it, specifically, but the results from a Nearby Search request seems close (but not identical) to the Place search (including Contact and Atmosphere).
I had originally thought the fact that Nearby Search results now include Contact and Atmosphere data (when available), that meant it would contain all the fields itemized as Contact and Atmosphere data in the Place details documentation, but that's not the case.
As per below link create interest functionality is nto avaialable.
http://developer.mailchimp.com/documentation/mailchimp/reference/lists/interest-categories/interests/#
But using API playgroung you can create interest. Even tried with REST api and I am able to create interest. Please let me know if "create interest " API has been removed from above page.
I think it never wasn't on that page. This new API Documentation lacks many things that are possible.
If you want to create new interest you can just POST to this endpoint:
/lists/{list_id}/interest-categories/{interest_category_id}/interests
Example request body:
{
"list_id": "id_of_the_list",
"name": "name of the interest",
"display_order": 1
}
So the answer for your question is that I am pretty sure they just haven't created documentation for that one yet.