Related
Sorry the question is so confusing, I couldn't find a way to word it better. This is better explained with an example:
I have an Image model linked to a Game model. Each Image has a category (the categories are fixed and number about 10). I want to get 3 images of each category (or less, if there aren't enough) for a game.
This is the current implementation:
from django.db import models
class Game(models.Model):
...
class Image(models.Model):
category = models.CharField()
image = models.ImageField()
game = models.ForeignKey(Game)
#classmethod
def categories(cls):
return ('category1', 'category2', ...)
#classmethod
def get_game_images(cls, game:Game):
return [cls.objects.filter(game=game, category=category)
for category in cls.categories()]
# Do stuff with the images
game = Game.objects.all().first()
for category in Image.get_game_images(game):
print(category)
for image in category:
print('\t', image.image.url)
I feel a bit dumb doing 10 very similar queries to retrieve 3 elements each... A simple Image.objects.filter(game=game).order_by('category') gets close, but then ensuring there are only 3 rows per category becomes a bit complex. Is there a better way to accomplish the same result?
Thank you
You can use a single query that makes a union of certain subqueries:
from django.db.models import QuerySet
# …
#classmethod
def get_game_images(cls, game:Game):
QuerySet.union(
*[cls.objects.filter(game=game, category=category)[:3]
for category in cls.categories()]
)
This thus will make one query, and furthermore the QuerySet is lazy so if you do not enumerate over it, call len(…) on it, etc. it will not make the query.
The [:3] at the end means we will fetch at most three objects for that game and category.
I want to express the following in an OWL ontology in Protege: IndividualA is composed of IndividualB1 at X %, IndividualB2 at Y % and so on, up until 100%.
Does a pattern exists to model this?
I want to express the following in an OWL ontology in Protege:
IndividualA is composed of IndividualB1 at X %, IndividualB2 at Y %
and so on, up until 100%.
Does a pattern exists to model this?
I don't think you'll be able to get the guarantee/restriction on sums that you're looking for in OWL. But part of the structure that you're talking about is just an n-ary relationship. Instead of a two place relationship
isComposedOf(IndividualA, IndividualB1)
you have a three place relationship:
isComposedOfByPercent(IndividualA, IndividualB1, 0.34)
There are lots of ways to represent n-ary relationships using semantic technologies, so many so that the W3C published a working note, Defining N-ary Relations on the Semantic Web. In OWL, one of the most common approaches might be:
x a Composition ;
hasComposite IndividualA ;
hasComponent IndividualB1 ;
hasPercentage 0.34 .
Another might be:
IndividualA hasCompositePart y .
y a CompositePart ;
hasComponent IndividualB1 ;
hasPercentage 0.34 .
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.
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.
Let's say I have to model the meals of a diner.
A meal can consist of several "components":
(Fries OR rice OR wedges)
AND (One of six different beverages)
AND (One or two out of seven different sauces OR none at all)
Another meal can consist of:
(Salad OR rice)
AND (Garlic OR no garlic)
Further meals can consist of:
Just fries
Just a beverage
Just ...
How can I model this? (UML, entity-relationship, code, ... whatever you can explain best)
Perhaps it helps if you know some tasks I want to perform, so:
Allowing the customer to choose a meal first and display all remaining "add-ons".
Detecting a meal from a list of components. For example if the customer ordered fries, a sauce and a beverage, it should be possible to detect the meal from the first example.
I've thought about dividing all components into articles and then adding some kind of role mapping to mark "fries" as supplement to "cheeseburger", "schnitzel", "..." but then I wondered, how I could model multiple add-ons, optional add-ons, n-out-of-m add-ons...
I hope you can help me out...
If this is homework, it may not matter...
But - if this is going to be used in a real-world app, I would strongly recommend against using concrete classes for each food item ie. Coke class, Salad class, Rice class, etc. as recommended above.
This is a sure way to make your application inflexible.
It would be much better to have a food item class and a drink class with a name property or some such..
Imagine having to rebuild your whole application just because there is now a new special or food item... not cool ;).
I think what is missing from the other answers is the idea of a group.
Each food item could belong to a group along with other items, or by itself.
Say fries, rice, and wedges belong to group A. Drinks belong to group B.
Then you could model a combo as a list of groups - ie. 1 group A item and 1 group B item, or two group A items and1 group B item.
You could also make food items able to belong to multiple groups at the same time... to make the options more flexible.
The db model could get complicated defining all of the relationships, but I think it's necessary.
Perhaps something like this:
group(id, name, desc) - group of like items - entrees, appetizers, drinks... or anything
foodItem(id, name, desc) - represents a single item - fries, rice, etc.
foodItem_group(foodIgem_Id, group_Id) - maps food items to their group - many to many
combo(id, name, desc) - describes a combo
combo_group(combo_Id, group_Id) - maps groups to combos - many to many
I think this would do for representing the basic required model - you may want additional tables to store what the customer actually ordered.. and of course detecting if a customer order matches a combo is left up to your business logic.
It seems like an order can consist of either meals, components, or a mix of both, so I would say, have an Order class that has a list of Components and Meals. Meal should either subclass Component, or they should implement the same interface.
A Meal consists of several "slots," which can be filled by some set of Components. Meals should know how many slots they have and what Components can fill them.
The "detecting a Meal from a list of Components" question is tricky. Off the top of my head, the best way I can think of is giving each Meal a method that takes a list of Components and returns true if that Meal can be made from them (or maybe the subset of Components that would make up that Meal). Order would go through the list of Meals it knows about and see if any of them can be made from the Components in the current Order. There may be a better way to do this, though.
Hope this helps!
Create Component class, and sublcasses (or objects) for all possible types of Components.
Create an abstract Meal class, and subclasses for all possible types of Meals. A Meal can check, whether a certain list of Components matches it (for detecting a meal from a list of components). And a Meal can present to a customer all the choices of components for this meal.
I agree with Amanda that the Meal should be built of the "Slots". Each slot represents one of the Component choices of the Meal, e.g. Fries OR rice OR wedges. A Slot may also model the m-outof-n option.
The Meal class:
class Meal
{
class MealSlot
{
Add(Component);
bool DoesItMatch(vector<Component> ComponentsVector)
{
//Check if this Slot is filled by some element(s)
// of ComponentsVector
}
PrintSlotOptions();
vector<Component> Options;
// for m-of-n option, if multiple items can be chosen in this slot
int HowManyNeededToFillIt;
};
bool DoesItMatch(vector<Component> ComponentsVector)
{
//Check if all Slots are filled by ComponentsVector elements,
//using Slot::DoesItMatch function
}
void PresentChoices()
{
for(i=0; i < Slots.size(); i++)
Slots[i].PrintSlotOptions;
}
vector<Slot> Slots;
};
One of Concrete Meals: (Salad OR rice) AND (Garlic OR no garlic)
class MealType2 : public Meal
{
MealType2()
{
Slots[0].Add(Salad);
Slots[0].Add(Rice);
Slots[1].Add(Garlic);
Slots[1].Add(NOTHING);
}
};
Create an Order class which will contain a Meal name, and a list of Components. If a Meal is ordered, call Meal.PresentChoices() . And if a list of Components is given, go over all the Meals and call Meal.DoesItMatch .
I assume this will eventually get stored in a database. I suggest to create two tables:
Would store the components (fries, salad, garlic, etc)
Would have: id1, id2, relationship. Relationship being:
belongs to
goes with
Based on the "belongs to" relationship, you could find if all components belong to a certain meal. Maybe then go and select all components that belong to that meal and suggest the meal if the components selected make up 50% or more of the meal.
Based on the "goes with" relationship, you could suggest add-ons to the meal, or to the components selected.
seems like you meal can be almost any collection of food items, so start with one abstract base class (or interface) for a Food. make lots of concrete subclasses, one for each food: coke, tea, steak, chicken, potato, rice, pasta, soup, salad, etc.
make your components interfaces: appetizer, dinner, protein, starch, dessert, drink, etc.
refactor your concrete classes into whatever hierarchy they seem to want to go into as you write code and tests.
sprinkle in the component interfaces where they make sense.