As shown in the screenshot, I have some subclasses of Person, and I've created Instances for Educational Level such as First_Level, Second_Level etc..
I'm wondering how would I assign these to individuals I have created or would I create these subclasses within Data Properties and assign it to individuals that way?
Thought I would've been able to assign Instances to individuals, but the only options I have are Object and Data property assertions under individuals.
You cannot assign an instance to an individual - instance and individual are synonyms in this context. If you want to establish a relation between two instances (i.e., two individuals), you should use an object property.
That said, your taxonomy looks surprising to me. Why would a date of birth be a subclass of Person? A date is not a kind of person, in most domains. Perhaps those shouldn't be subclasses of Person, and this is why you're finding it difficult to model your assertions?
Related
So I'm currently working on an ontology which has an EnumerationClass set up in a similar manner to how Enumeration is set up in Schema.org (https://schema.org/Enumeration).
It has subclasses which I'll call ProgramTypeEnumeration and SubstanceTypeEnumeration. Both of these have defined instances. Let's say ProgramTypeEnumeration has instances BasicProgram and AdvancedProgram.
Then there is a property called hasProgramType which relates an AcademicClass class to a program type in the ProgramTypeEnumeration. My assumption is that domain would be AcademicClass and range would be ProgramTypeEnumeration.
That being said, my understanding is that an enumeration is effectively a list. Is it correct to say that BasicProgram is an instance of ProgramTypeEnumeration when BasicProgram is not a list? As well, I'm not saying that hasProgramType has a range of instances of lists of programs, but a range of instances of programs. Would it be better to have a class ProgramType which is a part_of a ProgramTypeEnumeration and then have ProgramType be the range of hasProgramType?
As well, more broadly, is every finite class with a set number of instances technically a subclass of enumeration? e.g. would a class "U.S. State" be a subclass of enumeration if it has exactly 50 instances? Would "ZIP Code" be a subclass of enumeration since it technically also has an exactly number of instances? How do I define whether a class is or isn't an enumeration?
EDIT 1: Attempting to provide a more clear example here.
So Schema.org has an Enumeration subclass which is "MedicalSpecialty" (https://schema.org/MedicalSpecialty). "MedicalSpecialty" has instances which are medical specialties (anesthesia, cardiovascular, etc.).
In Schema.org, the property "medicalSpecialty" (https://schema.org/medicalSpecialty) has rangeIncludes "MedicalSpecialty" (the Enumeration subclass).
Two fundamental questions:
(1) Is there a benefit to having "MedicalSpecialty" as an Enumeration subclass and not a subclass outside of an enumeration?
(2) Is an Enumeration a class which contains lists, and if so, wouldn't an instance of an Enumeration also be a list, instead of a single option? (i.e. wouldn't an instance of the "MedicalSpecialty" enumeration itself be an enumeration?)
The main advantage of an Enumeration is that it makes clear to everyone that uses your ontology that a class consists of a finite list of named individuals. As for the example you mention of MedicalSpecialty, you will see that Schema.org has a list of "Enumeration Members" that are the named individuals MedicalSpecialty consists of.
An Enumeration and a plain class are indeed very similar. Both an Enumeration and a class consists of individuals (also called instances). The difference is that for a class all the individuals it may consist of is usually not known, but for an Enumeration it is known. Furthermore, a class may have a finite or an infinite number of individuals, whereas an Enumeration has a finite number of known individuals.
If you have a list of named individuals, then it is a good idea to use Enumeration.
Answers to your questions:
(1) The value of using Enumeration is to make clear to users the expected values to use for properties as for example with the medicalSpeciality property. If a reasoner or rules engine is used, these will be able to pick up errors when example the medicalSpeciality property is used incorrectly.
(2) An Enumeration is not a class that contains lists. Rather an Enumeration is a class that consists of named individuals. Thus, an instance of an Enumeration is an individual just like an instance of a class is an individual. An instance of an Enumeration is not an Enumeration, it is an individual.
If this may be helpful, I have written about Schema.org and OWL on my blog.
I'm needing some explanation for an assignement.
I'm modeling a ontology for restaurants. The classes relevant to this question are dishes and Restaurant.
The class dishes contain subclasses with the sort of dishes they serve. So for example class(dishes) has subclass(italian). To the subclass italian I've added instances like spaghetti.
The class restaurant contains mostly subclasses with necessary and sufficient restrictions to describe the type of restaurants based on the dishes they serve. But before a restaurant can get categorised I've got create instances with named restaurants. Take for example instance(pizzaFreddi) which is linked to the instance pizza through a property hasDish. Because the instance Pizza belongs to italian the restriction on one of the defined subclasses of restaurant (with ItalianDishes) infers this instance. This one works, I've used a some restriction. But what I want to do is also create a defined subclass that infers instances(namedRestaurants) that have for example more than one location. The instance PizzaFreddi for example is linked with a property isLocatedIn to the city Amsterdam and Den Haag. I've made a restriction that says: isLocatedIn min 2 City. But this does not seem to infer the instance PizzaFreddi. What's going wrong?
I've added screenshots for explanation.
http://i.stack.imgur.com/8sYNV.png
http://i.stack.imgur.com/z8rT6.png
You have Equivalent Restaurant and min 2 hasLocation, it should be enough to have SubClassOf min 2 hasLocation as you already have Restaurant as a superclass. Also, Equivalent has sometimes nonintuitive consequences - I cannot tell if in this case it is a problem without the ontology.
Also, check the inferred hierarchy and make sure you're using a reasoner. If you made changes after the reasoner was started, make sure to flush the reasoner so successive changes are seen.
Let's say I'm designing a Person class.
Is it appropriate to use an embedded class to group similar properties of this person?
For instance, let's a person has a weight, height, Hair color, and eye color.
Instead of hanging these properties directly off of the person, what if I created a class called PersonPhysicalAttibutes that had these properties.
So when you need to set a person's height, you'd use
personA.PhysicalAttributes.Height = 6.1;
Would you say this is a workable design?
EDIT:
One of the answers mention grouping address properties in a seperate class. I agree that that is a case where a seperate class works well. The address class could also be reused in an employer, customer or vendor class.
However I chose physical attributes as an example for a reason. My question is, does it make sense to break these out into another class when you're reasonable sure that that class won't be used in any other context? Strictly for ease of intellisense/grouping.
It depends on case to case basis. If you have group of properties such that all of them or most of them change together(in short the properties have strong binding in themselves), then it is appropriate to move them in another class. For example a person has address which contains houseNo,street,city,zipcode. These properties represent a group which can be associated with Person, but can exist together as a group. So including them in Person class would be inappropriate. Instead you should make a different class for them called Address and associate Address with Person. But weight,eyeColor, hairColor, height all of them are independent properties. Naturally they do not form a group together. It is better that they remain associated with Person class as an individual, independent properties. If you forcefully create a subgroup like the one you mentioned PhysicalAttributes, you will frequently come across a situation where you will violate law of Demeter.
This would be a violation of the Law of Demeter. In particular, by designing it this way, you are actually coupling the calling code to both your Person class and your PersonPhysicalAttributes class, thereby making later change to your code even harder.
I would avoid doing this approach, personally.
Not only is it appropriate, it's desired to split a big class into smaller classes. However, consider your naming. It would be most sensible to compose Person of objects like
Physique { Height, Weight, ... }
Face { EyeColor, HairColor, ... }
Psyche { Iq, Mood, ... }
I try to explain.
Simple sample project, with a Person class managed, for example, by Core Data.
I have many UITableViews that shows the data (one showing all persons, permitting to add, remove, update persons, another showing the middle age, another showing the persons grouped by same name...these are only some example, it doesn't matter).
Sure, I don't want to write the core data code inside all the viewcontrollers.
What would you do in a situation like this to write more maintainable code?
A singleton "PersonManager" class, with (for example) a mutableArray with all persons, insert-remove-update methods, a NSFetchedResultsController ecc ecc...
Class methods on the Person object? Something like "NSArray *array = [personObject allPersons];" and methods add-remove-update? The class knows how to load itself from memory ecc ecc...?
Or what?
Thank you
Fabio
I once read a very good book on design patters and OOP which stated that every class that you make and are tempted to call it "manager" is rubbish. I can't remember the book, but it matters less. The point is, every data object should be able to manage itself and manage its relationships (for example a person object could have an addFather: or addFriend: method). And a Core Data tip: use categories to implement additional methods to the automatically generated data object classes, it will make your life much easier when you add new relations or properties in Core Data.
So, in your case, you would need a data object that has all persons tied to it. You can call it AgendaDO or whatever. This object will have methods to add, remove persons, but also to get all the persons in a specific order, to sort only specific persons and so on.
context:
I have an entity Book. A book can have one or more Descriptions. Descriptions are value objects.
problem:
A description can be more specific than another description. Eg if a description contains the content of the book and how the cover looks it is more specific than a description that only discusses how the cover looks. I don't know how to model this and how to have the repository save it. It is not the responsibility of the book nor of the book description to know these relationships. Some other object can handle this and then ask the repository to save the relationships. But BookRepository.addMoreSpecificDescription(Description, MoreSpecificDescription) seems difficult for the repository to save.
How is such a thing handled in DDD?
The other two answers are one direction (+1 btw). I am coming in after your edit to the original question, so here are my two cents...
I define a Value Object as an object with two or more properties that can (and is) shared amongst other entities. They can be shared only within a single Aggregate Root, that's fine too. Just the fact that they can (and are) shared.
To use your example, you define a "Description" as a Value Object. That tells me that "Description" with multiple properties can be shared amongst several Books. In the real-world, that does not make sense as we all know each book has unique descriptions written by the master of who authored or published the book. Hehe. So, I would argue that Descriptions aren't really Value Objects, but themselves are additional Entity objects within your Book Aggregate Root Entity boundery (you can have multiple entities within a single aggregate root's entity). Even books that are re-released, a newer revision, etc have slightly different descriptions describing that slight change.
I believe that answers your question - make the descriptions entity objects and protect them behind your main Book Entity Aggregate Root (e.g. Book.GetDescriptions()...). The rest of this answer addresses how I handle Value Objects in Repositories, for others reading this post...
For storing Value Objects in a repository, and retrieving them, we start to encroach onto the same territory I wrestled with myself when I went switched from a "Database-first" modeling approach to a DDD approach. I myself wreslted with this one, on how to store a Value Object in the DB, and retrieve it without an Identity. Until I stepped back and realized what i was doing...
In Domain Driven Design, you are modeling the Value Objects in your domain - not your data store. That is the key phrase. It means you are not designing the Value Objects to be stored as independant objects in the data store, you can store them however you like!
Let's take the common DDD example of Value Objects, that being an Address(). DDD presents that an Mailing Address is the perfect Value Object example, as the definition of a Value Object is an object of who's properties sum up to create the uniqueness of the object. If a property changes, it will be a different Value Object. And the same Value Object 9teh sum of its properties) can be shared amongst other Entities.
A Mailing Address is a location, a long/lat of a specific location on the planet. Multiple people can live at the address, and when someone moves, the new people to occupy the same Mailing Address now use the same Value Object.
So, I have a Person() object with a MailingAddress() object that has the address information in it. It is protected behind my Person() aggregate root with get/update/create methods/services.
Now, how do we store that and share it amongst the people in the same household? Ah, there lies DDD - you aren't modeling your data store straight from your DDD (even though, that would be nice). With that said, you simple create a single Table that presents your Person object, and it has the columns for your mailing address within it. It is the job of your Repository to re-hydrate that information back into your Person() and MailingAddress() object from the data store, and to split it up during the Create/Update operations.
Yep, you'd have duplicate data now in your data store. Three Person() entities with the same mailing address all now have three seperate copies of that Value Object data - and that is ok! Value Objects are meant to be copied and destoyed quite easily. "Copy" is the optimum word there in the DDD playbook.
So to sum up, Domain Drive Design is about modeling your Domain to represent your actual business use of the objects. You model a Person() entity and a MailingAddress Value Object seperately, as they are represented differently in your application. You persist them a copied-data, that being additional columns in the same table as your Person table.
All of the above is strict-DDD. But, DDD is meant to be just "suggestions", not rules to live by. That's why you are free to do what myself and many others have done, kind of a loose-DDD style. If you don't like the copied data, your only option is that being you can create a seperate table for MailingAddress() and stick an Identity column on it, and update your MailingAddress() object to have now have that identity on it - knowing you only use that identity to link it to other Person() objects that share it (I personally like a 3rd many-to-many relationship table, to keep the speed of the queries up). You would mask that Idenity (i.e. internal modifier) from being exposed outside of your Aggregate Root/Domain, so other layers (such as the Application or UI) do not know of the Identity column of the MailingAddress, if possible. Also, I would create a dedicated Repository just for MailingAddress, and use your PersonService layer to combine them into the correct object, Person.MailingAddress().
Sorry for the rant... :)
First, I think that reviews should be entities.
Second, why are you trying to model relationships between reviews? I don't see a natural relationship between them. "More specific than" is too vague to be useful as a relationship.
If you're having difficulty modeling the situation, that suggests that maybe there is no relationship.
I agree with Jason. I don't know what your rationale is for making reviews value objects.
I would expect a BookReview to have BookReviewContentItems so that you could have a method on the BookReview to call to decide if it is specific enough, where the method decides based on querying its collection of content items.