I have following classes: Classes B, C and D are the subclasses of A.
A ----+----------> B
|
+----------> C
|
+----------> D
Besides, I have an object property, hasObjectProperty, and some other classes X, Y, Z,
where X, Y, Z are disjoint classes.
Then I set restrictions to classes B, C and D as following:
(Here I use Manchester OWL syntax used in Protege as well http://www.co-ode.org/resources/reference/manchester_syntax/ )
B: (hasObjectProperty only X) and (hasObjectProperty some X)
C: (hasObjectProperty only Y) and (hasObjectProperty some Y)
D: (hasObjectProperty only Z) and (hasObjectProperty some Z)
now the question is, how can I describe a Class E, which should be the union of only Class B and C?
How can I describe a Class which can be both Class B and Class C (but not Class D)?
A ----+----------> B ------> E
|
+----------> C ------> E
|
+----------> D
is is possible?
I tried to define Class E's restriction like this. But a Reasoner will determine it as invalid.
E: ((hasObjectProperty only X) and (hasObjectProperty some X)) or ((hasObjectProperty only Y) and (hasObjectProperty some Y))
thanks a lot!
In order to restrict E to be exactly the union of B and C, you can state:
E ≡ (B or C)
i.e., that anything belonging to the union of B and C is in E, and vice-versa (encoding the subsumption relationship both ways).
Note that this necessarily makes E a superclass to both B and C since it contains them both, so you will instead get:
A --+---> E --+---> B
| |
+---> D +---> C
Related
Chanced upon this beautiful problem. Since I am new to Boolean expressions, it is looking quite difficult.
I guess parentheses can be used.
If one of A, B, C is true, A||B||C must be true. Using AND and NOT, it can be done but, how do we know which one has which value?
I tried using truth tables, but three variables were too much.
Any ideas on how to solve, or at least how to make it faster?
Learn De Morgan's laws. It's a little piece of a basic knowledge for a programmer.
They state, among others, that not(X or Y) = (not X) and (not Y).
If you negate both sides and then apply the formula twice—first to ((A or B) or C), treating the (A or B) subexpression as X, and then to (A or B) itself—you'll get the desired result:
A || B || C =
(A || B) || C =
!(!(A || B) && !C) =
!((!A || !B) && !C) =
!(!A && !B && !C)
DeMorgan's Law (one of them, anyway), normally applied to two variables, states that:
A or B == not (not A and not B)
But this works equally well for three (or more) variables:
A or B or C == not (not A and not B and not C)
This becomes obvious when you realise that A or B or C is true if any of them are true, the only way to get false if if all of them are false.
And, only if they're all false will not A and not B and not C give true (hence not(that) will give false). For confirmation, here's the table, where you'll see that the A or B or C and not(notA and notB and notC) columns give the same values:
A B C A or B or C notA notB notC not(notA and notB and notC)
----- ----------- -------------- ---------------------------
f f f f t t t f
f f t t t t f t
f t f t t f t t
f t t t t f f t
t f f t f t t t
t f t t f t f t
t t f t f f t t
t t t t f f f t
I am working upon formalization of groups theory in coq. I have 2 files:
groups.v - contains definitions and theorems for groups
groups_Z.v - contains theorems and definitions for Z group.
groups.v:
Require Import Coq.Setoids.Setoid.
Require Import Coq.Lists.List.
Require Import PeanoNat.
Class Semigroup G : Type :=
{
mult : G -> G -> G;
assoc : forall x y z:G,
mult x (mult y z) = mult (mult x y) z
}.
Class Monoid G `{Hsemi: Semigroup G} : Type :=
{
e : G;
left_id : forall x:G, mult e x = x;
}.
Class Group G `{Hmono: Monoid G} : Type :=
{
inv : G -> G;
left_inv : forall x:G, mult (inv x) x = e;
}.
Declare Scope group_scope.
Infix "*" := mult (at level 40, left associativity) : group_scope.
Open Scope group_scope.
Section Group_theorems.
Parameter G: Type.
Context `{Hgr: Group G}.
(* More theorems follow *)
Fixpoint pow (a: G) (n: nat) {struct n} : G :=
match n with
| 0 => e
| S n' => a * (pow a n')
end.
Notation "a ** b" := (pow a b) (at level 35, right associativity).
End Group_theorems.
Close Scope group_scope.
groups_Z.v:
Add LoadPath ".".
Require Import groups.
Require Import ZArith.
Open Scope group_scope.
Section Z_Groups.
Parameter G: Type.
Context `{Hgr: Group G}.
Definition pow_z (a: groups.G) (z: Z) : G :=
match z with
| Z0 => e
| Zpos x => pow a (Pos.to_nat x)
| Zneg x => inv (pow a (Pos.to_nat x))
end.
Notation "a ** b" := (pow_z a b) (at level 35, right associativity).
End Z_groups.
Close Scope group_scope.
The attempt to define pow_z fails with message:
The term "pow a (Pos.to_nat x)" has type "groups.G" while it is
expected to have type "G".
If we use the different signature: Definition pow_z (a: G) (z: Z) : G
instead of Definition pow_z (a: groups.G) (z: Z) : G.
then it gives another error:
The term "a" has type "G" while it is expected to have type
"groups.G".
How to fix this?
In Coq, the command Parameter G : Type declares a global constant, which is akin to axiomatizing the existence of an abstract Type G : Type. From a theoretical point of view, this should be ok as this axiom is trivially realizable, but I think you meant Variable G : Type to denote a local variable instead.
The errors messages of Coq follow from there because you declare two global constants named G, one in each module. As soon as the second one is declared, the first one is designated by groups.G by Coq (it's the shortest name that disambiguates this constant from others). Now pow operates on and returns a groups.G, while you require pow_z returns a G (which in file groups_Z.v at this location means groups_Z.G, and is different from groups.G).
NB: Group theory has been developed several times in Coq, and if you want to do anything else than experimenting with the system, I would advise you work on top of existing libraries. For example the mathematical components library has a finite group library.
I changed Parameter G: Type. to Variable G: Type in both files and pow_z definition to this:
Definition pow_z (a: G) (z: Z) : G :=
match z with
| Z0 => e
| Zpos x => pow G a (Pos.to_nat x)
| Zneg x => inv (pow G a (Pos.to_nat x))
end.
I have the following problem: R(ABCDEFG) and F ={ AB->CD, C->EF, G->A, G->F, CE ->F}. Clearly, B & G should be part of the key as they are not part of the dependent set. Further, BG+ = ABCDEFG, hence candidate key. Clearly, AB->CD violates BCNF. But when I follow the algorithm, I do not end up in any answer. Probably doing something wrong. Can anyone show me how to apply the algorithm correctly to reach the decomposition?
Thanks in advance.
First, you should calculate a canonical cover of the dependencies. In this case it is:
{ A B → C
A B → D
C → E
C → F
G → A
G → F } >
Since the (unique) candidate key is B G, no functional dependency satisfies the BNCF. Then, starting from any functional dependency X → Y that violates the BCNF, we calculate the closure of X, X+, and replace the original relation R<T,F> with two relations, R1<X+> and R2<T - X+ + X>. So, chosing in this case the dependency A B → C, we replace the original relation with:
R1 < (A B C D E F) ,
{ A B → C
A B → D
C → E
C → F} >
and:
R2 < (A B G) ,
{ G → A } >
Then we check each decomposed relation to see if it satisfies the BCNF, otherwise we apply recursively the algorithm.
In this case, for instance, in R1 the key is A B, so C -> E violates the BCNF, and we replace R1 with:
R3 < (C E F) ,
{ C → E
C → F } >
and:
R4 < (A B C D) ,
{ A B → C
A B → D } >
two relations that satisfy the BCNF.
Finally, since R2 too does not satisfy the BCNF (beacuse the key is B G), we decompose R2 in:
R5 < (A G) ,
{ G → A } >
and:
R6 < (B G) ,
{ } >
that are in BCNF.
So the final decomposition is constituted by the relations: R3, R4, R5, and R6. We can also note that the dependency G → F on the original relation is lost in the decomposition.
I have this database:
R(A, B, C, D, E)
Keys: A
F = {A -> B, D -> E, C -> D}
I normalize it into 3NF like this:
R(A, B, C, D, E)
Keys: AD
F = {AD -> B, AD -> E, C -> D}
What I do is when I check D -> E, D is not a superkey and E is not a key attribute, so I treat D and A as a superkey {AD}. When I check C -> D, C is not a key but D is a key attribute so it's OK.
Is my normalization correctly?
There is a problem in your input data. If the relation R has the dependencies F = {A -> B, D -> E, C -> D}, then A cannot be a key. In fact, a key is a set of attributes whose closure determines all the attributes of the relation, which is not the case here, since:
A+ = AB
From F, the (only) possible key is AC, in fact
AC+ = ABCD
Normalizing means to reduce the redundancy by decomposing a relation in other relations in which the functional dependencies do not violate the normal form, and such that joining the decomposed relations, one can obtain the original one.
In you solution, you do not decompose the relation, but only change the set of dependencies with other dependencies not implied by the first set.
A correct decomposition would be instead the following:
R1 < (A B) ,
{ A → B } >
R2 < (C D) ,
{ C → D } >
R3 < (D E) ,
{ D → E } >
R4 < (A C) ,
{ } >
The algorithm to decompose a relation into 3NF can be found on any good book on databases.
I would like to build a kind of type hierarchy:
B is of type A ( B::A )
C and D are of type of B (C,D ::B)
E and F are of type of C (E,F ::C)
I asked here if this is possible to be directly implemented in Isabelle, but the answer as you see was No. Is it possible to encode this directly in Agda or Coq?
PS: Suppose A..F are all abstract and some functions are defined over each type)
Thanks
If I understood your question correctly, you want something that looks like the identity type. When we declare the type constructor _isOfType_, we mention two Sets (the parameter A and the index B) but the constructor indeed makes sure that the only way to construct an element of such a type is to enforce that they are indeed equal (and that a is of this type):
data _isOfType_ {ℓ} {A : Set ℓ} (a : A) : (B : Set ℓ) → Set where
indeed : a isOfType A
We can now have functions taking as arguments proofs that things are of the right type. Here I translated your requirements & assumed that I had a function f able to combine two Cs into one. Pattern-matching on the appropriate assumptions reveals that E and F are indeed on type C and can therefore be fed to f to discharge the goal:
example : ∀ (A : Set₃) (B : Set₂) (C D : Set₁) (E F : Set) →
B isOfType A
→ C isOfType B → D isOfType B
→ E isOfType C → F isOfType C
→ (f : C → C → C) → C
example A B .Set D E F _ _ _ indeed indeed f = f E F
Do you have a particular use case in mind for this sort of patterns or are you coming to Agda with ideas you have encountered in other programming languages? There may be a more idiomatic way to formulate your problem.