Modelling same type of entity in two graphs and linking them for querying

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Modelling same type of entity in two graphs and linking them for querying

Kalpa Gunaratna
Hi,
   I am thinking of a good way to model an entity type in two different perspectives and linking them. An example can be as follows.

Car model details graph
I will have details of a car model (e.g., Nissan Altima 2006) in a graph with an ontology to describe its facts. E.g., these facts are general to all Nissan Altima 2006 cars such as "4 cylinder", "2.5L engine", "cargo space", etc. The entity is of type "Car". And I will have similar other entities modeled like "Nissan Altima 2007", "Toyota Camry 2006", "Honda Accord 2008", etc.

Car model entity graph
Now, I will have another graph for instances of these car models that are owned by specific users. So there can be two or many different entities of "Nissan Altima 2006" in this graph owned by different or same person. Type of these entities is also "Car". In this graph, I will have facts like who owns the car, its color, buy date, repair details, etc, that are specific to that car instance.


I have one ontology class "Car" to type entities in two graphs. Then, I want to link entities in the two graphs in a way like, to get details for a specific model for a car that a person owns, it could look up in the first graph (by following a link to that graph). Theoretically, it is incorrect to link using "owl:sameAs" because they are not the same entity (two different granularity). I can think of making one graph having car instances in the first graph as class hierarchy (car model years) in the second graph but then how can I model the general facts about each car model year? May be explicit linking of entities between these two graphs is not necessary but have a common fact like "model number" to match entities when querying. What would be a good modelling practice for this kind of a problem?

--
Regards
Kalpa Gunaratna



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Modelling same type of entity in two graphs and linking them for querying

Michael DeBellis-2
Kalpa, I may be misunderstanding your example but I think there is a very straight forward way to model this. I'm just going to use the Nissan Altima example but obviously there would be other similar classes and instances for different kinds and instances of car.

So the classes would be Car with subclass NissanAltima2006. You could define axioms (I'm going to be lazy and just use English rather than work out the DL) such as "Has some cylinders" for Car and then "Has exactly 4 cylinders" for NissanAltima2006. Have you done the Pizza tutorial? It has examples that show how to model this kind of stuff at the class level using DL statements. 

Then for each example of a NissanAltima2006 you would create an instance such as JoesNissanAltima2006, MarysNissanAltima2006, etc.  Things such as cylinders, color, buyDate, etc. would all be properties with domain Car and the appropriate ranges, in some cases (e.g., buyDate) they would be data properties in other cases (probably cylinders and color) they would be object properties. 

I don't see the need for two separate graphs, unless you just mean the difference between the class data (this is called TBox in OWL) and the individual data (this is called ABox). As I see it, this is pretty much vanilla OWL, you just have classes, subclasses, and instances. The one complication might be if there are some properties you want to assert not about a specific car but about a class of car. For example, you might have price as a data property defined for each car (since dealers tend to highly customize how much they offer each car for depending on demand, etc.) but you might also want to describe dealersListPrice as a data property on a class of car. To do that you need to look at punning. It's a very basic kind of meta-object capability that lets you assert this kind of information about a class rather than an instance, so you could say that dealersListPrice on NissanAltima2006 is some floating point number. As I said it's basic but I think it would handle this example. 

That is how I would model it. Does that make sense?

Michael

On Fri, Nov 10, 2017 at 10:51 AM, Kalpa Gunaratna <[hidden email]> wrote:
Hi,
   I am thinking of a good way to model an entity type in two different perspectives and linking them. An example can be as follows.

Car model details graph
I will have details of a car model (e.g., Nissan Altima 2006) in a graph with an ontology to describe its facts. E.g., these facts are general to all Nissan Altima 2006 cars such as "4 cylinder", "2.5L engine", "cargo space", etc. The entity is of type "Car". And I will have similar other entities modeled like "Nissan Altima 2007", "Toyota Camry 2006", "Honda Accord 2008", etc.

Car model entity graph
Now, I will have another graph for instances of these car models that are owned by specific users. So there can be two or many different entities of "Nissan Altima 2006" in this graph owned by different or same person. Type of these entities is also "Car". In this graph, I will have facts like who owns the car, its color, buy date, repair details, etc, that are specific to that car instance.


I have one ontology class "Car" to type entities in two graphs. Then, I want to link entities in the two graphs in a way like, to get details for a specific model for a car that a person owns, it could look up in the first graph (by following a link to that graph). Theoretically, it is incorrect to link using "owl:sameAs" because they are not the same entity (two different granularity). I can think of making one graph having car instances in the first graph as class hierarchy (car model years) in the second graph but then how can I model the general facts about each car model year? May be explicit linking of entities between these two graphs is not necessary but have a common fact like "model number" to match entities when querying. What would be a good modelling practice for this kind of a problem?

--
Regards
Kalpa Gunaratna



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Modelling same type of entity in two graphs and linking them for querying

Kalpa Gunaratna
Michael,
    Thank you for trying to understand my problem description and providing a detailed response. Let me explain some facts that would help you understand the modelling requirements.

In the example, I have the following knowledge representation requirements (using the car example I gave earlier).
(1) I want to describe cars in general for specific year and model. I have facts to describe these and that is why I think of them as individuals (and not as classes). Each of these car models have a manual or spec. I want to represent them as facts describing them. Like the one we could see in DBpedia - http://dbpedia.org/page/Nissan_Altima .

(2) Then, I also want to represent specific instances of Nissan altimas people have bought. For example, Kalpa's Nissan Altima2006 has different facts than somebody else. Its color, interior modification, buy date, repair dates, repair places, where it is parked, etc are different to someone else's Nissan Altima 2006. These facts describe a specific Nissan Altima 2006 and that is why I have individuals like Kalpa's Nissan Altima 2006.

In the case of (1), it is still a type "Car" and I think of it as an individual because it has many facts describing it (not only in owl axiom level, e.g., manufacturer Nissan). There will be so many cars like this (and they have user manual or technical specs that I want to attach to them) and that is why I do not think of representing them as classes but individuals (Honda Accord, Toyota Camry, Toyota Corolla, etc).

Now, I would like to make a connection between a specific individual in case (2) (e.g., Kalpa's Nissan Altima 2006) to an individual in case (1) (e.g., Nissan Altima 2006). I can think of using a custom relation or SKOS:broderMatch like a relation to link individuals in two graphs. What I wanted to make clear is, I have facts to represent in both cases for individuals and I think those cannot be in axiom level. I was wondering if there a different way of thinking other than this.


On Fri, Nov 10, 2017 at 12:30 PM, Michael DeBellis <[hidden email]> wrote:
Kalpa, I may be misunderstanding your example but I think there is a very straight forward way to model this. I'm just going to use the Nissan Altima example but obviously there would be other similar classes and instances for different kinds and instances of car.

So the classes would be Car with subclass NissanAltima2006. You could define axioms (I'm going to be lazy and just use English rather than work out the DL) such as "Has some cylinders" for Car and then "Has exactly 4 cylinders" for NissanAltima2006. Have you done the Pizza tutorial? It has examples that show how to model this kind of stuff at the class level using DL statements. 

Then for each example of a NissanAltima2006 you would create an instance such as JoesNissanAltima2006, MarysNissanAltima2006, etc.  Things such as cylinders, color, buyDate, etc. would all be properties with domain Car and the appropriate ranges, in some cases (e.g., buyDate) they would be data properties in other cases (probably cylinders and color) they would be object properties. 

I don't see the need for two separate graphs, unless you just mean the difference between the class data (this is called TBox in OWL) and the individual data (this is called ABox). As I see it, this is pretty much vanilla OWL, you just have classes, subclasses, and instances. The one complication might be if there are some properties you want to assert not about a specific car but about a class of car. For example, you might have price as a data property defined for each car (since dealers tend to highly customize how much they offer each car for depending on demand, etc.) but you might also want to describe dealersListPrice as a data property on a class of car. To do that you need to look at punning. It's a very basic kind of meta-object capability that lets you assert this kind of information about a class rather than an instance, so you could say that dealersListPrice on NissanAltima2006 is some floating point number. As I said it's basic but I think it would handle this example. 

That is how I would model it. Does that make sense?

Michael

On Fri, Nov 10, 2017 at 10:51 AM, Kalpa Gunaratna <[hidden email]> wrote:
Hi,
   I am thinking of a good way to model an entity type in two different perspectives and linking them. An example can be as follows.

Car model details graph
I will have details of a car model (e.g., Nissan Altima 2006) in a graph with an ontology to describe its facts. E.g., these facts are general to all Nissan Altima 2006 cars such as "4 cylinder", "2.5L engine", "cargo space", etc. The entity is of type "Car". And I will have similar other entities modeled like "Nissan Altima 2007", "Toyota Camry 2006", "Honda Accord 2008", etc.

Car model entity graph
Now, I will have another graph for instances of these car models that are owned by specific users. So there can be two or many different entities of "Nissan Altima 2006" in this graph owned by different or same person. Type of these entities is also "Car". In this graph, I will have facts like who owns the car, its color, buy date, repair details, etc, that are specific to that car instance.


I have one ontology class "Car" to type entities in two graphs. Then, I want to link entities in the two graphs in a way like, to get details for a specific model for a car that a person owns, it could look up in the first graph (by following a link to that graph). Theoretically, it is incorrect to link using "owl:sameAs" because they are not the same entity (two different granularity). I can think of making one graph having car instances in the first graph as class hierarchy (car model years) in the second graph but then how can I model the general facts about each car model year? May be explicit linking of entities between these two graphs is not necessary but have a common fact like "model number" to match entities when querying. What would be a good modelling practice for this kind of a problem?

--
Regards
Kalpa Gunaratna



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user




--
Regards
Kalpa Gunaratna
Home Page LinkedIn Blog


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Modelling same type of entity in two graphs and linking them for querying

Csongor Nyulas
Administrator
I fully agree with Michael's earlier suggestion. I would also model Nissan Altima 2006 as a subclass of car. There are multiple instances of Nissan Altima in the world. So it natural to see it as a class which is basically a set of individuals. Nothing stops you to describe that class with properties, just like Michael suggested. I would recommend that you get more familiar with OWL, if you want to model things in it.

Csongor


On 11/10/2017 02:29 PM, Kalpa Gunaratna wrote:
Michael,
    Thank you for trying to understand my problem description and providing a detailed response. Let me explain some facts that would help you understand the modelling requirements.

In the example, I have the following knowledge representation requirements (using the car example I gave earlier).
(1) I want to describe cars in general for specific year and model. I have facts to describe these and that is why I think of them as individuals (and not as classes). Each of these car models have a manual or spec. I want to represent them as facts describing them. Like the one we could see in DBpedia - http://dbpedia.org/page/Nissan_Altima .

(2) Then, I also want to represent specific instances of Nissan altimas people have bought. For example, Kalpa's Nissan Altima2006 has different facts than somebody else. Its color, interior modification, buy date, repair dates, repair places, where it is parked, etc are different to someone else's Nissan Altima 2006. These facts describe a specific Nissan Altima 2006 and that is why I have individuals like Kalpa's Nissan Altima 2006.

In the case of (1), it is still a type "Car" and I think of it as an individual because it has many facts describing it (not only in owl axiom level, e.g., manufacturer Nissan). There will be so many cars like this (and they have user manual or technical specs that I want to attach to them) and that is why I do not think of representing them as classes but individuals (Honda Accord, Toyota Camry, Toyota Corolla, etc).

Now, I would like to make a connection between a specific individual in case (2) (e.g., Kalpa's Nissan Altima 2006) to an individual in case (1) (e.g., Nissan Altima 2006). I can think of using a custom relation or SKOS:broderMatch like a relation to link individuals in two graphs. What I wanted to make clear is, I have facts to represent in both cases for individuals and I think those cannot be in axiom level. I was wondering if there a different way of thinking other than this.


On Fri, Nov 10, 2017 at 12:30 PM, Michael DeBellis <[hidden email]> wrote:
Kalpa, I may be misunderstanding your example but I think there is a very straight forward way to model this. I'm just going to use the Nissan Altima example but obviously there would be other similar classes and instances for different kinds and instances of car.

So the classes would be Car with subclass NissanAltima2006. You could define axioms (I'm going to be lazy and just use English rather than work out the DL) such as "Has some cylinders" for Car and then "Has exactly 4 cylinders" for NissanAltima2006. Have you done the Pizza tutorial? It has examples that show how to model this kind of stuff at the class level using DL statements. 

Then for each example of a NissanAltima2006 you would create an instance such as JoesNissanAltima2006, MarysNissanAltima2006, etc.  Things such as cylinders, color, buyDate, etc. would all be properties with domain Car and the appropriate ranges, in some cases (e.g., buyDate) they would be data properties in other cases (probably cylinders and color) they would be object properties. 

I don't see the need for two separate graphs, unless you just mean the difference between the class data (this is called TBox in OWL) and the individual data (this is called ABox). As I see it, this is pretty much vanilla OWL, you just have classes, subclasses, and instances. The one complication might be if there are some properties you want to assert not about a specific car but about a class of car. For example, you might have price as a data property defined for each car (since dealers tend to highly customize how much they offer each car for depending on demand, etc.) but you might also want to describe dealersListPrice as a data property on a class of car. To do that you need to look at punning. It's a very basic kind of meta-object capability that lets you assert this kind of information about a class rather than an instance, so you could say that dealersListPrice on NissanAltima2006 is some floating point number. As I said it's basic but I think it would handle this example. 

That is how I would model it. Does that make sense?

Michael

On Fri, Nov 10, 2017 at 10:51 AM, Kalpa Gunaratna <[hidden email]> wrote:
Hi,
   I am thinking of a good way to model an entity type in two different perspectives and linking them. An example can be as follows.

Car model details graph
I will have details of a car model (e.g., Nissan Altima 2006) in a graph with an ontology to describe its facts. E.g., these facts are general to all Nissan Altima 2006 cars such as "4 cylinder", "2.5L engine", "cargo space", etc. The entity is of type "Car". And I will have similar other entities modeled like "Nissan Altima 2007", "Toyota Camry 2006", "Honda Accord 2008", etc.

Car model entity graph
Now, I will have another graph for instances of these car models that are owned by specific users. So there can be two or many different entities of "Nissan Altima 2006" in this graph owned by different or same person. Type of these entities is also "Car". In this graph, I will have facts like who owns the car, its color, buy date, repair details, etc, that are specific to that car instance.


I have one ontology class "Car" to type entities in two graphs. Then, I want to link entities in the two graphs in a way like, to get details for a specific model for a car that a person owns, it could look up in the first graph (by following a link to that graph). Theoretically, it is incorrect to link using "owl:sameAs" because they are not the same entity (two different granularity). I can think of making one graph having car instances in the first graph as class hierarchy (car model years) in the second graph but then how can I model the general facts about each car model year? May be explicit linking of entities between these two graphs is not necessary but have a common fact like "model number" to match entities when querying. What would be a good modelling practice for this kind of a problem?

--
Regards
Kalpa Gunaratna



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user




--
Regards
Kalpa Gunaratna
Home Page LinkedIn Blog



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Modelling same type of entity in two graphs and linking them for querying

Igor Toujilov-2

Hi Kalpa,

Michael and Csongor suggested the classical OWL approach. I also agree this is a preferable way of modelling to get full advantages of OWL and Description Logic (DL) reasoning, using DL Query language.

However, it looks like you tend using an RDF-based approach, and not an OWL-based one: you prefer SPARQL, not DL Query. Also if you need DBpedia compatibility, the majority of DBpedia resources are old-fashioned RDF-based, not OWL-based. So, if you use the suggested classical OWL approach, it will be very hard to represent your queries in SPARQL because the most of car model information will be encoded in class axioms, not in individual property assertions. (SPARQL is not great for OWL axioms.)

If this is the case, you can use a compromise approach: organise your first ontology as a hierarchy of car_model class in the root with car model individuals; and in your second ontology, link individuals of class “car” to the car model individuals with a functional object property, for example, belongs_to_car_model.

 

Cheers,

Igor

 
 
Sent: Friday, November 10, 2017 at 10:40 PM
From: "Csongor Nyulas" <[hidden email]>
To: [hidden email]
Subject: Re: [protege-user] Modelling same type of entity in two graphs and linking them for querying
I fully agree with Michael's earlier suggestion. I would also model Nissan Altima 2006 as a subclass of car. There are multiple instances of Nissan Altima in the world. So it natural to see it as a class which is basically a set of individuals. Nothing stops you to describe that class with properties, just like Michael suggested. I would recommend that you get more familiar with OWL, if you want to model things in it.

Csongor

 
On 11/10/2017 02:29 PM, Kalpa Gunaratna wrote:
Michael,
    Thank you for trying to understand my problem description and providing a detailed response. Let me explain some facts that would help you understand the modelling requirements.
 
In the example, I have the following knowledge representation requirements (using the car example I gave earlier).
(1) I want to describe cars in general for specific year and model. I have facts to describe these and that is why I think of them as individuals (and not as classes). Each of these car models have a manual or spec. I want to represent them as facts describing them. Like the one we could see in DBpedia - http://dbpedia.org/page/Nissan_Altima .
 
(2) Then, I also want to represent specific instances of Nissan altimas people have bought. For example, Kalpa's Nissan Altima2006 has different facts than somebody else. Its color, interior modification, buy date, repair dates, repair places, where it is parked, etc are different to someone else's Nissan Altima 2006. These facts describe a specific Nissan Altima 2006 and that is why I have individuals like Kalpa's Nissan Altima 2006.
 
In the case of (1), it is still a type "Car" and I think of it as an individual because it has many facts describing it (not only in owl axiom level, e.g., manufacturer Nissan). There will be so many cars like this (and they have user manual or technical specs that I want to attach to them) and that is why I do not think of representing them as classes but individuals (Honda Accord, Toyota Camry, Toyota Corolla, etc).
 
Now, I would like to make a connection between a specific individual in case (2) (e.g., Kalpa's Nissan Altima 2006) to an individual in case (1) (e.g., Nissan Altima 2006). I can think of using a custom relation or SKOS:broderMatch like a relation to link individuals in two graphs. What I wanted to make clear is, I have facts to represent in both cases for individuals and I think those cannot be in axiom level. I was wondering if there a different way of thinking other than this.
 
 
On Fri, Nov 10, 2017 at 12:30 PM, Michael DeBellis <[hidden email]> wrote:
Kalpa, I may be misunderstanding your example but I think there is a very straight forward way to model this. I'm just going to use the Nissan Altima example but obviously there would be other similar classes and instances for different kinds and instances of car.
 
So the classes would be Car with subclass NissanAltima2006. You could define axioms (I'm going to be lazy and just use English rather than work out the DL) such as "Has some cylinders" for Car and then "Has exactly 4 cylinders" for NissanAltima2006. Have you done the Pizza tutorial? It has examples that show how to model this kind of stuff at the class level using DL statements. 
 
Then for each example of a NissanAltima2006 you would create an instance such as JoesNissanAltima2006, MarysNissanAltima2006, etc.  Things such as cylinders, color, buyDate, etc. would all be properties with domain Car and the appropriate ranges, in some cases (e.g., buyDate) they would be data properties in other cases (probably cylinders and color) they would be object properties. 
 
I don't see the need for two separate graphs, unless you just mean the difference between the class data (this is called TBox in OWL) and the individual data (this is called ABox). As I see it, this is pretty much vanilla OWL, you just have classes, subclasses, and instances. The one complication might be if there are some properties you want to assert not about a specific car but about a class of car. For example, you might have price as a data property defined for each car (since dealers tend to highly customize how much they offer each car for depending on demand, etc.) but you might also want to describe dealersListPrice as a data property on a class of car. To do that you need to look at punning. It's a very basic kind of meta-object capability that lets you assert this kind of information about a class rather than an instance, so you could say that dealersListPrice on NissanAltima2006 is some floating point number. As I said it's basic but I think it would handle this example. 
 
That is how I would model it. Does that make sense?
 
Michael
 
On Fri, Nov 10, 2017 at 10:51 AM, Kalpa Gunaratna <[hidden email]> wrote:
Hi,
   I am thinking of a good way to model an entity type in two different perspectives and linking them. An example can be as follows.
 
Car model details graph
I will have details of a car model (e.g., Nissan Altima 2006) in a graph with an ontology to describe its facts. E.g., these facts are general to all Nissan Altima 2006 cars such as "4 cylinder", "2.5L engine", "cargo space", etc. The entity is of type "Car". And I will have similar other entities modeled like "Nissan Altima 2007", "Toyota Camry 2006", "Honda Accord 2008", etc.
 
Car model entity graph
Now, I will have another graph for instances of these car models that are owned by specific users. So there can be two or many different entities of "Nissan Altima 2006" in this graph owned by different or same person. Type of these entities is also "Car". In this graph, I will have facts like who owns the car, its color, buy date, repair details, etc, that are specific to that car instance.
 
 
I have one ontology class "Car" to type entities in two graphs. Then, I want to link entities in the two graphs in a way like, to get details for a specific model for a car that a person owns, it could look up in the first graph (by following a link to that graph). Theoretically, it is incorrect to link using "owl:sameAs" because they are not the same entity (two different granularity). I can think of making one graph having car instances in the first graph as class hierarchy (car model years) in the second graph but then how can I model the general facts about each car model year? May be explicit linking of entities between these two graphs is not necessary but have a common fact like "model number" to match entities when querying. What would be a good modelling practice for this kind of a problem?
 
--
Regards
Kalpa Gunaratna


 
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
 

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
 
 
 
--
Regards
Kalpa Gunaratna
Home Page LinkedIn Blog
 
 
 
 
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________ protege-user mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Modelling same type of entity in two graphs and linking them for querying

Michael DeBellis-2
In reply to this post by Kalpa Gunaratna
Kalpa, As Igor said, the way I and Csongor are advocating is the standard OWL method for representing models so if you need a more RDF based approach this won't work. But if your main issue is that you want concepts such as NissanAltima to be both individuals and classes that can be handled in OWL. 

I've created a very simple example just to give you an idea of how this could work. In this example ontology you can see that NissanAltima is both a class and an individual (this is an example of punning, which I mentioned in my previous message). There are two instances of NissanAltima: NissanAltima1 and NissanAltima2. Those individuals have data that would be relevant for specific cars: the date the car was manufactured, the person who owns the car, etc. But NissanAltima is also an individual of the class CarModel and it has data that would be relevant for the class of things that are NissanAltimas. E.g, the year the model was first manufactured, the predecessor and successor models, etc. Also, you can see that I've defined an axiom for all Cars, that they must have some number of cylinders: "hasCylinders some xsd:integer" and I've refined that for the sub class of car NissanAltima: "hasCylinders value 4". You can also see that the two instances of NissanAltima have 4 cylinders even though I didn't specify that because the reasoner knows they must given how the class was defined. 

Michael

On Fri, Nov 10, 2017 at 2:29 PM, Kalpa Gunaratna <[hidden email]> wrote:
Michael,
    Thank you for trying to understand my problem description and providing a detailed response. Let me explain some facts that would help you understand the modelling requirements.

In the example, I have the following knowledge representation requirements (using the car example I gave earlier).
(1) I want to describe cars in general for specific year and model. I have facts to describe these and that is why I think of them as individuals (and not as classes). Each of these car models have a manual or spec. I want to represent them as facts describing them. Like the one we could see in DBpedia - http://dbpedia.org/page/Nissan_Altima .

(2) Then, I also want to represent specific instances of Nissan altimas people have bought. For example, Kalpa's Nissan Altima2006 has different facts than somebody else. Its color, interior modification, buy date, repair dates, repair places, where it is parked, etc are different to someone else's Nissan Altima 2006. These facts describe a specific Nissan Altima 2006 and that is why I have individuals like Kalpa's Nissan Altima 2006.

In the case of (1), it is still a type "Car" and I think of it as an individual because it has many facts describing it (not only in owl axiom level, e.g., manufacturer Nissan). There will be so many cars like this (and they have user manual or technical specs that I want to attach to them) and that is why I do not think of representing them as classes but individuals (Honda Accord, Toyota Camry, Toyota Corolla, etc).

Now, I would like to make a connection between a specific individual in case (2) (e.g., Kalpa's Nissan Altima 2006) to an individual in case (1) (e.g., Nissan Altima 2006). I can think of using a custom relation or SKOS:broderMatch like a relation to link individuals in two graphs. What I wanted to make clear is, I have facts to represent in both cases for individuals and I think those cannot be in axiom level. I was wondering if there a different way of thinking other than this.


On Fri, Nov 10, 2017 at 12:30 PM, Michael DeBellis <[hidden email]> wrote:
Kalpa, I may be misunderstanding your example but I think there is a very straight forward way to model this. I'm just going to use the Nissan Altima example but obviously there would be other similar classes and instances for different kinds and instances of car.

So the classes would be Car with subclass NissanAltima2006. You could define axioms (I'm going to be lazy and just use English rather than work out the DL) such as "Has some cylinders" for Car and then "Has exactly 4 cylinders" for NissanAltima2006. Have you done the Pizza tutorial? It has examples that show how to model this kind of stuff at the class level using DL statements. 

Then for each example of a NissanAltima2006 you would create an instance such as JoesNissanAltima2006, MarysNissanAltima2006, etc.  Things such as cylinders, color, buyDate, etc. would all be properties with domain Car and the appropriate ranges, in some cases (e.g., buyDate) they would be data properties in other cases (probably cylinders and color) they would be object properties. 

I don't see the need for two separate graphs, unless you just mean the difference between the class data (this is called TBox in OWL) and the individual data (this is called ABox). As I see it, this is pretty much vanilla OWL, you just have classes, subclasses, and instances. The one complication might be if there are some properties you want to assert not about a specific car but about a class of car. For example, you might have price as a data property defined for each car (since dealers tend to highly customize how much they offer each car for depending on demand, etc.) but you might also want to describe dealersListPrice as a data property on a class of car. To do that you need to look at punning. It's a very basic kind of meta-object capability that lets you assert this kind of information about a class rather than an instance, so you could say that dealersListPrice on NissanAltima2006 is some floating point number. As I said it's basic but I think it would handle this example. 

That is how I would model it. Does that make sense?

Michael

On Fri, Nov 10, 2017 at 10:51 AM, Kalpa Gunaratna <[hidden email]> wrote:
Hi,
   I am thinking of a good way to model an entity type in two different perspectives and linking them. An example can be as follows.

Car model details graph
I will have details of a car model (e.g., Nissan Altima 2006) in a graph with an ontology to describe its facts. E.g., these facts are general to all Nissan Altima 2006 cars such as "4 cylinder", "2.5L engine", "cargo space", etc. The entity is of type "Car". And I will have similar other entities modeled like "Nissan Altima 2007", "Toyota Camry 2006", "Honda Accord 2008", etc.

Car model entity graph
Now, I will have another graph for instances of these car models that are owned by specific users. So there can be two or many different entities of "Nissan Altima 2006" in this graph owned by different or same person. Type of these entities is also "Car". In this graph, I will have facts like who owns the car, its color, buy date, repair details, etc, that are specific to that car instance.


I have one ontology class "Car" to type entities in two graphs. Then, I want to link entities in the two graphs in a way like, to get details for a specific model for a car that a person owns, it could look up in the first graph (by following a link to that graph). Theoretically, it is incorrect to link using "owl:sameAs" because they are not the same entity (two different granularity). I can think of making one graph having car instances in the first graph as class hierarchy (car model years) in the second graph but then how can I model the general facts about each car model year? May be explicit linking of entities between these two graphs is not necessary but have a common fact like "model number" to match entities when querying. What would be a good modelling practice for this kind of a problem?

--
Regards
Kalpa Gunaratna



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user




--
Regards
Kalpa Gunaratna
Home Page LinkedIn Blog


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user



_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

CarExample.owl (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Modelling same type of entity in two graphs and linking them for querying

Mike

Kalpa,

 

You may find of interest the work of Bernd Neumayr of Johannes Kepler University & Oxford University along with his colleagues.  From a somewhat broader perspective, they have addressed this topic in depth using materialization with abstraction.  e.g. see some pubs at  http://www.dke.jku.at/general/staff/details.xq?fn=Bernd&ln=Neumayr.

 

Michael Denny

 

From: protege-user [mailto:[hidden email]] On Behalf Of Michael DeBellis
Sent: Saturday, November 11, 2017 6:04 PM
To: User support for WebProtege and Protege Desktop
Subject: Re: [protege-user] Modelling same type of entity in two graphs and linking them for querying

 

Kalpa, As Igor said, the way I and Csongor are advocating is the standard OWL method for representing models so if you need a more RDF based approach this won't work. But if your main issue is that you want concepts such as NissanAltima to be both individuals and classes that can be handled in OWL. 

 

I've created a very simple example just to give you an idea of how this could work. In this example ontology you can see that NissanAltima is both a class and an individual (this is an example of punning, which I mentioned in my previous message). There are two instances of NissanAltima: NissanAltima1 and NissanAltima2. Those individuals have data that would be relevant for specific cars: the date the car was manufactured, the person who owns the car, etc. But NissanAltima is also an individual of the class CarModel and it has data that would be relevant for the class of things that are NissanAltimas. E.g, the year the model was first manufactured, the predecessor and successor models, etc. Also, you can see that I've defined an axiom for all Cars, that they must have some number of cylinders: "hasCylinders some xsd:integer" and I've refined that for the sub class of car NissanAltima: "hasCylinders value 4". You can also see that the two instances of NissanAltima have 4 cylinders even though I didn't specify that because the reasoner knows they must given how the class was defined. 

 

Michael

 

On Fri, Nov 10, 2017 at 2:29 PM, Kalpa Gunaratna <[hidden email]> wrote:

Michael,

    Thank you for trying to understand my problem description and providing a detailed response. Let me explain some facts that would help you understand the modelling requirements.

 

In the example, I have the following knowledge representation requirements (using the car example I gave earlier).

(1) I want to describe cars in general for specific year and model. I have facts to describe these and that is why I think of them as individuals (and not as classes). Each of these car models have a manual or spec. I want to represent them as facts describing them. Like the one we could see in DBpedia - http://dbpedia.org/page/Nissan_Altima .

 

(2) Then, I also want to represent specific instances of Nissan altimas people have bought. For example, Kalpa's Nissan Altima2006 has different facts than somebody else. Its color, interior modification, buy date, repair dates, repair places, where it is parked, etc are different to someone else's Nissan Altima 2006. These facts describe a specific Nissan Altima 2006 and that is why I have individuals like Kalpa's Nissan Altima 2006.

 

In the case of (1), it is still a type "Car" and I think of it as an individual because it has many facts describing it (not only in owl axiom level, e.g., manufacturer Nissan). There will be so many cars like this (and they have user manual or technical specs that I want to attach to them) and that is why I do not think of representing them as classes but individuals (Honda Accord, Toyota Camry, Toyota Corolla, etc).

 

Now, I would like to make a connection between a specific individual in case (2) (e.g., Kalpa's Nissan Altima 2006) to an individual in case (1) (e.g., Nissan Altima 2006). I can think of using a custom relation or SKOS:broderMatch like a relation to link individuals in two graphs. What I wanted to make clear is, I have facts to represent in both cases for individuals and I think those cannot be in axiom level. I was wondering if there a different way of thinking other than this.

 

 

On Fri, Nov 10, 2017 at 12:30 PM, Michael DeBellis <[hidden email]> wrote:

Kalpa, I may be misunderstanding your example but I think there is a very straight forward way to model this. I'm just going to use the Nissan Altima example but obviously there would be other similar classes and instances for different kinds and instances of car.

 

So the classes would be Car with subclass NissanAltima2006. You could define axioms (I'm going to be lazy and just use English rather than work out the DL) such as "Has some cylinders" for Car and then "Has exactly 4 cylinders" for NissanAltima2006. Have you done the Pizza tutorial? It has examples that show how to model this kind of stuff at the class level using DL statements. 

 

Then for each example of a NissanAltima2006 you would create an instance such as JoesNissanAltima2006, MarysNissanAltima2006, etc.  Things such as cylinders, color, buyDate, etc. would all be properties with domain Car and the appropriate ranges, in some cases (e.g., buyDate) they would be data properties in other cases (probably cylinders and color) they would be object properties. 

 

I don't see the need for two separate graphs, unless you just mean the difference between the class data (this is called TBox in OWL) and the individual data (this is called ABox). As I see it, this is pretty much vanilla OWL, you just have classes, subclasses, and instances. The one complication might be if there are some properties you want to assert not about a specific car but about a class of car. For example, you might have price as a data property defined for each car (since dealers tend to highly customize how much they offer each car for depending on demand, etc.) but you might also want to describe dealersListPrice as a data property on a class of car. To do that you need to look at punning. It's a very basic kind of meta-object capability that lets you assert this kind of information about a class rather than an instance, so you could say that dealersListPrice on NissanAltima2006 is some floating point number. As I said it's basic but I think it would handle this example. 

 

That is how I would model it. Does that make sense?

 

Michael

 

On Fri, Nov 10, 2017 at 10:51 AM, Kalpa Gunaratna <[hidden email]> wrote:

Hi,

   I am thinking of a good way to model an entity type in two different perspectives and linking them. An example can be as follows.

 

Car model details graph

I will have details of a car model (e.g., Nissan Altima 2006) in a graph with an ontology to describe its facts. E.g., these facts are general to all Nissan Altima 2006 cars such as "4 cylinder", "2.5L engine", "cargo space", etc. The entity is of type "Car". And I will have similar other entities modeled like "Nissan Altima 2007", "Toyota Camry 2006", "Honda Accord 2008", etc.

 

Car model entity graph

Now, I will have another graph for instances of these car models that are owned by specific users. So there can be two or many different entities of "Nissan Altima 2006" in this graph owned by different or same person. Type of these entities is also "Car". In this graph, I will have facts like who owns the car, its color, buy date, repair details, etc, that are specific to that car instance.

 

 

I have one ontology class "Car" to type entities in two graphs. Then, I want to link entities in the two graphs in a way like, to get details for a specific model for a car that a person owns, it could look up in the first graph (by following a link to that graph). Theoretically, it is incorrect to link using "owl:sameAs" because they are not the same entity (two different granularity). I can think of making one graph having car instances in the first graph as class hierarchy (car model years) in the second graph but then how can I model the general facts about each car model year? May be explicit linking of entities between these two graphs is not necessary but have a common fact like "model number" to match entities when querying. What would be a good modelling practice for this kind of a problem?

 

--

Regards
Kalpa Gunaratna

 

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

 


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user



 

--

Regards
Kalpa Gunaratna
Home Page LinkedIn Blog


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

 


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Modelling same type of entity in two graphs and linking them for querying

Kalpa Gunaratna
Thank you for all your responses. I am processing all the information and suggestion you have sent me.

I really appreciate that Michael spent time in creating a model and explaining his thinking on this. I understand "punning" have reasonable idea on that. I am also comfortable with RDF/S and OWL modelling (but have not seriously used them other than querying in recent months).

I think Igor got my line of thinking and ideas for having RDF-like representation because I need to query some specific information for application purpose (like DBpedia or Wikidata). For example, I need to represent very specific information regarding each car model other than their general characteristics like number of cylinders and name of engine manufacturer, material used to make the body, etc, which looks like property-value pairs (rather than OWL axioms). With my experience, I believe, if I need to query very specific information, they "can" be at the entity level (note that I used "can" and we also may use owl axioms to define every little bit of piece). That is the main reason that I decided I have to have different representations guided by an ontology, (1) to represent car model details (very specific facts) and (2) to represent personal car details (again very specific facts). I will have ontology axioms to reason (lite reasoning) for car models as Michael suggested (number of cylinders, number of tires that define a car different to a bus) but do not think model specific property-value pairs should be in owl axioms (like I mentioned, car manufacturer "Nissan Motors" and Nissan Motors in turn has to have property-value pairs describing the individual). In that case I can use "punning" or have to graph representations and link them as Igor suggested. I need efficiency at querying property-value facts (like querying a graph representation) and some lite reasoning for intelligence.

Thank you for all you kind suggestions and help. I welcome any more thoughts if you have.

On Sat, Nov 11, 2017 at 5:19 PM, Mike <[hidden email]> wrote:

Kalpa,

 

You may find of interest the work of Bernd Neumayr of Johannes Kepler University & Oxford University along with his colleagues.  From a somewhat broader perspective, they have addressed this topic in depth using materialization with abstraction.  e.g. see some pubs at  http://www.dke.jku.at/general/staff/details.xq?fn=Bernd&ln=Neumayr.

 

Michael Denny

 

From: protege-user [mailto:[hidden email]] On Behalf Of Michael DeBellis
Sent: Saturday, November 11, 2017 6:04 PM
To: User support for WebProtege and Protege Desktop
Subject: Re: [protege-user] Modelling same type of entity in two graphs and linking them for querying

 

Kalpa, As Igor said, the way I and Csongor are advocating is the standard OWL method for representing models so if you need a more RDF based approach this won't work. But if your main issue is that you want concepts such as NissanAltima to be both individuals and classes that can be handled in OWL. 

 

I've created a very simple example just to give you an idea of how this could work. In this example ontology you can see that NissanAltima is both a class and an individual (this is an example of punning, which I mentioned in my previous message). There are two instances of NissanAltima: NissanAltima1 and NissanAltima2. Those individuals have data that would be relevant for specific cars: the date the car was manufactured, the person who owns the car, etc. But NissanAltima is also an individual of the class CarModel and it has data that would be relevant for the class of things that are NissanAltimas. E.g, the year the model was first manufactured, the predecessor and successor models, etc. Also, you can see that I've defined an axiom for all Cars, that they must have some number of cylinders: "hasCylinders some xsd:integer" and I've refined that for the sub class of car NissanAltima: "hasCylinders value 4". You can also see that the two instances of NissanAltima have 4 cylinders even though I didn't specify that because the reasoner knows they must given how the class was defined. 

 

Michael

 

On Fri, Nov 10, 2017 at 2:29 PM, Kalpa Gunaratna <[hidden email]> wrote:

Michael,

    Thank you for trying to understand my problem description and providing a detailed response. Let me explain some facts that would help you understand the modelling requirements.

 

In the example, I have the following knowledge representation requirements (using the car example I gave earlier).

(1) I want to describe cars in general for specific year and model. I have facts to describe these and that is why I think of them as individuals (and not as classes). Each of these car models have a manual or spec. I want to represent them as facts describing them. Like the one we could see in DBpedia - http://dbpedia.org/page/Nissan_Altima .

 

(2) Then, I also want to represent specific instances of Nissan altimas people have bought. For example, Kalpa's Nissan Altima2006 has different facts than somebody else. Its color, interior modification, buy date, repair dates, repair places, where it is parked, etc are different to someone else's Nissan Altima 2006. These facts describe a specific Nissan Altima 2006 and that is why I have individuals like Kalpa's Nissan Altima 2006.

 

In the case of (1), it is still a type "Car" and I think of it as an individual because it has many facts describing it (not only in owl axiom level, e.g., manufacturer Nissan). There will be so many cars like this (and they have user manual or technical specs that I want to attach to them) and that is why I do not think of representing them as classes but individuals (Honda Accord, Toyota Camry, Toyota Corolla, etc).

 

Now, I would like to make a connection between a specific individual in case (2) (e.g., Kalpa's Nissan Altima 2006) to an individual in case (1) (e.g., Nissan Altima 2006). I can think of using a custom relation or SKOS:broderMatch like a relation to link individuals in two graphs. What I wanted to make clear is, I have facts to represent in both cases for individuals and I think those cannot be in axiom level. I was wondering if there a different way of thinking other than this.

 

 

On Fri, Nov 10, 2017 at 12:30 PM, Michael DeBellis <[hidden email]> wrote:

Kalpa, I may be misunderstanding your example but I think there is a very straight forward way to model this. I'm just going to use the Nissan Altima example but obviously there would be other similar classes and instances for different kinds and instances of car.

 

So the classes would be Car with subclass NissanAltima2006. You could define axioms (I'm going to be lazy and just use English rather than work out the DL) such as "Has some cylinders" for Car and then "Has exactly 4 cylinders" for NissanAltima2006. Have you done the Pizza tutorial? It has examples that show how to model this kind of stuff at the class level using DL statements. 

 

Then for each example of a NissanAltima2006 you would create an instance such as JoesNissanAltima2006, MarysNissanAltima2006, etc.  Things such as cylinders, color, buyDate, etc. would all be properties with domain Car and the appropriate ranges, in some cases (e.g., buyDate) they would be data properties in other cases (probably cylinders and color) they would be object properties. 

 

I don't see the need for two separate graphs, unless you just mean the difference between the class data (this is called TBox in OWL) and the individual data (this is called ABox). As I see it, this is pretty much vanilla OWL, you just have classes, subclasses, and instances. The one complication might be if there are some properties you want to assert not about a specific car but about a class of car. For example, you might have price as a data property defined for each car (since dealers tend to highly customize how much they offer each car for depending on demand, etc.) but you might also want to describe dealersListPrice as a data property on a class of car. To do that you need to look at punning. It's a very basic kind of meta-object capability that lets you assert this kind of information about a class rather than an instance, so you could say that dealersListPrice on NissanAltima2006 is some floating point number. As I said it's basic but I think it would handle this example. 

 

That is how I would model it. Does that make sense?

 

Michael

 

On Fri, Nov 10, 2017 at 10:51 AM, Kalpa Gunaratna <[hidden email]> wrote:

Hi,

   I am thinking of a good way to model an entity type in two different perspectives and linking them. An example can be as follows.

 

Car model details graph

I will have details of a car model (e.g., Nissan Altima 2006) in a graph with an ontology to describe its facts. E.g., these facts are general to all Nissan Altima 2006 cars such as "4 cylinder", "2.5L engine", "cargo space", etc. The entity is of type "Car". And I will have similar other entities modeled like "Nissan Altima 2007", "Toyota Camry 2006", "Honda Accord 2008", etc.

 

Car model entity graph

Now, I will have another graph for instances of these car models that are owned by specific users. So there can be two or many different entities of "Nissan Altima 2006" in this graph owned by different or same person. Type of these entities is also "Car". In this graph, I will have facts like who owns the car, its color, buy date, repair details, etc, that are specific to that car instance.

 

 

I have one ontology class "Car" to type entities in two graphs. Then, I want to link entities in the two graphs in a way like, to get details for a specific model for a car that a person owns, it could look up in the first graph (by following a link to that graph). Theoretically, it is incorrect to link using "owl:sameAs" because they are not the same entity (two different granularity). I can think of making one graph having car instances in the first graph as class hierarchy (car model years) in the second graph but then how can I model the general facts about each car model year? May be explicit linking of entities between these two graphs is not necessary but have a common fact like "model number" to match entities when querying. What would be a good modelling practice for this kind of a problem?

 

--

Regards
Kalpa Gunaratna

 

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

 


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user



 

--

Regards
Kalpa Gunaratna
Home Page LinkedIn Blog


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

 


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user




--
Regards
Kalpa Gunaratna
Home Page LinkedIn Blog


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user