Submissions:Summarization of an inverse n-ary relation

From Odp

(Difference between revisions)
Jump to: navigation, search
m (Review has been assigned.)
Current revision (11:40, 30 September 2010) (view source)
m (Submissions:Inverse n-ary relationship moved to Submissions:Summarization of an inverse n-ary relation: Pattern changed its named based on review suggestions)
 
(17 intermediate revisions not shown.)
Line 5: Line 5:
}}
}}
{{Logical OP General Template
{{Logical OP General Template
-
|Name=Inverse n-ary relationship
+
|Name=Summarization of an inverse n-ary relation
|SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,
|SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,
|Author=MariaPoveda, MariCarmenSuarezFigueroa,
|Author=MariaPoveda, MariCarmenSuarezFigueroa,
}}
}}
{{Logical OP Description Template
{{Logical OP Description Template
-
|Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; (c) a relationship that is really amongst several things.
+
|Motivation=An n-ary relationship should be used to address any of the following situations:  
-
The motivation of this pattern is to express the inverse relationship of a n-ary one where there are distinguished participants, that is, there is a single individual standing out as the subject or the "owner" of the relation. This means that the relationship exits mainly between two entities and the rest of entities involved in the relationship can be considered as just additional, and probably optional, arguments.
+
(a) a binary relationship that really needs a further argument. For example, to represent the distance between two places.
-
This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this patter could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.
+
(b) two binary relationships that always go together and should be represented as one n-ary relation. For example, to represent the value of an observation (e.g. temperature in a patient) and its trend.
-
|Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).
+
 
 +
(c) a relationship that is really amongst several things. For example, to represent the spatial location of a person in a given point of time.
 +
 
 +
On the one hand, the motivation of this pattern is to express the inverse relationship of an n-ary relation where there are distinguished participants. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments. This situation can also mean that there is a single individual standing out as the subject or the "owner" of the relation.
 +
 
 +
On the other hand, the motivation is to provide a shorcut for queries that involve the distinguished participants in the n-ary relationship.
 +
 
 +
This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants in the relationship. Therefore, this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations./#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.
 +
|Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse relations between two distinguished participants without a complex query (Such a comples query would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).
 +
|Solution=The class "NAryRelationClass" is the class created to support the n-ary relationship (like in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1) and its further relations or attributes. The relationship "mainRelationship" and its inverse relation have been created to short-circuited the relation between the distinguished participants in the n-ary relationship.
|Elements=Class, Relationship, Attribute and inverseOf
|Elements=Class, Relationship, Attribute and inverseOf
}}
}}
{{Logical OP Example Template
{{Logical OP Example Template
|ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider.  
|ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider.  
-
We have also observed that the querys executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.
+
We have also observed that the queries executed by our applications often ask for the relationship between providers and their services and rarely ask for the relationships about the services and where they are provided.
-
|SolutionExample=http://ontologydesignpatterns.org/wiki/Image:LP-IN-01v1.jpg
+
 
-
|Consequences=The main advantage of this pattern is that allows asking for those services taht are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).
+
 
 +
[[Image:N_aria_provider_service.JPG]]
 +
|Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (this complex query would involve the class created to support the n-ary relation between service providers and services).
}}
}}
{{Logical OP Reference Template
{{Logical OP Reference Template
Line 29: Line 40:
}}
}}
{{Additional information header}}
{{Additional information header}}
-
[[Category:Waiting for review]]
+
[[Category:Review assigned]]
{{Scenarios about me}}
{{Scenarios about me}}
{{Reviews about me}}
{{Reviews about me}}
Line 37: Line 48:
|Event=WOP:2010
|Event=WOP:2010
}}
}}
-
[[Category:Review assigned]]
 
-
[[Category:Review assigned]]
 
-
[[Category:Review assigned]]
 

Current revision


This pattern has been certified.

Related submission, with evaluation history, can be found here

If you are a member of quality committee please visit the

evaluation section

If you are author of this proposal or you want to contribute to this pattern's review, you can:

In general, it could be useful to visit the evaluation section to have information about the evaluation process of this proposal

Current revision ID: 10179

Graphical representation

Diagram

Image:LP-IN-01v1_general.jpg

General information

Name Summarization of an inverse n-ary relation
Also known as
Author(s) MariaPoveda, MariCarmenSuarezFigueroa
SubmittedBy MariaPoveda, MariCarmenSuarezFigueroa


Description

Motivation An n-ary relationship should be used to address any of the following situations:

(a) a binary relationship that really needs a further argument. For example, to represent the distance between two places.

(b) two binary relationships that always go together and should be represented as one n-ary relation. For example, to represent the value of an observation (e.g. temperature in a patient) and its trend.

(c) a relationship that is really amongst several things. For example, to represent the spatial location of a person in a given point of time.

On the one hand, the motivation of this pattern is to express the inverse relationship of an n-ary relation where there are distinguished participants. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments. This situation can also mean that there is a single individual standing out as the subject or the "owner" of the relation.

On the other hand, the motivation is to provide a shorcut for queries that involve the distinguished participants in the n-ary relationship.

This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants in the relationship. Therefore, this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations./#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.

Aim The aim of this pattern is to allow asking for n-ary relationships and their inverse relations between two distinguished participants without a complex query (Such a comples query would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).
Solution description The class "NAryRelationClass" is the class created to support the n-ary relationship (like in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1) and its further relations or attributes. The relationship "mainRelationship" and its inverse relation have been created to short-circuited the relation between the distinguished participants in the n-ary relationship.
Elements Class, Relationship, Attribute and inverseOf
Implementation
Reusable component
Component type


Example

Problem example We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider.

We have also observed that the queries executed by our applications often ask for the relationship between providers and their services and rarely ask for the relationships about the services and where they are provided.


Image:N_aria_provider_service.JPG

Pattern solution example
Consequences The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (this complex query would involve the class created to support the n-ary relation between service providers and services).


Pattern reference

Origin Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2
Known use
Reference
Related ODP Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation
Used in combination with Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation
Test

Additional information

Scenarios

Scenarios about Summarization of an inverse n-ary relation

No scenario is added to this Content OP.

Reviews

Reviews about Summarization of an inverse n-ary relation
Review article Posted on About revision (current is 10179)
CatherineRoussey about Inverse n-ary relationship 245545010 September 2010 1006010,060
GerdGroener about Inverse n-ary relationship 245545010 September 2010 1006010,060
OlafNoppens about Inverse n-ary relationship 245545616 September 2010 1010110,101
AlessandroAdamou about Inverse n-ary relationship 245545616 September 2010 1010110,101

This revision (revision ID 10179) takes in account the reviews: none

Other info at evaluation tab


Modeling issues

Modeling issues about Summarization of an inverse n-ary relation

There is no Modeling issue related to this proposal.


References

Add a reference


Submission to event

WOP:2010

Retrieved from "http://ontologydesignpatterns.org/wiki/Submissions:Summarization_of_an_inverse_n-ary_relation"
Personal tools
Quality Committee
Content OP publishers