I am trying to connect different entity types or entity properties. Consider this case:
I have a list of animals and I have a list of vegetables
Each animal eats a subset of vegetables - Cow eats veggieA,veggieB and Hen eats veggieB,veggieC
Once Cow is in context, the only vegetable entities I want to catch are veggieA and veggieB. Even if veggieC is mentioned, I do not have want to catch this entity for all my follow up intents
How can I achieve this?
Can I have an animals entity type with a list of animals like Cow,Hen etc and a vegetable entity type with a list of vegetables like veggieA,veggieB etc
Or like Each animal form a different entity type - Cow is a entity, Hen is a entity
How can I connect different entities like how I described earlier?
The key point to consider is that any value within an entity (custom or not) will be a valid match for a particular intent that has that entity as a parameter.
Meaning, if you have an animal entity and a vegetable entity, even if you train an intent Cow-intent only with cow as the animal this intent will be matched regardless of the animal you submit. As far as I know you cannot restrict the entity values that are valid within an intent.
For this reason, the easiest approach to ensure your behavior is met is to create separate entities for each animal (group of animals with the same veggies). Then create specific intents for each animal entity which follow-up intent/s will have a specific vegetable entity assigned as well. Meaning, a lot of particular entities instead of general ones. You would have entities: Cow-like,Hen-like,Cow-veggies,Hen-veggies,...
If that seems unfeasible for your particular use case you can also try to keep general entities and code some conditionals in the Webhook Fulfillment to handle your particular behavior, similar to what is done in here.
Related
I don't yet completely seem to understand how association class works, why the role class attributes can't just be inside the person class?
as example:
Person
name
position
description
Suppose we live in a world where a person must have a role in a company in order to live and a company may exist without persons at all.
If that is all you want to know about the relationship between persons and companies, i.e. only the fact that there are such relationships and nothing more, you model it like this:
Then if you want in addition to capture position and description of the Person's role you use so called AssociationClass (Role in our case):
Each instance of Role has four properties (both an attribute and an end of an association are Properties in UML):
Company
Person
position
description
For example, suppose a person named Scott Tiger has roles in two companies - Food Inc and Water Ltd and each company knows that Scott Tiger has role in it. Then there will be two instances of Role (shown as tuples):
(Food Inc., Scott Tigger, eater, eats here)
(Water Inc., Scott Tigger, drinker, drinks here)
Now, returning to you question, it should be clear that an instance of Person with name, position, description attributes actually "lacks" Company and if you "add" an Company you will get Role, not Person!
So what you proposed in the end of your question is a valid design, if you model Company and Role and a person is just an attribute of Role:
It reads as follows: each instance of Company has zero or more Roles and each instance of Role has only one Company. Both ends of the association are navigable, i.e. Role knows its Company and Company knows its Roles.
UML Specification in clause 9.5.3 gives you the following advice:
A Property may represent an attribute of a Classifier, a memberEnd of an Association, or in some cases both simultaneously.
A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association
end, while a property whose type is a kind of DataType is not. This convention is not enforced by UML.
why the role class attributes can't just be inside the person class?
notice the multiplicity 1..*, if you move position and description into Person you have to manage a collection of them and to associate each to the corresponding Company.
[from your remark]
For a given Person the position and description depends on each associated Compagny, so it is not possible to have the fields you propose except if position and description are both a collection, and to have a way/rule to know which entry in position and description correspond to the right Compagny.
Moving also these information in Person you remove the symmetry, it is also possible to move these information in Compagny, with the same remarks as for Person
An association class is both a class and a relation, when you implement it in a language like C++ or Java etc of course that concept does not exist, so one way is as you propose to move the fields in one of the two classes, or to create a third class having the expected fields more one to a Person and one to Company.
The advantage of the third class is to have all the associated information grouped having the equivalent of :
As example an object diagram can be :
Without the third class you need to know how to associate all the separated information, for instance having all in Person using three vectors to memorize the company and position and description you may use the same index value for all, but this is less clear and when you add/remove a Company for a Person you have to update all these vectors.
When you create Intents and enter their sample utterances in LUIS, the parser will sometimes classify some words as being entities. This is a nice feature when it accurately identifies them, but sometimes it mislabels them.
For example, if you have an entity for statuses of a switch (on/off), constructed as a List with "true" and "false" being the values for which "on" and "off" are synonyms, respectively, then every time you use the words "on" or "off" (which have various meanings, uses and purposes) in an intent's sample utterances, they get labeled as that entity, often inaccurately.
The documentation (https://learn.microsoft.com/en-us/azure/cognitive-services/luis/luis-how-to-add-example-utterances) states that List type entities cannot be removed from utterances. Is there any way to avoid simple words that may be used as synonyms in entities from being matched as entities?
Thanks!
I think the only way to do it is to remove those simple words as synonyms (on, off, etc.) from the List entity synonyms (clicking x next to the synonym). Per the message when you create a List entity, they behave differently than other entity types and are direct matching:
Unlike other entity types, additional values for list entities aren't
discovered during training. This entity type is identified in
utterances by the direct matching of utterance text to the defined
values, rather than learning from context.
You could also use simple entities along with Phrase Lists to help boost the signal to those instances where on/off would be an entity that you would want to capture. Adequately supplied phrase lists to help identify those types of instances would be needed.
Simple question:
I have e-r model. I have entity Car. Car can be either BMW or Opel. If it is BMW then it must have color. If it is a Opel then it must have attribute - amount of passangers.
How can it be displayed in e-r model? I mean IF clase.
Thanks!
In an ER model this is normally represented as a sub-type.
http://en.wikipedia.org/wiki/Enhanced_entity%E2%80%93relationship_model
Sub-types can be exclusive or non-exclusive, depending on whether more than one of the sub-types should apply simultaneously. For example, a Bank Account entity might have sub-types for Current Account or Savings Account. These would be exclusive sub-types since a bank account cannot be both. Depending on the type of the account, one of the sub-types is used to "extend" the main entity. On the other hand an entity named Sportsman could have sub-types Golfer and Footballer. The Sportsman entity would contain common information such as name, and the sub-types would contain only the additional attributes applicable to the sport (e.g. Golf Handicap). Records only exist in the sub-type entities when the main entity is of the applicable type. These would be non-exclusive sub-types since it is quite possible that someone plays both golf and football.
In IDEF1X notation it is represented like this
I am learning Core Data so I was confused about the following.
I need to know how the relationships worked in the inherited scenario.
I have a data model with Entities Zoo, Animal , Dog, Lion.
Dog and Lion have Animal as the parent Entity.
Now Zoo has one to many relationship to animal.
I want to know if Zoo will need to have one to many relationship to animal or it need to have to one to many relationship to Dog and Lion. Will the inheritance work in this case or not. Like in future if I add Tiger, Do I need to add that in Zoo relationship or it will work just fine once I inherit Tiger from Animal.
As long as your child entities inherit from the Animal entity, they will also inherit the relationship that the Animal parent entity has with Zoo. It's like class inheritance in OOP, where subclasses inherit variables, methods, etc from their superclasses automatically.
So all you need to do is declare that relationship between Zoo and Animal in your data model, and any new entities you add which extend Animal will have the same relationship with Zoo — there is no extra work to be done to ensure this.
See the Managed Object Models section of Apple's Core Data Programming Guide for details.
This is only an example.
Say that you have 2 entities for 2 different context boundaries. The first context is the SkillContexter, the entity is 'Player' and has 3 properties: Id, Name and SkillLevel. In the other context (Contactcontext) the entity is 'Player' and has 3 properties: Id, Name and EMail.
How do I persist these entities to the database? I only want one table (Player) and not two tables (PlayerContact, PlayerSkill). Shall I have two different repositories for player that save the different context-entities, but into same table? Or shall I have a "master" player entity that holds all properties that I need to save, so that I create a new entity called PlayerMaster that has 4 properties: Id, Name, EMail and SkillLevel?
The first solution gives me more repositories, and the second makes me make a "technical" entity that only purpose is to save data to a database, and that feels really wrong, or is there a better solution that I have missed?
How have you guys solved it?
When I first started with DDD, I also wrestled with the Context + Domain + Module + Model organization of things as well.
DDD is really meant to be a guide to building your domain models. Once I stopped trying to sub-organize my Contexts and boundies, and started thinking of what really is shared between entities - things started to fit together better.
I actually do not use contexts, unless it is a completely different application (app = context). Just my preference. But, I do have Modules that only share base abstracts and interfaces common throughout code (IRepository, IComponent, etc). The catch is, DDD says that Modules can share entities between modules - but, only on a very limited scale (you really don't want to do it often).
With that in mind, I would get away from using contexts and move to a "what really am I trying to accomplish, what do these models have in common). Here's what I would think, reading your question (if I understand them).
Person() is a base entity. It has ID and Name.
PlayerSkill() is a Value Object, that is
accessable from Person().PlayerSkill.
Contact() is an entity that inherits Person(),
so it inherits ID and Name, and has additional Contact properties you want.
Now, I just tore up your domain. I know.
You can use a hybird approach as well:
Person() is a base entity. It has ID and Name.
Player() inherits Person(), applies Skill()
and other VOs.
Contact() inherits Person(), applies Address()
and other VOs.
I'm not quite sure what you mean by context boundaries, so my answer may be off.
Do the two Player entities represent the same physical entity (person)? If so, then I would create a single Player entity with all four attributes and store their data in a single table.