A.2 Semantic network
A.2.2 The structure of Semantic Networks
Semantic networks are composed of “nodes,” “edges,” and “rules.”
(1) Nodes may represent objects (i.e., classes and their instances), or (in the case of the value can be semantic relationship) states that objects may assume.
(2) Edges may be either “constrained” or “unconstrained.”
(3) Rules are both implicit and explicit.
A.2.2.2 Different Kinds of Objects
There are two broad categories of objects: Class and Instance.
· The class is the blueprint, pattern, or template for the category of the same structure items. The items are called instances when they create the using class. It is often referred to the “class as a
‘cookie cutter’” view.
· The class is a thing which make of both the mechanism and the pattern for establishing items. It is the class as example’s view. The example is individual items which are “manufactured” by the creator of using class
· The class is the items established using the specific pattern. For example, the cluster is a set of all the pattern instances.
Tom
Jerry Teach
Man Isa
is Isa
94
A.2.2.3 State
Objects are characterized by using a state. The object state is condition, or the set of circumstances which describe the object. Also, it is not unusual to hear people talk about the “state information”
associative with an object. The bank account state object which may includes a current measure, and the clock object state may be the current time. When we speak the state of a constants (“Tom,”
“Jerry,” and “man”), the predicate symbols corresponds to labels on the arcs of semantic network which is always have two arguments as these cases. Given an object, we are most often referring to that information that we can either query or change via interactions with the operations in the public interface for that object.
(a) Node
(b) Relationship “Is a”
(c) Relationship “has a”
(d) Relationship “A kind of”
(e) Relationship “Value can be”
(f) Relationship “Is a”
Figure 2.3. Relationship
Figure 2.3 (a) shows a node in a semantic network use a rectangle and contain objects or states Is a
<=200 Has
part
A a A kind of
B A Value can be
C
B
A Is a
95 in a specific situation.
Edges
· All edges in a semantic network represent a specific semantic relationship. The semantic relationship specifies the one between the nodes (e.g., the objects) which are found at each end of the edge.
· There are two types of edges in semantic network: “Unconstrained” and “Constrained.” The type of semantic relationship represents whether the edge is constrained, or not.
Unconstrained Edge
Figure 2.3 illustrate its example. An unconstrained edge is depicted as a line with an arrowhead at one end. A text on the line explains a specific unconstrained semantic relationship.
Constrained Edge
A constrained edge is expressed as a line with an arrowhead. The constraint itself is represented as a Boolean expression contained in a box placed on the line. The text on the line identifies a specific constrained semantic relationship. (Some people use an additional arrowhead where the edge enters the constraint box.)
A.2.2.4 Rules
· Semantic networks are governed by “rules”. The rules are restricted on semantic relationships and illustrated by a network.
· A “rule” is either implicit or explicit. “Implicit” is implied in the definition of a semantic relationship. On the other hand, “explicit” means that a rule is explicit when a stated restriction is not directly derivable from the semantics of the relationship. All explicit rules must accompany their respective semantic network.
A.2.2.5 Unconstrained Semantic Relationships
There are three types of unconstrained semantic relationships:
· A kind of
· Value can be
· Is a
Unconstrained semantic relationships are denoted by a labeled directed edge.
Relationship “A kind of”
As Figure 2.3 (d) shows relationship “A kind of” denotes a relationship between a specialization and its immediate generalization.
·Relationship “A kind of” represents what is often referred to as relationship “Is a” in many object-oriented discussions. Unfortunately, “Is a” is seldom used consistently, even within the same discussion.
· A specialization must be differentiated from its immediate generalization. In many instances, these
96
shows up in the semantic network for the specialization, i.e., it exhibits an additional semantic relationship which belongs to a general relationship.
Implicit Rules for relationship “A kind of”
· A node on each end of an edge of relationship “A kind of” must represent a (Meta) class, i.e., one or both nodes cannot represent a non-class instance. (In so-called “classless” object-oriented programming languages, e.g., Self, the objects on each end of the “A kind of” edge is allowed to be a non-class instance.)
· The edge is directed toward (i.e., the arrowhead points to) a node that represents the generalization and the other node represents the specialization of the generalization.
· The specialization inherits all the characteristics of the generalization, i.e., if there are any semantic relationships which hold for the generalization, they also hold for the specialization unless it is altered.
Relationship “Value can be”
As Figure 2.3 (e) shows, relationship “Value can be” denotes relationship between a class, and the values that instances of the class assume, or the relationship between a non-class instance and the values assumes.
· “Values can be” is listed in a schematic form such as 1 .. 10, String (1 .. 300), or “any legal calendar date(1/1/2013,2/2/2012,…).”
· When a schematic form is used, it should be as simple and straightforward as possible.
Implicit Rules for relationship “Value can be”
· An edge is directed toward (i.e., the arrowhead points to) a node representing value(s), and the other node represents an object, or category of objects, which may assume the value(s). (In some uncommon cases, the edge may originate from a node which represents an instance.)
· The value(s) is illustrated explicitly, or as an abstraction, but in any case, all possible values that the object or instances of the (Meta) class must be represented. If a node representing a (Meta) class has more than one “Value can be” relationship (i.e., there are multiple edges representing “Value can be” relationships), the union of those “Value can be” relationships must represent all the values that an instance of that (Meta) class can assume.
Relationship “Is a”
As Figure 2.3 (b) shows, relationship “Is a” denotes contextual usage. Specifically, it denotes a relationship between an object and a specific context in which the object is used.
· Although relationship “Is a” is commonly (and inconsistently) used as it is defined, it does not denote a specialization-generalization relationship. Relationship “Is a” is defined to denote the difference between an object and a specific use of that object, i.e., the usage of an object in a specific context.
· Since relationship “Is a” does not denote a new object, there is no need to produce a separate specification for the specific use of a previously existing object.
Implicit Rules for relationship “Is a”
97
· The nodes on both ends of the edge of relationship “Is a” must illustrate the same category of an object, e.g., a class.
· The edge is directed toward (i.e., the arrowhead points to) the node representing the defined object.
A.2.2.6 Constrained Semantic Relationships
There are three types of constrained semantic relationships:
· Has part
· Has attribute
· Can be a
Constrained semantic relationships are represented by a labeled directed edge with the constraint placed in a box on the directed edge.
Relationship “Has part”
Figure 2.4. Relationship “Has part”
As Figure 2.4 shows, relationship “Has part” denotes a relationship between a composite object and its component objects.
· A composite object can be composed of more than one component object.
· If a composite object inherits one or more component objects, it is permissible to have only one additional component object.
· Objects which represent abstract classes (sometimes referred to as “partial types”) may be shown as having only one component object, since, by definition, they represent incomplete abstractions.
· It is important to note that the relationship “Has part” shows a conceptual composition of an object from an external point of view.
Implicit Rules for relationship “Has part”
· The nodes on both the end of the edge of relationship “Has part” are generally the same category of an object,
· The edge is directed toward (i.e., the arrowhead points to) a node representing the component object and the other node represents the composite object.
· The union of all relationships “Has part” originating from a composite object, plus all of relationships “Has part” originating from that composite object’s generalizations, must completely describe the conceptual (and externally viewed) composition of the composite object.
Rule “part” is different from rule “attribute” which is used to measure or characterize an object’s component.
=1
A Has part
=2 A2
A1
98 Relationship “Has attribute”
Figure 2.5. Relationship “Has attribute”
Relationship “Has attribute” denotes a relationship between an object and its metrics and/or characteristics.
· Relationship “Has attribute” exists because, while some people have no problem saying that an object is composed of (Has part) conceptually tangible items, but some people cannot say that an object is composed of (Has part) intangible items, i.e., metrics and/or characteristics. For example, saying that “a PC [Has part] monitor” is easy, but saying that “a PC [Has part] power level” seems to be unnatural.
· It is very important to remember that, at the code level, parts and attributes are not treated differently. In another way, referring to an object as either a part or an attribute does not change the design, but may make descriptions of objects “easier on the ears.”(“easier on the ears.” is a wrong example describing difference between parts and attributes)
· It is sometimes difficult to distinguish “attributes” from “parts.” In essence, an attribute is a piece of state information which is used to measure (and, occasionally, characterize) an object, and is either maintained by an object, or is derived when required.
· Since attributes denote characteristics or metrics, it is possible for an object to have only one attribute, and no other externally visible parts. This is only the manner in which they differ from parts.
· Attributes represent legitimate objects. Specifically, in isolation, they are not treated differently than other objects, e.g., classes.
Implicit Rules for relationship “Has attribute”
· The nodes on both the end of the edge representing a relationship “Has attribute” are generally the same category of an object, e.g., classes. Nevertheless, for exceptions, meta-classes are allowed to have attributes which are not meta-classes.
· The edge is directed toward (i.e., the arrowhead points to) a node representing a characteristic (metric) object and the other node represents an object possessing that characteristic (metric).
· The union of all relationships “Has attribute” originates from an object’s character, which must completely describe the characteristics (metrics) of the object.
Relationship “Can be a”
Figure 2.6. Relationship “Can be a”
=1 A Has attribute
=2 P2
P1
=1
A Can be a
=2 Y
X
99
As Figure 2.6 shows, relationship “Can be a” denotes a property relationship. Specifically, properties are objects that encapsulate relationships between/among objects.
· Relationship “Can be a” is different from all the other semantic relationships in that it is used to encapsulate relationships between/among objects.
· The encapsulation of relationships between/among objects is referred to as a property. In another words, properties are objects which encapsulate the set of relationships which come into existence when one object is placed in the context of another object.
· We refer to the object which represents the context into which one or more objects may be placed as the context object. Objects which are placed into this context are referred to as component objects.
The object which encapsulates the relationship between the context object and the component objects is referred to as a property object.
· Using the semantic relationships we have defined (i.e., “A kind of”, “Is a”, “Value can be”, “Has part”, “Has attribute”, and “Can be a”), we note that “contexts” can be created with the “Has part”,
“Has attribute”, and the “Can be a” relationships. Said another way, when we say that “a component object is brought into the context of a context object,” we mean that this can be accomplished via a
“Has part”, a “Has attribute”, or a “Can be a” relationship.
· When two, or more, component objects share the same property object, they are said to be polymorphic with respect to the context object. Said another way, they are treated in the same general manner, with respect to the context object, at a given level of abstraction.
· If there are two, or more, component objects, they must all be related in the same logical way, e.g., they are all items which may be placed in a control panel.
· If two, or more, component objects can be present at the same time, constraints are used to show any implied ratios among component objects. (A constraint is also required even if there is only one component object.)
· The constraints in a “Can be a” relationship are context dependent.
Implicit Rules for the relationship “Can be a”
· The nodes on both the end of an edge representing relationship “Can be a” are generally the same category of an object, e.g., classes. We do allow, however, for exceptions, e.g., meta-class properties having components which are not meta-classes.
· The edge is directed toward (i.e., the arrowhead points to) the node representing the component object.
· All component nodes which are connected to the same property node must be capable of being treated in the same general manner.
A.2.2.7 Notes on Semantic Networks
The following should be taken into consideration when using semantic networks:
· There are formal rules for verifying semantic networks;
· Semantic networks provide a static view of the relationships among objects;
· Semantic networks do not show flow of data, nor do they show flow of control;
100
· When documenting an individual object, semantic networks should be limited to the immediate object and those objects within one level of abstraction;
· An analyst or designer may choose to use a large semantic net showing many system-level interrelationships.
Figure 2.7. Flow of Web Mining Process
What is the important information?
User’s input words:
Extract the key word: [important] [information]
What is the important information?
What is the important information
Mining the useful Information from
internet:
Judge noise symbol:
Is noise symbol?
Yes No
Is noise word?
Judge noise word:
Yes No
ASCII code:
32-47, 58-64, 91-96, 123-126 Noise symbol Database
which, or, the, what, to, and, must, is, was, need…
…
Noise word Database
Garbage Box
101