NeOn: Lifecycle Support for Networked Ontologies

Скачать 340.61 Kb.
НазваниеNeOn: Lifecycle Support for Networked Ontologies
Размер340.61 Kb.
1   2   3   4   5   6   7   8   9
3.2.2 Requirements for Collaboration (literature)

A substantial volume of research has gone into exploring user requirements in collaborative activities.

[Kol96] is a brief survey of the main studies (at the time when the World Wide Web was emerging) on principles that seems to underline successful cooperative communities. The aim of the paper was to understand if such principles and best practices (or some of them) are applicable in building successful cooperative online communities. The paper is a bit dated, nevertheless it is worth to report (part of) the list of design principles the author identified, which are still basic good practices for online commuinities creation and management:

 [Axe84] requirements for the possibility of cooperation:

o Arrange that individuals will meet each other again

o They must be able to recognize each other

o They must have information about how the other has behaved until now

 [Ost90] design principles of successful communities:

o Group boundaries are clearly defined

o Rules governing the use of collective goods are well matched to local needs and conditions

o Most individuals affected by these rules can participate in modifying the rules

o The right of community members to devise their own rules is respected by external authorities

o A system for monitoring members' behavior exists; this monitoring is undertaken by the community members themselves

o A graduated system of sanctions is used

o Community members have access to low-cost conflict resolution mechanisms

 [God94] principles for making virtual communities work:

o Use software that promotes good discussion

o Don't impose a length limitation on postings

o Front-load your system with talkative, diverse people

o Let the users resolve their own disputes

o Provide institutional memory

o Promote continuity

o Be host to a particular interest group

o Provide places for children

o Confront the users with a crisis

More recently, in the course of the case studies for the DILIGENT methodology, several requirements were identified with regard to an efficient support of a collaborative workflow. For example, if one wants to create an ontology related to professional knowledge, one should form a team of domain experts and ontology engineers (see [VRA06] and [TEM06]). Thus, the used tools must be user friendly and should not require the special knowledge of ontology engineers (see [VRA06]).

Additional requirements identified in [VRA06] and [TEM06] with regard to ontology engineering tools are:

engineering tools should have support for communicating changes in the collaboratively developed ontology

all other required tools like version control and argumentation support should be strongly integrated into the engineering tool

it is important to have a graphical visualization of the ontology.

Furthermore, using a concrete methodology for the collaborative development process helps to clarify the objectives and to have a list of things to do next. The methodology should cover the whole ontology lifecycle including the maintenance phase and not only the initial creation of the ontology. With this respect, it proved to be useful to have a well-defined process for feeding back change requests and to document the argumentation process which led to certain design decisions (see [VRA06]). Additionally, it is important to find good evaluation measures which show whether one reached the goals which were originally set for the ontology.

An important part of the DILIGENT methodology is its argumentation framework. Important lessons for an appropriate support of the argumentation process are described in [SUR06] and [TEM06]. It showed that discussions are often inefficient and time consuming if a clear structure is missing. For example, it was useful to restrict the users to certain argument types so that they didn't get lost in the discussion. Furthermore, a clear decision process has to be defined which of the proposed solutions should be included into the ontology. Many of the requirements for ontology engineering tools also apply for the argumentation tool. Especially the following requirements are of importance (see [SUR06] and [TEM06]):

the user needs a possibility to monitor a discussion so that she/he is automatically informed of changes to discussions of interest

the argumentation tool should be integrated with the ontology engineering tool so that one can access the argumentation data from the engineering tool and vice versa.

In [NOY06] several scenarios for collaborative ontology development are identified. Subsequently, they derive requirements for an efficient support of these collaborative activities. Many of those requirements are with regard to an efficient version management and control system. For example, it is very important for the users that they can attach annotations to their changes which explain the rationale and/or which refer to citations and documents on which the change is based. This requirement covers similar aspects like the design rationale and provenance information mentioned in this deliverable.

Further requirements mentioned in [NOY06] are more related to the core functionalities of a versioning system: the representation of changes. Here it is especially important that not a textual difference between e.g. two OWL ontologies is computed but that instead a list of changed ontology elements is available including information about e.g. which concepts were split or merged, an information typically not available if the changes were computed based on textual differences. The description of changes is needed in such a granularity that is is possible to go back to earlier versions of an ontology at any time.

Another requirement which is important for collaborative ontology development is having fine grained access rights. It is especially not sufficient to define the access on the level of an ontology. Instead it should be possible to define it on the level of ontology elements. This helps to avoid conflicts between the different versions of editors. Nevertheless, before checking in a new version it is necessary to identify direct and indirect conflicts between two versions. Indirect conflicts may e.g. occur in subclasses which depend on one of the changed classes. In case that a conflict occurs, a kind of negotiation process between editors is needed which helps to resolve the conflict.

In some collaborative scenarios, there exists a central authority or curator which decides which local changes of editors will be included in the shared version of an ontology. In this case, the curator needs the possibility to accept a whole set of changes. This set of changes may be identified structurally or based on who performed the change and when. Otherwise, accepting each single change separately would be very tedious. In this scenario, the automatic detection of conflicts as well as the annotations made by the authors are very useful for the curator as they explain why a change was necessary.

3.2.3 Tools for Collaboration Support (literature)

[DWG01] describes an application suite named Ontology Builder and Ontology Server (OBOS), developed for supporting the creation and maintenance of ontologies used in e-commerce and B2B applications. There is not a precise definition of collaboration, the issue is approached focusing mainly on tool functional requirements identification. OBOS has been built with the aim of supporting a distributed and collaborative team of users (ontologists, domain experts, and business analysts) developing and maintaining shared ontologies. Basing on an informal evaluation of four existing tools (i.e., Ontolingua/Chimaera, Protégé/PROMPT, OntoWeb/Tadzebao, Ontosaurus/Loom), a set of requirements are identified. Among them the following are very important for collaborative ontology creation: scalability, availability, reliability, performance, ease of use, distributed multi-user collaboration support, security management, difference and merging support, internationalization, and versioning. OBOS uses a frame-based representation based on OKBC knowledge model and its implementation is based on J2EE. The tool provides a collaborative environment for the development and maintenance of shared ontologies. Multiple access is managed using a role-based policy, and users are provided with discussion rooms where they can communicate about their work on the ontology/ies. OBOS implements a pessimistic locking strategy for editing and changes to the ontologies are immediatly notified so as the user can refresh the information. Multilinguality is supported by means of so called locales, versioning is not supported. The tool resulted to be sufficiently easy to use (as claimed by the authors), nevertheless the different types of users (ontologist, domain expert, and business analyst) are not provided with specific interfaces and/or methods.

[SHU02] describes the application of a Compendium approach to Hypertext-Augmented Collaborative Modelling (HACM). Within the Advanced Knowledge Technology (AKT) consortium the AKTive Portal was designed to be a next generation portal infrastructure that supports the capture, indexing, dissemination and querying of information. The first application of the portal was to the AKT project itself. Mifflin, a hypertext tool for Compendium, was used to facilitate ontology-based scientific knowledge creation and management in a collaborative settings and, interestingly, the case-studies were AKT meetings. Mifflin’s main functions in the project were to provide:

1. Structure to collaborative sense-making;

2. The rationale for an ontology engineer when implementing the agreed specification;

3. A memory aid in and between meetings for both the group and for the group coordinator;

4. Multiple on screen visualizations of both the existing ontology structure and of the ongoing discussion about it.

Mifflin succeeded in supporting the collaborative creation of an ontology of scientific knowledge, mainly in terms of:

1. Dialog mapping,

2. Direct formalization of conceptual proposals,

3. Direct display of proposals on screen,

4. Compatibility with existing software tools.

The achievement of these four results were not cost-free, though. Mifflin imposed on (even expert) users the development of some literacy and, at the beginning, some cognitive overhead.

[SER04] presents Claimspotter, an open architecture based on the ScholOnto ontology. Claimspotter supports the semiformal (collaborative) annotation of scholarly documents. It is based on a simple paradigm: triples. The text of a document are represented by couples of concepts (source and destination concept) plus a relation between them (for instance: ‘is an example of’, ‘is enabled by’, ‘proves’, ‘supports’, ‘is similar to’, etc.). Such triples allow to built a network of claims about the internal structure of the document, or about its relations with other documents. The resulting network, or parts of it, can be shared and incremented by different users over time. The final result is a commentary to the original text, which is usually dialectic, as the network can host logically contradictory claims about the contents of the document.

Claimspotter supports the creation of triples by means of suggestions given to the user. On the one hand, suggestions have to do with the structure of the document and the scientific rhetoric the keeps it together. Two main families of rhetorical roles are considered: what in the document refers to the work being described (background, aim, textual structure) and what refers to the the work of other researchers (contrast, basis). On the other hand, suggestions have to do with so-called information bricks, i.e. parts of the document, which may be used as concepts in the network (keywords, the instances of ScholOnto relations found in the text - i.e. verbal expressions -, cited documents).

Claimspotter’s architecture as well as the presentation of the suggestions is highly modular. A toolbar gathers all different suggestions on the following aspects: the concepts made by the current annotator, the instances of ScholOnto relations found in the text, the documents important sentences (where importance is defined in terms of keyword-matching with title, headers, abstract), the document’s rhetorically-consistent zones, the sentences matching a particular user-defined query expressions.

A very limited user study has been done for evaluation of Claimspotter. This has revealed two main points. On the hand, an annotation system should be very flexible with respect to the quantity and the quality of suggestions provided to the user. Users want to be able to switch back and forth from a very structured configuration (where to get support and inspiration from what other annotators have done) to a lightweight configuration (where to “think outside the box”). On the other, it has become clear that gaining expertise with the system corresponds for annotators to move from a “concepts to relations approach” (which tends to produce idiosyncratic networks) to a “relations to concepts approach” (which facilitates standardization).

[BEN05] presents material that is very much in line with [SER04]. It generalizes that approach (in terms of an Ontology of the Academic Field, rather than of scholarly comment only) and it makes one step towards automation (in terms of a number of functionalities that allow to derive knowledge from a model based on the ontology).

The Ontology of the Academic Field comprises three main components:

1. the Community of Practice (with concepts, attributes and relations like Publication, Title, author-of, researcher-at, etc.);

2. the Lexicon (with concepts, attributes and relations like Lexical-Term, Gloss, broader-term, etc.);

3. the Argumentative Discourse (with concepts, attributes and relations like Statement, Question, Issue, Premise, Conclusion, Postulates, supports, coheres).

Services are provided for:

1. The usual bibliographic database functions provided by tools like CiteSeer or Google Scholar;

2. Finding key statements made by an author on a particular issue;

3. Assisting navigation around a complex argumentation network, which renders an ontology as an interactive map;

4. Flexible visualization of the network;

5. Inferences on the network, by creating paths, like for instance, (in)coherence paths that connect the opinions of a given author with a scholarly position that is typical of the reference field.

[MAN06] describes the theoretical principles behind the ClaiMaker tool, a system designed to represent discourse in a semiotic way within the scholarly domain. More generally, the paper discusses the representational requirements for collaborative systems that support sensemaking and argumentation over contested topics. Sensemaking is intended as expressing and contesting explicit, possibly competing views of the world. Supporting sensemaking therefore means supporting a way of annotating different interpretations of the same object or issue. This is what ClaiMaker does, with a theoretical backbone consisting of semiotic (in a saussurian fashion) and coherence relations, as in Mann and Thompson’s Rhetorical Structure Theory (RST) [MAN88].

ClaiMaker is a hypertext system that makes use of constrained base relational classes, but imposing no constraints on how such classes are rendered, or on how nodes are expressed/classified. ClaiMaker's ontology allows users to establish as many referential relations between concepts (e.g. the summary message of a document) and sources (e.g. a document) and also connective relations between sources. Claims of the first kind are called “primary claims”, whereas those of the second type are called “secondary claims”.

Primary claim: users can associate documents with concepts: this consists in establishing a referential relation between a concept and a referent. In other words: a primary claim is the creation of a sign (=the concept) that refers to a particular referent (=the document) in the virtual reality (=the ClaiMaker repository), in some respect (=a context). From an ontological point of view, it is interesting to note that concepts linked to sources can (optionally) be classified. The classification is not rigid, however, so that the same concepts can be assigned different classes by two different persons, or even by the same one in different contexts. Like in natural language, in ClaiMaker meaning is continually negotiated by means of establishing referential relations between referents and concepts, and by means of defining concepts according to different classes (different from ontology-based systems).

Secondary claim: A secondary claim establishes a discourse connection between two concepts. The authors borrow plenty of terminology and insights from linguistic theories, such as RST and Sanders et al.’s theory of connectives [SAN93] to model what they term an "upper level discourse relations ontology". Grounding on Sanders et al's approach, they treat coherence relations as psychological constructs and take a small number of cognitively basic concepts. The relational scheme is based on four parameters (Cognitive Coherence Relations [CCR]):

 Basic operation [additive,causal]

 Source of Coherence [semantic,pragmatic]

 Order [basic,non-basic]

 Polarity [positive,negative]

A relational hierarchy is then derived from these four parameters. By also incorporating insights from Louwerse's (2001) description of coherence relations [LOU01], the authors obtain the final ClaiMaker’s relational ontology, which can be used for annotation of secondary claims. Since it is based on cognitive primitives, it has the main advantage of being applicable in different disciplines and domains.

[Buc06] presents the integration of two existing tools (i.e., Compendium, and I-X) for the Co-OPR project, the simulation of a personnel recovery mission. The experiment presented deals with decision-making support for a team collaborating on the same mission. In particular, Compendium has been used in order to support the collaboration between members of the team who were geographically distributed; I-X has been involved as a tool supporting a team whose members were physically in the same place. The paper underlines the effectiveness and usability of the two tools when used together by giving a very pragmatical evaluation. The focus is mainly on the usability and utility of provided functionalities.

3.2.4. Matching requirements and tools (literature)

Tools that support collaboration are obviusly developed on the basis of user requirements. Some valuable insights come from comparing such requirements and available tool, as to identify not only the technical gaps, but rather determine which gaps can be bridged by advancing technology and which are instead unavoidable (i.e. which requirements are unsupportable).


An important contribution is Mark Ackerman’s work on the gap existing between social requirements and technical feasibility [ACK01]. What Ackerman terms “the social-technical gap” is “the divide between what we know we must support socially and what we can support technically.”, and is likely to be the highest challenge of Computer-Supported Cooperative Work (CSCW). What is relevant to work within NeOn is not only the description of social requirements (in collective work), but also the attention to what kind of support is difficult to achieve technically, and therefore a definition of an upperbound with respect to tool development for supporting collaborative activities.

The following are some social aspects of communication that need to be considered when building any tool that supports collaborative activities: [WOULD BE NICE TO MATCH THESE WITH USER REQUIREMENTS FROM NEON CASE STUDIES]

Nuances of social activity: social activities are fine-grained and flexible, thus making systems technically difficult to build.

Multiplicity and Diversity of Goals: members of a given organisation might have different goals and different organisations may not have shared goals, knowledge, and meanings. Conflict is as important as cooperation in issue resolution. Meanings must be negotiated, for example (see also [MAN06] about the importance of building tools that support negotiation of “sensemaking”, such as ClaiMaker [MAN06]).

Exceptions in work processes are normal. And roles can often be informal and fluid [SEE FAO CASE STUDIES??] CSCW approaches to workflow should deal with exceptions and fluidity.

Visibility of communication exchanges and information facilitates learning but might inhibit for fear of criticism. Ways must be found to manage the trade-offs in sharing.

Norms for using CSCW: they are set (negotiated) by the users and can change while using the system. The system must therefore allow for renegotiation, changes and flexibility (see again [MAN06]).

Critical Mass: with an insufficient number of users, people will not use a CSCW system.

Adaptation: people adapt their systems to their needs, so not everything can be forseen when developing a system; however, systems are often too rigid to allow for such changes.

Incentives: using a tool might be time consuming, also from a learning-to-use-it point of view. So it must be rewarding, i.e. benefits must be evident.

Additionally, [POR04] claim how one of the main failures of human-computer interaction (HCI) is the treatment of turn-taking. They present experiments that show that HCI systems are not equipped with means for dealing with natural turn-taking issues, such as pauses, overlaps, and similar behaviour. Although this applies to human-machine interaction, in the spoken dialogue domain there might be similar problems in collaborative activities between humans conducted over the Web, especially if done in a synchronous manner (see also [CHA01]).

In the specifics of collaboration towards ontology development, [LU94] is a source of interesting points with respect to requirements and tool support. According to [LU94], since modern ontologies are characterized by their huge size and high complexity, ontology engineering is to be considered an inherently collaborative activity, involving the effort of many domain experts and software developers which are often not co-located. This is especially prominent when not only the design stage, but the whole ontology life cycle is considered. Throughout this work, ‘collaboration’ seems to be defined as a reiterated process, the output of which, at each of the involved stages, is the obtaining of a ‘convergence of views’.

Based on a survey of five authoring tools (Ontolingua Server, OntoEdit, APECKS, CO4, and Protégé-2000), which were widely used at the time of the inquiry (updated in 2000), the conclusion is reached that collaborative ontology development was – again, at that time – far from being well supported by said tools.

The identified inefficiencies wrt collaboration support were the following:

 coordinated group work (e.g. collaborative editing, discussion or annotation) was not well supported, mainly because the systems lack functions for keeping developers informed of each other’s activities [compare, by contrast, with current wikis]

 contextual communication support was not considered in these tools (no way of easily keeping track of a whole coherent discussion, which is e.g. scattered in many people’s mailboxes) [compare, by contrast, with Compendium, Claimspotter, and ClaimMaker below]

Since collaborative work across distance in software engineering and ontology engineering share many similar characteristics, three dimensions of collaborative ontology engineering are identified based on documents and experiences in the first field:

Distance and communication:

Co-located team members communicate informally anytime during the work day, while this cannot happen to geographically distributed team members (A study at Carnegie Mellon University showed that the rate at which scientists collaborated spontaneously with one another was a function of distance between offices). Informal and unplanned communication has been proved to have a direct impact on development processes, in particular on

coordination (“the act of integrating each task with each organizational unit, so each unit contributes to the overall objective”), and

control (“the process of adhering to project goals, specifications, and standards”).

Coordination and control are necessary not only to manage interdependencies within the tasks, but also for the development and maintainance of shared mental models [compare with FLE36 on thought-styles], i.e the most effective support for explicit coordination in team work. Communication affects shared mental models in two ways: a) during task execution, refines team members’ mental models with contextual cues; b) keeps the models up-to-date, especially in dynamic or novel situations. It’s been proved that weak shared mental models in asyncronous tasks can lead to productivity losses. Designing tools to support and enhance informal communication is then a key step toward bridging the missing link in distributed development work.

Documentation and knowledge management:

Information and knowledge obtained during meetings, email correspondences, and instant messaging need to be captured easily, stored and shared effectively. The distribution of resources and developers in space and time combined with the the dynamic evolution of knowledge make the use of tools for knowledge management a necessity. Moreover, the documentation must be kept up-to-date.

Version control and change tracking:

Tools for version control and change history tracking are crucial when development resources are not co-located, in order to make sure that two developers do not work on the same part of the ontology and to avoid the complication of resolving conflicts.

Finally, a range of tools and groupware technologies in the Computer Supported Collaborative Work (CSCW) domain are investigated, in order to determine how they can be used in the ontology development domain:

experiences in the Global Software Development (GSD) field are examined in order to understand the correlation between distance and collaboration:

1) instant messaging techniques (support spontaneous and informal communication)

2) web portals (support tasks in the area of group knowledge management)

3) Peer-to-Peer (P2P) network technologies (but poor reliability and security)

- report of an experiment where the possibility of adding collaborative support to a knowledge engineering tool based on a P2P network was evaluated

long term vision: to combine these two fields and create a collaborative ontology engineering environment that provides collaboration support in multiple dimensions:

- exploration of how collaborative support can be provided by Protégé-2000, in particular how live bookmarks, a lightweight collaborative mechanism, can be used with Protégé- 2000.

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

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

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