NeOn: Lifecycle Support for Networked Ontologies




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

3. ODO as a language for collaborative ontology design

in ogni sottosezione, occorre rimandare al pattern descritto in 2, che va dettagliato graficamente e rimandato alle domande dell'introduzione e alle funzionalità in sezione 4

3.1 Ontology projects

breve sezione: rimandiamo ai progetti per software e altro; lo specifico ontologico consiste nel prodotto finale: i rationale di pianificazione di un progetto non sono trattati in ODO (almeno non in D2.1.1).

Un po' di figure dedicate, esempi e codice da ODO in DL o in OWL astratto

3.2 Collaborative design workflows

più o meno com'è adesso la sezione 4 di 0.1f, ma con narrativa e rimandi rivisti. Dire che i rationale di un workflow non sono trattati qui. Occorre aggiungere rimandi ai coordination patterns (paper da Ciancarini). Un po' di figure dedicate, esempi e codice da ODO in DL o in OWL astratto

Analyses of collaboration found in the literature are rarely focused on ontologies (with the notable exception of [LU94] and [FAR96]).), and a general theory of collaboration is currently missing. For the present purposes, we will mainly focus on what directly relates to ontology development, or can be easily adapted to it.

Our notion/definition of collaboration within NeOn should:

cover all of the scenarios related to our use cases

be formalisable

be supportable by tools

(be general enough to be reusable)


The current section is therefore organised as follows. In Section 4.1 we present our definition of collaboration, with specific attention to collaboration towards ontology building. All examples will be concerned with collaborative ontology development, and wherever possible they will be taken from the case studies provided by WP7 and WP8. We will then discuss typical requirements for collaborative activities (especially in online distributed environments) as found in the literature [and compare them with those provided by the case studies?] (Section 4.2). Further, we will present a review of current tools that support (some of the types of) online collaboration (Section 4.3), and finally discuss the so-called social-technical gap between requirements and support (Section 4.4). The desired functionalities of collaboration support within NeOn (including state of the art) are then presented in Section 5.

3.2.1 Our definition

Following intuition, a collaborative activity is concerned with the way a community carries out a complex task in a cooperative fashion.


Most approaches to collaboration identify as a necessary requirement the presence of two or more agents that work together towards a given goal. The collaboration frame in FrameNet is also defined around such concepts: ``Partner_1 and Partner_2 or a group of Partners work together in some Undertaking"1.


As far as knowledge-production goals are concerned, both partners are (implicitly) required to be rational agents (cf. [GAN05a]), with one of the two possibly having a more prominent role (this could be realised, e.g., as the subject of a clause). The ``undertaking" element marks the expressions that refer to the project/plan on which the partners are collaborating.

When talking of knowledge communities like those targeted by ontology engineering and NeOn, we should assume, as a starting point, a very comprehensive notion of knowledge relationship, including e.g. the following different situations:

1) social relationships whose participants are physically co-located, work in a same group and project and can communicate flawlessly in shared languages and with common tools. For example, two prospective NeOn users both working at UN-FAO, Rome, speaking a fluent English, both expert in their respective fields, competent on using the same communication tools, and collaborating on the design of an ontology for fishery regulations

2) social relationships whose participants are geographically distributed, work in a same community for related projects and can communicate with some fluency in a language and with some common tools. For example, two prospective NeOn users working at UN-FAO, Rome, and CABI, Oxford, speaking a decent English, both expert in their respective fields, somehow competent on using at least one communication tool, and collaborating on the design of two ontologies for fishery regulations and for fishery techniques respectively

3) social relationships whose participants are not co-located in space, work in heterogeneous communities and cannot easily access their respective languages and communication tools, but have compatible goals. For example, two users who work, respectively, for UN-FAO and as an independent farmer in the Maluti Mountains, Lesotho. They have never met, have respectively unaccessible languages and, while being both experts in their respective fields, they are not necessarily competent on using the same communication tools. Moreover, they are not going to make any joint work on the design of an ontology for farming techniques; in principle, however, the knowledge owned by the independent farmer can be relevant for that task, and the UN-FAO user could involve the farmer in her project as a consultant

4) social relationships whose participants belong to heterogeneous communities, live in disjoint space-time, work on unrelated projects, and have no accessibility to their languages and communication tools. For example, a UN-FAO user, and Aristotle. It is not completely absurd to think about a distinction by Aristotle to be reused by the UN-FAO user, e.g. that between matter and attribute (substance and accident in Aristotle's terms)

While the third and fourth situations cannot be considered typical collaborative scenarios, nonetheless, a form of knowledge (or ‘epistemic’) relationship can be generalized to occur even between agents living at disjoint space-time, and having apparently incompatible goals and communication means.

3.2.1.1 Background notions: the plan ontology, the information-object ontology and the ontology-design ontology

In order to identify entities and relations involved in collaborative development of ontologies, we reuse the plan ontology and the information-object ontology introduced in [GAN05a], and add to them a new module for the specific treatment of ontology design and development (called ontology-design ontology, hereafter ODO). ODO is meant to be used as a set of social requirements for NeOn.

According to the plan ontology, plans are descriptions (hence, socially created entitities) that represent sequences of actions that lead from a given situation to a new one, and the entities involved in these actions. These descriptions are abstract and independent from computational system design: they are reusable and easy-to-customise representations of the objects and activities involved in multiple action domains. Plans are internally represented by rational agents, and their typical components are tasks that provide instructions to execute (classify) actions. A plan defines or uses at least one task and one role (which must classify an object, and at least one role must classify an agent), and has at least one main goal as proper part (that goal is usually desired by the creator or beneficiary of a plan). A plan can have further proper parts besides its goal (i.e., other descriptions such as, e.g., regulations or laws). It can also include other plans, which are called subplans, and whose goals are called subgoals to distinguish them from the main goal of the overall plan.

Tasks are treated as concepts defined within plans, which refer to actions (e.g. “write a deliverable”), and are organized into a subclass hierarchy. Control constructs (e.g. “choose between the following alternatives”) from traditional planning and workflows are represented as control tasks, also defined within plans. Ordering of tasks is formalized by using part (mereological) relations, control tasks and a successor relation.

In addition, plans may include parameters that are classified by attributes (called “regions”) of actions or objects. Parameters are related to roles or tasks by a requisite for relation, expressing the kind of requisites that the entities which are classified by said roles or tasks should have in a given plan.

Tasks are connected to roles by a target relation, expressing the modalities (e.g. duties, obligations, or rights) that, in given plans, roles can have towards specific tasks.

Plans as descriptions are different from plan executions, which are situations (a different kind of entities, introduced by the DnS ontology, cf. [GAN05a]). A satisfies relation holds between situations and descriptions, implying that at least some components in a description must classify at least some entity in the situation setting. A plan execution is a situation that (proactively) satisfies a plan description. Goal situations are situations that satisfy a goal, but that are not part of a plan execution.

Plans may also have situations as pre- or post-conditions. A situation is a pre-condition for a plan if it should preliminarily satisfy some description before executions of that plan occur. A situation is a post-condition of a plan if it should satisfy some description after plan executions of that plan occur. It often holds that the goal situation is a postcondition of plans, but this is not mandatory. Of course, every plan execution has predecessor and successor situations, but only some of them are pre- or post-conditions for the plan that the plan execution is supposed to satisfy.

A plan can be expanded by adding new parts, or refined by specializing its tasks, roles, or parameters. Clearly, almost any sequence of actions directed at the obtaining of some goal can be seen at different levels of granularity, so the decision whether to consider a specific process or workflow description as an atomic or composite plan (and its more complex tasks as subplans) is very much dependent on the needs of the formalization at hand.

Information objects (hereafter, IOs) are social (hence, non-physical) products such as books, diagrams, thesauri, folksonomies or formal expressions. An IO is characterized as follows:

is realized by at least one information realization (i.e., a support),

is ordered by one or more code/s (i.e. combinatorial structure/s or grammar/s, e.g. OWL),

expresses one or more description/s (i.e., conceptualization/s, meaning/s, or viewpoint/s),

is about one or more entity/ies (i.e., the IO’s reference), which are in the setting/s of one or more situation/s, which in turn satisfy the description/s expressed by the IO, and

is interpreted by at least one rational agent.

Hence, every IO is intrinsically provided with a viewpoint (the original description its author/s meant the IO to express), regardless whether this viewpoint is known to – or deemed interesting by - the agent/s that is/are currently considering the IO. The rational agent which is the original author/designer of a given IO can also be a knowledge collective.

The relation interprets implies that an expressed description is internally represented by an agent; i.e., when an agent interprets an IO, it internally represents the description expressed by the IO; of course, two agents can represent different descriptions, then resulting in different interpretations. As a consequence, a same IO can be seen as many different IOs, according to the different viewpoints from which it is interpreted.

In ODO (at the social level), we consider an ontology project to be a plan that uses at least one functionality, one knowledge-resource role, one working-knowledge-item role, and one knowledge-product role; and that has an epistemic workflow as component.

Functionalities are considered to be tasks defined in some functionality description (e.g. a methodology).

‘Knowledge resource’ is a role, defined in an ontology-lifecycle schema, that classifies information objects. Knowledge resources include any piece of information that is used for developing ontologies. In particular, however, they include formal expressions such as architectural design patterns, queries, ontologies and ontology elements (i.e., formal expressions which are proper-part of an ontology, e.g. axioms, classes, individuals and relations). Ontologies and ontology elements (such as any other IO) can also play the roles of working-knowledge-items (when they are seen as the ‘evolving’ objects on which e.g. a designer is working) and of knowledge products (when they are seen as the final result of a knowledge production process such as e.g. an ontology project). Knowledge resources, working-knowledge items and knowledge products have knowledge creators, which are rational agents or knowledge collectives.

Epistemic workflows are themselves plans, characterized by having a knowledge-production goal as their main goal and an argumentation structure as component.

Argumentation structures are schemas or frames (i.e., types of descriptions) for argumentation primitives, which define 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'.

As for all plans, ontology projects and epistemic workflows can be expanded or refined, and their most complex functionalities can be treated as subplans (consider, e.g., the evaluation functionality).

Ontology projects as plans are different from ontology-project executions, which are the situations that satisfy a given ontology project. Executions can be more or less constrained according to the constraints, preferences, and resources declared in the project (plan). The same holds for ontology lifecycles, which are occurrences of ontology-lifecycle schemas (descriptions of typical ontology building and maintenance practices).

Design motivations, too, are treated as situations, i.e. as the instantiations of a design rationale in the design of an ontology, which are setting for (at least one of each of) the following entities that play roles in the rationale: a rational agent/knowledge collective, an information object, a design operation (i.e., an action that is classified by a functionality) on it, and a time interval at which the operation is performed. Design choices are another kind of situations, i.e. structural states that include only components (e.g. ontology elements) and their relations.

A rational agent (or knowledge collective) that executes some task/s (functionality/ies) in an ontology project is a performer. If that agent or collective adopts the main goal of the project, then he/she/it is an accountable performer. A knowledge creator which is also an accountable performer is an accountable knowledge creator with reference to a given knowledge product.

3.2.1.2 Formalisation: the Nyis model of funtionalities [to be done; move somewhere else?]

Refer to work in NeOn wiki and elsewhere --- not relevant after ODO

3.2.1.3 Epistemic influence, epistemic workflows, and collaboration proper [SOME REVISION STILL NEEDED; must be integrated with argumentation]

In order to comply with the most general and intuitive definition of collaboration, and at the same time account for all of the scenarios that might arise in the NeOn-related environments, we include the concept of `collaboration’ proper in a wider descriptive context, which we term epistemic influence.

An epistemic influence is a relationship between rational agents that influences the knowledge of one or more agents in the relationship.

This relationship uses at least two roles: an agent-driven role (i.e., a role that must be played by an agent), and a knowledge-resource role. Epistemic-influence situations are setting for at least two rational agents and one information object classified by a knowledge-resource role. They include the case in which there is only one rational agent that is 'influenced' by some information/knowledge that, in turn, has been produced at a different time by the very same agent (as when, e.g., revising one’s own work).

A subclass of epistemic influence is epistemic workflow:

An epistemic workflow is both an epistemic influence and a plan, which has a knowledge-production goal as main goal and uses a working-knowledge-item role, a knowledge-resource role, and a knowledge-product role.

An epistemic-workflow enactment, on the other hand, is a situation that has an agent-co-participation situation as proper part, and has a direct successor a knowledge-production-goal situation (which has the final knowledge product in its setting).


Hence, any epistemic-workflow enactment includes the following elements:

A1 = rational agent/knowledge collective

A2 = rational agent/knowledge collective

K1 = working knowledge item (expressing a viewpoint, e.g. a working hypothesis) of A2

K2 = knowledge resource (expressing a viewpoint) of A1

P = plan (e.g. ontology-design project), including at least one knowledge-production goal as main goal (G)

TK = at least one task (e.g. functionality), of which the plan consists of

R = at least one accountable performer role, played by one or both rational agents, that is targeted at one or more tasks

Kf = a final information object playing the role of knowledge product (expressing an emerging viewpoint) resulting from epistemic influence (that is in the setting of the knowledge-production-goal situation)

T = at least one time interval, at which a rational agent interprets a knowledge resource

The plan must be created or internally represented by at least one of the rational agents involved the epistemic workflow (although, as said above, in the typical collaborative case a project is ‘shared’ by all the involved agents; cf. [GAN05a] and [BOT06]).

Wrt the epistemic-influence relation, assigning different values of specific features applying to agents will yield different influence types, in a hierarchy ranging from the weakest influence to the highest, namely collaboration proper. More specifically, rational agents can adopt the plan’s main goal or not, hence can be accountable for it or not. The second feature basically expresses whether an agent is committed (through an explicit agreement) to the plan or not.

Finally, Kf must be conceived as an element in the setting of the situation that satifies the main goal of the plan (or, at a different level of granularity and recursively, one of its subgoal, e.g. the expected output of a task). In the case of collaborative ontology development, all the involved knowledge objects are typically ontology objects, i.e. bits of formal elements, annotations, or even natural language. The conceptualizations/ descriptions expressed by ontology objects can either be the result of design rationales (e.g. a certain modelling solution), or the representation of a design rationale (e.g. a comment, an argumentation tag, or an email argument).

Let us now consider some cases of epistemic workflow.

Let us take an example (FAO use case 1.1.2 “Include a selection from an existing ontology”): an ontology expert needs to include a selection from an existing ontology into the ontology she is working with or building.

A1 = ontology expert, who is accountable knowledge creator (i.e., accountable performer and knowledge creator) of K1

A2 = author of K2 (could be A1 at a previous time or any other ontology creator at any time), who, wrt P and Kf, is a non-accountable knowledge creator

K1 = working-ontology-lifecycle item (an information object expressing e.g. use-case requirements)

K2 = ontology-lifecycle resource (ontology to be selected, or take selection from)

P = how to build ontology Kf

G = having Kf built properly

TK = a selection from ontology K2

Kf = ontology-lifecycle product (the final resulting ontology)


This is a type of epistemologic workflow that we term usage. The main condition is the non-accountability of A2. Note that this holds also in case A1 = A2, since in that case A1 plays an accountable role when dealing with K1, but A2 does not, because she must have necessarily authored K2 at a previous time, for a different task or a different execution of a same task. In other words, the identity of agents in a task of the use scenario does not require that that same agent is accountable for that task at all times of her lifecycle (this is formally represented by using admitting roles and tasks in the domain of quantification of our language).

Usage is a case of epistemic workflow that uses two additional roles (wrt epistemic workflow): accountable performer (for agents that adopt the main goal), and non-accountable knowledge creator (for agents that have created the knowledge resource to be used in the workflow, but that are not actively involved in the current knowledge production plan).

An usage situation is an enactment of a usage workflow. It is the setting for at least two rational agents: one accountable, the other a non-accountable knowledge creator.

Let us now consider another example: the same scenario as above, but A1 asks A2 to send her the ontology she needs in order to achieve her goal, and A2 complies. This means that A2 is assigned a role in a task of the project, but it does not imply that she is accountable for anything related to it. So, more specifically, elements are described as follows:

A1 = ontology expert, who is an accountable knowledge creator

A2 = author of K2 , who, wrt P and Kf, is a non-accountable knowledge creator and non-accountable performer

K1 = A1’s view on the ontology to be build

K2 = ontology to be selected (or take selection from)

P = include a selection from ontology K2

Kf = final resulting ontology


This type of epistemic workflow we term interaction:

Interaction is a case of epistemic workflow that prescribes the proactive involvement of two rational agents. One rational agent can also be a team (a collective), provided that the members perform actions expected by a shared interaction plan. Moreover, only some of the activated rational agents adopt the goal of the interaction (some of them are non-accountable performers).

An interaction situation is an enactment of an interaction workflow. It is the setting for at least two rational agents: one an accountable performer, the other a non-accountable performer.

In case all involved agents are accountable performers,, we can talk of collaboration proper:

Collaboration is a case of epistemic workflow that prescribes the proactive involvement of all rational agents, i.e. all the involved rational agents adopt the main goal of the collaboration plan. A rational agent can also be a team (a collective), provided that the members perform actions expected by a shared interaction plan.

A collaboration situation is an enactment of a collaboration workflow. It is the setting for at least two rational agents, both accountable.


STILL TO BE MERGED This definition of epistemic workflow includes the ‘Aristotle case’ (the fourth in our initial list), which is a typical situation of ‘usage’. The third of the above-listed examples, on the contrary, is a case of ‘interaction’, while we will talk of ‘collaboration’ for the first two above-listed examples, which imply a sharing of both goals and tools, as well as the performance (by each of the collaborating agent) of (at least one) task defined in a same project. [The performed tasks should be, typically, different, but maybe we should allow for ‘redundancy’….]

Based on this definition of collaboration, a network (of whatever kind) always implies collaboration, and viceversa.

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
обратиться к администрации
Библиотека
Главная страница