I am wondering why public biomedical ontologies are often organized in such a way that there are no class instances and only classes? I understand it in a way that all instances are classes, but I do not understand what is the advantage or purpose of such modelling? Those classes have also only annotation properties. For example NCIT ontology: https://bioportal.bioontology.org/ontologies/NCIT/?p=summary.
I would appreciate if someone could provide me with an explanation what is the purpose of such model and if there is an advantage to a model where classes have class instances. I am definitively not an expert in the field and I only was working on modelling 'standard' ontologies with classes and their instances.
TLDR
The reason for preferring classes over individuals (or instances) is that classes allow for sophisticated reasoning which is used to infer classification hierarchies.
The longer answer
The semantics of OWL allows you to make the following type of statements:
ClassExpression1 is a subclass of ClassExpression2
PropertyExpression1 is a subproperty of PropertyExpression2
Individual c1 is an instance of Class1
Individual x is related to individual y via property1
Of these 4 options, (1) by far allows for the most sophistication. Intuitively it comes down to how much each of these allow you to express and the reasoning capability to derive inferences from those statements. To get an intuitive feel of this, using the OWL Direct Semantics, we can see what
ClassExpression1 and ClassExpression2 can be substituted with:
There no way that this expressivity can be achieved using individuals.
Individuals vs Classes
In your question you say that all instances (individuals) are classes. This is not exactly true. Rather, classes consists of instances or instances belong to classes. From a mathematical perspective classes are sets and individuals are members of a set.
Annotations in biomedical ontologies
These ontologies have a substantial (80%-90%) amount of annotations. However, they do have lots of logical axioms. You can see it for example when you look at http://purl.obolibrary.org/obo/NCIT_C12392 on the righthandside, if you scroll down to the bottom, you will see the axioms listed:
I'm fairly new to ontologies and have the following situation:
Given a class definition, I want to automatically generate individuals based on all possible combinations of a given restriction.
For example:
Let's say a "Pizza" class has the property "hasTopping" which is supposed to be linked to an individual of class "Topping". I want to generate an individual of the class Pizza for each individual existing for a Topping. If there are two Topping individuals, Tomato and Cheese, I want to create one Pizza individual with "hasTopping Tomato" and one with "hasTopping Cheese".
Is there any general way to generate individuals in ontologies like this? (As an alternative to implement it myself.)
Is this "violating" the intent/purpose of ontologies in general? Would this usually be handled in a different way? (I'm not completely familiar with ontologies yet.)
There's no standard method to do this, so I think you'll have to implement it yourself. The Leigh University Benchmark does something similar, so it might provide you with some ideas: http://swat.cse.lehigh.edu/projects/lubm/
I don't think this violates the idea behind ontologies at all - seems quite straightforward. There is no best practice for it, so however you choose to implement it will probably be adequate.
I have always viewed tags as completely different than the normal folder hierarchy model. I am building a system that needs tagging to tag sets of data. We had the db design all worked out, (pretty straightforward model) but a debate arose around the value of still having concepts of hierarchies within a world of tags.
On SOF, as an example, the only equivalent I see some of this by using - in some tag names like tagging; jquery, jquery-ui, jquery-ui-dialog so there is no inherent modeled relationship (just a naming convention).
Is there any conventional wisdom of best practices around how and if hierarchies should exist in a world of tagging?
I developed a portal that involved hierarchical tags. I can assure you that is a mess to manage :)
My solution then moved to a hybrid approach in which tags can be stand-alone or hiearchically handled but they reside in two different namespaces.
This because some tags can be seen as children of parents of other tags while others cannot, so for example dialog tag is a concept that is also indipendent from jquery so a content with both tags jquery dialog has implicitly the relationship needed.
Hierarchical should be used to express a kind of inheritance between concepts, eg. collections -> trees, lists, maps in which trees tag can be effectively included inside a collections tag.
In your example dialog and jquery are orthogonal and uncomparable, so it makes no sense to make one child of another.
The names "jquery", "jquery-ui", "jquery-ui-dialog" aren't tags, but the equivalent of file structure paths, hierarchical by nature.
If your data is easy to authoritatively categorize then present it as a tree. If users only see a few of their own tags (like in Gmail), you could make it possible to sort and nest the tag list and save that structure per user, separately from tags themselves. If there are great many tags with power distribution of content (for example if 10% of tags describe 90% of content) then a tag cloud can help.
In short, it depends on the data.
hierarchies have in general a disadvantage compared to sets.
think of bookmarks and tag-bundles like delicious.com.
i prefer to search for a set using sport and newer-than-1-week and ( english-language or chinese-language ) and not ( soccer or boxing ).
There is a question very similar to this but I wanted to ask it in a different way.
I am a very customized guy, but I do like to take shortcuts at times. So here it goes.
I do find these two classes very similar although one "helps" the programmer to write code faster or have less code/repeating code. Connecting Models to Forms sounds like an obvious thing to do. One thing that is not particularly clear in the docs using a ModelForm. What happens if you need to add extra fields that are not in the Model or some way connected to another Model?
I guess you could subclass that out and make it work, but does that really help you save time than just manually doing it with a Form?
So next question may not have a definite answer if I do subclass it out, and use ModelForm. Is ModelForm particularly faster than Form? Does it still use the same Update techniques or is binding significantly faster in one or the other?
If you want a form across two models, you got a couple options:
1) create two modelforms, save each individually when posted, and if one of the two depends on the other (i.e. foreignkey), set that in your view before saving.
2) try Django's inline formset: http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#using-an-inline-formset-in-a-view
3) Add non-model fields to your modelform. On a ModelForm, you can add fields that are not tied to your model. They are available in cleaned_data as any other field would, be but are simply ignored when the model is saved.
One advantage that ModelForm's have over Form's is you can specify the ordering of fields (searching for how to order Form fields brought to your post incidentally). Obvious other advantages are you don't have to rewrite your model saving code
I used to have one class for one file. For example car.cs has the class car. But as I program more classes, I would like to add them to the same file. For example car.cs has the class car and the door class, etc.
My question is good for Java, C#, PHP or any other programming language. Should I try not having multiple classes in the same file or is it ok?
I think you should try to keep your code to 1 class per file.
I suggest this because it will be easier to find your class later. Also, it will work better with your source control system (if a file changes, then you know that a particular class has changed).
The only time I think it's correct to use more than one class per file is when you are using internal classes... but internal classes are inside another class, and thus can be left inside the same file. The inner classes roles are strongly related to the outer classes, so placing them in the same file is fine.
In Java, one public class per file is the way the language works. A group of Java files can be collected into a package.
In Python, however, files are "modules", and typically have a number of closely related classes. A Python package is a directory, just like a Java package.
This gives Python an extra level of grouping between class and package.
There is no one right answer that is language-agnostic. It varies with the language.
One class per file is a good rule, but it's appropriate to make some exceptions. For instance, if I'm working in a project where most classes have associated collection types, often I'll keep the class and its collection in the same file, e.g.:
public class Customer { /* whatever */ }
public class CustomerCollection : List<Customer> { /* whatever */ }
The best rule of thumb is to keep one class per file except when that starts to make things harder rather than easier. Since Visual Studio's Find in Files is so effective, you probably won't have to spend much time looking through the file structure anyway.
No I don't think it's an entirely bad practice. What I mean by that is in general it's best to have a separate file per class, but there are definitely good exception cases where it's better to have a bunch of classes in one file. A good example of this is a group of Exception classes, if you have a few dozen of these for a given group does it really make sense to have separate a separate file for each two liner class? I would argue not. In this case having a group of exceptions in one class is much less cumbersome and simple IMHO.
I've found that whenever I try to combine multiple types into a single file, I always end going back and separating them simply because it makes them easier to find. Whenever I combine, there is always ultimately a moment where I'm trying to figure out wtf I defined type x.
So now, my personal rule is that each individual type (except maybe for child classes, by which a mean a class inside a class, not an inherited class) gets its own file.
Since your IDE Provides you with a "Navigate to" functionality and you have some control over namespacing within your classes then the below benefits of having multiple classes within the same file are quite worth it for me.
Parent - Child Classes
In many cases i find it quite helpful to have Inherited classes within their Base Class file.
It's quite easy then to see which properties and methods your child class inherits and the file provides a faster overview of the overall functionality.
Public: Small - Helper - DTO Classes
When you need several plain and small classes for a specific functionality i find it quite redundant to have a file with all the references and includes for just a 4-8 Liner class.....
Code navigation is also easier just scrolling over one file instead of switching between 10 files...Its also easier to refactor when you have to edit just one reference instead of 10.....
Overall breaking the Iron rule of 1 class per file provides some extra freedom to organize your code.
What happens then, really depends on your IDE, Language,Team Communication and Organizing Skills.
But if you want that freedom why sacrifice it for an iron rule?
The rule I always go by is to have one main class in a file with the same name. I may or may not include helper classes in that file depending on how tightly they're coupled with the file's main class. Are the support classes standalone, or are they useful on their own? For example, if a method in a class needs a special comparison for sorting some objects, it doesn't bother me a bit to bundle the comparison functor class into the same file as the method that uses it. I wouldn't expect to use it elsewhere and it doesn't make sense for it to be on its own.
If you are working on a team, keeping classes in separate files make it easier to control the source and reduces chances of conflicts (multiple developers changing the same file at the same time). I think it makes it easier to find the code you are looking for as well.
It can be bad from the perspective of future development and maintainability. It is much easier to remember where the Car class is if you have a Car.cs class. Where would you look for the Widget class if Widget.cs does not exist? Is it a car widget? Is it an engine widget? Oh maybe it's a bagel widget.
The only time I consider file locations is when I have to create new classes. Otherwise I never navigate by file structure. I Use "go to class" or "go to definition".
I know this is somewhat of a training issue; freeing yourself from the physical file structure of projects requires practice. It's very rewarding though ;)
If it feels good to put them in the same file, be my guest. Cant do that with public classes in java though ;)
You should refrain from doing so, unless you have a good reason.
One file with several small related classes can be more readable than several files.
For example, when using 'case classes', to simulate union types, there is a strong relationship between each class.
Using the same file for multiple classes has the advantage of grouping them together visually for the reader.
In your case, a car and a door do not seem related at all, and finding the door class in the car.cs file would be unexpected, so don't.
As a rule of thumb, one class/one file is the way to go. I often keep several interface definitions in one file, though. Several classes in one file? Only if they are very closely related somehow, and very small (< 5 methods and members)
As is true so much of the time in programming, it depends greatly on the situation.
For instance, what is the cohesiveness of the classes in question? Are they tightly coupled? Are they completely orthogonal? Are they related in functionality?
It would not be out of line for a web framework to supply a general purpose widgets.whatever file containing BaseWidget, TextWidget, CharWidget, etc.
A user of the framework would not be out of line in defining a more_widgets file to contain the additional widgets they derive from the framework widgets for their specific domain space.
When the classes are orthogonal, and have nothing to do with each other, the grouping into a single file would indeed be artificial. Assume an application to manage a robotic factory that builds cars. A file called parts containing CarParts and RobotParts would be senseless... there is not likely to be much of a relation between the ordering of spare parts for maintenance and the parts that the factory manufactures. Such a joining would add no information or knowledge about the system you are designing.
Perhaps the best rule of thumb is don't constrain your choices by a rule of thumb. Rules of thumb are created for a first cut analysis, or to constrain the choices of those who are not capable of making good choices. I think most programmers would like to believe they are capable of making good decisions.
The Smalltalk answer is: you should not have files (for programming). They make versioning and navigation painful.
One class per file is simpler to maintain and much more clear for anyone else looking at your code. It is also mandatory, or very restricted in some languages.
In Java for instance, you cannot create multiple top level classes per file, they have to be in separate files where the classname and filename are the same.
(C#) Another exception (to one file per class) I'm thinking of is having List in the same file as MyClass. Where I envisage using this is in reporting. Having an extra file just for the List seems a bit excessive.