I'm thinking through a domain model, if I want to get the most out of Grakn's reasoner is it better to have more relations or more subtypes?
What should I be thinking about when considering various ways of modelling in Grakn?
When thinking about how to model your domain in Grakn, we suggest focusing on how specific concepts behave in order to decide if you should be using a relation or a subtype.
So you subtype if you think the subtype is really a valid subtype, or use a relation if you think that a role is a better description of the behaviour of that type.
For example, consider person and teacher.
You could subtype teacher from person, but then what happens when a person is both a teacher and a student? In this case person should play the roles teacher and student in a relation instead of using inheritance (subtyping).
Related
The same question is like in the topic.
When using AWS documentation, they recommend that you keep your related data in one table. But reading the various comments from other users, for the most part, I saw not to use nested objects (list of maps). So what is it really supposed to look like?
When we use maps/lists, we are often modeling one-to-many relationships. For example, here's an example where I model the relationship between Users and their Hobbies.
This strategy works fine to model one-to-many relationships if you don't have any access patterns around searching users by hobby. For example, if your access pattern includes "fetch all users who like photography", this is not a good way to store your data. Instead, you may consider storing hobbies like this
This data model allows you to fetch users by hobby, something you couldn't do in the prior example.
There is no single way to model data in DynamoDB. Instead, there are common strategies and patterns that model various relationships (one-to-many, many-to-many, etc). The best strategy for any particular situation will depend on the needs of your application.
I was going over some of the docs here.
I was curious why Grakn opts to indicate relations using noun semantics rather than verb semantics? In most of the other graph work and research I’ve covered, it usually makes sense to think that two entities (nouns) are linked by a verb e.g. person worked at company. Indeed, for a few entities that I am dealing with, it is a bit difficult to reason about the relationships as nouns for example if artist remixed track.
I’m inclined to use verbs as relations but I wonder if that is not how I should be thinking about it in a Grakn setup. Are there eventual difficulties I can expect to face if I decide to use verb semantics?
Typically, graph databases use directed edges to represent binary relations. Under those circumstances it makes sense to use a verb to describe a relation, since verbs often indicate a directional action between a subject and an object.
Grakn is a knowledge graph, which works differently. This is because relations in Grakn act as hyperedges. This means that there can be more than two participants (called roleplayers) in a relation. This is great for flexible modelling, but it can break the verb naming convention.
To work from your example, rather than artist remixed track, we could (very conveniently in this case) use the noun remix as the relation. Taking a guess at the domain model, an artist remixes a track, and as a result they have created a new track. That’s a great opportunity for a ternary (3-way) relation in grakn. The model for that would be as follows:
define
remix sub relation,
relates original-track,
relates remixed-track,
relates remixing-artist;
track sub entity,
plays original-track,
plays remixed-track;
artist sub entity,
plays remixing-artist;
Once the schema above has been defined in Grakn, we can add a remix instance connecting two new tracks and a new artist like so:
insert
$o isa track, has name "Brimful of Asha";
$rt isa track, has name "Brimful of Asha (Norman Cook Remix)";
$a isa artist, has name "Norman Cook";
$r(original-track: $o, remixed-track: $rt, remixing-artist: $a) isa remix;
It has then proved useful to use a noun for the relation because it doesn’t connect any of the 3 roleplayers it can have in a binary way. Instead we have named the concept that sits in-between the two tracks and the artist.
In this way we see that the relation nicely describes the (undirected) link between any pair of the roles:
original-track <-remix-> remixed-track
original-track <-remix-> remixing-artist
remixed-track <-remix-> remixing-artist
We can see that using remixed in place of remix wouldn't work so well, it would try to add direction to these links where there is none.
Grakn's data model can be extended on-the-fly. Therefore even if you start with a binary relation, should you later add more roles, making it ternary or N-ary, verb naming will no longer make sense.
It’s not always easy to name relations with nouns.
My suggestions are:
first try using a past or present participle of a verb (used as an adjective) with a noun. For example the role remixing-artist uses this.
resort to verbs when using nouns is really awkward, and/or if you’re dealing with a relation that you expect always to be binary.
If you must use verbs as relation names, then use the gerund form (which for all practical effects, acts like a noun). e.g.
faceting sub relation,
relates facet-assignment,
relates assigned-facet.
listing sub relation,
relates list-assignment,
relates assigned-list.
I'm a little confused on what the relationship would be for the scenario below. When examples of composition are used they always tend to use simple ones such as rooms and a building.
This scenario is that doctor patient visits are recorded. Would it be an association, composition or a mix of both? I've included a picture below of the two different relationships I am stuck between. I am thinking composition because the visit belongs to each party?
Derived association
In general my rule of thumb is that when in doubt, always use association rather than composition/aggregation. My reasons for this are:
(1) In Object-oriented analysis and design for information systems Wazlawick notes that the real advantage of composition and aggregation
is that the attributes of the parts are often used to derive attributes of the whole. As an example he mentions that the total value of an order (whole) is derived of the value of each of its items (parts). However, this to him is a design concern rather than a conceptual modelling
concern. From a conceptual modelling perspective, he believes that modellers often apply aggregation and composition inappropriately (that is, where whole-part relations are not present) and that their use seldom have real benefit. Hence he suggests avoiding or even abolishing their use.
(2) UML aims to provide a semi-formalization of part-whole relations through composition/aggregation. However, formalization of part-whole relations is a non-trivial task, which the UML specification does not do justice. Indeed, a number of researchers have pointed out various aspects with regards to aggregation and composition in which the UML specification is under specified. All have proposed means for addressing the shortcomings of the UML specification, but to date these changes have not been incorporated into the UML specification. See for instance Introduction to part-whole relations.
When being in doubt, which kind of associoation to use, use the more generic one. Especially, in your case there is no real "consists of" relation. Further in your EX2, you would have an instance of visit, which is an existance bound instance to an Doctor instance and to Patient instance. This is problem when applying the composition rules, as it also introduces an existence relation between Doctor and Patien implicitely. Thus, this shall not be done.
I guess the concept you are loooking for is an association class. This is a class, which instances give the association between an Doctor instance and Patient instance some further information.
I'm coding an application to create surveys with Symfony3 and Doctrine. I would like to understand which is the best way to model the relation between the survey, items, and answers. A survey is composed by multiple items that have peculiar typologies of answer. For instance I could have the following typologies:
AnswerChoice
AnswerText
AnswerRange
etc..
Which is the best way to model this scenario with Doctrine?
I thought 2 possible solutions:
I create a single Answer object including every possible feature of the answers. The Item object should have a one-to-one relationship with this objects.
Pros: I have just one answer object
Cons: Confusing and against the single responsibility principle
I create a generic Item object containing a specific Answer object (AnswerChoice, AnswerText...) in a predefined class property. The Survey object should have a one-to-many relationship with Item that in turn will have a one-to-one relationship with a specific Answer object;
Pros: Nice solution but...
Cons: I need a property for each type of answer!
Could you please help me to choice the best solution? I have the feeling that I'm not facing well this problem. Thanks
It's inheritance. Actually Doctrine handles inheritance pretty well.
There are a few ways of implementing inheritance in Doctrine but I think, that in your case Single Table Inheritance is what you're looking for.
That way you will be able to get a repository for parent (abstract) answer,but you'll get instances of actual child types in return.
is there a way to get the recursive superclass concepts of a concept from freebase? For example, i would call the topic "/games/game_publisher" a concept, and I would like to know if it has any superclasses (e.g., /organization/organization would make sense).
Many thanks!
Freebase Types (the equivalent of your "concept") don't have an inheritance structure. They do however have "included types". One key difference is that an included type only gets added to a topic by when it's main type does by convention of the web client (or other client), but after that it can be removed or re-added independently. For example, Deceased Person has Person as an included type and it's unlikely anyone would ever remove the latter, but Author also has Person as included type because that's the case for the overwhelming majority of authors, but for so-called "corporate authors" one would remove Person and add Organization.
So, the included types does carry some semantic information, but it's not as strong as a super/sub-class relationship.