NeOn: Lifecycle Support for Networked Ontologies




Скачать 340.61 Kb.
НазваниеNeOn: Lifecycle Support for Networked Ontologies
страница4/9
Дата24.09.2012
Размер340.61 Kb.
ТипДокументы
1   2   3   4   5   6   7   8   9

3.3 Argumentation structures

riprende stato dell'arte, tool e requisiti dallo stato dell'arte (5.7 nell'attuale versione 0.1f), ma finalizza rispetto alla definizione di argumentation structures e situations in ODO. Dire che i rationale delle strutture argomentative non sono trattati qui. Un po' di figure dedicate, esempi e codice da ODO in DL o in OWL astratto

3.4 Design Rationales and Making

più o meno com'è adesso la sezione 2 di 0.1f, ma con narrativa e rimandi rivisti. Occorre aggiungere rimandi a qualcosa dal libro sui design rationales che dovrebbe avere Carola. Dire ancora che qui si parla di design rationales relativi ai pattern prescelti per le specifiche situazioni di scelta dentro le ontologie, che quindi sono collezioni (meglio: configurazioni) di prodotti informativi generati nelle situazioni di scelta. Quando parliamo di sostenibilità, parliamo della combinazione dei vincoli/richieste che provengono da dominio e task, con i vincoli generati dalle scelte progettuali generali, che a loro volta possiamo supporre siano state influenzate da considerazioni sulla stima delle necessità didominioe task. Un po' di figure dedicate, esempi e codice da ODO in DL o in OWL

3.4.1 Background notions

According to the historical survey provided in [REG00], design rationales (DRs) are related to the ways in which organisations capture, preserve and manage their intellectual capital. Currently, DRs constitute an intensively researched topic in a number of disciplines, spanning from mechanical design to software engineering, artificial intelligence, computer-supported cooperative work, and human-computer interaction.

In the literature, a DR has been defined as:

(i) “a representation of the reasoning which has been invested in a design” ([CON91]);

(ii) “an explanation of why an artifact, or some part of an artifact, is designed the way it is” ([LEE91]);

(iii) "a representation for explicitly documenting the reasoning and argumentation that make sense of a specific artifact" (MacLE91);

(iv) “design rationales are the solutions adopted to reach a given goal” (cf. Simon Buckingham-Shum, Design rationale [..]).

According to [REG00], DRs should include all the background knowledge of a creation process, such as deliberating, reasoning, trade-off and decision-making in the design process of an artifact – i.e., all the information that can be crucially valuable to various people who have to deal with the artifact. In the 1980s, this information used to be expressed in terms of specifications and parameters to describe the way the artifact worked, but did not include a description of why it had been designed the way it was. Due to this uncomplete documentation, work teams often needed (and still need) considerable amounts of communication in order to understand others’ previous work when performing maintenance and redesigning activities. Hence, research since then has mainly focused on ways of keeping track of DRs, so that they can be used both to record the history of design process (in order to modify and maintain existing designs, or to design similar artifacts) and to structure design problems (as a basis to explore new design options, and an aid to discussion and reasoning among collaborating designers). Under this respect, DRs are partially related to the 'provenance' functionality (sec. 5.8 ), as the latter has also the purpose of tracking the reasons why a change has occured and to record the history of the design process.

Crucial attention must be paid to the notion of argumentation. According to (MacLE91), DR's analyses are not simply records of the design process, but rather they "are coproducts of design, along with the target artifact being designed. That is to say, documented analyses are themselves artifacts - they are explicit representations that must be created and designed by designers…". A DR represents "a structured space of design alternatives and the considerations for choosing among them - different choices in the design space resulting in different possible artifacts". Hence, a DR "has to be constructed alongside the artifact itself… supporting both the original process of design and subsequent work on redesign and reuse… serving as a vehicle for communication".

3.4.2 Our definition of design rationales

One aim of our work is to provide people involved in the design of ontologies with a way to represent the rationales that characterizes their design decisions. On the basis of the definitions (i)-(iii) of design rationales given in the previous section, we distinguish between solutions adopted and reasons behind such choices, and assume that design rationales represent reasons.

Hence, we define a design rationale (DR) as an explicit statement (or set of statements) which represents the reasons why an object (product) has been (or is being) designed the way it is.

At a very general level, we will then represent design activities as including projects, which in turn include workflows (or coordination patterns) involving argumentation schemas that lead to explicitly formulate (by means of DRs) the motivations for the choice of a specific design-pattern schema.

DRs involve, and can be analyzed along, three dimensions:

content: deals with the objects used or created in order to design the product;

task (or service): is related to the requirements the product is meant to meet;

sustainability: “what use at what cost”, cf. [SHU94]

3.4.3 Ontology Design Rationales

In order to define the notion of DR in the context of ontology design, we introduce the following concepts (see also sec. 4.1.1.):

[GAN05a] defines the concept of information object as a social object (a non physical entity of the social world) which is realized by some (physical) entity. Information objects can express a description (the ontological equivalent of a meaning/conceptualization), can be about any entity, and can be interpreted by an agent. From a communication perspective, an information object can play the role of ‘message’. From a semiotic perspective, it plays the role of ‘expression’. When an information object is used in a process of knowledge production (such as building an ontology or ontology network), to the end of building a new object, we say that it plays a knowledge-resource role in said process; the final produced object, on the other hand, plays the role of knowledge product.

In this sense, any piece of (both formal and non-formal) information that is used for building an ontology or ontology network, including ontologies and ontology networks themselves, is a knowledge resource. Examples of knowledge resources are: ontologies, design patterns, annotations, methodologies, and so on.

Ontology elements, on the other hand, are formal expressions which are (proper) parts of an ontology, e.g. axioms, classes, individuals and relations. Of course, ontology elements (being information objects) can play both the roles of knowledge resources and knowledge products.

An ontology-design operation is an action classified by some functionality (e.g., selection), and carried out according to the method/s described in a functionality description.

An ontology design-pattern schema is an explicit or implicit description including the roles, tasks, and parameters to implement a 'best' practice for an ontology design operation. For example, a design-pattern schema for content creation provides instructions to clone, choose, compose, or specialize an existing ontology or collection of ontology elements. Purely structural patterns have simpler, non-procedural descriptions, which we call ‘skins’ (cf. pf. 4.1.1). Ontology design-pattern schemas are instantiated to design choices (situations) that are the setting for ontology elements and their axioms.

Finally, an argumentation structure is a schema or frame for argumentation primitives, such as e.g. agree/disagree, motivated claim, etc. Such schema defines at least one argumentation role, i.e. a role taken within an argumentation situation, e.g. an axiom that is 'motivated' by a design motivation, or a design choice that is 'agreed upon' (see below).


On the base of such concepts, we define ontology design rationales as follows:


An ontology design rationale is a is a component of an argumentation structure, and is a description of an ontology-design motivation involving design operations, ontology elements, and rational agents or knowledge collectives (the designers)2.


A design motivation is a situation that satisfies both an ontology-design rationale and a functionality description (its method). It comprises in its setting at least one rational agent/knowledge collective, one information object, one design operation on it, and a time interval at which the operation occurs. It is the instantiation of a design rationale in the design of an ontology, and it is a component of an argumentation situation.

A design choice, on the other hand, is a ‘structural’ situation (a state) that includes only components (e.g. ontology elements) and their relations. For example, the occurrence of a subClassOf axiom (which is an ontology element) and its elements as included in a design solution complying to a subClassOf OWL macro. A design choice satisfies a design-pattern schema.

Although design motivations involve operations to materialize a design, we would like to distinguish between design motivations concerning the ‘structure’ of ontologies versus motivations concerning their production, implementation, etc. The first set of motivations will be represented here as ‘ontology design rationales’, while the second set will be possibly considered in future work.

Ontology design can be motivated with reference to task or sustainability criteria (see below), but it is typically motivated with reference to structure and content, i.e. against a choice space created by the use of a pattern (either implicit or explicit) and a rationale that motivates its application.

For example, if a designer is designing an ontology from a flat list of 10 classes, and is willing to apply the subClassOf axiom pattern to a class Dog against those 10 classes, the implicit choice space has a cardinality=10 (9 possible superclasses, or being a top class).

If the rationale of choosing e.g. the axiom Dog subClassOf Canine is that Dog's instances are all Canine's instances, the designer is applying an ‘extensional semantics’ rationale to the pattern employed.

In other words, the design pattern (in the example, the subClassOf axiom pattern) represents the design quality of a certain design solution (in the example, the actual axiom), whose rationale is ‘extensional semantics’, and whose rationale application is the design choice of the Dog subClassOf Canine axiom because all Dog’s instances are also Canine’s instances.

Of course, the choice can be motivated by different rationales, e.g. the axiom Dog subClassOf Canine can be supported by a ‘lexical semantics’ rationale, which could take WordNet hyponymy relation as evidence.

Another rationale is the ‘expertise semantics’ rationale, which could use a poll system against a sample of domain experts voting on the best candidate as Dog's superclass.

Still another rationale is ‘best approximation semantics’ to a repository of content design patterns, so that the best candidate as a superclass may be chosen from an existing content pattern that includes Dog and Canine, with a best similarity match.

Arbitrarily complex rationales can be built to support decision on simple patterns like subClassOf or very complex ones like content pattern composition.

As another, more complex example, a choice can involve two different patterns. E.g. a designer wants to create a relation between A and B, but she is undecided if the relation is A subClassOf B or A partOf B. The two possible choices are not two axioms, but two different axiom patterns, which have their own related choice spaces. The choice space of the designer is the union of those choice spaces, while the rationale is some combination of the rationales pertaining to the different choices.

In practice, the designer can apply:

- an extensional rationale to A subClassOf B: the relative choice space has a cardinality of 4: either all A's instances are all B's instances, or not all, or none (disjointness), or unknown, and

- an ‘intensional’ rationale to A partOf B: the relative choice space has a cardinality of 4: either it is conceivable in the designer’s world to think of all A’s instances as being part of some B’s instance, or it is conceivable in the designer’s world for any A’s instance to be part of any B's instance, or no A's instance can ever be part of any B’s instance, or it is unknown.

The combined rationale is executed against a choice space with a cardinality of 4*4=16, i.e. any combination of one choice from the first set and one choice from the second set: first set: either A subClassOf B, or A overlaps B, or A disjoint B, or unknown(A subClassOf B), and second set: A partOf some B, or A partOf only B, or A partOf exactly 0 B, or unknown(A partOf B).

Choice spaces are defined here as collections of choice spaces, i.e. possible situations resulting from the application of a rationale to one or more design pattern, either architectural (untyped, see the class: architectural-design-pattern), or content (typed, see the class: content-design-pattern).

Ontology design rationales can be very general, as when they work as guidelines for a class of design motivations, as well as very specific, as when they work as criteria for a particular design motivation.

Following the three dimensions of analysis proposed in 2.2, ontology DRs can be of different sorts, and a specific rationale can result as a composition of these sorts:

A first sort, content rationales, are usually data, like attributes, measurement data, natural language evidence, etc., which motivate a choice within a choice space for a design operation. Ideas on how to represent such data into choice spaces are still in evolution, but a possible solution is to reduce choice spaces to design patterns, either focusing on architectural choices (untyped), or content choices (typed). Motivating data will then be fillers of parameters defined within these patterns.

A second sort is task rationales, usually queries (also called competency questions) that motivate a choice within a choice space for a design operation. Motivating queries can be represented as use case descriptions, and can be exploited as unit tests.

A third sort is sustainability rationales, usually pragmatic principles that motivate a choice.

All the concepts described above are formally defined in OWL ontologies which are available at: http://www.loa-cnr.it/ontologies/OD/OntologyDesign.owl.


3.5 Design patterns and choices

qui bisogna fare tutto, perché anche lo stato dell'arte sulle funzionalità e i tool manca. Comunque questo sarà oggetto più specifico di D2.5.1, quindi non ci soffermiamo. Occorre dire che per design patterns intendiamo un sacco di cose: pattern architetturali, macro di linguaggi logici, pattern di contenuto, anti-pattern, etc. Un po' di figure dedicate, esempi e codice da ODO in DL o in OWL astratto

4. Desired Functionalities for Supporting Collaborative Ontology Development

[It would be good if we could refer back to use cases]

1   2   3   4   5   6   7   8   9

Похожие:

NeOn: Lifecycle Support for Networked Ontologies iconThe Use of uml as a Tool for the Formalisation of Standards and the Design of Ontologies in Agriculture

NeOn: Lifecycle Support for Networked Ontologies iconEnterprise Architecting Lifecycle Management

NeOn: Lifecycle Support for Networked Ontologies icon[edit] Primary lifecycle processes

NeOn: Lifecycle Support for Networked Ontologies iconNetworked Peers For Business

NeOn: Lifecycle Support for Networked Ontologies iconThe importance of trust in the digital networked economy

NeOn: Lifecycle Support for Networked Ontologies iconDans – Data Archiving and Networked Services

NeOn: Lifecycle Support for Networked Ontologies iconVirtual Collaborative Learning Environments for Music: Networked DrumSteps

NeOn: Lifecycle Support for Networked Ontologies iconРуководитель программы: проф. В. А. Иванов Кафедра оптики Научный доц. Ю. Э. Скобло Рецензент: доц. А. А. Пастор Study of the population processes of neon atom

NeOn: Lifecycle Support for Networked Ontologies iconHighly versatile Senior System Administrator, skilled in the architectural design and implementation of high-availability systems for all major networked

NeOn: Lifecycle Support for Networked Ontologies iconNew Media is the term used for networked computerized or digital technologies that permeate society. There are many definitions of New Media, depending on the

Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2014
обратиться к администрации
Библиотека
Главная страница