Submissions:Summarization of an inverse n-ary relation - Revision history

EvaBlomqvist: Submissions:Inverse n-ary relationship moved to Submissions:Summarization of an inverse n-ary relation: Pattern changed its named based on review suggestions

2010-09-30T11:40:03Z

Submissions:Inverse n-ary relationship moved to Submissions:Summarization of an inverse n-ary relation: Pattern changed its named based on review suggestions

MariCarmenSuarezFigueroa at 09:14, 30 September 2010

2010-09-30T09:14:13Z

MariCarmenSuarezFigueroa at 09:12, 30 September 2010

2010-09-30T09:12:59Z

MariaPoveda at 17:58, 29 September 2010

2010-09-29T17:58:14Z

MariaPoveda at 17:17, 29 September 2010

2010-09-29T17:17:03Z

MariaPoveda at 16:36, 29 September 2010

2010-09-29T16:36:59Z

MariCarmenSuarezFigueroa at 10:29, 29 September 2010

2010-09-29T10:29:50Z

MariCarmenSuarezFigueroa at 10:26, 29 September 2010

2010-09-29T10:26:56Z

MariaPoveda at 16:26, 28 September 2010

2010-09-28T16:26:04Z

MariaPoveda at 16:20, 28 September 2010

2010-09-28T16:20:43Z

@@ Line 32: / Line 32: @@
 [[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 (that would involve the class created to support the n-ary relation between service providers and services).
+|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

@@ Line 10: / Line 10: @@
 }}
 {{Logical OP Description Template
-|Motivation=The n-ary relationships should be used to address any of the following situations:
+|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.
+(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.
+(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.
@@ Line 21: / Line 21: @@
 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 into 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.
+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 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).
+|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 have been created to short-circuited the relation between the distinguished participants in 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
 }}

@@ Line 23: / Line 23: @@
 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 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 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).
 |Elements=Class, Relationship, Attribute and inverseOf
 }}

@@ Line 11: / Line 11: @@
 {{Logical OP Description Template
 |Motivation=The n-ary relationships should be used to address any of the following situations:
-(a) a binary relationship that really needs a further argument
+(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
+(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.
+(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.

@@ Line 5: / Line 5: @@
 }}
 {{Logical OP General Template
-|Name=Inverse n-ary relationship
+|Name=Summarization of an inverse n-ary relation
 |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,
 |Author=MariaPoveda, MariCarmenSuarezFigueroa,

← Older revision	Revision as of 11:40, 30 September 2010
(No difference)

@@ Line 27: / Line 27: @@
 {{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.
-We have also observed that the queries 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.

@@ Line 10: / Line 10: @@
 }}
 {{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=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; or (c) a relationship that is really amongst several things.
 On the one hand, the motivation of this pattern is to express the inverse relationship of an 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 exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments.