I am quite new to Semantic Web and I have a task to model two ontologies. Let's say that ontology A has 3 classes, 4 object properties and 4 datatype properties. Ontology A also includes class instances with all the data. Now, ontology B has identical structure as ontology A, plus a couple of extra datatype properties, but it does not have any instances - it only contains the schema. Let's say that I create ontology B class instance with a certain ID. My question is, how based on that ID (which is identical in ontology A) can I populate or pull all the properties from A to B that are identical in both ontologies?
For example ontology A instance has following properties: ontologyAinstance id:1, name:'instance name', age:'15YO' . How can I pull name and age properties from A to B when I create: ontologyBinstance id:1?
Related
For example, Barack Obama, in Labelled Property Graph, the birth date (1965) would be modeled as a Property of the entity BarackObama, without using a relation. But in RDF, i.e. freebase, BarackObama is linked through a relationship (birth_date) to a value '1965'. In these two cases, the former involves only one entity without relationship, but the latter, two entities are involved, "BarackObama" and "1965" with a relationship.
Is this the major difference?
I am using protege 5 for developing ontology. I have created has_composition as object property. In my ontology the same object_property is used for different domains and their respective range, like has_composition of A is B and has_composition of C and D is E and F.
How can I model this mapping??
OWL (Ontology Web Language, the ontology that defines ontologies) does not allow to model what you're trying to do.
A workaround I can think of is to use sub-properties. Imagine the following classes:
Pizza
TomatoSauce
ChocolateCake
Chocolate
If you want to define relations such as
A Pizza has_composition TomatoSauce, and
A ChocolateCake has_composition Chocolate
then define the following relations:
has_composition: No domain nor range (or a common superclass such as Dish and Ingredient for example)
has_tomato_sauce: Domain Pizza, range TomatoSauce
has_chocolate: Domain ChocolateCake, range Chocolate
This will allow the reasoner (the software that computes inferences) to infer that if something has_chocolate a_chocolate, then
something rdf:type Chocolate (inferred by the domain of has_chocolate);
something has_composition a_chocolate (because has_chocolate is a sub-property of has_composition).
You can check out this example in this Gist I made.
Download it, open it, and start the reasoner. You will see the inferred statements in yellow.
I am new in the field of ontologies and reasoning in Jena and I am in desperate need for help to get the logic of how to do the following. I am building and owl ontology with the following classes:
-A person hasInterests Interests
- A person hasMessage Message
- A message hasCategory Category ( or subclass of message)
- A message can be spam or ham ( subclasses of message)
I want to say if the message's category is the same as the person's interests then the message is ham
Q1: I wanted to build the ontology such that the reasoner would infer this so I thought of defining ham as an intersection of class category and interests and that spam is complemet to this intersection class . Is this applicable using a reasoner or shall I need SPARQL queries
Q2:How to create individuals and do the following inference :
hana is a person
message1 is a message
sports is a category
movies is an interest
how to infer that since the sport is not equal to movies then message1 is spam.
I am in desperate need to be directed how to implement this and what exactly to refer to to do so for my masters thesis
The easiest way of doing so (I'm a newbie, but I just succeeded to make inference in ontologies x_x), is by creating your ontology with Protégé and thinking about the concepts you want to link...
You have categories and interests that are pretty abstract, compared to message and person. You have to think about how to link them, and to which classes they belong.
Concrete vs Abstract... Objects vs LivingBeing... Animals vs Plants...
It's an example.
When you are okay with these, you can implement them with Protégé (as it's a graphical tool, it's easier at the beginning) : check the "Entities" tab, and the "Classes" subtab.
Then, you put rules and properties. (the hardest part)
Typically, what is concrete is NOT abstract... so you have to disjoint the two within their properties.
And if you expect some relations to make a "real" ontology, you have to define your own properties (a person can "own" objects, for example... but an object does not "owns" a person).
When you have your basic ontology builded. You have to check if some inferences can be done (search within protégé the "reasoner" menu, and activate one of them, and synchronise it regularly).
Finally, you can add individuals inside, and fill their properties (search for a subtab named "Individuals").
I know union is a SQL construct, but it's the best analogue for what I'm trying to do.
I have multiple groups of data that I'm receiving from an external source. I'm maintaining them as separate entities in Core Data (they only have some attributes in common (e.g. name)), but I want to present them in the same tableView.
Say I have an entity Food that has relationships with FruitGroup and VegetableGroup. The FruitGroup has a relationship with Fruit which has a relationship with FruitType. The VegetableGroup is similar.
How can I use FruitGroup.Fruit.name and VegetableGroup.Vegetable.name as sectionTitles? And FruitGroup.Fruit.FruitType.name and VegetableGroup.Vegetable.VegetableType.name for row data. (I tried coming up with a predicate that walks down from Food, but that doesn't appear to be workable)
Example modeled data (my groups are far more disparate than fruits and veggies, so re-doing my data model is not an option):
Food
FruitGroup
Apple
Macintosh
Granny Smith
Pear
Bartlett
Asian
Anjou
VegetableGroup
Asparagus
white
wild
Peas
baby
split
Which I would like to appear as:
Apple [section]
Macintosh [row]
Granny Smith
Pear
Bartlett
Asian
Anjou
Asparagus
white
wild
Peas
baby
split
I could use multiple NSFetchedResultsControllers in the UITableViewController and conditionally select the FRC within each of the UITableViewDataSource methods, but that doesn't feel clean.
I'm thinking about subclassing NSFetchedResultsController and, internal to my subclass, merging the results of multiple private NSFetchedResultsControllers that each represent one of the entities. (e.g. sections returns a concatenation of the returns from the sections calls of the internal FRCs)
Does this make sense - or is there a better way? (I saw Core Data Union Query Equivalent but since there are relationships among my entities, I wanted to seek alternatives)
While you can do this as described in the other answers (via creating an abstract Parent entity), I would not recommend it. The performance when it comes to dealing with abstract parents gets bad very quickly. The reason for this is that Core Data will put all of the children into a single table in the underlying SQLite file.
I would suggest going a different route. Have a single entity called Food with attributes describing if it is a vegetable or fruit. Then you have one NSFetchedResultsController which has the type of the food item as the sectionPath and you will get your display the way that you want it.
I recommend creating entities in Core Data based on what the objects are as a very loose level. I would not create entities for Honda, Ford and Dodge, but create an entity for Car and perhaps type or a relationship to a manufacturer.
While Core Data can be backed by a database, at the end of the day it is not a database but an object graph and should be treated as such. Trying to normalize the database will result in poor performance of the object graph.
You should probably look into abstract entities. For example, you could create an abstract entity called Food. Then you're able to create Fruit and Vegetables, which inherits the abstract entity. You'll have to set Food as the "Parent Entity".
Then you could fetch all the items with the entity Food, which includes both Fruit and Vegetables. Based on your post, you'll probably will have a relation from Food to FoodGroup.
To answer your question:
You cannot unify different entity types (if they are not subclasses of the same entity) under a single fetch request. You can define an entity (B) to inherit from another entity (A) and then fetch by the parent entity (A) and get both kind of entities (As and Bs)
You can try and think of it this way:
Item ("Macintosh","White Asparagus",...) has a relationship to Group ("Apple","Asparagus",...), and Group has a relationship to Area (or simply to another parent group).
In this manner you could use a single FRC with sectionNameKeyPath of "group.name" and entity Item (you can filter by "group.area" to only select food items).
Is it legitimate to create a one to one relationship between two entities when one is set to be abstract ?
An abstract entity is not meant to be instantiated. That's why you cannot create such a relationship. What you could do though is to create a relationship where the entity(s) are inheriting from an abstract entity.
From Apple's docs:
A relationship specifies the entity, or the parent entity, of the
objects at the destination. This can be the same as the entity at the
source (a reflexive relationship). Relationships do not have to be
homogeneous. If the Employee entity has two sub-entities, say Manager
and Flunky, then a given department's employees may be made up of
Employees (assuming Employee is not an abstract entity), Managers,
Flunkies, or any combination thereof.
EDIT:
Apparently you could create such a relationship (so that child entities would inherit the relationship as well)...
If you define an entity inheritance hierarchy (see “Entity
Inheritance”), when you specify a super-entity as the entity for a
fetch request, the request returns all matching instances of the
super-entity and of sub-entities. In some applications, you might
specify a super-entity as being abstract (see “Abstract Entities”). To
fetch matching instances of all concrete sub-entities of the abstract
entity, you set the entity for fetch specification to be the abstract
entity. In the case of the domain described in “Abstract Entities,” if
you specify a fetch request with the Graphic entity, the fetch returns
matching instances of Circle, TextArea, and Line.
See also this answer: Core Data: Abstract Entity in Fetch Request
yes. you can have a person who owns a "thing"...