In this work we look into the details of modeling shapes in an ontology as property restrictions on classes. In this way shapes do not have to be categorized in an exhaustive hierarchy and there is no need to take immediate decisions on how to group the objects, it is rather possible to individualize some important characteristics of shapes and use them as the basis for their categorization and comparison. This approach also makes it possible to use the adequate similarity measure based on properties which helps find similar shapes in di↵ erent contexts, depending on the relevance of the properties in the particular situation.
In many di↵ erent areas, from virtual reality to architectural design, from biology to medicine, from mathematics to computer science, the notion of shape plays a crucial role. Finding patterns and forms in objects surrounding us, describing them and understanding their interaction is essential to human nature. Hence, varied approaches to the categorization of shapes and forms, as well as their mutual similarity and connectedness, are of great importance for the development of many scientific fields.
In various domains, there is a raising tendency to use ontologies as powerful
formalisms for knowledge representation with associated reasoning mechanisms
(inheritance, subsumption, classification etc.). Ontologies provide explicit specifications of
domain concepts and relationships that exist between them [
In the domain of shape, form and structure representation, there were some attempts
at modeling shapes ontologically, as an exhaustive hierarchy. In [
In the realm of spatial design and reasoning, authors in [
As far as similarity among ontological concepts is concerned, three main approaches
can be distinguished. The first one [
The rest of the paper is organized as follows. Section 1 provides a summary of the treatment of properties in OWL and the definition of property restrictions on classes. In Section 2 we discuss some issues concerning modeling of shapes as property restrictions on classes, followed by some examples of shape definitions. Details of the approach to calculating similarity of shapes based on properties can be found in Section 3. Section 4 concludes.
In di↵ erent contexts, domain knowledge can be represented semantically using ontologies expressed in OWL2. In an ontology, domain concepts are organized hierarchically and have their features defined as properties. Two kinds of properties can be distinguished in OWL: (i) object properties relating individuals among themselves and (ii) data type properties relating individuals to data type values.
Characteristics of a property are defined with a property axiom, most commonly defining its domain and range. rdfs:domain links a property to a class description, whereas rdfs:range links a property to either a class description or a data range. For example: <owl:ObjectProperty rdf:ID="has_curvature"> <rdfs:domain rdf:resource="#Shape"/> <rdfs:range rdf:resource="#Curvature "/> </owl:ObjectProperty> defines the property has curvature which ties the elements of Shape class to the elements of Curvature class.
Equivalent properties are defined with owl:equivalentProperty.
In the following section we will see how properties are used in OWL to define classes with property restrictions.
Properties are used in OWL for defining classes with property restrictions, by means of local anonymous classes, which are collections of individuals all satisfying certain restrictions on certain properties. Two kinds of property restrictions exist: value constraints and cardinality constraints. A value constraint concerns constraints on the range of the property when applied to a particular class description. A cardinality constraint imposes constraints on the number of values a property can take, in the context of a particular class description.
We start with the brief description of value constraints. There are three ways of defining value constraints: • owl:allValuesFrom defines a class for which all the values of the given property are either members of the specified class or data values within the specified data range. It is possible not to have any values for the given property. For example: <owl:Restriction> <owl:onProperty rdf:resource="#has_angle" /> <owl:allValuesFrom rdf:resource="#RightAngle" /> </owl:Restriction> describes an anonymous OWL class of all individuals for which the has angle property only has values of the class RightAngle (for example square or rectangle). In predicate logic, the counterpart of owl:allValuesFrom constraint is the universal quantifier, i.e. for each instance of the class defined with the restriction, every value for the property must fulfill the constraint and the constraint is trivially satisfied for an instance that has no value for the specified property. • owl:someValuesFrom specifies a class for which at least one of the values of the given property is either a member of the specified class or a data value within the specified data range (at least one must exist). There might be other values for the given property. For example: <owl:Restriction> <owl:onProperty rdf:resource="#has_angle" /> <owl:someValuesFrom rdf:resource="#RightAngle" /> </owl:Restriction> describes an anonymous OWL class of all individuals which have at least one right angle (for example right-angled triangle). In predicate logic, the counterpart of owl:someValuesFrom constraint is the existential quantifier, i.e. for each instance of the class defined with the restriction, there exists at least one value for the property that fulfills the constraint. • owl:hasValue defines a class for which the specified property has at least one value semantically equal to the specified value, which can be either an individual or a data value3. For example: <owl:Restriction> <owl:onProperty rdf:resource="#contains" /> <owl:hasValue rdf:resource="#Circle100" /> </owl:Restriction> describes an anonymous OWL class which contains a specific circle.
On the other hand, cardinality constraints can be expressed by using one of the following three constraints: • owl:maxCardinality describes a class with at most max semantically distinct values for the specified property (max being the value of the cardinality constraint). For example <owl:Restriction> <owl:onProperty rdf:resource="#has_number_of_edges" /> <owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">5 </owl:maxCardinality> </owl:Restriction> describes an anonymous OWL class of individuals that have at most five edges (for example polygons with 3 or 4 or 5 edges),. • owl:minCardinality is defined analogously to maxCardinality, where the class has at least min semantically distinct values. • owl:cardinality is defined analogously to maxCardinality, where the class has exactly m semantically distinct values. It is actually a redundant concept, since it can be defined with the combination of maxCardinality and minCardinality.
From the above we can see that we can consider each of the concepts in our ontology, to have certain properties defined for it. These properties further describe the concepts in the ontology and can be used to categorize them and to calculate their mutual similarity.
An instance in the ontology is defined with individual axioms called “facts” which describe its class membership, property values and individual identity. An instance is related to the class it belongs to directly with the rdfs:type relation and basically inherits 3For datatypes “semantically equal” means that the lexical representation of the literals maps to the same value. For individuals it means that they either have the same URI reference or are defined as being the same individual with owl:sameAs. the properties of the class it belongs to. Hence, in OWL the properties of the instances are defined by associating to each property its specific value. For example, the following describes a red circle with the radius equal to 3 and a dotted outline. <Circle rdf:ID="Circle100"> <has_radius rdf:datatype="&xsd;positiveInteger">3</has_radius> <has_outline rdf:resource="#Dotted"/> <has_color rdf:resource="#Red"/> </Circle>
Categorization of the world around us is inherent to human perception and reasoning. Many objects are internalized easier if they are reduced to simpler forms and shapes that we are familiar with and that we can easily group with other similar objects.
We give some directions on how to model two-dimensional shapes, since they are the easiest to comprehend and understand.4 The most common categorization of twodimensional shapes is according to the kind of edges the shapes contain to curved shapes and straight line composed shapes (polygons). But another categorization could start from convex and concave shapes. Or we might want to categorize the shapes based on the number of edges they have. The possibilities are many.
So instead of forcing this somehow artificial categorization upon the shape world, we would do the shapes more justice by defining them as property restrictions on classes. We can start by defining many di↵ erent properties which would help us precisely describe the shapes we need. For example, the property has edge kind could be used to define as property restrictions the classes CurvedShape and Polygon (shapes composed from straight lines), whereas the property has curvature would be used to distinguish ConvexShape class from ConcaveShape class (again defining them as restrictions). In this way, there is no need to a-priori decide which categorization should happen higher up in the hierarchy, they can peacefully co-exist together (and not be the only ones). Once the first level is modeled, we can proceed to model their subclasses. At this point we can have direct subclasses with additional properties or additional restrictions. So we can include properties like number of edges, number of equal edges, number of parallel edges etc. This would also help us compare the shapes having all these properties defined explicitly for them.
In this light, let us have a look at two shape definitions, namely rhombus and rectangle. A rhombus can be defined as a simple (non-self-intersecting) quadrilateral with four equal edges, whereas a rectangle can be defined as quadrilateral with four right angles (and they are both convex). So if we define the Quadrilateral class as a subclass of Polygon class which has the property has number of sides restricted to 4, we can define rhombus and rectangle as follows: <owl:Class rdf:ID="Rectangle"> <rdfs:subClassOf rdf:resource="#Quadrilateral"/> <rdfs:subClassOf rdf:resource="#ConvexShape"/> 4Three-dimensional and n-dimensional objects are treated similarly. <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#has_angle" /> <owl:allValuesFrom rdf:resource="#RightAngle" /> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#has_number_of_angles"/> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">4 </owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Rhombus"> <rdfs:subClassOf rdf:resource="#Quadrilateral"/> <rdfs:subClassOf rdf:resource="#Convex"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#has_number_of_equal_edges"/> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">4 </owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
Obviously, these are not the only ways to define these two, or any other shape. The process is versatile and applicable in many di↵ erent contexts. Above all, it enables very natural comparison of shapes and establishes their similarity based on properties, as we will see in the following section.
If we define shapes as property restrictions (on values and cardinality), we can find
similar shapes by comparing their properties. The property-based similarity of two shapes
S 1 and S 2, can be calculated by starting from Tversky’s feature-based model of
similarity [
Hence, to be able to use Tversky’s model we need to calculate the following: • common features of S 1 and S 2: cf(S 1, S 2) = (S 1) \ • distinctive features of S 1: df(S 1) = (S 1) \ (S 2) and • distinctive features of S 2: df(S 2) = (S 2) \ (S 1). (S 2), Putting these values into the formula (1) and taking ↵ = = = 1 we obtain:
In order to calculate common and distinctive features for S 1 and S 2, for each property p, we calculate cfp, df1p and df2p, which denote how much the property p contributes to common features of S 1 and S 2, distinctive features of S 1 and distinctive features of S 2, respectively. In what follows we would see how di↵ erent ways of defining properties in OWL influence the calculation of these values. We consider equal the properties defined with owl:EquivalentProperty.
We start from three kinds of value restriction declarations: (i) owl:allValuesFrom; (ii) owl:someValuesFrom; (iii) owl:hasValue. Based on how the restrictions on properties are defined for S 1 and S 2, we can distinguish the following six cases: 1. The property p is defined with owl:allValuesFrom for both S 1 and S 2. Let the property p be defined for S 1 with
howl:allValuesFrom rdf:resource=”#A1”i and for S 2 with
howl:allValuesFrom rdf:resource=”#A2”i.
Let a1 (resp. a2) be the number of sub-classes of A1 (resp. A2). If A1 and A2 are equal classes or declared equivalent with owl:equivalentClass or A1 is a subclass 1 1 1 of A2, then cfp = . Otherwise df1p = and df2p = .
(a1 + 1) a1 + 1 a2 + 1 2. The property q is defined with owl:someValuesFrom both for S 1 and S 2. Let the property q be defined for S 1 with
howl:someValuesFrom rdf:resource=”#B1”i and for S 2 with
howl:someValuesFrom rdf:resource=”#B2”i.
Let b1 (resp. b2) be the number of sub-classes of B1 (resp. B2) and w be the number of classes in the whole domain. If B1 and B2 are equal classes or declared equivalent with owl:equivalentClass or B1 is a subclass of B2, then 1 1 1 cfq = . Otherwise df1q = and df2q = .
(b1 + 1)w (b1 + 1)w (b2 + 1)w 3. Let property r be defined for S 1 with
howl:hasValue rdf:resource=”#V1”i and for S 2 with
howl:hasValue rdf:resource=”#V2”i If V1 and V2 are the same values or declared same with owl:sameAs, then cfq = 1. Otherwise df1q = 1 and df2q = 1. 4. If the property t is defined for S 1 with
howl:hasValue rdf:resource=”#V3”i and for S 2 with howl:allValuesFrom rdf:resource=”#A3”i, and if V3 is an instance of A3 or one of its subclasses, then cft = 1. Otherwise, if a3 is the number of sub-classes of A3, then dft1 = 1 and dft2 = 1 . a3 + 1 5. If the property x is defined for S 1 with
howl:hasValue rdf:resource=”#V4”i and for S 2 with
howl:someValuesFrom rdf:resource=”#B3”i and if V4 is an instance of B3 or one of its subclasses, then cfx = 1. Otherwise, if b3 is the number of sub-classes of B3 and if w is the number of classes in the whole domain, then df1x = 1 and df2x = 1 .
(b3 + 1)w 6. If the property y is defined for S 1 with
howl:allValuesFrom rdf:resource=”#A4””i and for S 2 with
howl:someValuesFrom rdf:resource=”#B4””i and if a4 (resp. b4) is the number of sub-classes of A4 (resp. B4) and w is the number of classes in the whole domain, then cfy = (a4 + 1)(1b4 + 1)w , dfy1 = a41+ 1 and dfy2 = 1 .
(b4 + 1)w
Next we consider three kinds of cardinality restriction declarations: (i) minCardinality; (ii) maxCardinality; (iii) cardinality. We can distinguish the following cases: 1. If the property f is defined with owl:maxCardinality for both S 1 and S 2, and it has value m in S 1 and value n in S 2, where m n, then cf f = n 1 1 , df1f = 0 and df2f = n m. The case when m n is analogous. 2. If the property g is defined with owl:minCardinality for both S 1 and S 2, the values for this restriction would not contribute to common and distinctive features, since each of these restrictions can have infinitely many values. It only contributes to similarity calculation if it is declared together with owl:maxCardinality restriction, which is then the following case. 3. If the property h is defined with owl:cardinality for both S 1 and S 2, and it has value m in S 1 and value n in S 2, then if m = n cf f = 1. Otherwise, if m < n then df1f = 0 and df2f = n m. The case when m > n is analogous.
Of course, the subclass relation should be taken into account, hence providing each class with the property definitions inherited from parent classes.
Finally, to calculate all common and distinctive features of S 1 and S 2 we repeat the above process for each property defined for S 1 and S 2, obtaining: cf(S 1, S 2) = ⌃ inpp=1cfpip + ⌃ inqq=1cfqiq + ⌃ inrr=1cfrir + ⌃ intt=1cftit + ⌃ inxx=1cfxix + ⌃ inyy=1cfyiy + ⌃ n f
i f =1cf fi f + ⌃ ingg=1cfgig + ⌃ inhh=1cfhih df(S 1) = ⌃ inpp=1df1pip + ⌃ inqq=1df1qiq + ⌃ inrr=1dfr1ir + ⌃ intt=1dft1it + ⌃ inxx=1df1xix
+ ⌃ inyy=1dfy1iy + ⌃ inff=1df1fi f + ⌃ ingg=1df1gig + ⌃ inhh=1df1hih df(S 2) = ⌃ inpp=1df2pip + ⌃ inqq=1df2qiq + ⌃ inrr=1dfr2ir + ⌃ intt=1dft2it + ⌃ inxx=1df2xix
+ ⌃ inyy=1dfy2iy + ⌃ inff=1df2fi f + ⌃ ingg=1df2gig + ⌃ inhh=1df2hih where np (resp. nq, nr, nt, nx, ny, n f , ng, nh) is the number of properties defined in each of the possible ways explained above. Finally, we calculate the similarity between two entities S 1 and S 2 defined with restrictions using the formula (2): sim(S 1, S 2) = .
Another feature we want to take into account is the presence of equivalent classes, even though they are not defined as restrictions. We assume that two classes declared equivalent with owl:equivalentClass have similarity based on properties equal to 1.
As far as individuals are concerned (instances of the classes) we simply compare the property-value pairs for each instance. If the property p has h0 di↵ erent values in S 1 and h00 di↵ erent values in S 2, and we denote by k the number of times S 1 and S 2 have k2 h0 k h00 k the same value for p, then cfp = , df1p = and df2p = . We repeat this for h0h00 h0 h00 every property p1, . . . , pk used to describe the given instance. Finally, for instances of classes we obtain: npk cf(S 1, S 2) = ⌃ inpp11=1cfpip1 + . . . + ⌃ ipk =1cfpipk df1(S 1, S 2) = ⌃ inpp11=1df1pip1 + . . . + ⌃ inppkk=1df1pipk df1(S 1, S 2) = ⌃ inpp11=1df2pip1 + . . . + ⌃ inppkk=1df2pipk .
When defining a certain shape, not all the properties have the same importance in di↵ erent contexts. For example, in one context two shapes would be regarded similar if they have similar number of angles and edges, in another one if they are of similar size or if they are both concave or convex. In the above presented approach, it is possible to account for relevance of properties by providing the relevance factors Ripp , ip = 1, . . . , np, for each property p. Relevance factors can be either given as a-priori expert values or gathered as user preferences. In this way, some properties become more important than the others and the formula for calculating the mutual similarity between shapes S 1 and S 2 becomes: simr(S 1, S 2) =
cfr(S 1, S 2) dfr(S 1) + dfr(S 2) + cfr(S 1, S 2) where cfr(S 1, S 2) = ⌃ inpp=1Rip cfpip + . . . + ⌃ ih=1Rih cfhih
nh dfr(S 2). and similarly for dfr(S 1) and
When using ontologies to represent domain knowledge, not always it is convenient to represent shapes in an exhaustive hierarchy. It might be desirable to single our certain properties of shapes and then categorize them having these properties in mind. This is possible if shapes are defined as property restrictions on classes, both on value and cardinality. Representing shapes as property restrictions makes it possible to introduce a very natural similarity measure based on properties. This measure changes depending on the context in which it is being used, making it possible to give more relevance to certain properties in di↵ erent situations. Apart from modeling shapes as property restrictions on classes, this approach would bring new insights into modeling forms and patterns as well, as it avoids strict categorizations, providing a flexible environment for expressing various features of complex forms.
The presented technique for calculating property-based similarity was first used
in [