I want to find out if an Individual belonging to Class A, has a least one relation with ALL the Individuals of Class B.
I have a problem finding a suitable expression that gives me the DL query results I desire. For the below example:
Classs: Course {CourseA, CourseB, CourseC, CourseD}
Class: Program {UG_CE, G_CE}
Class: Student {John}
ObjectProperty: is-PartOf (Course,Program)
ObjectProperty: hasEnrolledIn (Student, Course)
for Individuals: CourseA and CourseB, I asserted the property:
is-PartOf UG_CE
For Individual John, the following 3 properties were asserted:
hasEnrolledIn CourseA
hasEnrolledIn CourseB
hasEnrolledIn CourseC
I also added to individual type
hasEnrolledIn only ({CourseA , CourseB , CourseC})
to address OWA problems.
I want to know if John has enrolled in all the courses that are required for UG_CE, note that John has enrolled in all courses and an additional course.
After invoking the reasoner, the following query will not give me the desired result:
Student that hasEnrolledIn only (is-PartOf value UG_CE)
since "only" is limited to defining the exact number of relationships, it does not serve the intended purpose. Also, I can't use Max or Min since the number of courses are inferred and not known in advance.
Can another approach address my problem?
While it's good to "close" the world with regard to what classes John is taking, it's just as important to close it with regard to what classes are required for UG_CE. I think you need an approach like this:
M requires A.
M requires B.
M : requires only {A, B}.
J enrolledIn A.
J enrolledIn B.
J enrolledIn C.
J : enrolledIn only {A, B, C}.
For an individual student J, you can find out whether they are enrolled in all the classes required for M by asking whether the set of classes required by M is a subset of the set of classes enrolled in by the student:
(inverse(requires) value M) SubClassOf (inverse(enrolledIn) value J)
or, in DL notation, with enumerated classes (lots of possible ways to express this):
∃ requires-1.{M} ⊑ ∃ enrolledIn-1.{J}
Now, if OWL had property negation, you could get the set of students who are only not enrolled in classes not required by an expression like this:
not(enrolledIn) only not(inverse(requires) value M)
That asks for things such that the only courses they're not enrolled in are courses not required by M. However, OWL doesn't have property negation expressions, so I'm not sure where that leaves us. The simplest thing to do would be add a "not enrolled in" property, though that doesn't seem as elegant.
Related
I am wondering if there is a way to define sets in ampl for the following problem?!
I wanna make a model with parameter X which is n dimensional. It is about information of each person in a household. such as age, job, ...
now I have 1000 family and for each family I want to define a parameter which has information X for each person.For example if I have one family I can define:
set G, default{1..p};
set F, default{1..t}; #number of family
set K, within G cross F;
param X{K};
in the above example, X show the information of each person in the household.
How about if I have 1000 household? it does not make sense if I want to define 1000 sets with my hand!
You can index a set over another set; see Section 6.5 of the AMPL book.
As a side note, I would recommend that you create separate parameters for each piece of information (age, job, ...) rather than including them all in a single parameter X.
First of all, my English is poor, so sorry if my writing is confusing.
I'm trying to create the following relationship between instances: if A propertyX B, and C propertyY A, then C propertyX B. In my case, I want to specify that if a ManagerA "manages" an employee, and ManagerB has the same job as ManagerA, then he also manages the same employee.
I tried to use chain properties to do that, but the reasoner (FaCT ++ 1.6.5) doesn't work when I activate it (the log says a non-simple property is being used as one). I think the problem is in the fact that the property "manages" is asymmetric and irreflexive and the property "sameJob" is transitive and symmetric, but I'm not sure if that's the case. I applied the chain property in the "manages" property, stating: sameJob o manages SubPropertyOf: manages.
I'm just starting with Protégé and will appreciate any help a lot.
The reason for the error is due to manages not being a simple role, i.e. if you have r1 o ... o rn subPropertyOf r where n>1 then r is a non-simple role. Non-simple roles cannot be used in IrreflexiveObjectProperty and AsymmetricObjectProperty. See section 11 of OWL 2 syntax. The reason for the constraint on roles is to maintain decidability.
However, you can achieve the desired result by adding a SWRL rule:
manages(?x, ?y) ^ sameJob(?x, ?z) -> manages(?z, ?y).
In an OWL-DL ontology, consider a property p with domain D and range R where D has a restriction over p to have cardinality of exactly one:
D SubClassOf p exactly 1 Thing
(D ⊑ =1 p.Thing)
Can we then infer that p is a functional property, since each d of type D will have exactly one value for p? If this is correct, can a reasoner infer this knowledge?
In OWL, a property is function when each individual has at most one value for the property. That "at most" is important; it is permitted for something to have no value for the property. (That means that a functional property in OWL is actually more like a possibly partial function in mathematics.) That said, if every individual has a exactly one value for a property, then it clearly has at most one value for the property, so the property would, as you suspect, be functional. We can walk though a specific case, though, to be sure that this is general, and because we need to make sure that the property p here actually has at most one value for every individual.
Proof: Suppose the property p has domain D, and D is a subclass of =1 p.Thing, so that every D has exactly one p
value. Is it the case that every individual x has at most one value
for p? There are two cases to consider:
x is a D. Then by the subclass axiom with the restriction, x must have exactly one value for p, and one is less than or equal to
one.
x is not a D. Then x has no values for p. If it did, then it would be in the domain of p, which is D, and that is a
contradiction. Then x has zero values for p, and zero is less
than or equal to one.
Then any individual x at most one value for the property p, which
is the definition of p being functional. Thus, p is functional.
QED
An OWL DL reasoner should be able to confirm this, and it shouldn't be hard to check.
I'm using Protege v4.3 for making ontologies.
I have a question about OWL ontology and DL query.
For instance, in the Pizza ontology,
http://owl.cs.manchester.ac.uk/co-ode-files/ontologies/pizza.owl
I can execute the DL query
hasTopping some CheeseTopping
The result is
American, AmericanHot, Cajun,.. etc. That's OK.
Now, i tried DL query
isToppingOf some American
But the result is nothing.
Because the property isToppingOf is inverse property of hasTopping,
I expected to get the result including FourCheesesTopping, CheeseyVegetableTopping, etc. from that query(by inference). Bud it didn't.
Is there any ways automatic reasoning like that?
The class expression
hasTopping some CheeseTopping
is the set of individuals each of which is related to some CheeseTopping by the hasTopping property. In the Pizza ontology, where there are no individuals, you can still get class subclass results for this query because the definition of certain types of Pizzas (e.g., American) are such that any Pizza that is an American must have such a topping.
Now, the similarly-structured query
isToppingOf some American
is the set of individuals each of which is related to some American pizza by the isToppingOf property. However, the Pizza ontology defines no particular individuals, so there aren't any individuals as candidates. But what about classes that might be subclasses of this expression? For instance, you mentioned the FourCheeseTopping. Now, some particular instance of FourCheeseTopping, e.g., fourCheeseTopping23 could be a topping of some American pizza, e.g.:
fourCheeseTopping23 isToppingOf americanPizza72
However, fourCheeseTopping might not have been placed on any particular pizza yet. When we choose an arbitrary individual of type FourCheeseTopping, we can't infer that it is a topping of some American pizza, so we cannot infer that the class FourCheeseTopping is a subclass of
isToppingOf some American
because it's not the case that every instance of FourCheeseTopping must be the topping of some American pizza. For a similar case that might make the logical structure a bit clearer, consider the classes Employer and Person, and the object property employs and its inverse employedBy. We might say that every Employer must have some Person as an Employee (since otherwise they wouldn't be an employer):
Employer ⊑ employs some Person
However, since a person can be unemployed, it is not true that
Person ⊑ employedBy some Employer
even though employs and employedBy are inverses.
What you can do, though, if you want to know whether toppings of a particular type could be placed an pizza of a particular type, is to ask whether
PizzaType ⊓ ∃hasTopping.ToppingType
is equivalent to, or a subclass of, owl:Nothing. For instance, since an American pizza has only toppings of type TomatoTopping, MozzarellaTopping, and PeperoniTopping [sic], the class
American ⊓ ∃hasTopping.MixedSeafoodTopping
is equivalent to owl:Nothing:
On the other hand, since an American pizza must have a MozzarellaTopping, the class
American ⊓ ∃hasTopping.MozzarellaTopping
is equivalent to American:
When you ask what are the subclasses of:
isToppingOf some American
you are asking what classes contain toppings that are necessarily used on top of American pizzas. But in the pizza ontology, no such class exists. Consider cheese toppings: Are all cheese toppings on top of some American pizzas? No, some cheese toppings are on top of Italian pizzas. The same holds for all topping classes.
I am trying to use SmallCheck to test a Haskell program, but I cannot understand how to use the library to test my own data types. Apparently, I need to use the Test.SmallCheck.Series. However, I find the documentation for it extremely confusing. I am interested in both cookbook-style solutions and an understandable explanation of the logical (monadic?) structure. Here are some questions I have (all related):
If I have a data type data Person = SnowWhite | Dwarf Integer, how do I explain to smallCheck that the valid values are Dwarf 1 through Dwarf 7 (or SnowWhite)? What if I have a complicated FairyTale data structure and a constructor makeTale :: [Person] -> FairyTale, and I want smallCheck to make FairyTale-s from lists of Person-s using the constructor?
I managed to make quickCheck work like this without getting my hands too dirty by using judicious applications of Control.Monad.liftM to functions like makeTale. I couldn't figure out a way to do this with smallCheck (please explain it to me!).
What is the relationship between the types Serial, Series, etc.?
(optional) What is the point of coSeries? How do I use the Positive type from SmallCheck.Series?
(optional) Any elucidation of what is the logic behind what should be a monadic expression, and what is just a regular function, in the context of smallCheck, would be appreciated.
If there is there any intro/tutorial to using smallCheck, I'd appreciate a link. Thank you very much!
UPDATE: I should add that the most useful and readable documentation I found for smallCheck is this paper (PDF). I could not find the answer to my questions there on the first look; it is more of a persuasive advertisement than a tutorial.
UPDATE 2: I moved my question about the weird Identity that shows up in the type of Test.SmallCheck.list and other places to a separate question.
NOTE: This answer describes pre-1.0 versions of SmallCheck. See this blog post for the important differences between SmallCheck 0.6 and 1.0.
SmallCheck is like QuickCheck in that it tests a property over some part of the space of possible types. The difference is that it tries to exhaustively enumerate a series all of the "small" values instead of an arbitrary subset of smallish values.
As I hinted, SmallCheck's Serial is like QuickCheck's Arbitrary.
Now Serial is pretty simple: a Serial type a has a way (series) to generate a Series type which is just a function from Depth -> [a]. Or, to unpack that, Serial objects are objects we know how to enumerate some "small" values of. We are also given a Depth parameter which controls how many small values we should generate, but let's ignore it for a minute.
instance Serial Bool where series _ = [False, True]
instance Serial Char where series _ = "abcdefghijklmnopqrstuvwxyz"
instance Serial a => Serial (Maybe a) where
series d = Nothing : map Just (series d)
In these cases we're doing nothing more than ignoring the Depth parameter and then enumerating "all" possible values for each type. We can even do this automatically for some types
instance (Enum a, Bounded a) => Serial a where series _ = [minBound .. maxBound]
This is a really simple way of testing properties exhaustively—literally test every single possible input! Obviously there are at least two major pitfalls, though: (1) infinite data types will lead to infinite loops when testing and (2) nested types lead to exponentially larger spaces of examples to look through. In both cases, SmallCheck gets really large really quickly.
So that's the point of the Depth parameter—it lets the system ask us to keep our Series small. From the documentation, Depth is the
Maximum depth of generated test values
For data values, it is the depth of nested constructor applications.
For functional values, it is both the depth of nested case analysis and the depth of results.
so let's rework our examples to keep them Small.
instance Serial Bool where
series 0 = []
series 1 = [False]
series _ = [False, True]
instance Serial Char where
series d = take d "abcdefghijklmnopqrstuvwxyz"
instance Serial a => Serial (Maybe a) where
-- we shrink d by one since we're adding Nothing
series d = Nothing : map Just (series (d-1))
instance (Enum a, Bounded a) => Serial a where series d = take d [minBound .. maxBound]
Much better.
So what's coseries? Like coarbitrary in the Arbitrary typeclass of QuickCheck, it lets us build a series of "small" functions. Note that we're writing the instance over the input type---the result type is handed to us in another Serial argument (that I'm below calling results).
instance Serial Bool where
coseries results d = [\cond -> if cond then r1 else r2 |
r1 <- results d
r2 <- results d]
these take a little more ingenuity to write and I'll actually refer you to use the alts methods which I'll describe briefly below.
So how can we make some Series of Persons? This part is easy
instance Series Person where
series d = SnowWhite : take (d-1) (map Dwarf [1..7])
...
But our coseries function needs to generate every possible function from Persons to something else. This can be done using the altsN series of functions provided by SmallCheck. Here's one way to write it
coseries results d = [\person ->
case person of
SnowWhite -> f 0
Dwarf n -> f n
| f <- alts1 results d ]
The basic idea is that altsN results generates a Series of N-ary function from N values with Serial instances to the Serial instance of Results. So we use it to create a function from [0..7], a previously defined Serial value, to whatever we need, then we map our Persons to numbers and pass 'em in.
So now that we have a Serial instance for Person, we can use it to build more complex nested Serial instances. For "instance", if FairyTale is a list of Persons, we can use the Serial a => Serial [a] instance alongside our Serial Person instance to easily create a Serial FairyTale:
instance Serial FairyTale where
series = map makeFairyTale . series
coseries results = map (makeFairyTale .) . coseries results
(the (makeFairyTale .) composes makeFairyTale with each function coseries generates, which is a little confusing)
If I have a data type data Person = SnowWhite | Dwarf Integer, how do I explain to smallCheck that the valid values are Dwarf 1 through Dwarf 7 (or SnowWhite)?
First of all, you need to decide which values you want to generate for each depth. There's no single right answer here, it depends on how fine-grained you want your search space to be.
Here are just two possible options:
people d = SnowWhite : map Dwarf [1..7] (doesn't depend on the depth)
people d = take d $ SnowWhite : map Dwarf [1..7] (each unit of depth increases the search space by one element)
After you've decided on that, your Serial instance is as simple as
instance Serial m Person where
series = generate people
We left m polymorphic here as we don't require any specific structure of the underlying monad.
What if I have a complicated FairyTale data structure and a constructor makeTale :: [Person] -> FairyTale, and I want smallCheck to make FairyTale-s from lists of Person-s using the constructor?
Use cons1:
instance Serial m FairyTale where
series = cons1 makeTale
What is the relationship between the types Serial, Series, etc.?
Serial is a type class; Series is a type. You can have multiple Series of the same type — they correspond to different ways to enumerate values of that type. However, it may be arduous to specify for each value how it should be generated. The Serial class lets us specify a good default for generating values of a particular type.
The definition of Serial is
class Monad m => Serial m a where
series :: Series m a
So all it does is assigning a particular Series m a to a given combination of m and a.
What is the point of coseries?
It is needed to generate values of functional types.
How do I use the Positive type from SmallCheck.Series?
For example, like this:
> smallCheck 10 $ \n -> n^3 >= (n :: Integer)
Failed test no. 5.
there exists -2 such that
condition is false
> smallCheck 10 $ \(Positive n) -> n^3 >= (n :: Integer)
Completed 10 tests without failure.
Any elucidation of what is the logic behind what should be a monadic expression, and what is just a regular function, in the context of smallCheck, would be appreciated.
When you are writing a Serial instance (or any Series expression), you work in the Series m monad.
When you are writing tests, you work with simple functions that return Bool or Property m.
While I think that #tel's answer is an excellent explanation (and I wish smallCheck actually worked the way he describes), the code he provides does not work for me (with smallCheck version 1). I managed to get the following to work...
UPDATE / WARNING: The code below is wrong for a rather subtle reason. For the corrected version, and details, please see this answer to the question mentioned below. The short version is that instead of instance Serial Identity Person one must write instance (Monad m) => Series m Person.
... but I find the use of Control.Monad.Identity and all the compiler flags bizarre, and I have asked a separate question about that.
Note also that while Series Person (or actually Series Identity Person) is not actually exactly the same as functions Depth -> [Person] (see #tel's answer), the function generate :: Depth -> [a] -> Series m a converts between them.
{-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, FlexibleContexts, UndecidableInstances #-}
import Test.SmallCheck
import Test.SmallCheck.Series
import Control.Monad.Identity
data Person = SnowWhite | Dwarf Int
instance Serial Identity Person where
series = generate (\d -> SnowWhite : take (d-1) (map Dwarf [1..7]))