I am trying understand cases where vacuous entailment occurs due to use of universal quantification in Protege. That is, axioms of the form:
A rel *only* B
Here is my setup:
I have created an ontology that (more or less) follows the one described in this Ontogenesis article:
http://ontogenesis.knowledgeblog.org/1260
It consists of an owns relation and two high level disjoint classes: person and pet.
Under the pet class, I have three primitive disjoint classes: dog, elephant, and newt.
Below the person class, I have a defined class pet owner, defined as follows:
'pet owner' equivalent_to person and (owns only pet)
Lastly, I have created and individual person, named person 1, that does not own any pets.
Universal quantification:
My understanding of universal quantification is that the only quantifier describes those individuals that only have relationships to individuals of a specific class. This entails that individuals that do not have any relationships to another individual would also be described by universal quantification.
In my example, I thought person 1 would be inferred to be a pet owner, since person 1 does not own any pets or stand in any other relationships. However, when I run the reasoner (HermiT and Pellet), this does not turn out to be the case. Person 1 is not inferred to be a member of pet owner.
So, it seems that I am not understanding universal quantification. Can someone please help me?
The problem here is that you didn't take into account Open World Assumption (OWA). By OWA the ontology only contains facts that are known; there might be other facts. If you say nothing about the things person 1 owns, it doesn't mean that it owns nothing. It might own other things, that are not in the ontology. So your universal restriction may prevent someone to be a pet owner (in case they own something that is not a pet, and the corresponding axiom is in the ontology). To make someone a pet owner, you might 'close' the information about it, e.g. saying that known pets are the only things that person owns. For this you may use owns only {pet1, pet2, pet3} construction.
Related
I have what I think should be a common problem in OWL ontology design, but it proves a bit hard to get direct advice on this.
Summary: I need to restrict a ternary relation of 3 taxonomically rich class structures so that the range of the relation is dependent on the respective domain. And I don't absolutely have to model this as schema, I just want to store the information "this subclass is connected to that one" somehow. I see as best options object property restrictions or storing the information as instances, which directly realize the relations I need as instances of a general relation.
Situation:
I have a ternary relation that I modeled by an additional class
There are two taxonomically rather rich classes A,B with respectively many subclasses and a third class C with some subclasses that connects to the relationship between subclasses of A and B
I introduced class D which connects to subclasses of A,B,C
An obfuscated example is: A are herbivores, B are carnivores and C are climatological settings. Now I want to model that certain carnivores hunt certain herbivores and in addition, certain climatological settings affect the hunting behaviour. But not all climatological settings affect all pairs (a,b), so there's interestig information to be stored
Since I can't point from climatological settings directly to a pair (a,b), I introduce D, the class of hunting habits, which relate to carnivores as hunting participants, to herbivores as hunted participants and to climatological settings as modifying setting.
Problem:
I now have a relation from A to D which is general, yet I don't want every hunting habit (pair of hunting and hunted) to be affected by the same climatological settings
For example: Maybe I want rain to affect only the hunting habits between macroscopic animals, or I want volcano eruptions to only affect animals that live near volcanoes
Solution Options:
introduce object property restrictions, which are like virtual superclasses (e.g. the class of animals that participate in hunting habits which are affected by volcano eruptions)
directly introduce all the information in the instance level: create instances of all the animals I want to make assertions about, then also create instances of the climatological settings and hunting habits, then link those instances together
create a bunch of sub-relations that have domain and range the specific animals, hunting habits and climatological settings
I suspect the answer will be "It depends". In that case, I am really thankful to understand some of the advantages and disadvantages of the options. Of course there might be a really good solution that I am missing.
I am modeling an ontology that should be used to represent knowledge about restaurants, their served dishes, prices and cuisines types.
One of the functionalities of this system will be to allow users browsing for places to eat some specific kind of Dishes or to search restaurants that are specialized in some cuisines.
Given that in mind, I have modeled the first version of my ontology, but I question appeared.
To represent the specialty of a Restaurant: (a) should I do it as an Object Property, having a class Cuisine, or (b) just as a data property, i.e. being a simple attribute of the Restaurant Class?
Which are the implications of choosing a or b?
In principle, the purpose of an ontology is to describe knowledge about a certain topic. An ontology should partially answer the question "What is a [NameOfTheConceptYouWantToDefine]?". In OWL, the question is answered by providing categories (OWL classes) and binary relations between objects of the categories (OWL individuals) or between an object and a data value (literals). For instance, ask yourself the question "what is an ingredient?". If your answer is "an ingredient is a finite sequence of unicode characters", then you'll need a datatype property to relate something to an ingredient. If you believe that an ingredient is a date or a number, same.
However, if you think an ingredient is an entity that cannot be digitally encoded in a data structure, then you may need a specific class for it, and object properties to relate things to it.
However, ontologies may also be used as a guide to data structures about the things you describe. Sometimes, it is convenient to use a character string as a description of the thing rather than talk about the thing itself. For instance, one may use a string to describe the ingredients of a recipe. This string should not be confused with the ingredient itself. To make this distinction explicit, you can use datatype properties with a clear name like ex:ingredientDescription.
Now, ask yourself "what is a cuisine?". Is it a string, a number, a date? Do you need to describe further the cuisines or do you just need a string-based cuisine description?
The motto of Semantic Web is “Things, not strings”. This is what makes RDF/RDFS/OWL different from other modelling frameworks.
In OWL 2, object properties might possess different characteristics, while data properties mightn't:
Also, data properties can not be parts of property chains. All these restrictions are due to decidability reasons.
There exist quite a few cuisines, they can have their own attributes (at least, detailed descriptions) and relations, so I'd suggest to use object properties.
My assignment is to draw an ER model (by hand) using Chen notation using the specifications below:
http://i57.tinypic.com/73ff2f.png
If you have questions about these specs. I'll play the role of the
client who will resolve them.
The database will serve a university.
Students have id's, names and gpa's. They must have exactly one major,
but they could have minors as well. Each major or minor is a
department which has a unique name and a phone number. For each
student with a minor, we record the date she signed up for it. Faculty
members are associated with a unique department and have id's, names
and office locations. Each internship is held by a particular student
at a particular compain and is supervised by a particular faculty
member. We also keep track of the last term in which that student
registered under that advisor for an internship at that company.
Students may have many internships over time. A given faculty member
may supervise many students at a given company, and she may supervise
a given student at several companies. However, for a given student and
company, there can be only one faculty advisor.
Students, Departments,
Faculty and Companies should be your entity types. Internship should
be a ternary relationship type. The specs should also lead you to some
binary relationship types. Don't add any ingredients to this mix other
than what appear in the specs.
Below is my work:
http://i60.tinypic.com/28rf7tf.jpg
Can anyone please help as I really need a better understanding of this (my professor is AWFUL at explaining this).
You missed (per your assignment's last paragraph) a department entity type. (Box.)
You missed 'Faculty members are associated with a unique department'. That's a relationship between those two entity types. (Diamond with lines to those boxes.)
You could have those major and minor entitie types that are 1:1 with departments. (Your present boxes with each a line to its own diamond each with a line to department.) But (per your assignment's last paragraph not listing them as entities) you could have major being a relationship 'student[s] has a major in department [d]' and similarly for minor. (Lines from student to each of two diamonds each with a line to department.) But the assignment actually says 'each major or minor is a department' so that's major as 'student[s] has major department [d]' and similarly for minor. (Same picture.)
Per your assignment's last paragraph you should make internship a ternary relationship. (Under Chen it's a relationship diamond (possibly with its own properties) formed by 3 lines to entity type rectangles (possibly with their own properties) rather than an entity box.) However, it's not clear exactly when your assignment considers that an internship holds. (It tells us what relationships hold; it's just not clear which one it wants to call interning.) (Although we can look for interpretations consistent with it being ternary.) One is 'student [s] interns at company [c] supervised by faculty member [f]'. But since 'for a given student and company, there can be only one faculty advisor' that notion of internship is more simply characterized by a binary relationship 'student [s] interns at company [c]'. But then you still need a relationship 'faculty member [f] advises student [s] at a company [c]'. So I will suggest that your assignment expects the former. We can add property term. (This is more reasonably called a relationship on student, company, faculty member and date; but E-RM considers relationships to be on entities. Although it all depends on your class's method's particulars.)
(The possibility of multiple reasonable variations is why you should propose a particular design fully handling a particular specification in a SO question.)
A problem with the E-R Model [sic] is that it introduces needless distinctions between entities, reltionships and properties. There is really no distinction between a relationship instance and an entity. Eg: Here we could just as well have an internship be per above an entity in a 4-way relationship plus property. Eg: Your assignment says 'each major or minor is a department'. But a major or minor isn't a department. A major or minor could be considered a subject, which would be the subject after which a department is named or the subject of the degree offered by a department. Or we could just have relationships in which a department participates but the relationship is about that department's subject or name or degree being a major or minor.
(If an internship as relationship participated in its own relationships I don't know how your instructor's particular method would keep the further lines organized. Some methods add internship entities (box) 1:1 with relationships (diamond); then some methods specially associate the entity type with the relationship as a reification while some make the relationship 4-way by including the reified entity type. Eg 'internship [i] is student [s] at company [c] and ...'.)
(Correctly speaking there are entity types vs relationships and entities vs relationship instances. But the assignment talks of relationship "types".)
Re E-RM see this answer and this one. Also the E-RM wiki page section 'Entity–relationship modeling'. (Which correctly mentions misinterpretations of Chen's E-RM & E-RDs by some related modeling and diagramming methods and tools and even some presentations of E-RM itself. But the 'Overview' is nonsense.)
Re E-RM problems see this.
Both are looking same to me. i am not getting the exact deference. i search on different forums and sites but not getting clear. what is the difference between them?
The exact difference is as follows. You have to first separate the total/partial participation constraints to understand this better and we'll take them into account later on.
Disjoint Constraint
Any instance can map to at most one subclass. Not more than that. e.g Bank Account can be either 'Savings Account' or 'Current Account' not both. So when the database is operational, every given instance will be mapped to exactly one subclass defined under the super class. Another example would a meal will be mapped to either Veg or Non-veg..It can't be both.
Partial Constraint
Any instance may or may not map to multiple sub classes of a given super class. This usually happens when an instance play multiple roles and not limited to a single one. e.g Employee may map to either supervisor, manager or both. This means an employee can play both the roles of a manager and a supervisor. Another example would be a musician who maybe mapping to either violin player, guitar player, flutist,saxophonist or all of them.
Note:
So when you specify an 'ISA' relationship your subclasses may behave in either disjoint way or overlap way.. They can't be both, meaning that Disjoint is the exact opposite of Overlap constraint.
Now let's focus on Total and Partial constraints.
Regardless of the overlapping/disjoint constraints, total/partial mean 'do all the instances support the specialization?' question. So when the database is operational and if your ISA relationship is total, any instance coming will be directed to one of the sub classes and nothing will stay in the super class. Conversely, if it's partial, some instances may not have an appropriate subclass so they will stay in the super class.
This brings up the interesting notions as follows.
Total-Disjoint- All the instances coming, will map to one subclass only and will not be shared among other subclasses
Partial-Disjoint- All instances coming, may stay with superclass or map to one of the sub classes only
Total-Overlap- All instances coming, will map to multiple subclasses.
Partial-Overlap- All instances coming, may stay with the super class or map to multiple sub classes.
Total Participation vs Partial Participation.
In total participation, patient must be an outpatient or resident patient, it can not simply be the superclass patient type. Partial participation allows you to have a patient be just a patient.
Under Total specialization, there can be no entities that are of a superclass but are not of any of the subclasses. This is represented by the double line drawn from patient
Disjoint means a subclass type patient can be either an outpatient or resident patient but not both. Subclasses can only be one subclass from the superclass not both.
So in both diagrams a patient must be a one of the subclasses, but the disjoint means it can not be both subclasses.
When you use a total specialization, in the example shown, a patient must be either a outpatient or a resident patient, which means that all patients needs to be one of the sub types(outpatient or resident).
The disjoint rule is different in the way that a patient needs to be in only one subtype.
Basically, as I understand, the difference is that the total specialization says a super type needs to be in a sub type and the disjoint says it need to be in only one sub type.
I hope this helps.
There is a link that you can read about all these types and rules:
http://www.tomjewett.com/dbdesign/dbdesign.php?page=subclass.php
There are 2 different decisions {Total participation vs Partial participation} and {Disjoint vs Overlap}.
Participation -> ∈ {subclass1,..,subclassN} vs ∈ {subclass1,..,subclassN, superclass}
Subclass Type -> ∈ {S1 xor S2 xor ... xor SN} vs ∈ {S1 or S2 or ... or SN}
where S is the entities.
I'm really confused on the difference between disjoint and overlapping design constraints in relational databases. I've looked around, but have had a hard time finding an understandable example. Could someone please explain this to me via an example?
Thanks!
Say you have a super class 'musician' then two sub classes 'singer' and 'guitar player'.
In a disjoint constraint you would have to put the musician in either one or the other sub classes. In an overlapping constraint the musician can be put in both.
Let's say you have a super class 'account' with sub classes 'Savings Account' and 'Current Account'. This is a disjoint constraint situation because a bank account can either be Savings or Current. It cant be both at the same time.
For an overlapping constraint situation, let's say we have a super class 'Person' and subclasses 'Customer' and 'Employee'. In this case, a person can be Customer and Employee both. Therefore, overlapping.
The disjoint rule states an entity instance of a supertype can only be a member of one subtype. The overlap rule states an entity instance of a supertype can be a member of multiple subtypes.
Example of disjoint rule:
Instance of Super-type Animal can only be member of exactly one of these Sub-types being Panda, Cheetah and Dog
Disjoint Union , (An animal can either be Panda or be Dog or be Cheetah but can't be any two or more at the same time)
Example of overlap rule: Instance of Super-type Person can be member of multiple Sub-types being Woman, Driver and Engineer
Overlapping Union , (A person can be a Woman and that same Woman can be Driver and that same Woman can be Engineer at the same time)
Let's simplify this confusing concept. First of all, understand that there is a discriminator between subtype and supertype. If the value of a discriminator is not null and appears in supertype entity instance then that must be linked with the only one subtype. This is called disjoint constraint.
For example, you say in school a person can be teacher and student but a teacher can't be a student and vice versa. Then in person supertype and (student, teacher) subtype exists a discriminator called person_type. If person_type in person entity is 't' then it is linked with teacher subtype only not with a student. Similarly, we can write it for the student.
Now, in overlapping constraint, the supertype entity instance can appear in many subtype instance.
In overlapping example consider a teacher can be a student also. Then 't' can be linked with student and teacher subtype entity.
suppose Member is super class and its two sub-classes one is student and 2nd one is faculty,if(Member) of subclass(student or faculty)not both then it is disjoint.
if member both of its subclass then it non-disjoint or overlapping.
.