Design Ontology

Ontologies and context modeling for the Web of Things

Suparna De , ... Klaus Moessner , in Managing the Web of Things, 2017

1.4.2.2 IoT-Enabled e-Learning

The IMS Learning Design (IMS-LD) ontology [59] provides a semantic representation of learning resources and smart objects, while taking into account the learners activities. The ontology defines Learning Objects as addressable digital or physical learning resources, which could take the form of Web resources or physical resources attached with IoT devices such as sensors, actuators or tags. Smart Learning Objects are abstracted as virtual objects which have properties describing their functionalities, location and status. The Learning Record Store models the data collected as a result of the learners activity and use of the Learning Objects. The associated xAPI ontology adds semantic meaning to the collected data.

A different perspective is captured in the u-learning object model [31], which captures the relationships between the learner, the learning resources and the educational content. The core concept is that of a service object that links to the Learner, Device object and Content object classes. The Content object can be text/image/video/audio and is further defined through metadata such as an object profile, attribute container, time and location.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128097649000020

Constructing Design-Informing Models

Rex Hartson , Partha S. Pyla , in The UX Book, 2012

6.6.5 Information Object Model

Information objects are work domain objects shared by users and the system. As internally stored application objects, information objects are hugely important in the operation and design of a system. These are mainly the entities that move through the workflow in the flow model. These are the entities within an application that are operated on by users; they are searched and browsed for, accessed and displayed, modified and manipulated, and stored back again.

In action-object task names, such as "add appointment," the object (appointment) is often an information object. They are connected directly to the design ontology that drives the bread and butter of most domain-complex system designs. They show up as objects of user actions in usage scenarios and other task descriptions and drive design questions such as how will users access the objects and how will we represent them to users in displays, as well as how will users do the operations to manipulate these application objects?

Design Ontology

Design ontology is a description of all the objects and their relationships, users, user actions, tasks, everything surrounding the existence of a given aspect of a design.

In a calendar application, for example, appointments will be objects that are created and manipulated by users. As another simple example, suppose a user draws a circle with a graphics-drawing package. Data representing the circle are stored by the system, the user can call it up and the system will display it, and the user can manipulate and modify it and save it back in the system.

Most information objects have defining attributes. A calendar appointment has date, time, subject, and so on; a graphical circle has a radius, location, color, and so on. Start the information object model by compiling information objects identified in the contextual data. Sketch an outline or list of information objects, their attributes, and the relationships among them.

Example: Identifying Information Objects and Attributes in MUTTS

The two-word goal of the main task of the ticket seller work roles is "sell tickets." Within this goal, the term "tickets" identifies a principal information object in the system. We know that a ticket is associated with an event, another information object, which in turn is linked to attributes, such as event date, time, venue, and so on. We also know that each event object is associated with descriptive attributes, such as genre, to support customer user searching and browsing.

Analyzing scenarios to identify ontology

As usage stories, scenarios tie together many kinds of design-informing models. They help you identify information objects and how they are manipulated and by which work roles. To see links with other design-informing models, you can tag or highlight words and phrases occurring in scenarios with the type of design element they represent. You can identify and label the components of design scenarios, such as tasks, actions, user interface objects, user roles, user experience goals, user classes, user characteristics, application information objects, system data objects, and work context.

Example: Scenario Analysis to Help Identify Ontological Elements of the Ticket Kiosk System

We have highlighted (with italics and color) some of the ontological elements of the example scenario for the Ticket Kiosk System given earlier.

On cellphone and email over a day or two, Priya and a group of her friends agree to take in some entertainment together on the coming weekend. They agree to meet at the Ticket Kiosk System kiosk at the library bus stop at 5:30   PM on Friday. Some walk to the kiosk from nearby, while others avail themselves of the convenience of the bus. The group is in a festive mood, looking forward to sharing some fun over the weekend.

Priya steps up to the kiosk and sees a "Welcome" screen with an advertisement for a movie scrolling at the top and text that says "What kind of even information would you like to see?," followed by several touchscreen buttons with labels on the left-hand side such as "Browse by event type," "Browse by venue/location," and "Event calendar: Browse by date." On the right-hand side there are buttons for specific types of events, such as "Sports," "Concerts," "Movies," "Special features," etc.

Because they are looking for something specifically for the next night, she touches the "Event calendar" button, looking for events such as movies, concerts, plays, fairs, or even a carnival for Saturday night. After browsing for a while and talking among themselves, they want to go to a concert. Priya touches the "Concerts" button, and they are presented with the subcategories Rock, Classical, Folk, and Pop. They choose to go with pop concerts and Priya touches that button. From among several choices, they finally decide on a concert called "Saturday Night at the Pops" playing at The Presidium.

▪

Cellphone and email refer to methods of communicating with family and friends outside the system

▪

Priya is the name of a person in the customer/user role

▪

a group of her friends refers to other roles, customers who are probably not direct users

▪

library bus stop refers to a location of use (of a kiosk), part of the work context

▪

5:30   PM on Friday refers to a time of use (a time when the kiosk is open but the old MUTTS would not have been open), also part of the work context

▪

festive mood, looking forward to sharing some fun over the weekend refers to an emotional state of mind of the users, expressing an expectation to be met by the product, a subtle part of the work context

▪

"Welcome" screen with an advertisement for a movie scrolling at the top is a design idea for user interface objects

▪

touchscreen buttons are possible user interface objects

▪

"Browse by venue/location" is a suggested button label, which also indicates a user task

▪

looking for something specifically for the next night is a user task

▪

looking for events such as movies, concerts, plays, fairs, or even a carnival for Saturday night is a combination of user tasks

▪

"Concerts," Rock, Classical, Folk, and Pop are names of categories of information/application objects

And so on. Can you identify others? The idea of identifying these different entities within scenarios is that they help pick out types and instances of design-informing models and help identify ontological objects and tie them together in the threads of design scenarios in ways that directly inform designing.

Exercise

See Exercise 6-9, Identifying Information Objects for Your System

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123852410000063

27th European Symposium on Computer Aided Process Engineering

Sawitree Kalakul , ... Rafiqul Gani , in Computer Aided Chemical Engineering, 2017

4 Conclusion

A computer-aided framework for design of chemical products has been developed and used as the architecture for the ProCAPD software. The model libraries, the structured databases and the generic workflow are integrated through the product design ontology developed to represent the associated knowledge. The use of the framework has been highlighted through 2 representative case studies involving tailor-made jet-fuels and microcapsules for controlled release of a pesticide. It helps to reduce the search space and provides promising chemical candidates that are competitive as well as economic and environmentally feasible, satisfying product performance specifications and making it more flexible and capable of solving a wide range of product design problems.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780444639653501653

Tools For Chemical Product Design

S. Kalakul , ... R. Gani , in Computer Aided Chemical Engineering, 2016

5 Conclusion

A computer-aided framework for design of chemical products has been developed and used as the architecture for the VPPD-Lab software. The model libraries, structured databases, and generic workflow are integrated through the product design ontology developed to represent the associated knowledge ( Kalakul et al., 2015). The software is able to handle the complexity of product design and analysis problems, in terms of models, calculation algorithms, use of databases, and the various problem-specific solution strategies. The application of the product analysis template is highlighted through the stability check of solvent mixtures. The template has potential to screen feasible binary mixtures that are miscible. In addition, the application of the product design template is highlighted through case studies involving mixture/blend design of a jet fuel and a lubricant as blended liquid products and insect repellent lotion as a formulation product. The product design template is able to handle the large mixed-integer nonlinear problem formulated to design the three products. It helps to reduce the search space and provides promising chemical candidates that are competitive and environmentally feasible, making it more flexible and capable of solving a wide range of product design problems. Therefore, VPPD-Lab enhances the future development of chemical product design as huge amounts of data, models, knowledge, methodologies, and algorithms are integrated and managed in a systematic and efficient way, increasing the possibility to capture past experiences and provide better guidelines for future chemical products (Gani, 2004). However, despite the recent advances, with the currently available methods and tools, only a small percentage of chemical product design problems can be solved. Much work and concerted efforts are needed in the area of property modeling and their integration with data and design tools that incorporate data models in multidisciplinary solution approaches to cover a wider range of chemical-based products of significance.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780444636836000034

26th European Symposium on Computer Aided Process Engineering

Sawitree Kalakul , ... Rafiqul Gani , in Computer Aided Chemical Engineering, 2016

4 Conclusion

A computer-aided framework for design of chemical products has been developed and used as the architecture for the VPPD-Lab software. New templates (novel pure, mixed and blended products) that are employed through a generic workflow have been added to the software. The model libraries, the structured databases and the generic workflow are integrated through the product design ontology developed to represent the associated knowledge. The use of the framework has been highlighted through three representative case studies involving tailor-made jet-fuels, refrigeration fluid-cycle design and a mixture/blend design problem involving lubricant design. The product design template is able to handle, among others, the mathematical programming solution approach to design the three products. The tool helps to reduce the search space and provides promising product candidates that are competitive and are economic and environmentally feasible, making it more flexible and capable of solving a wide range of product design problems.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780444634283503957

11th International Symposium on Process Systems Engineering

Heinz A. Preisig , in Computer Aided Chemical Engineering, 2012

3 Discussion

The concept of ontology can be directly projected into chemical engineering. For example we can define basic operations as elements of a plant ontology and construct new plants by generating different combinations of them. This would be a substitute of our old "bag of tricks", enabling a logical formal handling of the information and for example generate combinations automatically or in an optimal way, given a measure for quality of the design, a process which is likely to enable us to generate a very wide range of combinations that we today term as "intensified processes". So this ontology would serve in the first place as our design ontology.

Collecting the theoretical pieces of chemical engineering into an ontology, capturing the basics of physical behaviour, adding the chemistry and the biology, yields a formal body of information to be used for constructing models for the processes. Obviously there is a close relation between the design ontology mentioned above and the modelling ontology, though in a quite different form, with the modelling ontology providing detailed process information.

The ontology concept applies equally well to the information processing and handling framework. Here we have a model for the plant design, plant control, operations design, plant realisation, product planning and product information as well as knowledge exchange. This ontology captures the different processes associated with design and operations on the different levels.

By clearly separating process ontology, from math model ontology and information handling ontology, we enable an integrated model-based computational engineering approach covering the range from process design to process realisation and process operations. The interlinking reduces the time from idea to realisation in all aspects whilst reducing the costs and increasing the efficiency. This in turn enables also the testing of many more alternatives in the same time, increasing the chance for finding a better solution, in terms of any objectives one may have in mind: profit, inter-operability, embedding in the environment, ecology and the like.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B978044459506550167X

Mental Models and Conceptual Design

Rex Hartson , Partha S. Pyla , in The UX Book, 2012

8.2.2 Designer's Mental Model

Sometimes called a conceptual model (Johnson & Henderson, 2002, p. 26), the designer's mental model is the designer's conceptualization of the envisioned system—what the system is, how it is organized, what it does, and how it works. If anyone should know these things, it is the designer who is creating the system. But it is not uncommon for designers to "design" a system without first forming and articulating a mental model.

The results can be a poorly focused design, not thought through from the start. Often such designs proceed in fits and starts and must be retraced and restarted when missing concepts are discovered along the way. The result of such a fuzzy start can be a fuzzy design that causes users to experience vagueness and misconceptions. It is difficult for users to establish a mental model of how the system works if the designer has never done the same.

As shown in Figure 8-2, the designer's mental model is created from what is learned in contextual inquiry and analysis and is transformed into design by ideation and sketching.

Figure 8-2. Mapping the designer's mental model to the user's mental model.

Johnson and Henderson (2002, p. 26) include metaphors, analogies, ontological structure, and mappings between those concepts and the task domain or work practice the design is intended to support. The closer the designer's mental model orientation is to the user's work domain and work practice, the more likely users will internalize the model as their own. To paraphrase Johnson and Henderson's rule for relating the designer's mental model to the final design: if it is not in the designer's mental model, the system should not require users to be aware of it.

Metaphor

A metaphor is an analogy used in design to communicate and explain unfamiliar concepts using familiar conventional knowledge. Metaphors control complexity by allowing users to adapt what they already know in learning how to use new system features.

Designer's mental model in the ecological perspective: Describing what the system is, what it does, and how it works within its ecology

Mental models of a system can be expressed in any of the design perspectives of Chapter 7. In the ecological perspective, a designer's mental model is about how the system or product fits within its work context, in the flow of activities involving it and other parts of the broader system. In Norman's famous book, The Design of Everyday Things, he describes the use of thermostats (Norman, 1990, pp. 38–39) and how they work. Let us expand the explanation of thermostats to a description of what the system is and what it does from the perspective of its ecological setting.

Design Ontology

Design ontology is a description of all the objects and their relationships, users, user actions, tasks, everything surrounding the existence of a given aspect of a design.

First, we describe what it is by saying that a thermostat is part of a larger system, a heating (and/or cooling) system consisting of three major parts: a heat source, a heat distribution network, and a control unit, the latter being the thermostat and some other hidden circuitry. The heat source could be gas, electric, or wood burning, for example. The heat distribution network would use fans or air blowers to send heated or cooled air through hot air ducts or a pump would send heated or cooled water through subfloor pipes.

Next, we address what it does by noting that a thermostat is for controlling the temperature in a room or other space. It controls heating and cooling so that the temperature stays near a user-settable value—neither too hot or too cold—keeping people at a comfortable temperature.

Designer's mental model in the interaction perspective: Describing how users operate it

In the interaction perspective, a designer's mental model is a different view of an explanation of how things work; it is about how a user operates the system or product. It is a task-oriented view, including user intentions and sensory, cognitive, and physical user actions, as well as device behavior in response to these user actions.

In the thermostat example, a user can see two numerical temperature displays, either analog or digital. One value is for the current ambient temperature and the other is the setting for the target temperature. There will be a rotatable knob, slider, or other value-setting mechanism to set the desired target temperature. This covers the sensory and physical user actions for operating a thermostat. User cognition and proper formation of intentions with respect to user actions during thermostat operation, however, depend on understanding the usually hidden explanation of the behavior of a thermostat in response to the user's settings.

Most thermostats, as Norman explains (1990, pp. 38–39), are binary switches that are simply either on or off. When the sensed ambient temperature is below the target value, the thermostat turns the heat on. When the temperature then climbs to the target value, the thermostat turns the heat source off. It is, therefore, a false conceptualization, or false mental model, to believe that you can make a room warm up faster by turning the thermostat up higher.

The operator's manual for a particular furnace unit would probably say something to the effect that you turn it up and down to make it warmer or cooler, but would probably fall short of the full explanation of how a thermostat works. But the user is in the best position to form effective usage strategies, connecting user actions with expected outcomes, if in possession of this knowledge of thermostat behavior.

There are at least two possible design approaches to thermostats, then. The first is the common design containing a display of the current temperature plus a knob to set the target temperature. A second design, which reveals the designer's mental model, might have a display unit that provides feedback messages such as "checking ambient temperature," "temperature lower than target; turning heat on," and "temperature at desired level; shutting off." This latter design might suffer from being more complex to produce and the added display might be a distraction to experienced users. However, this design approach does help project the designer's mental model through the system design to the user.

Designer's mental model in the emotional perspective: Describing intended emotional impact

In the emotional perspective, the mental model of a design it about the expected overarching emotional response. Regarding the thermostat example, it is difficult to get excited about the emotional aspects of thermostats, but perhaps the visual design, the physical design, how it fits in with the house décor, or the craftsmanship of its construction might offer a slight amount of passing pleasure.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123852410000087

Ontologies and Semantics

Jules J. Berman Ph.D., M.D. , in Principles of Big Data, 2013

Choosing a Class Model

The simple and fundamental question "Can a class of objects have more than one parent class?" lies at the heart of several related fields: database management, computational informatics, object-oriented programming, semantics, and artificial intelligence (see Glossary item, Artificial intelligence). Computer scientists are choosing sides, often without acknowledging the problem or fully understanding the stakes. For example, when a programmer builds object libraries in the Python or the Perl programming languages, he is choosing to program in a permissive environment that supports multiclass object inheritance. In Python and Perl, any object can have as many parent classes as the programmer prefers. When a programmer chooses to program in the Ruby programming language, he shuts the door on multiclass inheritance. A Ruby object can have only one direct parent class. Most programmers are totally unaware of the liberties and restrictions imposed by their choice of programming language until they start to construct their own object libraries or until they begin to use class libraries prepared by another programmer.

In object-oriented programming, the programming language provides a syntax whereby a named method is "sent" to data objects, and a result is calculated. The named methods are functions and short programs contained in a library of methods created for a class. For example, a "close" method, written for file objects, typically shuts a file so that it cannot be accessed for read or write operations. In object-oriented languages, a "close" method is sent to an instance of class "File" when the programmer wants to prohibit access to the file. The programming language, upon receiving the "close" method, will look for a method named "close" somewhere in the library of methods prepared for the "File" class. If it finds the "close" method in the "File" class library, it will apply the method to the object to which the method was sent. In simplest terms, the specified file would be closed.

If the "close" method were not found among the available methods for the "File" class library, the programming language would automatically look for the "close" method in the parent class of the "File" class. In some languages, the parent class of the "File" class is the "Input/Output" class. If there were a "close" method in the "Input/Output" class, the method would be sent to the "File" Object. If not, the process of looking for a "close" method would be repeated for the parent class of the "Input/Output" class. You get the idea. Object-oriented languages search for methods by moving up the lineage of ancestral classes for the object instance that receives the method.

In object-oriented programming, every data object is assigned membership to a class of related objects. Once a data object has been assigned to a class, the object has access to all of the methods available to the class in which it holds membership and to all of the methods in all the ancestral classes. This is the beauty of object-oriented programming. If the object-oriented programming language is constrained to single parental inheritance (e.g., the Ruby programming language), then the methods available to the programmer are restricted to a tight lineage. When the object-oriented language permits multiparental inheritance (e.g., Perl and Python programming languages), a data object can have many different ancestral classes spread horizontally and vertically through the class libraries.

Freedom always has its price. Imagine what happens in a multiparental object-oriented programming language when a method is sent to a data object and the data object's class library does not contain the method. The programming language will look for the named method in the library belonging to a parent class. Which parent class library should be searched? Suppose the object has two parent classes, and each of those two parent classes has a method of the same name in their respective class libraries? The functionality of the method will change depending on its class membership (i.e., a "close" method may have a different function within class "File" than it may have within class "Transactions" or class "Boxes"). There is no way to determine how a search for a named method will traverse its ancestral class libraries; hence, the output of a software program written in an object-oriented language that permits multiclass inheritance is unpredictable.

The rules by which ontologies assign class relationships can become computationally difficult. When there are no restraining inheritance rules, a class within the ontology might be an ancestor of a child class that is an ancestor of its parent class (e.g., a single class might be a grandfather and a grandson to the same class). An instance of a class might be an instance of two classes, at once. The combinatorics and the recursive options can become computationally difficult or impossible.

Those who use ontologies that allow multiclass inheritance will readily acknowledge that they have created a system that is complex and unpredictable. The ontology expert justifies his complex and unpredictable model on the observation that reality itself is complex and unpredictable (see Glossary item, Modeling). A faithful model of reality cannot be created with a simple-mined classification. With time and effort, modern approaches to complex systems will isolate and eliminate computational impedimenta; these are the kinds of problems that computer scientists are trained to solve. For example, recursiveness within an ontology can be avoided if the ontology is acyclic (i.e., class relationships are not permitted to cycle back onto themselves). For every problem created by an ontology, an adept computer scientist will find a solution. Basically, ontologists believe that the task of organizing and understanding information no longer resides within the ancient realm of classification.

For those nonprogrammers who believe in the supremacy of classifications over ontologies, their faith has nothing to do with the computational dilemmas incurred with multiclass parental inheritance. They base their faith on epistemological grounds—on the nature of objects. They hold that an object can only be one thing. You cannot pretend that one thing is really two or more things simply because you insist that it is so. One thing can only belong to one class. One class can only have one ancestor class; otherwise, it would have a dual nature. Assigning more than one parental class to an object is a sign that you have failed to grasp the essential nature of the object. The classification expert believes that ontologies (i.e., classifications that permit one class to have more than one parent class and that permit one object to hold membership in more than one class) do not accurately represent reality.

At the heart of classical classification is the notion that everything in the universe has an essence that makes it one particular thing, and nothing else. This belief is justified for many different kinds of systems. When an engineer builds a radio, he knows that he can assign names to components, and these components can be relied upon to behave in a manner that is characteristic of its type. A capacitor will behave like a capacitor, and a resistor will behave like a resistor. The engineer need not worry that the capacitor will behave like a semiconductor or an integrated circuit.

What is true for the radio engineer may not hold true for the Big Data analyst. In many complex systems, the object changes its function depending on circumstances. For example, cancer researchers discovered an important protein that plays a very important role in the development of cancer. This protein, p53, was considered to be the primary cellular driver for human malignancy. When p53 mutated, cellular regulation was disrupted, and cells proceeded down a slippery path leading to cancer. In the past few decades, as more information was obtained, cancer researchers have learned that p53 is just one of many proteins that play some role in carcinogenesis, but the role changes depending on the species, tissue type, cellular microenvironment, genetic background of the cell, and many other factors. Under one set of circumstances, p53 may play a role in DNA repair, whereas under another set of circumstances, p53 may cause cells to arrest the growth cycle. 47,48 It is difficult to classify a protein that changes its primary function based on its biological context.

Simple classifications cannot be built for objects whose identities are contingent on other objects not contained in the classification. Compromise is needed. In the case of protein classification, bioinformaticians have developed GO, the Gene Ontology. In GO, each protein is assigned a position in three different systems: cellular component, biological process, and molecular function. The first system contains information related to the anatomic position of the protein in the cell (e.g., cell membrane). The second system contains the biological pathways in which the protein participates (e.g., tricarboxylic acid cycle), and the third system describes its various molecular functions. Each ontology is acyclic to eliminate the occurrences of class relationships that cycle back to the same class (i.e., parent class cannot be its own child class). GO allows biologists to accommodate the context-based identity of proteins by providing three different ontologies, combined into one. One protein fits into the cellular component ontology, the biological process ontology, and the molecular function ontology. The three ontologies are combined into one controlled vocabulary that can be ported into the relational model for a Big Data resource. Whew!

As someone steeped in the ancient art of classification, and as someone who has written extensively on object-oriented programming, I am impressed, but not convinced, by arguments on both sides of the ontology/classification debate. As a matter of practicality, complex ontologies are not successfully implemented in Big Data projects. The job of building and operating a Big Data resource is always difficult. Imposing a complex ontology framework onto a Big Data resource tends to transform a tough job into an impossible job. Ontologists believe that Big Data resources must match the complexity of their data domain. They would argue that the dictum "keep it simple, stupid" only applies to systems that are simple at the outset (see Glossary item, KISS). I would comment here that one of the problems with ontology builders is that they tend to build ontologies that are much more complex than reality. They do so because it is actually quite easy to add layers of abstraction to an ontology, without incurring any immediate penalty.

Without stating a preference for single-class inheritance (classifications) or multiclass inheritance (ontologies), I would suggest that when modeling a complex system, you should always strive to design a model that is as simple as possible. The wise ontologist will settle for a simplified approximation of the truth. Regardless of your personal preference, you should learn to recognize when an ontology has become too complex. Here are the danger signs of an overly complex ontology.

1.

Nobody, even the designers, fully understands the ontology model.

2.

You realize that the ontology makes no sense. The solutions obtained by data analysts are absurd, or they contradict observations. The ontologists perpetually tinker with the model in an effort to achieve a semblance of reality and rationality. Meanwhile, the data analysts tolerate the flawed model because they have no choice in the matter.

3.

For a given problem, no two data analysts seem able to formulate the query the same way, and no two query results are ever equivalent.

4.

The time spent on ontology design and improvement exceeds the time spent on collecting the data that populates the ontology.

5.

The ontology lacks modularity. It is impossible to remove a set of classes within the ontology without reconstructing the entire ontology. When anything goes wrong, the entire ontology must be fixed or redesigned.

6.

The ontology cannot be fitted into a higher level ontology or a lower level ontology.

7.

The ontology cannot be debugged when errors are detected.

8.

Errors occur without anyone knowing that the error has occurred.

Simple classifications are not flawless. Here are a few danger signs of an overly simple classification.

1.

The classification is too granular to be of much value in associating observations with particular instances within a class or with particular classes within the classification.

2.

The classification excludes important relationships among data objects. For example, dolphins and fish both live in water. As a consequence, dolphins and fish will both be subject to some of the same influences (e.g., ocean pollutants, water-borne infectious agents, and so on). In this case, relationships that are not based on species ancestry are simply excluded from the classification of living organisms and cannot be usefully examined.

3.

The classes in the classification lack inferential competence. Competence in the ontology field is the ability to infer answers based on the rules for class membership. For example, in an ontology you can subclass wines into white wines and red wines, and you can create a rule that specifies that the two subclasses are exclusive. If you know that a wine is white, then you can infer that the wine does not belong to the subclass of red wines. Classifications are built by understanding the essential features of an object that make it what it is; they are not generally built on rules that might serve the interest of the data analyst or the computer programmer. Unless a determined effort has been made to build a rule-based classification, the ability to draw logical inferences from observations on data objects will be sharply limited.

4.

The classification contains a "miscellaneous" class. A formal classification requires that every instance belongs to a class with well-defined properties. A good classification does not contain a "miscellaneous class" that includes objects that are difficult to assign. Nevertheless, desperate taxonomists will occasionally assign objects of indeterminate nature to a temporary class, waiting for further information to clarify the object's correct placement. In the classification of living organisms, two prominent examples come to mind: the fungal deuteromycetes and the eukaryotic protists. These two groups of organisms never really qualified as classes; each were grab-bag collections containing unrelated organisms that happened to share some biological similarities. Over the decades, these pseudo-classes have insinuated their way into standard biology textbooks. The task of repairing the classification, by creating and assigning the correct classes for the members of these unnatural groupings, has frustrated biologists through many decades and is still a source of some confusion. 49

5.

The classification may be unstable. Simplistic approaches may yield a classification that serves well for a limited number of tasks, but fails to be extensible to a wider range of activities or fails to integrate well with classifications created for other knowledge domains. All classifications require review and revision, but some classifications are just awful and are constantly subjected to major overhauls.

It seems obvious that in the case of Big Data, a computational approach to data classification is imperative, but a computational approach that consistently leads to failure is not beneficial. It is my impression that most of the ontologies that have been created for data collected in many of the fields of science have been ignored or abandoned by their intended beneficiaries. They are simply too difficult to understand and too difficult to implement.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780124045767000034

Supply chain management ontology from an ontology engineering perspective

Andreas Scheuermann , Joerg Leukel , in Computers in Industry, 2014

2.3.3 Ontology design

Ontology design supplies techniques that help the ontology engineer in determining the structure of the ontology. These techniques are more specific than OE methodology and have been influenced by experiences acquired in prior ontology engineering projects. Three types of techniques are proposed in the literature: Ontology Design Principles are overarching quality criteria in terms of desiderata, i.e., desired properties that the ontology should exhibit, though their direct assessment is difficult and achieving them completely is often not possible. Criteria such as clarity, modularity, and minimal encoding bias were adopted from model quality research. Ontology Design Patterns provide basic ontological building blocks for recurring issues of ontology structure, content, and representation [34,35]. The rationale of these patterns is, again, influenced by patterns in software engineering, which first proposed patterns that abstract from a concrete form and "keep recurring in specific nonarbitrary contexts" [36]. Ontology Reuse suggests the adoption of top-level ontologies for specific ontologies [10], e.g., by specializing a top-level ontology's class with a new domain-specific class.

Read full article

URL:

https://www.sciencedirect.com/science/article/pii/S0166361514000438

From science to e-Science to Semantic e-Science: A Heliophysics case study

Thomas Narock , Peter Fox , in Computers & Geosciences, 2012

Abstract

The past few years have witnessed unparalleled efforts to make scientific data web accessible. The Semantic Web has proven invaluable in this effort; however, much of the literature is devoted to system design, ontology creation, and trials and tribulations of current technologies. In order to fully develop the nascent field of Semantic e-Science we must also evaluate systems in real-world settings. We describe a case study within the field of Heliophysics and provide a comparison of the evolutionary stages of data discovery, from manual to semantically enable. We describe the socio-technical implications of moving toward automated and intelligent data discovery. In doing so, we highlight how this process enhances what is currently being done manually in various scientific disciplines. Our case study illustrates that Semantic e-Science is more than just semantic search. The integration of search with web services, relational databases, and other cyberinfrastructure is a central tenet of our case study and one that we believe has applicability as a generalized research area within Semantic e-Science. This case study illustrates a specific example of the benefits, and limitations, of semantically replicating data discovery. We show examples of significant reductions in time and effort enable by Semantic e-Science; yet, we argue that a "complete" solution requires integrating semantic search with other research areas such as data provenance and web services.

Read full article

URL:

https://www.sciencedirect.com/science/article/pii/S0098300411004080