Submissions:SimpleOrAggregated
From Odp
Current revision (10:19, 29 September 2010) (view source) |
|||
(17 intermediate revisions not shown.) | |||
Line 5: | Line 5: | ||
}} | }} | ||
{{Content OP Proposal Template | {{Content OP Proposal Template | ||
- | |SubmittedBy=MariaPoveda, MariCarmenDeFigueroa | + | |SubmittedBy=MariaPoveda, MariCarmenDeFigueroa |
|Name=SimpleOrAggregated | |Name=SimpleOrAggregated | ||
- | |Intent=The goal of this pattern is to represent | + | |Intent=The goal of this pattern is to represent objects that can be simple or aggregated (that is, several objects gathered in another object acting as a whole). |
+ | The main difference between the aggregation relation and other mereological relationships (such as part-of or componency) is that the aggregated object and its aggregated members should belong to the same concept. For example, a turbine is part of an engine, whereas an aggregated provider is formed by providers. | ||
|Domain=Parts and Collections, | |Domain=Parts and Collections, | ||
|CompetencyQuestion=What elements are aggregated members of this object?, What is this object aggregated member of? | |CompetencyQuestion=What elements are aggregated members of this object?, What is this object aggregated member of? | ||
- | |ContentODPDescription= | + | |ContentODPDescription=The class "ObjectByCardinality" has been created to classify simple and aggregated objects into its subclasses "SimpleObject" and "AggregatedObject", respectively. These subclasses are disjoint among them. |
+ | |||
+ | The aggregation relationship between objects means that objects can be composed by other objects. This relationship is represented by the transtive property "hasAggregatedMember" and its inverse "isAggregatedMemberOf". These properties have as subproperties the non transitive properties "hasDirectAggregatedMember" and its inverse "isDirectAggregatedMemberOf", respectively. By means of this structure of properties, we provide a mechanism (a) to represent transitive aggregation relationships (that is, if A has B as aggregated member and B has C as aggregated member then A has C as aggregated member) and (b) to link each aggregated member just to the next level (that is, A has B as direct aggregated member). | ||
+ | |||
+ | Finally, the class "AggregatedObject" has been defined as equivalent to those things that have some values for the property "hasAggregatedMember". This modelling allows the automatic classification of aggregated objects in this class when a reasoner is applied. | ||
|ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/SimpleOrAggregated.owl | |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/SimpleOrAggregated.owl | ||
- | |Consequences=This Content OP allows designers to represent simple individuals of a given concept (that is, an individual that is made up of itself) and aggregated individuals of a given concept (that is, an individual that is made up of several individuals of the same concept). | + | |Consequences=This Content OP allows designers to represent both simple individuals of a given concept (that is, an individual that is made up of itself) and aggregated individuals of a given concept (that is, an individual that is made up of several individuals of the same concept). |
In summary, this pattern allows to represent both simple objects and aggregated objects and their members. | In summary, this pattern allows to represent both simple objects and aggregated objects and their members. | ||
- | In addition, this pattern can be used to detect the following contradictory situation by means of applying a reasoner: 'to | + | In addition, this pattern can be used to detect the following contradictory situation by means of applying a reasoner: 'to instantiate the relationship "hasAggregatedMember" for an Object that belongs to "SimpleObject"'. This situation represents a consistency error and it is detected when a resoner is applied due to the following modelling decisions included in the pattern: (a) "AggregatedObject" class represents the "hasAggregatedMember" domain and (b) "AggregatedObject" is disjoint with "SimpleObject". |
- | |Scenario=A service provider can be simple or be an aggregate of a set of service providers. | + | |Scenario=A service provider can be simple or be an aggregate of a set of service providers. A context source can be simple or be an aggregate of a set of context sources. A computing or storage resource can be simple or be an aggregate of a set of computing or storage resources. |
- | A context source can be simple or be an aggregate of a set of context sources. | + | |
- | + | ||
- | A computing or storage resource can be simple or be an aggregate of a set of computing or storage resources. | + | |
}} | }} | ||
{{Element list header}} | {{Element list header}} | ||
Line 40: | Line 42: | ||
}} | }} | ||
{{Additional information header}} | {{Additional information header}} | ||
- | [[Category: | + | [[Category:Review assigned]] |
{{Scenarios about me}} | {{Scenarios about me}} | ||
{{Reviews about me}} | {{Reviews about me}} |
Current revision
If you are a member of quality committee please visit the
If you are author of this proposal or you want to contribute to this pattern's review, you can: specify if this revision takes in account any of the review(s) In general, it could be useful to visit the evaluation section to have information about the evaluation process of this proposal Current revision ID: 10170 |
Graphical representation
Diagram
General description
Name: | SimpleOrAggregated |
---|---|
Submitted by: | MariaPoveda, MariCarmenDeFigueroa |
Also Known As: | |
Intent: | The goal of this pattern is to represent objects that can be simple or aggregated (that is, several objects gathered in another object acting as a whole).
The main difference between the aggregation relation and other mereological relationships (such as part-of or componency) is that the aggregated object and its aggregated members should belong to the same concept. For example, a turbine is part of an engine, whereas an aggregated provider is formed by providers. |
Domains: | |
Competency Questions: |
|
Solution description: | The class "ObjectByCardinality" has been created to classify simple and aggregated objects into its subclasses "SimpleObject" and "AggregatedObject", respectively. These subclasses are disjoint among them.
The aggregation relationship between objects means that objects can be composed by other objects. This relationship is represented by the transtive property "hasAggregatedMember" and its inverse "isAggregatedMemberOf". These properties have as subproperties the non transitive properties "hasDirectAggregatedMember" and its inverse "isDirectAggregatedMemberOf", respectively. By means of this structure of properties, we provide a mechanism (a) to represent transitive aggregation relationships (that is, if A has B as aggregated member and B has C as aggregated member then A has C as aggregated member) and (b) to link each aggregated member just to the next level (that is, A has B as direct aggregated member). Finally, the class "AggregatedObject" has been defined as equivalent to those things that have some values for the property "hasAggregatedMember". This modelling allows the automatic classification of aggregated objects in this class when a reasoner is applied. |
Reusable OWL Building Block: | http://delicias.dia.fi.upm.es/ontologies/SimpleOrAggregated.owl (1021) |
Consequences: | This Content OP allows designers to represent both simple individuals of a given concept (that is, an individual that is made up of itself) and aggregated individuals of a given concept (that is, an individual that is made up of several individuals of the same concept).
In summary, this pattern allows to represent both simple objects and aggregated objects and their members. In addition, this pattern can be used to detect the following contradictory situation by means of applying a reasoner: 'to instantiate the relationship "hasAggregatedMember" for an Object that belongs to "SimpleObject"'. This situation represents a consistency error and it is detected when a resoner is applied due to the following modelling decisions included in the pattern: (a) "AggregatedObject" class represents the "hasAggregatedMember" domain and (b) "AggregatedObject" is disjoint with "SimpleObject". |
Scenarios: | A service provider can be simple or be an aggregate of a set of service providers. A context source can be simple or be an aggregate of a set of context sources. A computing or storage resource can be simple or be an aggregate of a set of computing or storage resources. |
Known Uses: | |
Web References: | |
Other References: | |
Examples (OWL files): | |
Extracted From: | |
Reengineered From: | |
Has Components: | |
Specialization Of: | |
Related CPs: |
Elements
The SimpleOrAggregated Content OP locally defines the following ontology elements:
Un objeto resultante de la agregación de dos o más objetos.
Cualquier objeto fÃsico, social o mental o sustancia.
Un objeto simple, es decir, un objeto que no tiene objetos agregados.
Additional information
Scenarios
- Modelling simple and aggregated service providers within the mIO! ontology network. Service providers are also organized by types. >>>
- Modelling simple and aggregated context sources within the mIO! ontology network. >>>
- Modelling simple and aggregated resources. These resources are also organized by types, specifically, they can be computing or storage resources. >>>
Reviews
Review article | Posted on | About revision (current is 10170) |
---|---|---|
CatherineRoussey about SimpleOrAggregated | 245545010 September 2010 | 1006410,064 |
GerdGroener about SimpleOrAggregated | 245545010 September 2010 | 1009710,097 |
VojtechSvatek about SimpleOrAggregated | 245545616 September 2010 | 1009710,097 |
This revision (revision ID 10170) takes in account the reviews: none
Other info at evaluation tab
Modeling issues
There is no Modeling issue related to this proposal.
References
Submission to event |
---|