Let's say we want to make an ontology model for the Light Switches in the home.Each Light Switch has two properties hasID, and hasLocation.
which way is the most correct way to doing it.
making a class LightSwitch
a data property hasID
an object property hasLocation
some individual Like LightSwitch-01, LightSwitch-02
OR
making a class LightSwitch
subclasses KitchenLightSwitch, LivingroomLightSwitch, and etc.
a data property hasID
an object property hasLocation
some individual Like LightSwitch-01, LightSwitch-02
In ontology design there is no right or wrong in general (of course there are situations where someone makes mistakes in the design process).
There is no such thing like "this is the one and only solution". There are always different solutions, based on your scenario, experience and what you would like to do with the ontology.
In your case you could solve your problem with both approaches (I would prefer the second one, since I'm a fan of classes). The only difference in your example that I see is that in the first one all lightswitch instances are of the type "LightSwitch" and in the second one the instances are of theire location type (e.g. KitchenLightSwitch).
However if you are using the object property "hasLocation" you do not really need subclasses for "LightSwitch".
Create a class "Lightswitch" with the instances "Switch1, Switch2,..." and create a class Room with instances (Kitchen, Livingroom, etc).
In the last step you associate a relationship: Switch1 hasLocation Kitchen.
Another possibility would be to create the class Room and subclasses LivingRoom, KitchenRoom, etc. Each of the subclasses would have an instance "kitchenroom, livingroom, etc."
But really, its up to you. I see nothing wrong with both of your solutions. However, if you would provide more information or your context would be more complex.. maybe then one could prefer either solution A or solution B, but for exactly this example that you are asking for, both solutions are right.
Related
I have a bunch of questions regarding Java 8 and SDN4. I created a model in Neo4j v3.0, played a bit with Cypher queries, and now moved to creating a Spring Boot application. As i started coding classes in Java, I've begun to rethink some of my model as well. Here's some questions in my mind (and I haven't found an example explaining this):
Do you need to use Interfaces in Java, with SDN?For eg. I'd code a Product interface and then have my products implement it, but is that how it's done when working with labels?
This is somewhat tied to my question on inheritance - I'd usually have a ProductFamily that my Product would inherit from. At the database level its modeled as (:Product)-[PartOf]->(:ProductFamily), but in the code these would not be super/sub class.
Any examples of using Generics in a graph context?
Is there a way to define constraints on what relationships a node can have and their direction in Java?
I understand there is probably not one right answer, but there's precious little on the web, so hope to get enlightened here!
If you had a Product interface annotated with #NodeEntity, then the you'll have the Product label in addition to the label on your implementing class, which I assume is what you want. If your interface isn't annotated, then your implementing classes will not inherit a label from it.
Not sure what you mean- if you say you have a ProductFamily that Product inherits from, but in the code it would not be a super/sub class?
Based on your graph model, if you want (:Product)-[PartOf]->(:ProductFamily) then you will have a Product class that maintains a reference to a ProductFamily class, and that reference annotated with #Relationship. If the Product class inherits from ProductFamily then persisting the Product will result in two labels- Product and ProductFamily because a Product IS-A ProductFamily.
How do you see yourself using generics- the answer really depends on that. Some cases are supported, some are not (an example of something not supported right now is equivalent of template.createRelationBetween in SDN4)
Yes, via the #Relationship annotation which accepts a type and direction. Note that this annotation only constrains your domain model, but you could very well flout this by creating relationships in another direction via a custom query.
Ive a method that takes an object. The object is dynamic and it can be constructed in 5 differents ways depending on how many children it has and which type of object it is. I want it to be clear how to build this object and also show which children types thay can be used together.
Example A:new Michael(id,name, Type.A, new Sara(id, name, ChildrenType.B));
Example B: new Sandra(id,name,Type. C, new Pheno(id, name,ChildrenType.D), new Leo(id, name,ChildrenType.E));
As i said before, the object is dymanic and can be build in different ways depending on which type the object has and how many children it has.
I thought that the best way to show all of this would be to have 5 different example bodys in swagger. But idk if it is possible? Is it and is this the best solution for this?
And im using java, if it makes any diff which languages i use.
Thanks!
You can define only one example per mime type.
However your can use externalDocs to redirect to another page with all your examples.
If you have a common interface for the payload, you can use a discriminator to choose the different concrete types that can be instantiated.
I am just getting started with ASP.NET MVC. So far I like it a lot.
I am trying to get up to speed but I need some clarification. I want to know when should I create a model for the logic.
I mean so many times I found my self putting all logic into one "master" model. I know its not the right way to go.
But then again I'm not sure if it is good to have redundant properties in my model.
I assume you are talking about ViewModels, and it is perfectly fine to have different viewmodels instead of having one complex model even the properties are repeating. With master model, it tends to get complicated down the road. However, for special cases like CustomerCreateVM and CustomerEditVM, I would create the commmon properties in base class CustomerVM and inherit it and for more readability I will keep them in one file. Does it answer your question ?
Your "View" model should accurately represent the information that is being shown/processed in that particular view. This means it should only have the fields that relate to the information being shown and nothing else. If it is not shown or used on the screen, it should not be in that model.
This is possibly a bit of a stupid question, but I am getting confused due to the ASP.NET MVC book I am currently reading...
Working with Linq-To-SQL it seems to say that it is not good practice to pass the Linq-to-SQL objects straight to the controller, but that each object should be modelled separately first and this should be passed between the controller and the repository.
Say, I have a database of products. Linq-to-SQl creates a product class for me with Name, Price and Whatnotelse properties. I could pass that straight from repository to controller and then view, but instead it seems to recommend that I use and third class, say Product_Entity, with also Name, Price etc. properties and pass that to the controller.
I fail to see the benefit of this approach, except possibly for adding attributes to the properties... But apart from that it seems to have more drawbacks than benefits. Say each product has manufacturer information as well, I don't see how I can model that easily in my third class.
Is this approach really best practice? Or did I misunderstand all that? If so, why is it bad to work straight off the linq-to-sql generated objects? And how do you deal with relationships between objects in y
The huge benefit to this other class you create is that, to use your example, it doesn't necessarily map to either a product or a manufacturer. Think about it like this:
Your Linq to SQL classes are meant for talking in the "data" domain.
Your "data" classes (the ones you're having trouble with) are meant for talking in the "application" domain.
Let's take an example. Suppose in your MVC application you wanted to show a grid of information about products. You want to see their Name, Price (from the Product table) and their Country of Manufacture and Manufacturer name (from the Manufacturer table). What would you name this class? Product_Manufacturer? What if later on you wanted to add properties from yet a third table such as product discounts? Instead of thinking about these objects in purely the data domain, think about them with regard to your application.
So instead of Product_Manufacturer, what about calling it ProductSummaryItem? Each property of the ProductSummaryItem class would map 1:1 with a field shown in your grid on the UI. Your controller would perform the mapping between the information in the data domain (Product, Manufacturer) with the custom class you'd created in the application domain (ProductSummaryItem).
By doing this, you get some awesome benefits:
1) Writing your views becomes really, really simple. All you have to do to display your data is loop through the ProductSummaryItems and wrap them in and tags, and you're done. It also allows for simple aggregation. Say for example you wanted to add a field called ProductsSoldLastYear to your ProductSummaryItem class. You could do that very simply in your views because all it is to them is another property.
2) Since the view is trivial and there's mapping logic in the controller, it becomes much easier to test the controller's output because it's customized to what the view is going to see.
3) Since the ProductSummaryItem class only has the data it needs, your queries can potentially become much faster because they only need to query for the fields that would populate your ProductSummaryItem object, and nothing else. This overhead can become overbearing the more data-domain objects make up your ProductSummaryItem object.
This pattern is called Model View ViewModel (MVVM) and is hugely popular with MVC as well as in frameworks like WPF.
The argument against MVVM is that you have to somewhat reimplement simple classes for CRUD operations. Fair enough, I guess, but you can use a tool like automapper to help out with things like that. I think you'll find fairly quickly, though, that using the MVVM pattern even for CRUD pays dividends, because before you know it, even with simple classes, you'll start wishing you had extra fields which can easily drive your views.
I have an interesting question to pose; when should one create a model class/object as opposed to setting a boolean flag for data stored in a database?
For example, say I have a Person class that has boolean flags for President, Guard, and PartTime. This class/model is treated differently depending on the value of the flags. So the President gets different privileges in the system from the Guard and from the PartTime(r).
When would one use Single Table Inheritance to represent this information and when would one just continue to use the boolean flag?
My instinct is to convert these to different Objects using STI since this seems more OO to me. Checking booleans seems wrong in some way, but I can also see a place for it.
Update for clarification
Let me use another example because the one above has too many cases involved with it.
I am working on a CMS application that contains Pages, a Page can be Public, Private, Shared, Hidden, or Default (meaning it is what you get when you don't specify a page in the url). Right now, we have a Page model and everything is a boolean flag - Public, Default, Shared.
I am not convinced this is the best method of handling this. Especially since we have rules governing what page can be what, i.e., the Default page or a Shared page must be a Public page whereas a Private page is just Private.
I agree with the comment below that Roles for the Person example makes a lot of sense. I am not sure that for the Page example it does.
And to make things more complicated, there can only be one Default page and one Shared page. STI may allow me to validate this, but I am not sure since there can be many default and shared pages in the table (just not associated with a particular site).
Note: The context for the question is a Ruby on Rails application, but is applicable for any object-oriented language.
First of all, let's establish what single-table inheritance typically is used for. It is a way to combine the storage and behaviour of multiple things that resemble each other. Sticking to a CMS, an example would be a table with posts, which could be either a Comment or an Article. They share similar data and behavior, but are ultimately different things. Whether or not something is a comment is not the state of the object, it's an identity.
In your example, however, whether or not a page is public or private, shared or not, or hidden, appears to be a part of the state of the page. Although single-table inheritance might technically work (provided all subclasses are mutually exclusive), it's not a good fit.
State should be implemented in one or more columns. An attribute that represents a certain dual state can be specified as a boolean; yes or no. If a page always is either private or public, you can model this as a single boolean column, private. If it's not private it's public (or the other way around).
In some cases you may want to store three or more different states that are mutually exclusive. For example, a page could be either private, or public, or shared (I don't know if this is the case -- let's pretend that it is). In this case a boolean will not help. You could use multiple boolean flags, but as you correctly observe that is very confusing. The easiest way is to model this as an enumeration. Or when you lack this (as is the case with Rails), simply use string values with a special meaning and add a validation that ensures the only values you use are one of private, public or shared.
Sometimes certain combinations of different state variables are invalid. For example, a page might be a draft or approved (reflected by a boolean column approved); and it is also either public or private (also reflected by a boolean column). We could decide that a page should must be approved before it is made public. In this case we declare one of the states invalid. This should be reflected by the validation of your model. It is important to realise that a draft, public page is not fundamentally impossible, it's only impossible because you decide it should not happen.
When creating your model, make a careful distinction between the attributes that reflect actual properties and states of the subjects in the real world, and the business rules that determine what should be possible and what shouldn't be. The first should be modelled as columns, the second as validations.
Original answer:
One obvious difference is that boolean flags allow a Person to be marked as president and guard at the same time. If your model should allow these situations, single-table inheritance will not work for you.
On the other hand, maybe a Person that is a president behaves differently from a regular person; and a single person can only be president or guard. In this case inheritance may be a better fit. I don't think you should model "part time" as a subclass, though. That is an attribute in any case.
There is also an important third option, one where you completely separate the job or role of a person from the model. One person has one (or many?) jobs, which are or are not part-time. The advantage of this model is that you separate attributes of a person from the attributes of their job. After all, people change jobs, but that does not make them literally a different person. Ultimately this seems to me the most realistic way to model your situation.
I prefer not to use a flag for this, but also not to subclass Person for this. Rather, attach a Role (or if you have someone who's both a President and a Guard, a set of Roles) with subclasses of Role governing the prvileges.
Personally, I am neither a President nor a Guard, but I am both a Programmer and a Musician, and have a few other roles at times (in fact, I was a Guard for a while simultaneous with being a Student many years ago.).
A Person has-a Role.
I have found that whenever I think "Hm, I have these 3 types of behavior and they do look like subclasses, but need to change at runtime", look at a strategy or state pattern. It usually fits very well and usually also beats a simple boolean flag with respect to keeping responsiblities apart.
In your case, this heuristic would say that you have a Person with an attribute of type AccessRights, which decides if a certain action can be performed or not. Person either gives access to this object or delegates appropiate methods. After that, you have PresidentialRights, GuardRights and PartTimeRights implemetning this AccessRights interface and you are good to go.
Given this, you never need to change the person class whenever a new type of access right appears, you might need to change the person class if a new type of action appears (depends on if you delegate and how you delegate) and in order to add new types of AccessRights, you just add new implementations of AccessRights.
the answer is that it is basically a design decision. There is not an a priori right way of designing an architecture. When you define classes and relationships among them you define an architecture and, at the same time, a language representing the domain of your application.
As any languages it consists of a vocabulary (i.e. Person, President, Guard, etc.); a Syntax (i.e. the relationships you can specify for the instances of your vocabulary) and Semantics (i.e. the meaning of the terms you specify in vocabulary and relationships).
Now you can obviously obtain the same behaviour in possibly infinite way. And anyone would come up with a different architecture for the same system since anyone might have a different way of thinking at the problem.
Despite this there are some criteria you should take into account when designing.
When you define a Class you are defining a "first order" construct of your language, when you define attributes for a Class you are describing the characteristics of your first order constructs.
The best way to decide if you need a class or an attribute might be this.
Do Presidents and Guards have different characteristics apart of those they share since they are both person? If that is the case, and they have a number of different characteristics you should create two classes (one for the President and one for the Guard)both inheriting from Person. Otherwise you have to collapse all the characteristics (those belonging to person, those belonging to President and those belonging to Guard) in the Person class and condition their validity to another flag (type). This would be a very bad design
The characteristic of a Page of being public or not is instead something which actually describes the status of a page. It is therefore quite reasonable to model it as a Property of the Page Class