I need to form hierarchical relations between a set of terms(which may be entities, nouns,etc) by mining the web. This is along the lines of a taxonomy, However I need to be able to link Proper Nouns(people) and entities in a meaningful manner.
Eg :
{Movies,Avengers: Age of Ultron,Robert Downey Junior}
Should be linked as
Movies -> Avengers: Age of Ultron -> Robert Downey Junior
How should I go about doing this?
Related
I need to train watson assistant on the following utterance, what is the order status of Bob/Jane or some name.
I tried with #sys-person but it does not recognize all names.
I defined an intent like this
what is order status of #name
and created entity #name as \b[A-Za-z0-9]\b
This is a good use for contextual entities. You can read up on those here:
Contextual Entities with IBM Watson Assistant
All about entities: Contextual entities with Watson Assistanthttps://medium.com/ibm-watson/all-about-entities-contextual-entities-with-watson-assistant-part-2-7697d2b73db0)
The idea is that you don't need your bot to know all possible names in advance, but instead it can recognize a name based on the context within an intent.
To set this up, you'd go to your order status intent and add some training examples such as:
what is the order status of Name
what is the order status of Another Name
what is the order status of Yet Another Name
(These examples can have any kind of name, whether fake or real.)
And then you'll annotate each of those to associate the name with the #name entity, by double-clicking on the name portion of the training examples (i.e. Name, Another Name, Yet Another Name) to bring up the entity selection UI and specifying your #name entity.
After Watson finishes training, you can test it in the "Try it out" window. Enter something like "what is the order status of Charles Flint" or "what is the order status of Thomas Watson" and you should see your #name entity matched. From there, you can access the name specified by the user with #name.value.
Hi JohnDon't wish to dismiss your entity pattern, however from experience I have seen its almost impossible to determine a complete list of people names. I use both #sys-person and my own #names entity which contains over 6,000 common names, and we are still adding missing values to the list. We also have a #bad_names list which contains names that match common words like; summer, cherry, star, cj, etc. By using both your intent or #sys-person or #names, etc in your condition you have a good chance to catch a high percent of the users messages.
I'm trying to build an NSPredicate to satisfy a given relationship. My data model has the following: University -> College -> Classrooms - ClassroomType
A university object has 1 to many colleges.
A college object has 1 to many classrooms.
Each classroom has a given classroom type with a specified property
i'm interested in.
That property is called typeDescription I want to build a query that can give me all universities that have a typeDescription equal to the value "computerlab". The objects that I have available to me are a list of Universities. I'm pretty sure that I'll need to construct an NSPredicate SUBQUERY but I'm not quite sure no how to build this to satisfy my requirements. If anyone has any input on the right way to build this query it would be much appreciated.
For one-to-many-to-many relationships, you need to nest two SUBQUERY clauses:
NSPredicate(format:"SUBQUERY(colleges, $c, SUBQUERY($c.classrooms, $room, $room.classroomType.typeDescription == %#).#count > 0).#count > 0","computer lab")
I would like some help as the data structure in Firebase. I've read the API guide and some blog articles like these:
Queries, Part 1: Common SQL Queries Converted for Firebase
Firebase: Now with more querying!
Denormalizing Your Data is Normal
I'm leaving SQL (MySQL and SQLite specifically) and trying to migrate to Firebas. I would like to know how to structure these tables and relationships for a structured JSON in Firebase.
Relationship 1-1; 1 - N; N - N;
I'm sending a picture of an example database containing some relationships, could you give me this support would look like this in the database you? Remembering that I need to consult with the data about the same as would query in SQL.
This is my Database:
I'll take a shot at this...
First and foremost, Firebase is not a relational database so it should not be thought of in those terms. However, you can craft 'relationships' between data that (for an end user) feels 'relational'
Let's use a Departments and Employees-like example. A department can have many employees and those employees belong to that department.
departments
dept_00
dept_name: "Bridge"
dept_01
dept_name: "Engineering"
dept_02
dept_name: "Medical"
crew
crew_00
crew_name: "Kirk"
in_dept: "dept_00"
crew_01
crew_name: "Scotty"
in_dept: "dept_01"
crew_02
crew_name: "Bones"
in_dept: "dept_02"
crew_04
crew_name: "Spock"
in_dept: "dept_00"
With this structure, a query can be performed for crew that are bridge members: here's an ObjC snippit
Firebase *ref = [myRootRef childByAppendingPath:#"crew"];
FQuery *q1 = [ref queryOrderedByChild:#"in_dept"];
FQuery *q2 = [q1 queryEqualToValue:#"dept_00"];
[q2 observeEventType:FEventTypeChildAdded withBlock:^(FDataSnapshot *snapshot) {
NSLog(#"%#", snapshot.value);
}];
This will return the crew_00 (Kirk) and the crew_04 (Spock) nodes.
Note the disassociation between the data (Bridge, Engineering) and the node name (dept_00, dept 01). This allows the data to be modified without breaking 'links' between them. So I could rename 'Engineering' to 'Scotty's Hideaway' and everything will continue to work. Those 'random' node names would be generated by a push() in firebase or ChildByAutoId (objc)
Likewise, if we know the crew member name (Bones) we could query for that specific node to return that he belongs to dept_02 (Medical).
You could expand beyond this in cases where say, Spock and Bones belongs to several different departments, say Bridge and Engineering, by adding another node to track which departments the crew member belongs to:
belongs_to
crew_02
dept_00: true
dept_02: true
crew_04
dept_00: true
dept_01: true
Here, crew_02 (Bones) is now in the Medical and Bridge departments (much to Spocks dismay) and crew_04 (Spock) is now in the Bridge and Engineering Department. With this added belong_to node, the in_dept child nodes could be removed from the crew node.
That should cover one to one, one to many and many to many
I want to model 2 entities in database: CafeBrand and Cafe. I have pretty much the same properties in both entities:
CafeBrand{
foodDescription,
website,
email,
phone
}
cafe{
foodDescription,
website,
email,
phone
}
So let's say in case of McDonalds all 'cafes' would have the same foodDescription: 'Junk food'. But some other brands might have separate food description for separate cafes('sandwiches', 'drinks only', ...).
Same with website/email/phone properties: cafe might have its own website/email/phone but also it could be using the same website/email/phone for all of them. Quite often the same CafeBrand has one website but different email/phone for its different cafes.
My question is: is it wise to store these properties as it is and then use if/else (in SQL or code) to get a proper description,website,email,phone (if cafe.website == null then use cafebrand.website) or is it better to use relationships to separate tables 'FoodDescription', 'Website' The data won't be written to the database very often and most of the time only select statements will be used.
And if Company has a single cafe. How should this foodDescription/Website be split into CafeBrand/Cafe tables.
As Bill Gregg has mentioned you should probably put all similar data in one table. So you'll receive following structure:
cafe {
foodDescription,
website,
email,
phone,
brand
}
Because of foodDescription, website and so on columns will contains pretty unique values I assume, you won't gain any profit with separation the data into different tables.
I am working on a project where I need to have data inherit at variable depths, and then be able to return any descendants of a particular piece of data. I am working with geographical regions, so I was thinking about having a "Region" table, and have everything from "North America" to individual neighborhoods such as "Bronx". So, if someone types in "North America", they should also receive results for "Bronx" because "Bronx" is a descendant of "North America" by means of the relationship
North America->United States->New York(State)->New York(City)->Bronx
In my DB I was planning on having the Region table link back to itself with a table that specifies a parent/child relationship between Regions. Here is an example of what I would propose:
Any help would be greatly appreciated!
Do you dont need a new table. A foreign key in major table is enough.
This is my approach:
First problem, design data schema: I keep hierarchis with a foreign key to parent row. It is simply. You have an example with hiererchy regions here:
WOE_ID ISO Name Language PlaceType Parent_ID
20069843 "NA" "Oshana" ENG State 23424987
55921113 "NA" "Ondangwa" ENG County 20069843
...
Second problem, retrieve ascendants/descendants: As you explain, problems comes with select: select some region and all descendants os ascendants. To solve this you should to create a new tree table. This table contains pairs: al combination to a person with all they ancestors (and itself):
region( id, name, id_parent)
region_tree( id, id_ancestor, distance )
Noticie that with this structure is easy to query hierarchies. Sample: all descendants of some region:
select region.*, distance
from
region p
inner join
region_tree t
on ( p.id = t.id)
where
id_ancesor = **someregion.id **
You can play with distance to get only sub-regions, sub-sub-regions, ...
Last problem, keep tree: tree must be all time up to data. You should automatize this: a trigger over region or a store procedure for CRUD operations,