Table of Contents - bivee

skillfulwolverineΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 11 μήνες)

275 εμφανίσεις

BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012
2012


Page

1

of

112


BIVEE

Business Innovation and Virtual Enterprise Environments

Grant No. 285746






Deliverabl
e
5.1


Production and Innovation Knowledge Repository



F. Taglino, F. Smith, M.

Proietti
, P. Assogna, A. Formica


CNR

A. A.

Sinaci
-

SRDC

C.
Diama
ntini, D.
Potena


UNIVPM

F. Gigante


AIDIMA

M. Piersantelli


LOC

R. Di Bernardo


E
-
IIS


Due

date

of

deliverable:

30
/
04
/
2012


Actual

submission

date:

14/06
/
2012



This

work

is

licensed

un
der

the

Creative

Commons

Attribution

3.0

License.


To

view

a

copy

of

this

license,

visit

http://creativecommons.org/licenses/by/3.0/

or

send

a

letter

to

Creative

Commons,

171

Second

Street,

Suite

300,

San

Francisco,

California,

94105,

USA.

This

work

is

partially

funded

by

EU

under

the

grant

of

285746.





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

2

of

112

E
XECUTIVE
S
UMMARY

Knowledge management is a crucial
aspect for enterprises that want to cope
with business innovation in an effective way
.
However, the full control of the
enterprise knowledge asset is very often missing due to the lack of precise
organizational models, policies, and dedicated and interoper
able technological
solutions. This is much more true in virtual organizations, like virtual enterprises
(VE
s
), which are characterized by a heterogeneous group of partners
with
different policies, skills, know
-
how and way of doing business. Due to the high

heterogeneity of such organizations, the need of knowledge sharing, efficient
access to knowledge resources, and interoperability technologies is much more
felt as primary.

One of the main goals of the BIVEE project is to provide an ICT platform to
suppor
t effective knowledge management for business innovation in a virtual
enterprise environment framework. This document proposes a semantics
-
based
i
nfrastructure, called the
Production and Innovation Knowledge Repository

(PIKR
),
for management of digital doc
umental resources

(DDRs)

within the
BIVEE platform. We adopt a semantic approach because semantics
offers the
means
to
capture the essence of a fragment of reality in a fully structured and
formal way.

The PIKR aims at being a central hub in charge of building a global picture of
the knowledge made available by different partners of a VE. To this end, the
PIKR is characterized by a federation of reference ontologies (Intensional PIKR)
which are used
to

s
emantically
describe

DDRs

and
produc
e

the corresponding
semantic descriptors (Factual PIKR).
The
Ontologies in the PIKR have different
natures. On
the
one hand we have Knowledge Resources Ontologies

(KROs)
,
which describe what kinds of DDRs the PIKR manage
s, what kind of
information we want semantically describe, and what kind of relations can occur
between different DDRs. At this stage of the project we identified three main
categories of DDRs: Documents, Business Processes, and Key Performance
Indicators
(KPIs), and we started with the development of the corresponding
DocOnto, ProcOnto and KPIOnto.

On the other hand, we have Domain Specific
Ontologies (here called DomOnto) which concern the knowledge related to the
particular application domains (such as,
furniture, and robotics)
. For instance, in
the DomOnto we have Competencies, Products, Technologies specific
to

a
particular domain application. According to that, KROs can be seen as
templates for the semantic descriptors, while the DomOnto allow
s

the inj
ection
of domain specific knowledge in the semantic descriptors.

The semantic layer
is
then exploited by a set of semantic services
,

for enabling
an efficient access to the available knowledge resources
,

and reasoning
capabilities
,

for

deriv
ing

additional
knowledge.

T
he PIKR intends to establish a virtual bridge between the other two main
components

of the BIVEE platform
, the Mission Control Room (MCR) and the
Virtual Innovation Factory (VIF). MCR and VIF are in charge of supporting the
two faces of a VE th
at are in the scope of the BIVEE project, current production
and its improvement, and innovation, respectively.





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

3

of

112

The specifications of the PIKR, which are in the scope of this document, are
based on

the initial results coming from the definition of the BIVE
E Virtual
Enterprise Modelling Framework (VEMF), and
from
the identification of
the
user
requirements.







BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

4

of

112

Document

Information


IST

Project

Number

285746

Acronym

BIVEE

Full

title

Business Innovation and Virtual Enterprise Environments

Project

URL

http://www.bivee.eu

EU

Project

officer

Cristina Martinez


Deliverable

Number

D5.1

Title

Production and Innovation Knowledge
Repository

Work

package

Number


5

Title

BIVEE Integrated Semantic Meta
-
Space


Date

of

delivery

Contractual

30
/
04
/
2012


Actual

14/06/2012

Status

Version 2.5, dated 14/06/2012


final



Nature

Report



Demonstrator



Other




Abstract

(for

dissemination)

This document is about the specifications of the Production and Innovation
Knowledge Repository (PIKR), which is for enabling for semantic
knowledge management within the BIVEE platform.

Keywords

Innovation, Knowledge Management,
Semantics, Documents, Business
Processes, KPIs, Semantic Search, Semantic Reasoning


Internal

reviewers

Benjamin Knoke

(
BIBA
)

Vedran Hrgovcic

(
BOC
)

Authors

(Partner)

Maurizio Proietti (CNR), Fabrizio Smith (CNR)
, Francesco Taglino (CNR),

Pierluigi Assogna (CNR), Anna Formica (CNR),
Ali Anil Sinaci (SRDC),
Claudia Diamantini (UNIVPM), Domenico Potena (UNIVPM)
, Fernando
Gigante (AIDIMA), Matteo Piersantelli (LOC), Roberto Di Bernardo (E
-
IIS)

Responsible

Author


Francesco Taglino

Email

francesco.taglino@iasi.cnr.it

Partner

(CNR
-
IASI)

Phone

+39067716433






BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

5

of

112


T
ABLE OF
C
ONTENTS


E
XECUTIVE
S
UMMARY

................................
................................
...........................

2

T
ABLE OF
C
ONTENTS

................................
................................
............................

5

1

I
NTRODUCTION

................................
................................
................................
...

8

1.1

BIVEE approach to business innovation and production improvement

...

10

1.1.1

Innovation waves

................................
................................
..............

11

1.1.2

Production phases

................................
................................
............

11

1.2

Analysis of user requirements

................................
................................
.

1
2

1.3

PIKR Overview

................................
................................
........................

14

1.4

PIKR Knowledge Framework

................................
................................
..

15

1.4.1

Intensional PIKR

................................
................................
...............

15

1.4.2

Factual PIKR

................................
................................
.....................

17

1.5

PIKR reasoning services

................................
................................
.........

17

1.6

Positioning of the PIKR in the BIVEE Architecture

................................
..

18

2

D
OC
O
NTO

................................
................................
................................
.......

20

2.1

Document Centric Approach
................................
................................
....

20

2.1.1

Document Categories

................................
................................
.......

22

2.2

Representational Framework

................................
................................
..

24

2.2.1

Header

................................
................................
..............................

24

2.2.2

Content

................................
................................
.............................

25

2.2.3

Related Knowledge Resources

................................
.........................

28

2.2.3.1

Dependency

................................
................................
................

28

2.2.3.2

Decomposition

................................
................................
............

29

2.2.3.3

Generic

................................
................................
.......................

29

2.2.4

Document Constraints

................................
................................
.......

29

2.3

DocOnto structure: A preliminary outline

................................
.................

30

2.4

Next steps

................................
................................
...............................

36

3

P
ROC
O
NTO

................................
................................
................................
.....

37

3.1

Introduction
................................
................................
..............................

37

3.1.1

Business Process Abstract Language
................................
...............

38

3.1.2

Positioning of the ProcOnto

................................
..............................

39

3.2

ProcOnto Categories

................................
................................
...............

41

3.3

Ontology definition

................................
................................
...................

42

3.3.1

Header

................................
................................
..............................

42

3.3.2

Content

................................
................................
.............................

44





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

6

of

112

3.3.2.1

Terminological Annotation

................................
..........................

44

3.3.2.2

Functional Annotation

................................
................................
.

45

3.3.3

Related Knowledge resources

................................
..........................

46

3.3.3.1

KPIs

................................
................................
............................

46

3.3.3.2

Participant

................................
................................
...................

46

3.3.3.3

Control Flow Dependencies

................................
........................

47

3.3.3.4

Item Flow Dependencies

................................
............................

47

3.4

Examples of Process Semantic Descriptors

................................
............

48

4

KPIO
NTO

................................
................................
................................
........

51

4.1

Analysis of requirements and KPI characteristics

................................
....

51

4.1.1

Priority Dimensions

................................
................................
...........

52

4.1.2

Classes and Sub Classes

................................
................................
.

53

4.1.3

Examples of indicators

................................
................................
......

55

4.2

Ontology schema

................................
................................
....................

58

4.2.1

KPIOnto Categories

................................
................................
..........

59

4.2.1.1

Indicator

................................
................................
......................

59

4.2.1.2

Priority

................................
................................
.........................

60

4.2.1.3

Dimension

................................
................................
...................

61

4.2.1.4

Formula

................................
................................
.......................

62

4.2.2

Related Knowledge resources

................................
..........................

63

4.3

An example of Semantic Descriptor of KPI

................................
.............

64

4.4

Next steps

................................
................................
...............................

65

5

D
OMAIN
S
PECIFIC
O
NTOLOGIES

................................
................................
........

66

5.1

Furniture domain

................................
................................
.....................

66

5.2

Machine Vision, Robotics and Measures

................................
................

69

6

S
EMANTIC
S
ERVICES

................................
................................
........................

71

6.1

An overview of the searching and reasoning services

.............................

71

6.1.1

Searching

................................
................................
..........................

71

6.1.2

Querying

................................
................................
...........................

72

6.1.3

Consistency checking

................................
................................
.......

74

6.1.4

KPI reasoning

................................
................................
...................

74

6.2

Knowledge representation and semantics
-
based reasoning methods

....

76

6.2.1

Representation languages for knowledge resources

........................

76

6.2.1.1

Ontology modelling with OWL/RDF

................................
............

76

6.2.1.2

Process modeling with BPAL

................................
......................

78

6.2.1.3

Rule
-
based modelling of consistency constraints

.......................

81

6.2.1.4

Modelling KPI definitions

................................
.............................

82

6.2.2

Semantics
-
based reasoning methods

................................
...............

82

6.2.2.1

The SemSim method for semantic search

................................
..

82

6.2.2.2

A logic
-
based framework for semantic reas
oning

.......................

85





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

7

of

112

6.2.2.3

Querying the PIKR

................................
................................
......

87

6.2.2.4

LP
-
based consistency ch
ecking

................................
..................

89

6.2.2.5

KPI equivalence and manipulation

................................
..............

90

7

A
RCHITECTURAL

AND
T
ECHNOLOGICAL ISSUES

................................
..................

93

7.1

Functional Overview

................................
................................
................

93

7.2

Storage S
ystem

................................
................................
.......................

94

7.2.1

Import Modules

................................
................................
.................

94

7.2.2

Storage Modules

................................
................................
...............

95

7.3

Reasoner

................................
................................
................................
.

95

7.3.1

Inference Engine

................................
................................
...............

95

7.3.1.1

XSB Logic Programming System.

................................
...............

96

7.3.2

Storage System Connector

................................
...............................

96

7.3.3

Service Library

................................
................................
..................

97

7.3.3.1

Semantic search module

................................
............................

97

7.3.3.2

Query module

................................
................................
.............

97

7.3.3.3

Consistency checking module

................................
....................

99

7.3.3.4

KPI reasoning module.
................................
................................

99

7.3.4

Semantic Data Handler

................................
................................
.....

99

7.3.5

Service Manager

................................
................................
.............

102

7.4

GUI

................................
................................
................................
........

103

7.4.1

Ontology Building GUI widget

................................
.........................

103

7.4.2

Semantic Annotation GUI widget

................................
....................

103

7.4.3

Reasoning GUI Widget

................................
................................
...

104

7.4.4

Resource Browsing GUI Widget

................................
.....................

104

8

C
ONCLUSIONS AND
N
EXT
S
TEPS

................................
................................
.....

105

R
EFERENCES

................................
................................
................................
...

107





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

8

of

112

1

I
NTRODUCTION

Nowadays, increasingly competitive environments within the global market
characterized by the continuous introduction of new products, request that
en
terprise organizations express a high level of dynamicity and flexibility in
order not to be displaced by their competitors.

On one hand, enterprises need to continuously reconsider their current
production activities with the purpose of reducing costs, ti
me to market,
production scraps. On the other hand
,

they need to go further and think in terms
of disrupting initiatives that can really innovate their current business.

These initiatives have a higher chance to be successful if enterprises centre
their in
novation strategies around knowledge and consider that
,

even if
knowledge

is usually spread throughout the various departments, it has to be
available in a seamless way to all relevant actors.

If this is true for a traditional enterprise,
it applies even m
ore
to

a
virtual
enterprise (VE). A VE is defined as “a temporary
alliance

of
businesses

that
come together to share ski
lls or core competencies and resources in order to
better respond to
business opportunities
, and whose cooperation is supported
by
computer networks

[17]
.
This means that i
n a VE, collaboration,
communication and interaction
s

are not restricted to departments or units of the
same enterprise, but
usually

involve very different organizations, with different
nature, policies, skills, know
-
how and way of

doing business. This creates a

higher order of magnitude of fragmentation and

heterogeneity that needs to be
coped with for reaching the desired degree of effectiveness. For this reason, a
VE environment requires a very high level of knowledge sharing, efficient
access to knowledge resources, and overcome interoperability issues co
ming
from the heterogeneity of the involved entities and knowledge resources. To this
end, effective knowledge management solutions are required. The following
considerations reinforce the differences between traditional enterprises and
VEs, focusing on th
e fact that knowledge sharing in a VE environment is a more
challenging objective:



A VE is a dynamic organizational structure where members may join or
leave freely, which hinders the establishment and development of a solid
infrastructure for knowledge
sharing among its members.



Different members might adopt different knowledge management
strategies and technologies. The heterogeneity of knowledge
representation inhibits direct interaction and exploitation of the shared
knowledge.



The risk of losing core

competences by sharing knowledge with partners
requires a balance between controlling the access to each member’s
knowledge resources and opening up these resources to partners so as
to maximize the added value of business activities.

It is now necessary
to introduce a clarification about two terms: knowledge and
semantics
, As already discussed in
[60]
. We use the term knowledge to denote
different kinds of informa
tion, documents content, competencies and skills of
people, capabilities of an organization. Information may concern products and




BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

9

of

112

production processes, marketing and commercial strategies, partners and
competitors, enterprise economics and finances, techno
logical infrastructures
and IT systems. We expect that the enterprise knowledge is largely in digital
form, but we are aware that there is a part of the knowledge, often referred to as
tacit knowledge, that remains concealed in the heads of people.

Howeve
r, enterprise knowledge (when explicit and digitalized) can be
represented in many different forms, from highly structured, such as a database
or an electronic sheet, to semi
-
structured, e.g., in the form of tables or XML
files, to unstructured, in the for
m of a textual report, an image or a video. But,
even if explicit and digitalized, such a knowledge (or collection of digital
artefacts) mainly refer to representation formats that are conceived for a
comfortable usage by humans. For example, a PDF documen
t cannot be
queried for answering to a certain question, even if the content of the document
contains the needed information.

On the other hand, the term
semantics

refers to a very specific form of
knowledge, which captures the essence of a fragment of th
e reality on a
document in a fully structured, and formal way

(see
Figure
1
)
. A semantic
structure is capable of capturing in rigorous, formal terms, t
he essence of the
content of, e.g., a textual document. We use the term semantics typically for the
part of knowledge that is stored in an ontology, or can be described in term of
ontological structures. To this end, such a knowledge must be encoded by
usi
ng a formal, machine
-
processable representation language. The formality of
such lang
uages (such as RDF(S), OWL

[29]
, etc.
) is necessary to allow
advanced semantic
services to be developed on top of reference ontologies.

The above clarification about knowledge and semantics is important for the
purpose of this document for the following reasons.



When we talk about knowledge we mean explicit and digitalized
enterprise knowledge. We refer to this as a collection of Digital
Documental Resources (DDRs), which consist of electronic matters that
provide information or evidence. So, a DDR can be
of many
different
types
: a feasibility study, a report of a brainstorming session reporting
proposals of innovation ideas, a model of a production process, a bill of
material, a document describing performance indicators (for instance, the
ones adopted by the VE f
or evaluating its
own
effectiveness), production
data coming from the ERP systems of the VE members.



However, DDRs in general present certain limits due to the fact that they
are mainly produced for human consumption (e.g., unstructured
documents), and con
sequently we intend to focus on their semantics
because it provides a number of benefits:

o

It c
aptures the essence of the content of DDRs;

o

It r
epresents the DDRs in a formal and fully processable format
(ontology
-
based representation);

o

It e
nables advanced s
ervices such as, search, query, and
reasoning facilities for deriving additional knowledge and making it
explicit.





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

10

of

112


Figure
1
:

From Reality to Virtuality

According to the previous argumentations, the purpose of this document is to
present
the conceptual specifications of a
knowledge
-
based infrastructure,
namely the Production and Innovation Knowledge Repository

(PIKR
) to support
knowledge management in Virtual Enterprise Environments. The proposal
adheres to the Linked Data approach

[11]
Error! Reference source not found.

which recommends a set of best practices for exposing, sharing, and
connecting pieces of data, information, and knowledge by using semantic web
technologies. The PIKR will provide, on one han
d a set of reference structures
(i.e., ontologies) for the semantic description (semantic annotation) of enterprise
knowledge resources, and on the other hand
,

semantics
-
based services for
accessing and reasoning over such descriptions.

For the definition
of the PIKR specifications, we start by referring to the work
that is being conducted in WP2
(
Business Innovation models and methods
)
and
WP6

(
Architecture, IT Platforms federation and services
)
, which is about the
definition of the BIVEE Virtual Enterpris
e Modelling Framework (VEMF), and the
identification of u
ser requirements, respectively.

1.1

BIVEE approach to business innovation and production
improvement

The BIVEE project

looks at

a VE

from
t
wo different but interconnected

perspectives
, improvement of production and innovation, and for this reason it
distinguishes between Value Production Space (VPS) and Business Innovation
Space (BIS).

Accordingly, the targets differ in these two spaces. The “Improvement” concept
is the focus when oper
ating in the VPS, while the target is “Innovation” in the




BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

11

of

112

BIS. In the BIVEE deliverable D2.1
[7]
, an improvement is defined as a set of
small changes which can dire
ctly be applied to the production processes. In
contrast, innovation processes are inherently different from the production
related processes in the sense that an innovation leads to a major change in the
structure of the ongoing production processes, new
production processes and
activities with construction of new VEs. Although there cannot be a distinct line
between the improvement and innovation processes, having such a
classification leads to a clearer understanding of the processes and an accurate
form
alization of the management of these processes.

1.1.1

Innovation
w
aves

BIVEE introduces the “waves” concept for the BIS. According to this
conceptualization, the BIS activities of a virtual enterprise are divided into four
waves as presented in
[7]
. The waves concept accepts that innovation activities
are divided into four distinct
moments
. The innovation starts with the creativity
related activities such as open discussio
ns on ideas. Then, a feasibility wave
can be applied on an idea, if it is given a positive evaluation at the end of the
creativity wave. After the feasibility studies, there is a prototyping wave in which
the initial idea is put into a concrete form and re
ady to be tested. Finally, an
engineering wave applies several optimizations on the prototype(s) to put
product/process/service/technology into

the

market.

D2.1

[7]
Error! Reference source not found.

details the four waves as in the
following:



Creativity
: The first wave starts with
an innovation idea or a problem to
be solved, proving a first specification. It mainly
refers to
creative
activities

and first connections between different units, affiliated to the
innovation process.



Feasibility
: At this point, the scope and the intended

impact are to be
defined. Additional planning justifies the undertaking and predicts the
chance of success.



Prototyping
: This wave features the first implementation of the initial
ideas. This is when the idea is drawn into the real world for the first tim
e.



Engineering
: This final wave contains testing and overhaul
-
procedures.
It concludes with the generation of production plans and the actual
production of a final product.

1.1.2

Production phases

T
he
VPS mostly
concerns
the supply chain management processes
,

wh
ich
already have widely accepted categorizations and document
s

in terms of
production phases, e.g., Universal Business Language (UBL)
[46]
Error!
Reference source not found.
. For the VPS processes, we adopt the following
phases:



Planning
: This phase includes strategies and evaluation processes for
the production. The expected cost analysis, expected time for pr
oduction,
datasheets of the parts of the product and several strategies and
forecasting related activities take place in this planning phase. Based on




BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

12

of

112

the planning activities, a final decision is made to go to the Supplying
phase.



Supplying
: In this phase
ordering and supplying related activities are
included. Ordering of goods or services is covered. For the production,
several components can be ordered from within the VE, or from external
enterprises. This is the sourcing of ordered goods with related
com
ponent specifications, budget distribution etc.



Building
: This is the core production phase. All production activities
performed by the VE are covered within this phase. Protocols and
specifications of the product components are checked and applied to
prod
uce the outcome. Quality controls and need for additional materials
are determined. Therefore, the supplying phase may also come back into
play during the building phase.



Delivering
: Transportation of the products is performed within this
phase. Several di
fferent enterprises within the VE might be in charge of
the delivery of the goods or services produced
.

1.2

Ana
lysis of user requirements

This section is dedicated to the analysis of user requirements identified in
the
BIVEE Deliverable
D6.11

[9]
, where requirements at VPS and BIS level have
been indicated. In particular, some requirements have been extracted and
reported in
Table
1

and
Table
2

w
ith the aim of highlighting expected
functionalities that the BIVEE plat
form should provide and that could be
supported by the PIKR.

According to these requirements, it is expected that the BIVEE platform:



Is able to take into account
different kinds of
enterprise
knowledge
resources
,
such as structured and unstructured documents
(requirements 1, 2, 3, and 6
in

Table
1
),
domain specific knowledge,
such as competencies, products

(requ
irement 7
in

Table
1
, and
requirement 4 in

Table
2
), data
for monitoring running activities
(requirements
10 and 11 in
Table
1
, and requirement 5 in
Table
2
),
business processes (requirements 1

and
2 in
Table
2
)
.



Allows the management of VE knowledge resources by means of
classification and annotati
on mechanisms, taking into consideration
application domain content of knowledge resources (requirements 1, 3 in
Table
1
).



Supports access and retrieval of resources by means of advanced
search functions, based on exact and similarity matching (requirements
3, 4, 8 in
Table
1
, and requirements 3, 4 in
Table
2
).



Takes track of links among knowledge resources (especially among
documents) for
supporting retrieval functions

(requirement 5 in Table 1).



Supports the evaluation of indicators for assessing the status of the
activities in a VEE (requirements 11, 12 in
Table
1

a
nd requirement 5 in
Table
2
).



Provides reasoning capabilities over business processes for supporting
their re
-
use and assessment (requirement 2 in
Table
2
).






BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

13

of

112



User Requirement

at BIS level

1

BIVEE platform should provide service for the ideas to be analyzed according to its
content. Classification
and semantic annotation should be performed on the idea
documents in order to provide further semantic functionalities.

2

BIVEE platform should consider that the ideas (feedbacks, comments) may not only
be unstructured text files, but also full business
plans including target
domains/customers, business models, competitors, marketing analysis, forecasts etc
.

3

BIVEE platform should notify the user about similar ideas before posting a new idea.
Semantic technologies such as semantic search and classificat
ion might be helpful at
this phase.

4

The innovation team and
/or other members of the research team can search the
ideas in order to find an innovative idea about a specific problem faced.

5

To facilitate the evaluation and implementation of the innovati
on process, BIVEE
should provide services for an issue to be organized in several sub
-
projects (sub
-
issues). That means a semantic relation should be managed among the documents
of the platform (among the sub
-
issues in this case).

6

B
I
V
EE platform should
enable the tracking of the meetings. Each scheduled meeting
should be inserted into the platform that remembers the event with its participants
and requires a report with the arguments discussed, decisions taken etc.

7

BIVEE platform should allow mapping
and seeing the competencies available in the
group. This information is crucial to analyze the feasibility of the ideas, or
improvement opportunities of ongoing activities.

8

BIVEE platform should provide services so that when a number of ideas (with
possibly some incomplete ones) are received, the tagging/classifying mechanism
helps other members display comments grouped by their tags and improve the faulty
ones with comments.

9

BIVEE platform should provide services so that the users can configure t
he
preferences to subscribe to the related topics and the way of receiving notifications.

11

BIVEE platform should provide services for the milestones of the projects to be
defined and inserted in the platform. The checks of the milestones should be done
through the platform.

12

BIVEE platform should provide services so that the financial people can learn the
status of the project in order to understand if the project is in line with the budget or
not and to forecast possible deviation. To do so, the mon
itoring platform will be able
to show the status of the indicators and the platform will be able to display the current
situation in the project using business process tools.

Table
1
:
User Requirements at BIS level (extract
ed

from D6.11)



User Requirement

at VPS level

1

BIVEE platform should support some standards to import processes. Process
definitions may be formalized in several different languages. BIVEE platform should
support major languages to increase the
interoperability
.

2

BIVEE platform should keep the track of old processes regarding the value production
space, so that no processes will be lost and processes can be re
-
used in the future
.

3

BIVEE platform should enable advanced search operations for an
y type of partners
(e.g. suppliers, carriers). Search is a very important aspect in VPS.

4

BIVEE platform should provide necessary search services for the products. The
platform could be useful while searching for products (general search) or even the
sea
rch of product design according to any destination. In this sense and similarly and
in the same way as in the supplier search, the use of semantic web techniques may be
useful to characterize and efficiently perform searches triggered by the manufacturers




BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

14

of

112

allowing the contact between both actors if the supplier offer covers the manufacturer
needs.

5

BIVEE platform should provide services so that the users can get detailed data about
the items displayed in VPS. Data can be KPIs, Comments, Ratings, Possible
values
for the item etc. For example, delays in delivery dates or material defects should be
captured by the BIVEE platform and related users should be notified
.

Table
2
: User requirements at VPS level (extract
ed

from D6.11)

This analysis of the user requirements
is taken into
consideration in the
knowledge organization of the PIKR, and the definition of the services it
exposes.

1.3

PIKR Overview

The mission of the PIKR is to create a semantics
-
based unified view of the
informati
on and knowledge that flow within a
nd among the VPS and BIS of a
VE
.


Figure
2
: PIKR Overview

The
role of the PIKR is to provide a semantics
-
based infrastructure for:



Annotating DDRs both from the VPS and the BIS in terms of onto
logy
structures (BIVEE Ontologies);



Providing a set of advanced services for accessing, making available,
and reasoning on the annotated DDRs.

To this end, the structure of the PIKR is organized into two semantic layers:





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

15

of

112



I
-
PIKR
:
the
Intensional PIKR

contains a federation of ontologies that
enable the description of DDRs
;



F
-
PIKR
:
the
Factual PIKR

contains the semantic representation (here
referred to as Semantic Descriptors) of the DDRs, in terms of the I
-
PIKR
ontologies.

The ontologies in the I
-
PIKR are partitioned into
Knowledge Resource
Ontologies

(KROs), and
Domain Specific Ontologies

(DomOnto). KROs have a
generic scope (they do not commit to any specific application domain) and
declare what kind of information, links,

and constraints, for each type of DDR
(i.e., Processes, Documents, and KPIs),
are

intend
ed

to
be
semantically
represent
ed
. DomOnto address specific application domains (e.g., the domain
of furniture and the domain of electrical and mechanical design of th
e BIVEE
end
-
users) and allow Semantic Descriptors to be enriched with domain specific
contents.

As a federation, the BIVEE ontologies are connected among each other,
enabling the creation of links among annotated DDRs.

In

Figure
2
, the approach of the PIKR is sketched.
Different DDRs pertaining to
the VPS and BIS are semantically annotated by using the ontologies in the I
-
PIKR, maintained in the F
-
PIKR
and made available to the VPS and BIS again
by means of semantics
-
based services. The effect of the semantic description
of the DDRs is also to establish links among different DDRs in accordance with
the dependencies defined at ontology level. This provide
s an integrated image
of the DDRs which is seen by the PIKR through their Semantic Descriptors.

1.4

PIKR Knowledge Framework

While in the previous section

the generic approach of the PIKR has been
outlined, this section is devoted to describe the knowledge fra
mework of the
PIKR in more details. By “knowledge framework” we intend the conceptual
structure used to organize a digital
repository and enable an effective access to
and navigation through its contents.

A knowledge framework is an essential component of a knowledge
management solution. The framework provides the representation mechanisms
for describing contents (i.e., DDRs), and
enabling

certain reasoning
mechanisms.

In the case of the PIKR, the Knowledge

Reference Framework is represented
by the structure of the two PIKR layers, the I
-
PIKR and the F
-
PIKR.

1.4.1

Intensional PIKR

The enterprises that participate in the VE have different methods and tools to
represent information and knowledge. The PIKR has the pr
imary objective to
act as a common hub for
the management of knowledge resources in a VE,
taking into considerations the indications coming from the user requirements as
analysed in Section
1.2
. In this perspective, an important role is played by the
ontologies managed within the PIKR. The Intensional PIKR (I
-
PIKR) is
organized as a set of interlinked reference ontologies. As anticipated, they are




BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

16

of

112

partitioned into K
nowledge Resource Ontologies (KROs) and Domain Specific
Ontologies (DomOnto).

KROs are mainly devoted to the semantic description of the following kinds of
DDRs: (i) documents, in the sense of reports (mainly textual), described by an
ontology called
DocOn
to
; business process models, described by an ontology
called
ProcOnto
, and performance indicators, described by an ontology called
KPIOnto
.


These ontologies are briefly introduced here, while in Sections
2
,

3
, and
4

they
will be described in more details.

DocOnto



This ontology defines in formal terms all the document templates,
with their structure, organization and dependencies, that will be used for
annotating the documents in the sc
ope of the VPS and the BIS.
The documents
are grouped in accordance with the four waves of the BIS and the four phases
of the VPS

[7]
. The document templates indic
ate which information is
mandatory and which one is optional. Dependencies indicate that a document,
to be accomplished, needs to consult (in case, including part of) the content of
other documents. A dependency does not require that the preceding doc
ument

is definitively completed before releasing it for consultation, provided that its
partial completion status is clearly indicated. A document will contain knowledge
of different nature, that will be defined with the following additional ontologies.

ProcOnt
o



This ontology defines how to semantically annotate a business
process model, for describing its tasks and their dependencies, input and output
resources and relationships with the other Semantic Descriptors.

KPIOnto



One key issue of BIVEE is the defi
nition of a system of indicators
having the purpose
of

making manageable and
keep
ing

under control the
production and innovation activities
. Costs, time, resources
, such as proposed
ideas (just for naming some examples of items to be measured),

need to be
constantly compared with the achieved results and the expected activities that
need to be accomplished to reach a successful conclusion. KPIs are intended to
keep everything (hopefully, or at least as much as possible) under control,
providing
alarms in case of critical events and, in general, a good basis for
decision making.

DomOnto



This ontology defines the classes of actors, entities, and processes
that characterise the industrial sector in which the VPS and the BIS operate.
This is an imp
ortant reference resource that allows the participating SMEs to
achieve a uniform management of information and knowledge despite their local
differences. In particular, in the BIVEE project, we address two application
domains

carried on by the two end use
rs AIDIMA and LOCCIONI. The
application domains are
: furniture in the scope of AIDIMA and mechanical and
electrical design in the scope of LOCCIONI.

It is worthy to underline that these ontologies are defined for the first prototype

of the PIKR
, but they c
ould

be complemented by additional
specialized
ontologies if required by the evolution of user requirements
.





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

17

of

112

Independently of their specificities, due to the different nature of the knowledge
resource types, the KROs will aim to catch certain categories of

information so
that the Semantic Descriptor will be characterized by a common structure
organized into the following sections:



Header
: collects information represented by traditional metadata like the
ones proposed by the Dublin Core Vocabulary
1

(e.g., na
me, natural
language description). This section will also contain the link to the actual
DDR that is assumed to be stored out of the PIKR.



Content
: collects information about the content of the described DDR in
terms of the DomOnto. In this section one can say that a given technical
report is about the design of a specific product, e.g., an innovative
contour chair in carbon fibre.



Related Knowledg
e Resources
: collects links to related Semantic
Descriptors, allowing the representation of semantic associations and
dependencies among resources (the input document of an activity, an
indicator occurring in a formula which defines a KPI, the temporal
dep
endency between a feasibility study and a project proposal).



External links
: links to resources external to the VE and possibly
available on the internet (e.g., technical documentation, external policies
or regulations, web
-
sites, bibliographic references)
.

Domain Specific Content and Related Knowledge Resources items can be
enriched with business rules which give the possibility to characterize the
structure of the S
emantic
D
escriptor
s

with respect to the particular reality of a
virtual enterprise. These c
onstraints depend on the specific application domain,
the dimensions of the VE, the VE internal policies. For example a feasibility
study for justifying the prototyping of a product needs financial information if the
expected cost is higher than a certain
amount (e.g., 300000 euro). This means
that not for all the feasibility studies, even in the same VE, financial information
is always mandatory.

1.4.2

Factual PIKR

The F
-
PIKR contains the Semantic Descriptors (SD) of the DDRs. These are in
accordance with the on
tologies in I
-
PIKR which represents the structure of the
S
emantic
D
escriptor
s.

1.5

PIKR reasoning services

In order to meet the
user requirements reported in Section
1.2
, the PIKR
provides a set of semantics
-
based services which enable the retrieval and the
processing of information
it stores
. These services offer functionalities which
can be used

for both production
and innovation management.

The PIKR makes available four main types of semantics
-
enabled services,
Searching, Querying, Consistency Checking, and KPI Reasoning, which are
here introduced and detailed in Section
6
.




1

http://dublincore.org/





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

18

of

112



Searching services

allow the user to perform keyword
-
based search,
similarly to traditional web information retrieval engines, enhanced by
exploiting the semantic information. The user request is expressed as an
onto
logy
-
based feature vector

describing the criteria for the selection of
the DDRs of interest. The search engine returns a list of ranked results
by applying
a
semantic similarity method.



Querying services

allow the user to retrieve conceptual and factual
kn
owledge, as well as the related DDRs, that satisfy properties specified
in terms of the ontologies defined in the PIKR. The underlying reasoning
engine returns a list of answers that satisfy all specified properties. The
main differences with respect to se
arching is that the querying criteria
can be much more sophisticated from a logical point of view and the
answers match the specified criteria in an exact way, not up to a certain
degree of similarity.



Consistency checking

services

allow the user to verify
, by means of a
logic
-
based reasoner, the compliance of the factual knowledge stored in
the F
-
PIKR with respect to business rules and other constraints. The
result of a consistency check is a yes/no answer. In the case where a
‘no’ answer is returned, the
reasoner also provides semantic descriptors
that do not satisfy the given constraint.



KPI reasoning services.
This module provides inference services for
supporting KPI elicitation (i.e., the identification of the KPIs which are
suitable for a given VE), b
y analyzing KPIs from different perspectives
(e.g., organization and time dimensions). This module also supports the
harmonization of the measures provided by VE
members

which are
needed for the evaluation of KPIs. Indeed, since measures can be
originated
by different data sources (e.g., proprietary information
systems) from different enterprises in the VE, they need to land on a
reference representation compliant with the KPI formulas.

1.6

Positioning of the PIKR in the BIVEE Architecture

Figure
3
, which comes from
BIVEE Deliverable
D6.20

[8]
, reports the

macro
architecture of the BIVEE platform, in which the main components are shown. In
particular, we recall about the Mission Control Room (MCR) and the Virtual
Innovation Factory

(VIF), which are in charge of supporting the VPS, and the
BIS, respectively.






BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

19

of

112


Figure
3
: BIVEE Macro Architecture

As a knowledge repository, the PIKR will mainly serve these two components
by allowing, first the annotation of th
e DDRs in their scope and then a set of
services for enabling semantic reasoning on them. The PIKR will play as a
semantic directory of the knowledge resources in the VE. It will not store the
actual DDRs (e.g., documents, models of processes), but a seman
tic
description of them, and a link to them in order to be able to access to such
resources.

The rest of the doc
ument is organized as follows: S
ection
s

2
,
3
,
4
, and
5

report
about the current work on the DocOnto, ProcOnto, KPIOnto and DomOnto,
respectively, while
S
ection
6

reports about the description of the reasoning
services offered by the PIKR. Section
7

is about the architectural issues of the
PIKR.
Section
8

reports about the c
onclusions and next steps
.







BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

20

of

112

2

D
OC
O
NTO

The document ontology (DocOnto) provides the

semantic means for the
semantic categorization and annotation of the “documents” identified through
the requirements analysis of BIVEE. During the requirements analysis, a
document centric approach has been adopted. In the upcoming subsections,
after desc
ribing this approach, initial design of DocOnto is presented

2.1

Document Centric Approach

BIVEE adopts a document centric approach which focuses on the documents
exchanged during the improvement and innovation activities within a virtual
enterprise. The objec
tive is to clearly identify and give formal definitions for
these documents. By formal definitions, we mean
that
the structure of each
document and meaning of each field will be determined through the BIVEE
ontologies.

Before identifying the document

onto
logy
, we start from the analysis of how
improvement and innovation
are
currently carried on by

BIVEE’s end users

AIDIMA and LOCCIONI. This activity is being conducted in conjunction with
BIVEE Task 6.2 (Analysis of User Requirements) and Task
.
7.1
(Definition of
BIVEE Pilot Validation Application Cases).

AIDIMA and LOCCIONI have
different processes in VPS and BIS. Furthermore, they have different kinds of
processes internally. For example, an innovation activity in LOCCIONI can
follow different path
s based on the starting point of the process. Or, AIDIMA
sets up different processes for each different project during the implementation
of the prototypes in the VPS.

Having identified the key processes,
the
identification of the documents comes
in turn.

Important documents which are exchanged between the employees of
different enterprises inside the virtual enterprise are marked and listed
according to the waves of

the

BIS and phases of
the
VPS.

Document exchange is not restricted to the cross
-
enterpris
e processes. As
defined in
the
BIVEE VPS specification, different departments of the same
enterprise can play a business unit role in the VPS and BIS. This can also be
derived from the fact that different departments of one enterprise can be in
independent

roles in a virtual enterprise environment.

The document centric approach of BIVEE adopts the Core Components
Technical Specification (CCTS)

[65]

methodology which

is produced by
UN/CEFACT
. According to the specification, CCTS can be employed wherever
data is being defined, stored, used, shared or exchanged. The objective of
the
CCTS approach is to identify, capture and maximize the re
-
use of business
information to

support and enhance information interoperability. The
foundational concept of CCTS is the core component (as its name implies).
Core components are semantic building blocks
which
can be used to build
document models (hence documents) through aggregations
and associations

of
the building blocks
.

The CCTS approach says that core components act as conceptual models
which

are used to define Business Information Entities (BIEs). BIEs are created




BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

21

of

112

through the application of context and may be qualified to guaran
tee unique
business semantics.

A Core Component

(CC)

contains only the information
pieces necessary to describe a specific concept. For example, while talking
about an “address” concept, a core component can be defined as follows:

Address: Street(Text), Po
st Code(Text), Town(Text), Country(
Text
)
, ...

Core components are defined to be context
-
independent so that they can later
be restricted to different contexts. Some example contexts can be listed as
follow
s:



Business

Process Context



Product Classication Context



Industry Classication Context



Business Innovation Context



Creativity Context (e.g. context definitions can be hierarchical)



...

A Business Information Entity

(BIE)

is the new form of a C
ore
C
omponent

when
context is applied. For example, if a new
reference model

is being constructed
based on CCTS,

then
A
ddress

component can be turned into a
UK_address

for
United Kingdom addresses. In this BIE
, on
ly a subset of the elements of
A
ddre
s
s

CC can be selected and data types of the selected elements can be
further restricted.

UK_Address: Street(Number), ZIP Code(Number), Town(Text),
Country(Indentifier), ...


F
ollowing the CCTS approach
, BIVEE
identifies the basic

information entities

(not f
urther structured components)

so that

the semantic structure of
each
document will be constructed by aggregation and association of

those entities
.

BIVEE names these entities as “Information Item”s. An Information Item is a
semantic building block th
a
t can

be used for all aspects of data and information
modelling and exchange. Similar to the core components of CCTS, Information
Items are the linchpin for creating interoperable business documents. Complex
data models for the business documents are constructe
d through the
association and aggregation of these items. Considering the CCTS design, we
can talk about
two

different types of
Information Items:



Basic Information Item (BII): This is the smallest meaningful Information
Item which cannot be decomposed int
o any other items. In data
modelling terms, a BII is the equivalent of an item attribute or a class
property/attribute (UML).



Aggregate Information Item (AII): This is a collection of related pieces of
information which together expose a meaning. That is,
a document is an
AII.

Associations between Information Items are actually semantic relations which
will be described later.





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

22

of

112


2.1.1

Document Categories

BIVEE applies several categorizations to the documents. A first categorization
comes from the VPS and BIS divis
ion. A document will either belong to the VPS
or to the BIS. “
spaceCategory
“ is used to indicate this categorization.

As stated in the previous section, the VPS and the BIS are divided into different
phases.
The document ontology (DocOnto) classifies each
document in the BIS
according to the innovation waves. Therefore, the ontology will annotate each
document with a
waveCategory
, whose value will be selected from the set
{Creativity, Feasibility, Prototyping, Engineering}. According to this
scheme
exactly

one wave category is associated with each document. This means there
is a need for a common understanding within the virtual enterprise in the sense
that each produced document will strictly belong to one innovation wave.

Belonging to an innovation wave, b
ut the same is true also for a production
phase, means that the document is created in that wave (or phase), even if it
can be used in any other wave (or phase).

Each enterprise will have the
knowledge of waves and activities will be tracked based on this knowledge.

The categorization scheme (four phases)

for the VPS

is in line with the OASIS
Universal Business Language (UBL)

[46]
, which provides a similar
categorization of the process definitions and document definitions. However,
UBL’s target is the supply chain management while in BIVEE our focus is on the
improvement p
rocesses within a VE, regarding the VPS activities. Rather than
the details of activities

such as invoicing, billing, freight management, etc., we
try to provide a conceptual management of the knowledge regarding the VPS at
a higher level. We address the “
improvement” related activities within the VE.

Referring to the experience of BIVE
E

and end
-
user organizations, in the
document centric approach, it is aimed at proposing extensions to UBL with
respect to improvement related context.

In the following, we d
escribe
the
relation of our categorization scheme described above with the UBL
categorization scheme:



Planning activities are mostly covered by the Sourcing/Catalogue
process of UBL. However, our planning phase includes additional
activities related to the

strategy of the VE through the production and
forecasting about the VPS activities.



The Sourcing phase corresponds to the Ordering and Billing phases of
the UBL processes. As mentioned earlier, we do not take into
consideration all processes defined withi
n UBL because we mostly deal
with improvement related activities.



The Building phase does not have an exact correspondence in UBL
processes. This is where we expect to have most of the improvement
activities. That’s why the definition of the documents of t
his phase is very
relevant.



The Delivery phase is covered by UBL Freight
Management/Transportation processes. We do not address most of the
activities within the UBL processes because they are very detailed to
cover all possible cases within a supply chain

management environment.





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

23

of

112

The
DocOnto

will

annotate each VPS document with a
phaseCategory
, whose
value will be selected from the set {Planning, Sourcing, Building, Delivery}.

The BIS has the four innovation waves, while the VPS has the phases adopted
from

OASIS Universal Business Language processes. A second categorization
of a document is performed according to the wave/phase it belongs to in the
BIS/VPS. “
waveCategory
” and “
phaseCategory”

are used to indicate the
categorization in the BIS and VPS respect
ively.

In parallel with the above categorization, BIVEE employs a different
categorization for each document indicating whether it is a
proposal

for the
information enclosed in that document, or it is an
assessment
,
feedback

about
the document, or an
upda
te

of a previous version of the document. If the
document category is an assessment or an update, it will have the appropriate
dependency from the document of which it is an assessment or update.

For the identification of the different kinds of documents,
WP5 is working in
conjunction with
BIVEE
WP6 and WP7
(
User Requirements, Application and
Validation Cases
)
by analyzing the documents that are currently used by
AIDIMA and LOCCIONI. As a first result, we identified a set of documents, both
from AIDIMA and
LOCCIONI,

related to the four innovation waves.

The waveCategory assignment of AIDIMA documents (hence this
categorization is the spaceCateogrization=BIS of AIDIMA) is as follows:


Creativity

Feasibility

Business Ecosystem

Project Proposal

Partner
Profile

Project Partner Request

Research Line

Candidacy Proposal

Proposed Idea

SWOT Analysis

Validated Idea


Customer Issue


Table
3
: Creativity & Feasibility waveCategorization of AIDIMA


Prototyping

Engineering

Prototype
Requirements

Prototype Modification

Implementation Roadmap

Product data
-
sheet

Monitoring Sheet

New Product Acceptance

Project Card

Working Report

Gantt Chart


Technical Report


Results Report


Table
4
: Prototyping &
Engineering waveCategorization of AIDIMA

The waveCategory assignment of LOCCIONI documents (hence this
categorization is the spaceCate
g
o
rization=BIS of LOCCIONI) is as follows:








BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

24

of

112

Creativity

Feas
i
bility

Business Ecosystem

Market Analysis

Partner Profile

Gantt

Research Line

Solution Subprojects

Proposed Idea

Feasibility Study

Solution (Technical Solution)


Research For Innovation Report


Marketing Report


Innovation Report


Budget


Internal Order


Resources


Table
5
:
Creativity & Feasibility waveCategorization of LOCCIONI


Prototyping

Engineering

Prototype Requirements

Budget

Implementation Roadmap

Bill of Materials

Monitoring Sheet

Cost Analysis

Gantt Chart

Commercial Components Requirements (CCR)

Technical
Report

Protocols

Results Report

Prototype Modification

Table
6
: Prototyping & Engineering waveCategorization of LOCCIONI

2.2

Representational Framework

2.2.1

Header

The DocOnto adopts Dublin Core Metadata Element Set
2

which is a vocabulary
of fifteen properties for use in resource description. These DC metadata
elements (actually a subset of the fifteen elements) and our extensions are
described in the context of BIVEE (especially DocOnto) as follows:

title
: The formal

name of the document.

This is an exact match to dc:title.

E
ach
document is clearly
classified

within the DocOnto,
f
or example, “Idea” is a
classification
for a document under BIS as spaceCategory and Creativity as
wave Category.

Title of an “Idea” documen
t might expose the content of the
idea, i.e. “A new TV chair system for disabled people”.

description
: A free
-
text account of the document.

This is
an

exact match to
dc:description.

creator
: The actor (referenced from the DomOnto) who is primarily responsi
ble
for making the document.

This is an exact match to dc:creator with the use of a
controlled vocabulary for the values from the DomOnto.

contributor
: An entity responsible for making contributions to the resource.
This corresponds to the actors from the
DomOnto who has contributed to the
document.

This is an exact match to dc:contributor with the use of a controlled
vocabulary for the values from the DomOnto.
date
: The delivery date of the
document. In DocOnto we assume that this date field will reflect
the date
-
time
when the document is transferred from its source to the destination.

This is an



2

http://dublincore.org/documents/dces/





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

25

of

112

exact match to dc:date. DC says that “
A point or period of time associated with
an event in the lifecycle of the resource”. In DocOnto, the event is the delivery
of the document.
format
: The mime
-
type of the document. Whether it is a plain
text, pdf, ms
-
word, ms
-
excel or any other type. That means, we adopt a
controlled vocabulary (MIME
3
) to define the format of the document.

This is an
exact match to dc:format whic
h also recommends to take the values from MIME
vocabulary.

identifier
: A unique reference

(identifier) to the document.

This is an exact
match to dc:identifier.

language
: The language of the document. We adopt a controlled vocabulary
(RFC4646
4
) for the lan
guage.

This is an exact match to dc:language.

sender
: In the DocOnto, this refers to the appropriate DomOnto actor to
indicate the sender of the document.

This property does not exist in DC,
however dc:publisher exposes a similar meaning.

receiver
: This is

the receiver actor of the document. The reference is in the
DomOnto.

This property does not exist in DC.

transfer
-
type
: The transfer type of the document from one actor to the other
one. Whether it is through e
-
mail, mail, document portal or a specific Co
ntent
Management System or anything else. This also should be a controlled
vocabulary. This time, the vocabulary will be specific to PIKR to indicate the
transfer type.

This property does not exist in DC.

2.2.2

Content

Each document
identified
within
the
VPS and

the
BIS
refers to
specific content
items. As mentioned earlier, we adopt the CCTS methodology
for developing
our document centric approach,
by

which we try to identify the information
entities
that
can be considered as
basic
information resource
s
, and can be
combined with other information entities to
structure

a document. Therefore,
identification of what information is being carried with a specific document is
very important in this respect.
The content
of a document should be identified in
a fo
rmal and structured way. This work is still being carried out inside WP6
and

WP7 activities.

In the following table
LOCCIONI

lists some fields within
the
mentioned
documents. The end
-
user enterprises have selected their most important
documents from each w
ave of
the
Innovation Space. Then, we
have
started to
formalize the content. Requirements analysis and pilot application development
activities will continuously update the structure and content as BIVEE evolves.








3

http://www.iana.org/assignments/media
-
types/

4

http://www.ietf.org/rfc/rfc4646.txt





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

26

of

112

Document

Fields

Optional Fields

Customer

Issue



Date



General description of the issue



Objective of the solution



Characteristics required from
the solution



People involved



Existing solutions

Solution sub
-
projects



Sub
-
project



Objective



Problems



Solution proposed



Technical properties /
characteristics



People involved



Date

Gantt diagram



Tasks



Timing for each task



People involved



Milestones

Bill of material



Materials



Code of each material


Table
7
: Structure of the LOCCIONI BIS Documents (some examples)


AIDIMA

provides more details about the fields of its selected (most important)
documents.


Research Line (Creativity)

Field name

Description

Area

Number and name of the related Research Area. By default AIDIMA maintains 5
different research areas.

Line
number

It is composed by two numbers X.Y where X is the number of the Area and Y is
the number of the line

Line name

Name of the research line.

Sub
-
lines

If it is the case, the list of sub
-
lines related.

Description



Table
8
:
Structure

of AIDIMA Research Line


SWOT Analysis (Feasibility)

Field name

Description

Name of the idea proposal


Brief description of the idea


Date of the report


Strengths

Staff experience

Weaknesses

List of the unknown areas of the project

Opportunities

Project profits

Threats

Possible problems that may arise during the project
development

Table
9
:
Structure

of AIDIMA SWOT Analysis









BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

27

of

112

Project Card (Prototyping)

Field name

Description

Official name

..

Acronym

..

Financial organization name

..

File / Project name

..

Project responsible

..

Project length

..

Start date

..

End date

..

Strategic lines of the project

This is linked to the number of the previous research lines

Project summary

Brief description of

the project

Project goals


External partners

This field is a list of partners indicating: Name of the
company, Name of the contact person and email.

Deliverables

This field contains a list of deliverables containing the
number, title, expected delivery

date, real delivery date and
a flag indicating if the company is Responsible or
Contributor of each deliverable.

Milestones

List of relevant tasks indicating the number, title, expected
date, real date and the Responsible / Contributor flag.

Quotation

This section contains the initial project quotation, indicating
the concept, the entire quantity, the financed part and the
percentage.

Resources

This field contains a list of the names of the involved staff of
the project and for each one, the expected d
edication time
and the finally dedicated time (hours). It also contains some
information about equipment and other expenses.

Exploitation

This list of possible products / services in which the project
is applicable, with the estimated cost and possible pr
ofit.

Project Organization

This field contains the list of the staff involved in the project
development including their name and job position.

Publications

A list of articles on magazines, etc. related with the project.

Table
10
:
Structure

of AIDIMA Project Card


Working Report (Engineering)

Field name

Description

Date

..

Person name

..

Department

..

Company

AIDIMA (by default)

Stage

Number and name of the project phase

Task (Sub
-

stage)

Number and name of the specific
stage task

Hours

Quantity of hours dedicated to the project task at that date

Table
11
:
Structure

of AIDIMA Working Report

Apart from the formal
and
structured definition of each document, the content of
a document might talk
about our reference dimensions for the improvement and
innovation activities. D2.1

[7]

introduces these dimensions in detail:



Products



Processes



Technologies



Servic
es





BIVEE •
285746


D5.1


Version 2.5, dated 12/06/2012


Page

28

of

112

Based on the business domain of the VE, a single document might be related
with one (or more) of the mentioned dimensions.
Moreover
, different fields of a
document might be mentioning different dimensions. For each of the
dimensions, there are several d
ifferent actions which
can be indicated by the
document
.
The

following set of actions can be performed within each
dimension
:



Define: Definition of a new product, process, technology or service.



Improve: Improvement of a product, process, technology or
service.



Analyze: Analysis on a product, process, technology or service.



Consume: Use of a product, adoption of a process, use of a technology
or consumption of a service.

The meaning
of
an
action
may be

different
when associated with different
dimension
s
.

For example,
a
C
onsume

action
may mean
the use of a product or
a technology,
the
adoption of a process
,

or
the
consumption of an external (or
internal) service.

The content
of each document can be annotated through
the above
schema.
Technologies, Process