Graphical representation

Diagram

General information

Name	Inverse n-ary relationship
Also known as
Author(s)	MariaPoveda, MariCarmenSuarezFigueroa
SubmittedBy	MariaPoveda, MariCarmenSuarezFigueroa

Description

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. 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 exists mainly between two entities and the rest of entities involved in the relationship can be considered as just additional, and probably optional, arguments. 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).
Solution description
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 service and rarely ask for the relationships about the services and where they are provided.
Pattern solution example	http://ontologydesignpatterns.org/wiki/Image:LP-IN-01v1.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).

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

There is no review about this proposal.

Some subquery has no valid condition.

This revision (revision ID 10144) 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.