June 5, 2017 at 07:43Concepts: set, type, attribute
Mathematicians are too lazy to explain in the language of the average person what a real number is. It is difficult for the average person to read the icons written by a mathematician, because their meaning is not clear to him. As a result, there is a gap between theory and practice. In theory, mathematicians are well aware of what types of objects are and what attributes are, but going down to practice, we see that few practitioners understand what it is. There are many intuitive concepts, but each of them is more like a religious dogma than knowledge. In this article, I tried to bridge the gap between mathematicians and applicants by explaining the basics of set theory in simple language, without complex icons. For example, are you familiar with the definition of an attribute? I suffered it myself, because I could not find a formal definition of it. And only then Igor Katrichek sent me a link to book E.
In this article, I will give my own, more general definition of an attribute so that you can easily imagine it.
In the last article Structural Modeling. Requirements for the modeler I said that several objects that we think of as a whole exist in our minds, but are not explicitly understood by us. Mathematicians realized this and made it explicit by introducing the concept of multitude for this. I also recalled that the concept of a multitude and the concept of an object- axioms that are not deducible from other concepts. Moreover, the concept of an object is familiar to us, and we have enough experience to work with them, but we get to know a lot at the institute when studying the basics of mathematics, and the idea of them is not so obvious. For those who are looking for the opportunity to learn to represent the set more clearly, I told where we can find a good image - in the representation of designs. In this article I will continue the story about sets, and I will tell what type and attribute are from the point of view of set theory. And most importantly, I will tell you how these concepts are reflected in the models that we are building.
We perceive the world either as space or as time, but we cannot simultaneously imagine both. This imposes its limitations on the language that we use and the models that we build.
For example, a mathematical set does not exist in time, as well as operations on it. This means that it cannot be said that the composition of the set changes in time.
To me this seems like a counterintuitive and non-obvious requirement, but without it we will not be able to perform operations on sets and make comparisons. This means that if we want to describe the many grains of sand in a pile of sand, then we have two ways to do this: for each new composition of grains of sand, introduce a new set, or consider the many temporal parts of grains of sand in the studied pile. The temporal part of a grain of sand is understood as a temporaryand I’m the part of a grain of sand that has the attribute: beginning and end, simulating the presence of this grain of sand in the heap. This set of temporal parts is also called the 4D representation performed in the 4D paradigm. The composition of the grains of sand on a particular point can be obtained from this set by a time of first cut-off: select only the temporal part of the grains of sand that are "relevant" for the time being, that is, those who were in a pile of early and went out of the pile after the selected time .
This simulates the composition of real "physical" sets. But for the current article, such a representation will be rather complicated, and I will return to the usual representation of simple sets “frozen” in time, that is, those that exist “out of time”.
The multitude is much, conceivable as a whole, where much is the composition of the multitude. Consider methods for determining the composition of a set. As we know, the composition of a set can be defined in two ways:
For example, suppose there are two objects in the room among other objects: a white plate and a green marker.
The first way to determine the composition is an enumeration. The
second way is to set the identification conditions.
During the discussion of the last article, I realized that not everyone clearly understands the difference between these two ways of determining the composition of a set. Therefore, I will tell you more about them.
The first method is based on a series of statements: The
plate is part of the set A.
The marker is part of the set A.
No one else is part of the set A. The
second method is the statement in the predicates:
That and only that object in the room that has a yellow sticker, is part of A.
In the first method for describing the composition, any object models can participate. In the second way of describing, object models must have one common attribute, the value of which determines whether an object is included or not in the set. That is, if the object models do not have common attributes, it is impossible to construct identification conditions.
In article discussionit was suggested that the entry into the set itself by means of enumeration also be made an attribute: "it is part of the set A". Thus, those objects that are in the set A have the value of this attribute “yes”. Then it was proposed, based on this attribute, to make a sign for selection in the composition of the same set A: those objects that have the value “yes” are part of the set A. The author of this idea did not notice that as a result of a logical conclusion from these two statements we get two tautologies:
The set A includes those and only those objects that are part of the set A and the
Object is part of the set A if and only if it is part of the set A.
These obvious statements contain neither information about specific objects, nor about A. If I take a plate, then on the basis of this statement it will not be possible to determine whether it belongs to the set A or not.
Therefore, the listing and the rule are two fundamentally different ways of describing the composition of a set, and in mathematics they are indicated as two basic and completely different ways of determining the composition of a set.
By the way, at one time there was a long debate about determining what a function is. This dispute arose because they could not decide which identification rules were considered correct and which were not. As a result, the idea of Dirichlet was accepted.that any rules will be considered correct. That is why I will not swindle at the classification of all the rules, but I will consider only a few that we will need in this context.
In textbooks, the identification rule is often called the selection rule. The term “selection rule” is misleading because it involves some sort of selection operation. And this is a hint that the set can be replenished. But this is not so. Many have a fixed composition. Therefore, it is better not to talk about selection, but about identification. We do not select elements into a multitude, we identify them as elements of a multitude.
Let's see how we determine the composition of many African elephants. I counted four different ways to do this.
Using OWL in our work, we are able to implement the three methods described above for defining a subset:
To understand whether we can implement the fourth method of identification using the type of objects, we consider it in more detail.
To determine the type of "African elephant" we need:
You can do otherwise and take animals living in Africa as a group. Then the unique property that distinguishes African elephants from other African animals is that these animals are elephants.
Total, to give a definition of the type, you need:
Additionally, you can specify:
Objects of the same type differ from other objects of the superset in some unique property. This unique property can be modeled through any conditions on any attributes. But it is not necessary that all values of all attributes coincide, or that the composition of the attributes of all objects of the same type is the same.
Knowing what a type is, one might think that the fourth way of selecting subsets is the same as the second. However, to determine the type, we need to additionally at least specify a specialized name, and as an option, specify other attributes of the type, for example, indicate the reasons for distinguishing this type of object, the history of the term, etc. Using the second method, this is not possible. Therefore, the fourth method is different from the second and is not yet implemented in the modeling standards that I know of.
So, from the point of view of set theory: A
type is a way to isolate a subset from an over-set and assign a new name to the objects of this subset.
If there is no over-set, then the type is considered axiomatic, non-deducible. As I said earlier, the concept of an object and the concept of a set are irreducible concepts, because one cannot specify over-many objects for them.
From the discussion of the article, I realized that there are people who believe that the type of objects and many objects are either related concepts, or the same thing. I’ll try to explain why this is not so. A type is both a rule for identifying objects and the name of these objects. That is, the type simultaneously serves to specialize (or isolate) a subset of the set, and gives a new name to specialized objects.
Each type determines the composition of a set, but not each set corresponds to a type that determines its composition, for example, when we talk about a set whose composition is given by listing its elements, or when we talk about a set whose elements do not have their own name.
It is clear that the rule that sets the set is not the set itself.
It seems to me that from the foregoing it is clear how the concept of “type of objects” differs from the concept of “many objects”.
Often in IP, objects of the same type are modeled using models containing the same set of attributes. Now we can see that this restriction is redundant, since objects of the same type can have different sets of attributes. Such a restriction is caused by technical features of the implementation, but not by the requirements of the subject area.
In IP, the list of objects of the same type is replenished. This suggests the variable composition of the sets that we model. However, it is not. The list of objects that have been registered in the IP is not an exhaustive list of the set. That is, models of not all elements of the set are stored in the IS, but only those that are currently registered. Therefore, when we make a request, its meaning is this: give me all the objects of this type that are currently registered in the IP.
In addition to the fact that an object can be attributed to a certain type of object, there are two more points that should not be forgotten:
The process of objectification and deobjectivization looks like this:
Objectivation
Having an idea of types, we try to find objects of these types in the world around us. Found objects, as a rule, belong to the widest types. For example, if we are talking about an enterprise, then at the first step, the objects found can relate to operations, functions, and objects. Or if we are talking about plants, first we divide them into trees, grass and shrubs. Next, the type of the object is refined by testing various hypotheses. In the refinement process, we try to find a type that will tell us enough about the object so that this knowledge can be effectively used in practice (we are trying to find a narrower type to which this object can be attributed). In the process of refinement, the object model is overgrown with new details. In parallel, we use our knowledge about this object in practice. If the application of this knowledge is successful,
Deobjectivization
However, everything changes: ideas about the world around us change, new knowledge appears, etc. As a result, it turns out that the model of the object ceases to satisfy the utility requirement. And then too narrow specialization of the object becomes his own enemy. The object is reclassified (the application has turned into a requirement), and sometimes it is completely destroyed, as the ether or calorific was destroyed. And then the cycle begins again: the selection of objects, the refinement of knowledge about them, etc.
Objectification:
Let the client come to apply. As long as the application is not executed, we can know its type only with some probability. Therefore, the application of the widest type is registered first. Then, as the details are clarified and in the process of its execution, the application model is overgrown with new attributes. After some time, it becomes clear to what type of applications this application belongs and its final classification takes place.
Deobjectivation:
Suppose we have a typical scenario for finding information on the Internet. Let it say that whenever you need to find the information you need, use such a search engine - a program to find the information you need. Let us use this program repeatedly, each time performing a search operation. There were many such operations during the operation of this program, and all of them were classified as operations of the “information search” type. After some time, it turns out that the search engine performs espionage functions, "draining" user data to people interested in this information. And then it turns out that those operations that this search engine used will now be reclassified from information retrieval operations to data transfer operations to interested parties. But it may well be
We formulate the requirements for the modeler, which is designed for modeling types:
How in the IT industry to implement these requirements without resorting to the database structure? How, without resorting to the data structure, take into account different points of view, add new types of objects, clarify the type of objects, reclassify objects if necessary?
There is one limitation that is present in OWL: in it, the set and type of objects are not different. Because of this, we have limited functionality for modeling object types. However, this functionality is much wider than what other modeling methods give us, because we have the following features:
Let there are many objects. And let the task be to divide this set into seven subsets, each of which is assigned its own color: “red objects”, yellow objects ”. Etc.
Dividing a set into subsets can be done in different ways.
The first method in OWL is implemented by creating seven different classes and specifying the objects that belong to them.
The second method can be implemented in three different ways:
The third method of dividing a set into subsets in IP is modeled in two ways:
It can be seen that the separation using types and attributes is modeled in two cases in the same way, but has different names. Indeed, the possession of an attribute value in OWL is modeled in the following triplet:
# object # attribute # value
Belonging to the class - like this:
# rdf object: type # class
That is, we can say that belonging to a class is simply expressed using a special service attribute defined in the standard - rdf: type.
We state the statement: An
attribute is a way of dividing many objects into subsets. Moreover, each attribute value corresponds to a certain subset whose objects have an attribute with that value.
Each of the three methods of the subset modeling methods listed above has its advantages and disadvantages depending on the context and the chosen implementation method.
If there are few subsets, you can choose any of the listed methods of separation into subsets and any implementation.
If there are many subsets (in the limit it is infinite, for example, when each of the sets groups of objects of the same length), then formally remain:
However, I wrote earlier that each type needs to be given a name. If there are many subsets (infinitely), then giving a name to each of them is unrealistic. Therefore, we do not model such a division using types. We model such division only with the help of an attribute whose range of values will be one of the common sets: a set of real numbers, a set simulating a timeline, a set of natural numbers, a set of lines of finite length, etc. Do you recognize data types?
About how to enter a function on the set of subsets, and not only about it, you can read here .
The third way to implement the attribute is good because with it you can simulate a huge number of subsets (there are a lot of options for writing a string), but the bad thing is that it’s not clear how to know that objects belong to one set: “Red”, red ”, "" Red) "are the values of the same set, or different?
A lot of literature has been written about how to better model subsets, and I will not repeat it here. Just remember that an attribute is a subset model, and a value is an indication of a subset.
In this article, I will give my own, more general definition of an attribute so that you can easily imagine it.
In the last article Structural Modeling. Requirements for the modeler I said that several objects that we think of as a whole exist in our minds, but are not explicitly understood by us. Mathematicians realized this and made it explicit by introducing the concept of multitude for this. I also recalled that the concept of a multitude and the concept of an object- axioms that are not deducible from other concepts. Moreover, the concept of an object is familiar to us, and we have enough experience to work with them, but we get to know a lot at the institute when studying the basics of mathematics, and the idea of them is not so obvious. For those who are looking for the opportunity to learn to represent the set more clearly, I told where we can find a good image - in the representation of designs. In this article I will continue the story about sets, and I will tell what type and attribute are from the point of view of set theory. And most importantly, I will tell you how these concepts are reflected in the models that we are building.
Sets in math and physics
We perceive the world either as space or as time, but we cannot simultaneously imagine both. This imposes its limitations on the language that we use and the models that we build.
For example, a mathematical set does not exist in time, as well as operations on it. This means that it cannot be said that the composition of the set changes in time.
To me this seems like a counterintuitive and non-obvious requirement, but without it we will not be able to perform operations on sets and make comparisons. This means that if we want to describe the many grains of sand in a pile of sand, then we have two ways to do this: for each new composition of grains of sand, introduce a new set, or consider the many temporal parts of grains of sand in the studied pile. The temporal part of a grain of sand is understood as a temporaryand I’m the part of a grain of sand that has the attribute: beginning and end, simulating the presence of this grain of sand in the heap. This set of temporal parts is also called the 4D representation performed in the 4D paradigm. The composition of the grains of sand on a particular point can be obtained from this set by a time of first cut-off: select only the temporal part of the grains of sand that are "relevant" for the time being, that is, those who were in a pile of early and went out of the pile after the selected time .
This simulates the composition of real "physical" sets. But for the current article, such a representation will be rather complicated, and I will return to the usual representation of simple sets “frozen” in time, that is, those that exist “out of time”.
Determination of the composition of the set
The multitude is much, conceivable as a whole, where much is the composition of the multitude. Consider methods for determining the composition of a set. As we know, the composition of a set can be defined in two ways:
- By a direct enumeration of objects selected from some set.
- The rules for identifying objects selected from some set.
For example, suppose there are two objects in the room among other objects: a white plate and a green marker.
- The set A, consisting of these two elements, can be specified by listing: a white plate is part of the set A and a green marker is part of the set A. Nothing else in the room is part of the set A.
- You can do otherwise. You can stick a yellow sticker on the plate and marker and make sure that there are no other stickers in the room. Then we can say that those and only those objects in this room that have a yellow sticker are part of A.
The first way to determine the composition is an enumeration. The
second way is to set the identification conditions.
During the discussion of the last article, I realized that not everyone clearly understands the difference between these two ways of determining the composition of a set. Therefore, I will tell you more about them.
The first method is based on a series of statements: The
plate is part of the set A.
The marker is part of the set A.
No one else is part of the set A. The
second method is the statement in the predicates:
That and only that object in the room that has a yellow sticker, is part of A.
In the first method for describing the composition, any object models can participate. In the second way of describing, object models must have one common attribute, the value of which determines whether an object is included or not in the set. That is, if the object models do not have common attributes, it is impossible to construct identification conditions.
In article discussionit was suggested that the entry into the set itself by means of enumeration also be made an attribute: "it is part of the set A". Thus, those objects that are in the set A have the value of this attribute “yes”. Then it was proposed, based on this attribute, to make a sign for selection in the composition of the same set A: those objects that have the value “yes” are part of the set A. The author of this idea did not notice that as a result of a logical conclusion from these two statements we get two tautologies:
The set A includes those and only those objects that are part of the set A and the
Object is part of the set A if and only if it is part of the set A.
These obvious statements contain neither information about specific objects, nor about A. If I take a plate, then on the basis of this statement it will not be possible to determine whether it belongs to the set A or not.
Therefore, the listing and the rule are two fundamentally different ways of describing the composition of a set, and in mathematics they are indicated as two basic and completely different ways of determining the composition of a set.
By the way, at one time there was a long debate about determining what a function is. This dispute arose because they could not decide which identification rules were considered correct and which were not. As a result, the idea of Dirichlet was accepted.that any rules will be considered correct. That is why I will not swindle at the classification of all the rules, but I will consider only a few that we will need in this context.
In textbooks, the identification rule is often called the selection rule. The term “selection rule” is misleading because it involves some sort of selection operation. And this is a hint that the set can be replenished. But this is not so. Many have a fixed composition. Therefore, it is better not to talk about selection, but about identification. We do not select elements into a multitude, we identify them as elements of a multitude.
Determining the composition of a subset
Let's see how we determine the composition of many African elephants. I counted four different ways to do this.
- You can define them by listing.
- You can stick the sticker on the elephants, and say that those elephants that have a glued sticker are considered African. This is the definition of the composition of a set through an attribute. The attribute will be considered the presence or absence of a sticker.
- You can determine the composition through the intersection of two sets: many elephants and many animals living in Africa.
- You can introduce a concept such as "African elephants."
Using OWL in our work, we are able to implement the three methods described above for defining a subset:
- Explicitly enumerate the objects included in the subset,
- Define an identification rule through any conditions on any attributes, with different operations: from the very fact of possessing the value of an attribute to falling into this certain range
- Define operations on other sets: for example, the set A includes only those objects that are part of the set B and are not included in the set C.
To understand whether we can implement the fourth method of identification using the type of objects, we consider it in more detail.
Modeling a subset using a type
To determine the type of "African elephant" we need:
- The group of objects from which we select objects for a subtype. In this case, this group has a name - this is a group of elephants.
- A unique property in which type objects differ from the rest of the group's objects: they live in Africa.
- Unique name for this type of object
You can do otherwise and take animals living in Africa as a group. Then the unique property that distinguishes African elephants from other African animals is that these animals are elephants.
Total, to give a definition of the type, you need:
- Specify over-many objects.
- Indicate the distinctive features (differential properties) of objects of a given type from group objects.
- Specify the name of objects of this type
Additionally, you can specify:
- The reasons why this type of object has become in demand (differential functional properties of objects of this type
- Benefits of introducing this type of object
- Term history
- Etc.
Objects of the same type differ from other objects of the superset in some unique property. This unique property can be modeled through any conditions on any attributes. But it is not necessary that all values of all attributes coincide, or that the composition of the attributes of all objects of the same type is the same.
Knowing what a type is, one might think that the fourth way of selecting subsets is the same as the second. However, to determine the type, we need to additionally at least specify a specialized name, and as an option, specify other attributes of the type, for example, indicate the reasons for distinguishing this type of object, the history of the term, etc. Using the second method, this is not possible. Therefore, the fourth method is different from the second and is not yet implemented in the modeling standards that I know of.
Concept type
So, from the point of view of set theory: A
type is a way to isolate a subset from an over-set and assign a new name to the objects of this subset.
If there is no over-set, then the type is considered axiomatic, non-deducible. As I said earlier, the concept of an object and the concept of a set are irreducible concepts, because one cannot specify over-many objects for them.
The difference between the type of objects and many objects
From the discussion of the article, I realized that there are people who believe that the type of objects and many objects are either related concepts, or the same thing. I’ll try to explain why this is not so. A type is both a rule for identifying objects and the name of these objects. That is, the type simultaneously serves to specialize (or isolate) a subset of the set, and gives a new name to specialized objects.
Each type determines the composition of a set, but not each set corresponds to a type that determines its composition, for example, when we talk about a set whose composition is given by listing its elements, or when we talk about a set whose elements do not have their own name.
It is clear that the rule that sets the set is not the set itself.
It seems to me that from the foregoing it is clear how the concept of “type of objects” differs from the concept of “many objects”.
Modeling objects of the same type
Often in IP, objects of the same type are modeled using models containing the same set of attributes. Now we can see that this restriction is redundant, since objects of the same type can have different sets of attributes. Such a restriction is caused by technical features of the implementation, but not by the requirements of the subject area.
In IP, the list of objects of the same type is replenished. This suggests the variable composition of the sets that we model. However, it is not. The list of objects that have been registered in the IP is not an exhaustive list of the set. That is, models of not all elements of the set are stored in the IS, but only those that are currently registered. Therefore, when we make a request, its meaning is this: give me all the objects of this type that are currently registered in the IP.
Object Life Cycle
In addition to the fact that an object can be attributed to a certain type of object, there are two more points that should not be forgotten:
- Classification (assigning an object to a particular class, or type of object) is always subjective. The same object from a different point of view may look different. If we are building an extensible domain model, the use of which involves the presence of different stakeholders, then there should be the possibility of modeling the context and different points of view. Moreover, from different points of view, the same object can be assigned to different types.
- Taking into account the life cycle of an object involves not only accounting for changes in the object, but also taking into account changes in our perceptions of this object, since the process of objectification and deobjectivation is ongoing along with the synthesis and analysis.
The process of objectification and deobjectivization looks like this:
Objectivation
Having an idea of types, we try to find objects of these types in the world around us. Found objects, as a rule, belong to the widest types. For example, if we are talking about an enterprise, then at the first step, the objects found can relate to operations, functions, and objects. Or if we are talking about plants, first we divide them into trees, grass and shrubs. Next, the type of the object is refined by testing various hypotheses. In the refinement process, we try to find a type that will tell us enough about the object so that this knowledge can be effectively used in practice (we are trying to find a narrower type to which this object can be attributed). In the process of refinement, the object model is overgrown with new details. In parallel, we use our knowledge about this object in practice. If the application of this knowledge is successful,
Deobjectivization
However, everything changes: ideas about the world around us change, new knowledge appears, etc. As a result, it turns out that the model of the object ceases to satisfy the utility requirement. And then too narrow specialization of the object becomes his own enemy. The object is reclassified (the application has turned into a requirement), and sometimes it is completely destroyed, as the ether or calorific was destroyed. And then the cycle begins again: the selection of objects, the refinement of knowledge about them, etc.
Case studies:
Objectification:
Let the client come to apply. As long as the application is not executed, we can know its type only with some probability. Therefore, the application of the widest type is registered first. Then, as the details are clarified and in the process of its execution, the application model is overgrown with new attributes. After some time, it becomes clear to what type of applications this application belongs and its final classification takes place.
Deobjectivation:
Suppose we have a typical scenario for finding information on the Internet. Let it say that whenever you need to find the information you need, use such a search engine - a program to find the information you need. Let us use this program repeatedly, each time performing a search operation. There were many such operations during the operation of this program, and all of them were classified as operations of the “information search” type. After some time, it turns out that the search engine performs espionage functions, "draining" user data to people interested in this information. And then it turns out that those operations that this search engine used will now be reclassified from information retrieval operations to data transfer operations to interested parties. But it may well be
Type Modeler Requirements
We formulate the requirements for the modeler, which is designed for modeling types:
- It is necessary to be able to model objects of the same type, the composition of the attributes of which does not match
- You must be able to model the rules that distinguish objects into one type
- The need to model other type attributes: the name of objects of a given type, the history of this name, and so on.
- You must be able to simulate different points of view on the same object
- You must be able to simulate the life cycle of an object
- You must be able to model the change in our understanding of the object over time.
How in the IT industry to implement these requirements without resorting to the database structure? How, without resorting to the data structure, take into account different points of view, add new types of objects, clarify the type of objects, reclassify objects if necessary?
Object Modeling with OWL
There is one limitation that is present in OWL: in it, the set and type of objects are not different. Because of this, we have limited functionality for modeling object types. However, this functionality is much wider than what other modeling methods give us, because we have the following features:
- Adding a new set of objects in OWL is no different from adding a new object.
- It may be required that if the type of the object is known, then the model of the object is created with the given attributes known in advance. In this case, after creation, attributes can be either added or deleted. Example: creating an application model, we may require you to specify attribute values (application number, application date, applicant, addressee). You just need to remember that these attributes in OWL exist separately from object types. And one attribute can be used in modeling objects of different sets. This is a fundamental difference from the common programming languages, where the attribute exists only within the framework of one type of object. Another attribute in another type, albeit called the same, will be a different attribute.
- You can demand the opposite: to determine a subset of the modeled object based on the attributes of the model of the object and its belonging to the over-set. To do this, it will be written in the rule that if the model of an object belonging to a certain over-set contains such and such attributes and their values satisfy certain rules, then the object will automatically be assigned to a specific subset. So with the help of the rules the so-called “duck classification” will be implemented. For example, if in the application model there is a value for the attribute “Phone Number”, and “Connection” is the value of the attribute “Type of work performed”, then the application will be automatically classified as an application for connecting a phone number.
Dividing a set into subsets
Let there are many objects. And let the task be to divide this set into seven subsets, each of which is assigned its own color: “red objects”, yellow objects ”. Etc.
Dividing a set into subsets can be done in different ways.
- You can divide a set into disjoint subsets by distributing objects among the subsets by listing them. Create seven subsets and list the objects that belong to each of the subsets.
- For each subset, you can come up with your own subtype. Then the whole set can be divided into seven subsets by introducing seven subtypes: “Type of red objects”, “Type of yellow objects”, etc. Each object can be attributed to one of the listed types and say, for example, this way: the object belongs to the type of red objects.
- You can split a superset using an attribute and its values. For example, you can enter the Color attribute and its seven values: Red, Yellow, and so on. Then the color name will become an adjective for the object and will sound like this: a red object, a yellow object, and so on.
The first method in OWL is implemented by creating seven different classes and specifying the objects that belong to them.
The second method can be implemented in three different ways:
- By creating separate sub-sets united by one type, but the types themselves, as I said earlier, are not modeled. This method is no different from the enumeration separation method.
- Using the reference book “Types of color objects”, the values of which will be objects that model types: “Red objects”, “yellow objects”, etc.
- Using the attribute with the name “object type”, the values of which will have the text form: “Type of red objects”, “Type of yellow objects”, etc.
The third method of dividing a set into subsets in IP is modeled in two ways:
- Using the “Colors” directory, the values of which will be objects modeling the values of attributes: red, yellow, etc.
- Using the attribute with the name "Color", the values of which will have the text form: "red", "yellow" and so on.
It can be seen that the separation using types and attributes is modeled in two cases in the same way, but has different names. Indeed, the possession of an attribute value in OWL is modeled in the following triplet:
# object # attribute # value
Belonging to the class - like this:
# rdf object: type # class
That is, we can say that belonging to a class is simply expressed using a special service attribute defined in the standard - rdf: type.
Concept attribute
We state the statement: An
attribute is a way of dividing many objects into subsets. Moreover, each attribute value corresponds to a certain subset whose objects have an attribute with that value.
Modeling subsets using the attribute
Each of the three methods of the subset modeling methods listed above has its advantages and disadvantages depending on the context and the chosen implementation method.
If there are few subsets, you can choose any of the listed methods of separation into subsets and any implementation.
If there are many subsets (in the limit it is infinite, for example, when each of the sets groups of objects of the same length), then formally remain:
- third way of modeling type and
- The second way to model an attribute.
However, I wrote earlier that each type needs to be given a name. If there are many subsets (infinitely), then giving a name to each of them is unrealistic. Therefore, we do not model such a division using types. We model such division only with the help of an attribute whose range of values will be one of the common sets: a set of real numbers, a set simulating a timeline, a set of natural numbers, a set of lines of finite length, etc. Do you recognize data types?
About how to enter a function on the set of subsets, and not only about it, you can read here .
The third way to implement the attribute is good because with it you can simulate a huge number of subsets (there are a lot of options for writing a string), but the bad thing is that it’s not clear how to know that objects belong to one set: “Red”, red ”, "" Red) "are the values of the same set, or different?
A lot of literature has been written about how to better model subsets, and I will not repeat it here. Just remember that an attribute is a subset model, and a value is an indication of a subset.