=Paper=
{{Paper
|id=None
|storemode=property
|title=SimpleOrAggregated
|pdfUrl=https://ceur-ws.org/Vol-671/pat05.pdf
|volume=Vol-671
|dblpUrl=https://dblp.org/rec/conf/semweb/Poveda-VillalonS10a
}}
==SimpleOrAggregated==
https://ceur-ws.org/Vol-671/pat05.pdf
SimpleOrAggregated
http://ontologydesignpatterns.org/wiki/Submissions:SimpleOrAggregated
María Poveda Villalón Mari Carmen Suárez-Figueroa
Ontology Engineering Group (OEG) Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial. Facultad de Departamento de Inteligencia Artificial. Facultad de
Informática, Universidad Politécnica de Madrid (UPM) Informática, Universidad Politécnica de Madrid (UPM)
Campus de Montegancedo, s/n Campus de Montegancedo, s/n
28660 Boadilla del Monte, Spain 28660 Boadilla del Monte, Spain
+34 913363670 +34 913363672
mpoveda@delicias.dia.fi.upm.es mcsuarez@fi.upm.es
ABSTRACT The main difference between the aggregation relation and other
In this paper, we describe a content ontology design pattern to mereological relationships (such as part-of or componency) is that
represent objects that can be simple or aggregated. The the aggregated object and its aggregated members should belong
aggregation relation refers to several objects gathered in another to the same concept.
object acting as a whole; all these objects should belong to the
same concept in the model. 2.2 Solution Description
As it can be observed in Figure 1 the class "ObjectByCardinality"
has been created to classify simple and aggregated objects into its
Keywords subclasses "SimpleObject" and "AggregatedObject", respectively.
Ontology design patterns, mereology, aggregation.
These subclasses are disjoint among them.
<>
1. INTRODUCTION ObjectByCardinality Object
Mereological relationships are one of the basic structuring <>
primitives of the universe, and many applications require
representations of them (catalogues of parts, fault diagnosis, U
anatomy, geography, etc.) [3].
<> hasAggregatedMember
SimpleObject AggregatedObject
We usually have the need of representing objects that are made up
<>
of other types of object. In these situations, we can use the part-of
<>
[1] pattern to represent transitive mereological relationships.
Some examples can be “Brain and heart are parts of the human AggregatedObject Object Object AggregatedObject
body” or “Substantia nigra is part of brain”. In addition, we can
use the componency [1] pattern to distinguish between parts and <> <> <> <>
proper parts in a non transitive fashion. An example of this case
can be “The turbine is a proper part of the engine; both are parts <>
<>
<>
<>
hasAggregatedMember isAggregatedMemberOf
of a car. Furthermore, the engine and the battery are proper parts <>
of the car”.
However, sometimes we need to represent objects that can be
made up of objects that belong to the same concept. In these cases <> <> <>
hasDirectAggregatedMember isDirectAggregatedMemberOf
it is also need to distinguish objects into simple or aggregated
ones. For this reason, we have created the SimpleOrAggregated
pattern to represent aggregation relationships, both transitive and
Figure 1. Graphical representation of the
non transitive, between objects that belong to the same concept in
SimpleOrAggregated pattern.
the model. An example of this situation can be “aggregated
service provider is formed by simple or aggregated service The aggregation relationship between objects means that objects
providers”. of a class can be composed by other objects of the same class.
This relationship is represented by the transtive property
"hasAggregatedMember" and its inverse property
2. PATTERN DESCRIPTION "isAggregatedMemberOf". These properties have as subproperties
the non transitive properties "hasDirectAggregatedMember" and
2.1 Intent its inverse "isDirectAggregatedMemberOf", respectively. By
The goal of this pattern is to represent objects that can be simple
means of this structure of properties, we provide a mechanism (a)
or aggregated (that is, several objects gathered in another object
to represent transitive aggregation relationships (that is, if A has B
acting as a whole).
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 ServiceProviderByCardinality ServiceProvider
MIOServiceProvider
member). <>
LocalServiceProvider
Finally, the class "AggregatedObject" has been defined as U
CulturalServiceProvider
equivalent to those things that have some values for the property EntertainmentServiceProvider
SimpleServiceProvider AggregatedServiceProvider
"hasAggregatedMember". This modelling allows the automatic <> hasAggregatedMember
FoodServiceProvider
<>
classification of aggregated objects in this class when a reasoner is HealthCareProvider
<>
applied. HostingServiceProvider
InformationServiceProvider
ReligiousServiceProvider
2.3 Consequences SecurityServicesProvider
Shop
This content pattern allows designers to represent both simple SportServiceProvider
individuals of a given concept (that is, an individual that is made TransportationServiceProvider
up of itself) and aggregated individuals of a given concept (that is, Figure 2. SimpleOrAggregated pattern applied to service
an individual that is made up of several individuals of the same providers.
concept). In summary, this pattern allows to represent both simple
objects and aggregated objects and their members.
5. Summary and Outlook
In addition, this pattern can be used to detect the following The SimpleOrAggregated pattern provides a mechanism to
contradictory situation by means of applying a reasoner: 'to classify objects as simple or aggregated objects depending on
instantiate the relationship "hasAggregatedMember" for an Object whether they are an aggregation of some objects. This
that belongs to "SimpleObject"'. This situation represents a classification is compatible with another possible classification of
consistency error and it is detected when a resoner is applied due objects.
to the following modelling decisions included in the pattern: (a)
"AggregatedObject" class represents the "hasAggregatedMember" 6. ACKNOWLEDGMENTS
domain and (b) "AggregatedObject" is disjoint with This work has been partially supported by the Spanish project
"SimpleObject". mIO! (CENIT-2008-1019).
3. PATTERN USAGE EXAMPLE 7. REFERENCES
This pattern has been applied to different domains such as service [1] Presutti, V., Gangemi, A., David S., Aguado de Cea, G.,
providers and context sources during the mIO! ontology network1 Suárez-Figueroa, M.C., Montiel-Ponsoda, E., Poveda, M.
development. NeOn D2.5.1: A Library of Ontology Design Patterns:
As an example, we show in Figure 2 the application of the reusable solutions for collaborative design of networked
SimpleOrAggegrated pattern to represent that a service provider ontologies. NeOn project. http://www.neon-project.org.
can be classified as simple or aggregated. Each service provider 2008.
can be also classified with respect to the type of service it [2] Poveda, M., Suárez-Figueroa, M.C., García-Castro, R.,
provides (e.g. cultural, entertainment, food, health, etc.). Gómez-Pérez, A. A Context Ontology for Mobile
Environments. Proceedings of CIAO 2010. Lisbon, Portugal.
4. Related work 11 October 2010.
The origin of this pattern is the modelling of service providers and [3] Suárez-Figueroa, M.C., Brockmans, S., Gangemi, A.,
context sources into the mIO! ontology network [2] within the Gómez-Pérez, A., Lehmann, J., Lewen, H., Presutti, V.,
Spanish project mIO!2. The pattern has been also applied to Sabou, M.. NeOn D5.1.1: NeOn Modelling Components.
computing and storage resources modelling in the Metascheduler NeOn project. http://www.neon-project.org. March 2007.
ontology3 in the context of the Spanish project España Virtual4.
1
http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/ontologies/82-
mio-ontologies
2
http://www.cenitmio.es/
3
http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/ontologies/85-
metascheduler-ontologies
4
http://www.españavirtual.org/