My question goes beyond one question which already has been asked here
I defined a qualified cardinality restriction like this one:
Pizza and hasTopping exactly 4 CheeseTopping and hasTopping only CheeseTopping
Now, how do I force inconsistency of the ontology when having an individual of asserted type 'FourCheesePizza' with less than four 'CheeseTopping' property assertions?
In other words: How do I state that the let us say two 'CheeseTopping' property assertions are definitely the only ones so that an inconsistency is forced?
Making a statement like that is not too difficult in OWL, but because of the open world assumption, it does mean that you have to make sure that a bit more knowledge is available. First, the two-cheese-pizza, let's call it p, that will be inconsistently labelled a four-cheese-pizza must somehow be declared to have exactly two cheese toppings. You can do this by giving p the type
hasTopping exactly 2 CheeseTopping .
This would be enough to get the inconsistency. If that seems a bit generic, and you want to specify the exact toppings that p can have, you could give p a type like
hasTopping only { Cheddar, Mozzarella }
which says that p can only have Cheddar and Mozzarella as toppings. At this point, we know that p can have at most two toppings (it could be just one, if Cheddar and Mozzarella haven't been declared to be different individuals), which is inconsistent with it being a FourCheesePizza and having four cheese toppings.
Related
This has bothered me for some time. What assumptions are to be made, in regards to cardinality when a relationship does not use crow's foot notation- in my opinion- completely. For example, here is a one-to-many relationship from Wikipedia:
I would have thought that this in incorrect; that children must have a mother so I would put two lines on the left side (one mandatory and only one) and a 1 to many for the children (a line and a crow's foot) on the right to indicate that a mother must have at least one child, but could have many. I would have expected this:
My question is, what assumptions are to be made in a "shortcut" like this because I see it everywhere on cardinality examples? Is there a known assumption or rule of what leaving those blank mean?
Both are correct.
The difference between them is that Wikipedia's example isn't Crow's Foot, but a variation called Barker Notation. It looks so similar as Richard Barker modelled it on Crow's Foot and intended it as a refinement
(For some reason, they taught us Barker Notation at college as opposed to Crow's Foot)
I am trying to understand an already annotated the sentence When this happens, the two KIMs show a magnetism that causes the first KIM to move toward the second KIM.
What does number 1 in POS tag WHADVP-1 for When mean/signify?
Similarly what does number 1 in POS tag WHNP-1 for that mean/signify?
I think I understand well POS tags, after reading http://web.mit.edu/6.863/www/PennTreebankTags.html and
notes by Andrew McIntyre.
They are indices for coreference resolution. I think this guide from the University of Tübingen, Germany puts it quite nicely.
4.1.2 Indexing
Indices are used only when they can be used to indicate a relationship
that would otherwise not be unambiguously retrievable from the
bracketing. Indices are used to express such relationships as
coreference (as in the case of controlled PRO or pragmatic coreference
for arbitrary PRO), binding (as in the case of wh-movement), or close
association (as in the case of it-extraposition). These relationships
are shown only when some type of null element is involved, and only
when the relationship is intrasentential. One null element may be
associated with another, as in the case of the null wh-operator.
Coreference relations between overt pronouns and their antecedents are
not annotated.
I work quite a lot with POS taggers and I usually just ignore the numbers chained on, unless I am debugging a parse error and want to know why a sentence is tagged wrong. They can be very useful for training sequencing algorithms such as MMEM, CRFs, etc.
Say we have this simple ontology as a toy example:
I now receive evidence about a certain object x (for example, "x is a boat", "x is a car") and want to make a statement on what I know about this object.
A sensible approach would be to use my tree and calculate the lowest common ancestor (LCA) of my evidence, and return that as a result. In my example (car and boat), this would result in vehicle.
Let's now say that I have evidence that an object y is a car and a vehicle. The LCA of these is vehicle. In this case, however, I want the result to be car, since the evidence of y being a vehicle does not contradict it being a car.
I implemented this alternative LCA algorithm (by ignoring evidence that's on the path to root of other evidence), but have not found anything about such an approach on the internet. Is there a name for the alternative algorithm I used?
From your description I think you're implementing a least common subsumer algorithm: the most specific class that subsumes two or more class expressions, and can also be equal to one such class.
I do understand the meaning of "discriminated" and "union" in their standalone contexts, but i am at loss when it comes to the F#'s "Discriminated Union".
Fyi, English is not my first language and I am not good at Math either. So i hope someone out there can shed some light on this feature of F#. Please.
What i need to know is:
the use case for this discriminated union. What it is normally used for?
it's equivalent to other OOP feature/terms. if there's any.
is it like set operation where we use venn diagrams to represent the data?
Or you can help me pointing to links.
A discriminated union is a union of two sets where you can tell which set an item originally belonged to; even if they are the same thing, you can discriminate between them, i.e. tell them apart.
For instance, if you have a discriminated union of two sets of integers, both containing the number 2, you can discriminate between the 2s because you know which original set it came from.
As an example, consider points in the 2-dimensional plane.
These can be expressed as a pair of reals in two ways, either using rectangular (or Cartesian) coordinates (x coordinate, y coordinate) or using polar coordinates (angle of rotation, distance).
But if someone just gives you a pair of numbers, you wouldn't know what they meant.
We can form a discriminated union, though:
type Point2D =
| Rectangular of real * real
| Polar of real * real
Now any Point2D value makes the intended interpretation clear, and the compiler can make sure that we don't try to mix the representations or fail to handle a case.
In an OO setting, you would build a class hierarchy with an abstract base class, or have a "kind" member that you could inspect.
It's more common to form unions of different types, though - if you wrote an interpreter for a programming language you might have something that looks like
type Expression =
| Integer of int
| String of string
| Identifier of string
| Operator of string
| Conditional of Expression * Expression * Expression
| Definition of string * Expression
and so on.
Discriminated unions are also called "sum types", and tuples are called "product types".
These terms come from the discipline of type algebra, and the resultant types are called "Algebraic Data Types".
(When functional programmers mention "ADT", the "A" is usually for "Algebraic", not "Abstract".)
The question is very broad but I will try to give a succint answer.
You can think of DUs as Enums on steroids - you can define a new datatype with distinct cases - just like enums - but on top of this each case may (or may not) contain additional data.
A simple example could be:
type Contact =
| Email of String
| Phone of String
| None
And where DUs are Enum on steroids so is patternmatching instead of switch where you can deconstruct the data
let contactToString = function
| Email e -> e
| Phone p -> p
| None -> "no conctact given"
Basically you use DUs in F# and other FP-languagues all the time to structure data in the obvious ways - you gain much from this - for example the compiler will warn you if you miss a case, ...)
The equivalent in OOP (indeed it's compiled into something very similar) is a Base-class Contact with subclasses for each case (EmailContact : Contact, etc. ) that contains the data-part.
But there is a important difference: you can extent such OOP inheritance structures but you cannot externaly extendt DUs. (see Expression-Problem).
And finally: no it has nothing to do with venn-diagramms or set-theory or anything.
The relation to math is, that this structures are called algebraic-datatypes or sum-types because if you count the different values these types can have you have to sum-up the values for each case. (See Tuples too - these are product-types for similar reasons)
I was following this tutorial -> LINK
At page 75, it explains how to define a FourCheesePizza using a qualified cardinality restriction. Under the instructions it says "With this description a FourCheesePizza can still also have other relationships to other kinds of toppings. In order for us to say that we just want it to have four cheese toppings and no other toppings we must add the keyword 'only' (the universal quantifier)".
Now, my definition of FourCheesePizza is:
Pizza and hasTopping exactly 4 CheeseTopping
but I don't understand where to add the 'only' keyword, because I only get syntax errors.
If you want a four cheese pizza with nothing else than cheese, you have to define it in this way:
Pizza and hasTopping exactly 4 CheeseTopping and hasTopping only CheeseTopping