I am currently working on the OWL Ontology I have a question in regard to property.
To be frankly saying, I don't really see the importance of giving a property restriction to class.
For example,
Product (class) has manufacturer (property) some Manufacturer.
In this case this means that one product has at least one manufacturer.
However, then why not just do object property assertions by
a plastic model (an individual of the product) has manufacturer (object property) DOCOMO (an instance of the manufacturer) ?
Do I have to do both? enve if I don't do the first thing, the reasoner says there is no problem. Why Do i have to do both?
Property restriction asserts something about a set of individuals, not just a single individual. Consider the property restriction:
Every man likes a woman. (i.e. "man subClassOf like some woman")
vs the property assertion:
John likes Mary. (i.e. "{John} subClassOf like some {Mary}")
where {John} and {Mary} are classes with a single individual, but man and woman are classes with 0 or more individuals.
Related
How to refactor/rewrite an association into inheritance in the following example.
The UML Diagram describes the currently working state of my program. The real code structure is more complex so please excuse this made-up example.
There is a Market which initially holds some computers types in a list. When a computer is sold a new object SoldComputer is created and added to a second list. The sold computer references to the computer type. The CPU of the first computer sold can be called by:
soldComupter.ReferenceComputerType.CPU
Is it possible to replace the association with inheritance? Removing ReferenceComputerType and inherit SoldComputer from ComputerType. A call would look like this:
soldComupter.CPU
The goal is not to disguise the reference by a decorator pattern but to descant all field and functionality by inheritance.
The problem i struggle with is, that multiple sold computer can reference the same computer type. So i cant typecast an existing computerType into a soldComputer as both list must exist at the same time in the real application.
If I understand correctly your reasoning, your market sells SoldComputer which are categorized according to a generic ComputerType. Furthermore the ComputerType pre-defines some characteristics of all the computers of that type.
Composition over inheritance
First, a Computer is not a ComputerType. But looking at the properties of these classes, it appears that my argument is only about a naming issue, because your ComputerType could also be named GenericComputer, in which case it would be less shocking.
But your ComputerType is only a small part of the problem. Because sooner or later, you'll realise that a sold computer can also have some StorageType (e.g. HDD, 1To) and maybe also some GraphicType, and many other configurable options. And tomorrow, you may even have new type of components you are not even aware off (e.g. holographic beamer 2D/3D) but that fundamentally do not change the way you describe and categorize the SoldCompter.
This is why you should prefer composition over inheritance: you could have association with other types of components. The big advantage, of your current approach is that if a user decides to extend the RAM of its SoldComputer, he/she can choose just the matching ComputerType and everything is fine.
If you'd go for inheritance, the SoldComputer would have its CPU and its memory: if the user would change their value, it would be inconsistent with the categorisation. And maybe there is no copmuter type corresponding to the new categorisation...
Alternative
Another way to look at the problem is to have a class Computer with all the fields that technically describe the computer (e.g. CPU, memory, disk, etc...):
the set of computer types in the market would be populated with Computer but with only some relevant fields filled.
the set of sold computers in the market would be populated with Computer having some owner.
The creation of a new Computer to be sold could use the prototype design pattern. But as soon as it is done, there would be no relation anymore between the computer and the prototype.
In this case, the market would no longer be categorised by compter type. The search would always be dynamic (eventually initialised using a choice list of the prototypes.
Is it possible to replace the association with inheritance?
No, it's not possible.
As pointed out by #ThomasKilian, "a computer IS NOT a computer type", or put more generally, a product IS NOT a product type.
Your model seems reasonable.
It's very common in business apps to have both a class for product types and another one for individual products, such that these two classes are associated for representing the information which type a product has.
Why would you like to use an inheritance/subclass relationship instead?
I have a class Person, and a set of data properties: First_Name, Surname, Gender, DoB, Country_of_Birth. The data properties have their Domains set to Person. What i would like to set up in my ontology is a rule which states that every Person must have exactly 1 of each of these properties.
So in Protege, I set up Person as a subclass of "First_Name exactly 1 xsd:string", "Surname exactly 1 xsd:string" and so on. I then set up an Individual with a Surname, but no First_Name, Gender etc.
I then run the reasoner. What I would expect is for it to throw a fit about inconsistency (Surname is being assigned to an individual which does not conform to the requirements to be a Person) but no, the reasoner infers that the Individual is a Person despite the fact that it does not have the required properties.
Is this proper behaviour? How do I make the ontology behave in the way that I want it to? Because what I want is for the ontology to be robust against incomplete data (so you can't add a person with no name, for example).
Yes, that is proper behavior due to Protege using the open world assumption rather than the closed world assumption of for example relational databases. Under the open world assumption nothing can be assumed that is not stated explicitly or can be derived from explicitly known information. When you create an individual (possibly of type Person) for which you assigned no First_Name, under the open world assumption the reasoner merely assumes that the First_Name is not known, not that it does not exist (as is the case for the closed world assumption). Hence, the reason why the reasoner gives no inconsistency even though it infers that the individual must be of type Person. To get an inconsistency you have to state that it is known that the individual is both a Person and does not have a First_Name. This can be achieved for an individual john by asserting:
john Type Person
john Type First_Name max 0 xsd:string
I am new in the field of ontologies and reasoning in Jena and I am in desperate need for help to get the logic of how to do the following. I am building and owl ontology with the following classes:
-A person hasInterests Interests
- A person hasMessage Message
- A message hasCategory Category ( or subclass of message)
- A message can be spam or ham ( subclasses of message)
I want to say if the message's category is the same as the person's interests then the message is ham
Q1: I wanted to build the ontology such that the reasoner would infer this so I thought of defining ham as an intersection of class category and interests and that spam is complemet to this intersection class . Is this applicable using a reasoner or shall I need SPARQL queries
Q2:How to create individuals and do the following inference :
hana is a person
message1 is a message
sports is a category
movies is an interest
how to infer that since the sport is not equal to movies then message1 is spam.
I am in desperate need to be directed how to implement this and what exactly to refer to to do so for my masters thesis
The easiest way of doing so (I'm a newbie, but I just succeeded to make inference in ontologies x_x), is by creating your ontology with Protégé and thinking about the concepts you want to link...
You have categories and interests that are pretty abstract, compared to message and person. You have to think about how to link them, and to which classes they belong.
Concrete vs Abstract... Objects vs LivingBeing... Animals vs Plants...
It's an example.
When you are okay with these, you can implement them with Protégé (as it's a graphical tool, it's easier at the beginning) : check the "Entities" tab, and the "Classes" subtab.
Then, you put rules and properties. (the hardest part)
Typically, what is concrete is NOT abstract... so you have to disjoint the two within their properties.
And if you expect some relations to make a "real" ontology, you have to define your own properties (a person can "own" objects, for example... but an object does not "owns" a person).
When you have your basic ontology builded. You have to check if some inferences can be done (search within protégé the "reasoner" menu, and activate one of them, and synchronise it regularly).
Finally, you can add individuals inside, and fill their properties (search for a subtab named "Individuals").
I'm new to ER diagrams. I noticed that draw.io (which was recommended on Stackoverflow) does not have a one (optional) to one (mandatory) relationship.
Let's say, I have two tables "user" (id, affiliate_id) and "affiliate" (id). There doesn't have to be an affiliate, in which case user.affiliate_id would be null.
However, if there is an affiliate, then user.affiliate_id will link to affiliate.id.
So wouldn't that be a one (optional) to one (mandatory) relationship?
PS: I was thinking that maybe user.affiliate_id must not be null in a strict sense. However, it doesn't break the foreign key constraints (at least for SQLite 3).
I think you are describing a one-to-many relationship. One user can (optionally) be associated to one affiliate, but the same affiliate can be associated to more than one user.
Or am I misunderstanding?
Yes, you are right, that would be a zero/one (or zero/many) to one relationship type, which has to be shown in the diagram. There are different notations for ER diagrams (and it's therefore, in fact, preferable to use UML class diagrams). For instance, in the notation used by Oracle the optional end of the connection line representing the relationship type is annotated with both a zero and a one symbol. In UML, the annotation of the optional association end would be 0..1 (if single-valued) or 0..* (if many-valued).
I'm trying to comprehend ontology basics.
Here's an example:
car (class)
2009 VW CC (sub-class or instance?)
My neighbor's 2009 VW CC (instance)
My issue is understanding what is "2009 VW CC" (as a car model). If you're making product model a sub-class in the ontology - all of a sudden your ontology becomes bloated with thousands of subclasses of a "car". That's redundant. At the same time we can't say "2009 VW CC" is an instance, at least it's not material instance of a class.
Does it make sense to distinguish between regular instances and material (distinct physical objects)?
At the other hand, if both are instances (of different nature so to say), then how can instance inherit properties / relations of a non-class?
I hate to say it depends, but it depends.
If you need to model every single car in the world, and have methods that you can call on them (like "change tyre", which is a process that is very different for each model) then yes, you are going to have a lot of bloated classes, because your real world situation is bloated too.
If you just want to have a database of pictures of archetypal cars, and you don't car whether it is a picture of your neighbour's instance or your sister's instance, then you can drop the bottom layer. "2009 VW CC" could well be an instance, even though you can visualise that it is also a class in another model.
Alternatively, maybe you don't need to make it a true subclass at all. A simple reference might be sufficient. For example, an insurance company knows about a large list of car models and years, but the developers don't write one subclass for each. Instead, they have a database of car models, where one row may represent 2009 VW CC. When you insure your car, they create an instance of "Insured Car" with a reference to the "2009 VW CC" instance.
This doesn't strictly follow the "Use inheritance for a 'is-a' relationship", but the operations on all the car types are identical - it is just the parameters (e.g. insurance price per annum) that change, and new car models are recorded in the database, not in the code.
An assumption here is that you can model the differences between the difference models as merely parameters to the same methods on car.
(Aside: When the iPhone started becoming available through phone company web sites, I noticed that it broke their class models - their web-sites seemed to handle dozens of brands and models of phone on one page - presumably using a simple database of phones and their features - and then needed a special page to handle the iPhone models, presumably because new special methods were required on their classes to support some aspects of the iPhone sale. Automated sales desks would say "Press 1 to buy a phone. Press 2 to buy an iPhone.")
You have it backwards.
2009 VW CC inherits from the class car. Thus 2009 VW CC needs to know about car, but car doesn't need to know about 2009 VW CC. Though we do occasionally use the term "subclass" in reality, car knows nothing about any of its subclasses.
What's more interesting is if you consider prototypal inheritance (like in javascript), where objects inherit directly from other objects (imagine if your 2009 VW CC inherited the aspects of your neighbor's 2009 VW CC). In reality how this is implemented is that new object have a secret pointer back to the object they inherited from. If you think about this secret pointer you can see how the originating object doesn't become bloated.
Now if you're suggesting that multiple inheritance and long family trees can lead to confusing structures, then I would agree with you.
I really agree with Oddthinking. Plus, if you need car models as classes, "all of a sudden your ontology becomes bloated with thousands of subclasses of a car" actually is not a problem. Why should it be? You just define classes instead of individuals, you might have an 'abstract' ontology, with base classes, and a 'concrete' ontology, with classes that represent the particular situation in real world. This is not OOP, defining thousand classes that are actually somewhat in between between instances and classes is no big deal, at least conceptually, nobody consider this 'bloated' or strange in any other way. Indeed, they do it all the time in my field (life science, where we typically don't care about the proteins P53 in our body, so P53 is a class, even though it's also used to model a record in a relational database).
Except, well, my experience is that tools like Virtuoso seem optimised for the situation of few classes and many instances. In fact, I've observed significant performance improvements when I turned million of classes in Virtuoso into instances. So, well, it's complicated...