M Barthes

Despres Sylvie

Mme Grandbastien

Keywords: firstName, foaf:lastName, foaf:gender, foaf:phone, etc member, foaf:maker, etc OnlineEcommerceAccount, etc.) accountName, etc. -Social network Document, foaf:Image, Subject, Description, Publisher, etc

Knowledge Management (KM) is a concept and a term that arose approximately in early 1980s. Knowledge management is the process of capturing, developing, sharing, and effectively using organizational knowledge. Despite the effectiveness of having a knowledge management system in an enterprise, this system is not enough to protect the enterprise from problems caused by "brain drain". When workers leave an enterprise, they take with them valuable job-related knowledge. In this case, managers and co-workers are left to get new employees for replacement. These new employees should take on the related responsibilities Oracle (2010). Enterprises could face "brain drain" in three cases: (1) An employee retire and take with him/her the history and legacy information of the enterprise. (2) a young employee leave the enterprise and integrates a competitor providing it with his/her intellectual experience and skills. [START_REF] Despres | Réflexions sur les étapes de la construction d'une ontologie modulaire[END_REF] An employee moves from one service to another within the same enterprise.

In order to overcome this potential lose of experience and knowledge within enterprises, the knowledge management system should be reinforced with a knowledge capitalization system. Unfortunately, this is not the case in most enterprises especially Small and Medium-sized Enterprises (SMEs).

A knowledge capitalization study made by the Institute for Corporate Productivity in 2008 showed that:

• 30% of enterprises acknowledged that they do not capitalize knowledge at all or their capitalization is so poor.

• 49% indicated that their capitalization is fair enough.

• 78% of enterprises do not have a specific person or team responsible for knowledge capitalization plans.

• 68% of enterprises do not have dedicated budget for knowledge capitalization issues.

By knowledge capitalization system we mean formal knowledge system with strategies for knowledge sharing to leverage best practices and reduce the risk of intellectual loss Oracle (2010). Knowledge sharing resides at the heart of a knowledge capitalization system.

The study indicated that enterprises that have an effective knowledge capitalization system were large enterprises. These enterprises are able to dedicate teams, departments and budget for knowledge capitalization. Small and Medium sized Enterprises (SMEs), contrary to large ones, do not have the ability to dedicate teams and budgets for knowledge capitalization. This is due to the characteristics of SMEs that often lead to produce problems related to knowledge transmission. These characteristics are represented by informal coordination between the members of SMEs, significant support to tacit knowledge and the high dependence on individuals as key-players of the SMEs' business. Despite this important problem of knowledge capitalization in SMEs, work considering this problematic remains relatively absent from academic contributions.

"You have to let ideas come to the forefront and proliferate, and let anyone with an idea explain and justify their opinion. Otherwise, ideas will migrate outside of the company to competitors or to become startup ideas." says Ramon Barquin, president of Barquin International1

In this situation of possible knowledge loss, organizations should do their best to stay competitive. [START_REF] Alavi | Exploring the relation between organizational learning and knowledge management for improving performance[END_REF] affirms that organizations that learn could have a good competitive situation. The first and direct benefit for having a knowledge capitalization system is to support organizational learning within enterprises. The organizational learning turn reduces the problems related to "brain drain" and protects the enterprises from knowledge loss.

From this fact, CESACO2 project has started in October 2012. The project associates members from Heudiasyc (ICI team), Costech laboratories, France Business School and the SME partner Tour Equipement. This PH.D thesis is part of CESACO project which is co-funded by the Picardie region and the European Union. Europe is engaged in Picardie with the FEDER (Fond européen de développment régional). The main objective of CESACO project is to facilitate the learning process in Small and Medium-sized Enterprises (SMEs). The study of knowledge capitalization in these small structures is therefore the main concern of CESACO project. In order to well understand these small structures, a field study has been established in industrial SMEs situated in the Picardy region in France. This field study took place within 18 SMEs in addition to Tour Equipement enterprise which is a privileged partner to CESACO project. Tour Equipement is a small enterprise specialized in the mechanical production.

This empirical field study had mainly two main objectives. The first objective is to characterize the practices of knowledge capitalization and diffusion within these SMEs.

The second objective is to qualify the requirements and expectations from a digital media technology to support such practices.

The field study illustrated that SMEs need a digital tool for the management and the capitalization of notes and annotations. This study showed that such a tool will support the expression of non-formal knowledge and even the explicitness of tacit knowledge. So the main concern of my PH.D in the CESACO project is to understand: how to support the capitalization of non-formal knowledge contained in notes and annotations within SMEs?

Scientific Problem Statement

The process of organizational learning within an organization is highly affected by its size and structure. In SMEs, the process of organizational learning becomes specific and it needs a non-traditional approach. We can characterize the problem statement of this PH.D thesis by the following question: How to support the organizational learning within SMEs?

Taking into consideration the results of the field study, we took the choice of supporting the organizational learning by the creation, management and sharing of notes and annotations within SMEs using ICT (Information and Communication Technologies).

ICT have invaded our life changing its daily activities. The scientific problem of this PH.D thesis is thus supporting the capitalization of notes and annotations as expression of non-formal knowledge and even the explicitness of tacit knowledge within SMEs by the use of ICT. This means digitizing the activity of taking and retrieving notes and annotations. Current digital platforms, despite their powerful and important functionalities that they offer, do not take into consideration the special need of SMEs for capitalizing notes and annotations. This is because the notes and annotations in these platforms are disconnected from the information system of the enterprises. In this case, notes and annotations are only accessible in the notes and annotations system. This would make it not possible to index and retrieve notes and annotations as any other information resource (e.g. a document). As a consequence, having a digital platform that supports taking and retrieving notes and annotations in SMEs implies having a robust model behinds it. The development of this model resides at the heart of this PH.D work. This model should take the exact need of SMEs in order to support the capitalization of notes and annotations. This model would be the base for a digital tool that overcomes the limitations of other platforms.

The Role of Semantic Web in Knowledge Capitalization

With the emergence of semantic web technologies, we have taken the decision to use ontologies in order to develop a supporting model for capitalizing notes and annotations. Ontologies are very interesting modeling tools. Using ontologies, we can model the knowledge and its circulation within an organization. We can also give descriptions to the organization concepts to ensure having no ambiguity. This could give us answers to questions like: What is shared? By whom? With whom? etc. In addition, ontology modeling opens the possibility of using semantic web standards which is so advantageous. Using these standards implies respecting a certain level of formality. This level of formality is required when reusing the model or when applying the ontology reasoner.

The re-usability of this semantic model or part of it rises as an important aspect. We therefore applied a modular approach in the construction of this semantic model. In this approach, the semantic model is divided into small / reusable components called modules (ontologies). Each ontology module could be easily imported / retrieved according to the specified need. In addition, the modular approach facilitates the maintainability of the semantic model and reduces its complexity. We, therefore, propose a method for integrating a new module to the semantic model.

Summery

The organization of the manuscript is as the following:

Chapter 2: It is dedicated to detail the field study within SMEs in the Picardy region in addition to the study within our partner Tour Equipement enterprise. The objective of the field study was to understand the problems of knowledge capitalization within SMEs.The field study is composed of three phases. The first phase was composed of interview sessions with managers of four SMEs (the manager of Tour Equipement enterprise was one of them). The second phase was composed of interview sessions and observations in situ. The interviews took place within 18 industrial SMEs in the Picardy region in addition to Tour Equipement enterprise. The observations in situ took place only in Tour Equipement enterprise. The third phase was only interviews in Tour Equipement enterprise. Employees of Tour Equipement were asked about their practices of taking notes and annotations.

Chapter 3: It is dedicated for the literature review. We will start by presenting the organizational learning: its definition, how it could be implemented, semantic web standards that support it and its specifications in SMEs. Afterwards, the definition of notes, annotations and their tools will be presented. The limitation of these tools will also be detailed. SMEs specifications and enterprise models will be described in this chapter.

Chapter 4: In this chapter, we will present the orientation that we took to implement the organizational learning within SMEs. We will present MEMORAe approach with its semantic model and web platform. We will also justify why we chose to rethink the development of MEMORAe-core 2 model using a modular approach. At the end, we will present the modules that respond to SMEs needs.

Chapter 5: MEMORAe prototype applications are presented in this chapter. There are two applications: web and mobile. The web application permits to share documents, notes, annotations, appointments, contacts and organize tours. The mobile application permits to take notes, appointments and organize tours.

Chapter 6: In this chapter, we will present two experimentations of MEMORAe web and mobile applications. The first experiment is done within a university course and the second is done within our enterprise partner Tour Equipement. The interest of testing the platform by the students is that they are habituated to use ICT and they could give interesting feedback about MEMORAe platform by comparing it to what they actually use. Whereas the objective of testing the platform within Tour Equipement enterprise is to evaluate its usability and utility within SMEs. Chapter 2

Field study

In this chapter, we will present the field study made by CESACO project members in order to understand the problems of knowledge capitalization within SMEs. Before presenting the field study, we will give a brief presentation of our partner and testing enterprise Tour Equipement. The field study is composed of three phases. The first phase was interview sessions with managers of four SMEs (the manager of Tour Equipement enterprise was one of them). The objective of the first phase was to understand why there is no Knowledge Management System (KMS) within SMEs. The second phase was composed of interview sessions and observations in situ. The interviews took place within 18 industrial SMEs in the Picardy region in addition to Tour Equipement enterprise.

The observations in situ took place only in Tour Equipement enterprise. Based on the results of first phase, the second phase's main objective was to identify the specific needs of SMEs in terms of knowledge management. The third phase was only interviews in Tour Equipement enterprise. Employees of Tour Equipement were asked about their practices of taking notes and annotations.

A Brief Presentation of Tour Equipement Enterprise

Tour Equipement is a small enterprise (15 salaried) in the Picardy region, France. It has more than 50 years of experience in the mechanical production. Tour Equipement is a partner of CESACO project. This partnership permitted the members of CESACO project to do a field study represented not only by interviews, but also by direct observations of the employees' activities. In addition, the partnership allowed us to do all the necessary tests within this enterprise. We can recognize two main activities in Tour Equipement:

1. Manufacturing of specific or standard mechanical products.

2. Buy and sell products for trading purposes.

The hierarchy of the enterprise is composed of:

• The Owner-Manager: He is not only the manager but also the owner of the enterprise. He is also a member of our project team CESACO.

• The Technical Director: He is considered by all the interviewees as the key-actor of the enterprise. Beyond activities dedicated to purely technical considerations, he assists in the organization of production, and in commercial relations. He therefore constantly interacts with the three other functional managers.

• The Commercial Director: Due to his function, he is the most itinerant actor of the enterprise. His visits are the source of numerous traces about the clients.

These visits also introduce the client to the enterprise.

• The Production Director: The Production Director's principal role consists in organizing the production and the supplies. His principal interactions are with the Technical Director and with operators (blue collar workers). His relation with the Technical Director is mainly to coordinate the demands of design and production.

These interactions are largely supported by annotations either on plans or on documents concerning the production range. The operators largely benefit from the notes and messages transmitted to them.

• The Administrative Director: As a recently hired member of the team, The Administrative Director's note-taking was frequently linked to her adaptation and learning to the enterprise activities. Furthermore her role also consists in interfacing with the Managing Director, who wasn't interviewed at this stage of the study, and with external actors (clients, suppliers, accountants, financial service providers).

• The Workshop Employees: They are blue-collar workers. Composed of 9 employees always present at the workshop.

• A Student: He is an apprentice and is present as a technical assistant to the Technical Director.

Defining the Scope of the Study

Knowledge Management (KM) has become increasingly important since the beginning of the nineties. This is due to the growing need for enterprises to create, preserve and share their knowledge. According to [START_REF] Steel | Corporate knowledge management[END_REF], the aim of Knowledge Management (KM) within an enterprise is to encourage the growth, the transmission and conservation of knowledge. However, the study of Knowledge Management almost exclusively concerns large structures without considering the specifications of small ones. In addition, the recommended tools are usually designed for big, large-scale enterprises and even for a specific department or function e.g. Chief Knowledge Officer (CKO). As these tools and functions (CKO) are not adapted for SMEs, the latter are excluded from any formal Knowledge Management process. As a consequence, SMEs loose the benefits of their accumulated experience and their reproducible practices over time. The problem arises more clearly when someone in which the expertise and know-how knowledge are concentrated leaves the enterprise. This is also the case when a new order that requires a previous experience to be carried out, while there is no registered trace about how the order was treated.

The advancements in information and communication technologies (ICT) could enhance the diffusion and retrieval of know-how knowledge within SMEs. Nevertheless, these technologies introduce a solution into SMEs which is not necessary adapted to their size and special need.

The objective of the this field study was to understand how to introduce a Knowledge Management System (KMS) taking into account these previous explanations. In addition, the field study aimed to better understand this quite "unfamiliar" context in SMEs which are recognized as weakly engaged in information and communication technologies (ICTs).

The field study was mainly conducted by our collaborators in Costech laboratory in the UTC (also members of CESACO project) Nathalie Darène and Fredric Huet.

The field study was organized as detailed in the following sections:

First Interview Sessions

The objective of these interviews was to understand the reason for the absence of a Knowledge Management System (KMS) within SMEs. The interviews took place with managers of four industrial SMEs in the Picardy region (Tour Equipement is one of these enterprises). This study took into consideration the aspects of knowledge management in enterprises proposed by [START_REF] Grundstein | De la capitalisation des connaissances au management des connaissances dans l'entreprise[END_REF] (For more information see appendix A).

The results of these interviews have pointed out two specificities that highlight this low diffusion of KMS within SMEs:

• First, coordination mainly relies on direct supervision and interaction. Activity often takes place in concentrated spaces of work and between only a few actors with a direct and flexible coordination. Contrarily to large and highly structured organizations, efficiency and productivity in these small organizations are closely linked to these interactions that are rarely mediated by procedures, codified rules or documents. So, the use of these KMS is often seen as inappropriate and useless.

• Second, managers mentioned the difficulty they face when they want to introduce digital tools. In order to overcome this dilemma, managers have two possible ways.

They either focus on "standard" solutions that are conceived for large enterprises (they regret the use of an over-sized tool); or they focus on a complete customized solution that will be well suited for their uses. But this last solution is costly for these small businesses.

Observations In Situ And Second Interview Sessions

Taking the results of the first interviews, the second phase's main objective was to check these results and to better specify and discover the specific needs of SMEs in terms of knowledge management. In this phase, observations in situ (at the place) was organized at our enterprise partner Tour Equipement. In addition, interviews were organized in 18 mechanical-manufacturing SMEs situated in the Picardy region. The observations and interviews focused on the flow of internal and external knowledge within SMEs. Four specificities were identified by analyzing the results of these observations and interviews:

• Digital tools are rarely used in the accomplishment of collective activities in SMEs.

Human interactions are direct and synchronous due to the restricted geographic area of SMEs. Regarding the small number of employees in these enterprises, the work implies that the employees stay in contact all the time. This contact is very important to solve frequently urgent matters e.g. the client is on the phone and an replying answer is needed immediately. The digital tools are used afterwards only if a confirmation is needed. As a consequence, no registered trace to the activity e.g. what was the reply to the client.

• In general, SMEs rely on key-employees i.e. employees that have considerable seniority. As a consequence, the experience and history of the enterprise are often held in a limited number of actors (one or two employees typically holding all the company history in memory). Such employees have lived through all the different stages, both the successful and the less successful ones, of the company's development. These employees have played an essential and fundamental role in establishing the company's commercial offer and catalog. These key-actors have become the main, privileged holders of the enterprise commercial and catalog knowledge. Their capacity to hold such knowledge is appreciated by the other employees even if this implies a certain degree of dependency on these actors.

• The archiving of the activities is centered only around commercial transaction and client orders detail. This transaction and order based capitalization makes it difficult to retrieve specific technical information e.g. what was the technical problem faced when manufacturing this product for this client. Such information is so useful and unfortunately missing from the database system of SMEs making its retrieval so difficult.

For example, when a new order arrives, especially if the request is atypical and client-specific (which is the case for most orders), it is compared to a past experience. Having no registered technical information about the order, senior employees rely on their memory of the event. In addition to the memory, the search in annotations, post-its attached to the client order. In other words, they rely on non-formalized information sources. These source give essential information which prevents repeating a problem and starting all over again to search for the solution. This illustrates the urgent need for capitalizing such information in a formal manner that helps dealing with similar cases in the future.

• The quick response to clients order is so essential aspect for the competitiveness.

As mentioned earlier, in most cases, the orders are client-specific and not standard. Such orders do not necessary require complex studies but quick response to the client indicating the cost, delay to validate and deliver the product. Having a capitalized information system accelerates the response to client and ensures its satisfaction.

Analyzing these points, we could conclude that digitizing and capitalizing non-formal knowledge is very important. The digitizing of such knowledge makes it more easier to retrieve technical aspects related to client order. In addition, the digitizing permits the quick response to client order. During the observations and the interviews, we have recognized that non-formal knowledge is mainly represented by notes and annotations taken during the client order. The knowledge behind these notes and annotations represents useful technical and order-specific details. As a consequence, digitizing such knowledge seemed as an adapted solution for SMEs. The digitizing should facilitate not only note and annotation taking, but also their retrieval in the future when needed. This means integrating an appropriate indexing system to these notes and annotations. The indexing system should enable the indexing of the same note or annotation by different point of view (index) at the same time (multi-indexing of the same note/annotation).

For example, when the commercial takes a note like: "The client GP have not ordered a chuck since summer of 2014". The commercial should be able to index the note by 1)the client GO, 2) the chuck product. So the note could be retrieved either by searching the chuck the GP index.

In the third interview session, questions were focused on the practices of taking notes and annotations. We differentiate note from annotations. Annotations are notes that have targets whereas notes do not have targets. More details are in next chapter.

Third Interview Sessions

This third session took place within our partner Tour Equipement. The objective was to understand the activity of taking notes and annotations. The interviews were with the following persons of the enterprise:

• The Technical Director.

• The Commercial Director.

• The Production Director.

• The Administrative Director.

The questionnaire had semi-directed questions. It was divided to the following topics (for each topic, an extract of the questions are presented, the whole list of questions is so long to be presented):

Notes or Annotations:

• Do you take notes on existing documents? If you do, what type of documents: plans, agendas, invoice.

• Are the notes necessarily related to these existing documents? Are they themselves sufficient or they are complementary to other information sources e.g. telephone exchanges, discussions, meetings?

The Context in which Notes and Annotations are Taken:

• When do you take those notes or annotations? What are the situations in which you are required to take notes or annotations?

• The place in which notes and annotations are taken: In which places do you take notes or annotations? in your office? When you are at the client? In shared or in calm and quite places?

• Time of taking notes and annotations: At what time you take notes or annotations? At an unexpected time? Or during planned and anticipated times (meetings, visits ...)? Are notes and annotations taken in hurry? Does note or annotation taking take you time? This activity is done in conjunction with another task e.g. a telephone call?

• Trigger events: What event makes you take your pen and write a note or an annotation?

• Actors and readers of the notes and annotations: To whom these notes or annotations are destined? Personal use? Or to already identified collaborators? Do you think about who will read the notes or annotations while writing them? If there the notes or annotations could be read by others, do you have control over who could read them? Could they be read by persons outside your enterprise?

Usefulness of Notes and Annotation:

• Remembering: Are the notes or annotations consulted after writing them? After consulting, are they seem to be useful? These notes or annotations help you to identify the most essential thing?

• Thoughts: Do these notes or annotations reflect your thoughts or opinions about a particular subject? Are they critics? personal opinions? questions? additional comments? Technical constraints?

• Clarifying: Are these notes and annotations are reformulations of your terms and of your habits? Are they Kinds of "translation"? Does this helps clarifying things in your mind?

• Key points: Do the notes and annotations permit you to take less time to find key points? Do they facilitate understanding the most important point of the topic they were taken for?

• Collaboration: Are the notes and annotations that you take for personal use only? Do you read notes or annotations written by others? If so, what usefulness they provide for you? What is the impact of these notes and annotations on a collective or collaborative activity? If the note and annotations do not circulate, is it useful to implement a circulation system?

Modality of Notes and Annotations

• Target: To what refer your notes and annotations? To oral exchanges (telephones, informal conversation)? To documents? Items? Minutes? Plans? Technical documents? Quotation? digital documents? mails? Applications sent by computer? Could these notes or annotations refer to more than one document?

• Anchor: If an annotation is present on a document, how do you know which part of the document is annotated? If the annotation is written on a post-it and the post-it was moved for some reason, is it easy to know to what refer this post-it?

• Content: What is the most common content of notes and annotations that you take? Text? Schema? Figures? Calculations? The content is easily understandable by you or by others?

Archiving and Reusing Notes and Annotation

• Archiving: Are notes and annotations archived after taking them? Are they saved somewhere? Are they ordered? abandoned?

• Reusing If a question or a problem happen months or years later, how do you find related notes or annotations? What do you use to find them? What is the impact on the problem if you do not find them?

From the answers to these questions, a table was organized describing the situation in which notes or annotations are taken and by whom : The main objective of this accompaniment of the commercial director is to observe his practice of taking notes or annotations within a tour. The accompaniment is done by our collaborator from the Costech laboratory in the UTC Nathalie Darène. The accompaniment took one day and it was dedicated to clients (or prospects) situated in the Picardy region. The observation shows us that the tour is divided to three phases:

• Before the tour: In this phase, the commercial director prepares for the tour.

The preparation permits the commercial director to know the itinerary of the tour.

The information of the tour is written on a paper that has the following information: date, the client (enterprise name), the address (street address, city, postal code) and the contact person within this enterprise (name, telephone number).

For each client (or prospect), the commercial director has a binder "classeur" that contains all the papers and notes related to the client. The binders (Fig. 2.1) are the accumulated work of three years.

• During the tour: The commercial director visits the clients (or prospects) in their order as listed in the preparation paper. The commercial director takes notes (or annotations) either when he is actually at the client or just after leaving when he is in his car. Notes taken at the client are very short (one or two words)

as he has to be very quick. He sometimes take photos at the client enterprise (with the accord of the client). When he lives the client enterprise, he could either add new notes or modify the notes taken in the enterprise. The notes are organized in the binder of the client.

• After the tour: The commercial director informs the technical director and the enterprise owner-director the results of his visit. He may show them the notes taken during the tour.

Results of the Field Study

We can resume the results of the field study to:

• There is a remarkable absence of a knowledge management system within SMEs.

This is due to the direct supervision and interaction between only a few actors of the enterprise. In addition, there is a clear difficulty in the deployment of digital tools which are not adapted to the enterprise needs. On one hand, these tools are generally destined to large enterprises and they come with overloaded functionalities that are not suitable for SMEs' need. On the other hand, customized digital tools are so costly and extend SMEs dedicated budget.

• The knowledge of SMEs mainly relies in the minds (memories) and activities of SMEs' key-actors. These key-actors are senior employees and have played an important role the enterprise history. The absence of these key-actors are so critical to the enterprise because they leave with their knowledge with them. Having no knowledge management system, the knowledge of key-actors are missed from the enterprise.

• Non-formal knowledge takes a sufficient part of SMEs' knowledge. The field study showed us that this non-formal knowledge is mainly represented by notes and annotations. Employees rely on these notes or annotations to save or retrieve useful technical and order-specific details. All the interviewee mentioned that digitizing notes and annotations taking, sharing and retrieval is time-saving. We know the very known phrase of Benjamin Franklin 1 : "Time is money". So timesaving means cost-saving. As a consequence, digitizing the notes and annotations seems as an urgent need for SMEs.

These results oriented our work to implement the organizational learning within SMEs.

Having an effective organizational learning within SMEs would support their knowledge management which is remarkably weak. The main aspect that of implementing the organizational learning is having an effective sharing system of knowledge. As previously mentioned is this field study, notes and annotations (as non-formal knowledge) takes a large part of SMEs' knowledge. As a consequence, we were oriented to facilitate the sharing / retrieving the notes and annotations using a digital tool.

Chapter Summary

In this chapter, we presented the field study made within 18 SMEs in the Picardy region in addition to Tour Equipement partner enterprise. The first phase of the field study gave us answers about the reason of absence of a knowledge management system. This was mainly due to the direct supervision and interaction and the difficulty to introduce digital tools. The second phase of the field study illustrated the needs of SMEs in terms of knowledge management. This phase oriented us to consider notes and annotations as important knowledge sources in SMEs especially notes and annotations taken by keyactors. The main objective of the third phase and the accompaniment of the commercial in his tour was to understand the practices of taking notes and annotations. These practices are useful to take into consideration within any proposed digital tool. This study oriented our work to the implementing of organizational learning within SMEs by sharing / retrieving notes and annotations via a digital tool.

Chapter 3

Literature Review

As mentioned in chapter 2, the field study oriented us to implement the organizational learning in SMEs by sharing / retrieving notes and annotation using a dedicated digital tool. In this chapter, we will present the organizational learning and its specificities in SMEs. We will illustrate how semantic web standards could support the organizational learning. Notes and annotations will be defined as well as their dedicated tools. The limitations of these tools will also be presented. In addition, SMEs specifications and enterprise models will be described.

Organizational Learning

Organizational learning has become the fundamental path of organizations to obtain The definition of individual learning within any dictionary is: the acquiring of information, knowledge or skill. There is direct relation between individual and organizational learning. An organization cannot learn without the continuous learning of its members.

So there is no organizational learning without individual learning. On the other hand, and contrarily to the intuitive thinking, the organizational learning is more than the sum of individuals' learning [START_REF] Nevis | Understanding organizations as learning systems[END_REF]. Individual learning requires a conversion to become an organizational learning. This conversion can take place through individual and organizational memory [START_REF] Chen | Systems requirements for organizational learning[END_REF]. So in order to understand how this conversion could take place, we have to define the individual and organizational memory. [START_REF] Girod | La mémoire organisationnelle[END_REF] defines individual memory as the knowledge held in the brain of the individual in addition to knowledge physically visible to individual (files in his/her office, documents, etc.). According to [START_REF] Stein | Actualizing organizational memory with information systems[END_REF], organizational memory is the means by which knowledge of the past is applied to everyday activities and can act at different levels on the effectiveness of the organization. [START_REF] Anand | An organizational memory approach to information management[END_REF] defines the organizational memory as information and knowledge known by the organization and the processes by which such information is acquired, stored and retrieved by the organization members. Individual learning becomes organizational learning when individual memory becomes part of the organizational memory.

To explain how organizational learning occurs in other words, let's have this illustration. The members of the organization gain experience during their activities. From this experience, the organization is able to create knowledge. The organizational learning takes place when sharing the knowledge and practices resulting from this accumulated experience. This point is affirmed by [START_REF] Huber | Organizational learning: The contributing processes and the literatures[END_REF]. According to [START_REF] Huber | Organizational learning: The contributing processes and the literatures[END_REF], organizational learning consists of four points: knowledge acquisition, knowledge storage, knowledge sharing and knowledge interpretation.

In order for this knowledge to be shared all over the organization, it must be communicable, consensual and integrable [START_REF] Duncan | Organizational learning: Implications for organizational design[END_REF]. According to [START_REF] Chen | Systems requirements for organizational learning[END_REF], being communicable means that knowledge must be represented in an easily comprehensible and distributable way. Being consensual implies that this organizational knowledge must be valid and useful for all members of the organization. Being integrable means that its representation could be saved in an organizational memory which must be consistent, accessible and well maintained. [START_REF] Argyris | Organizational learning: a theory of action perspective. Addison-Wesley series on organization development[END_REF] differentiates between two types of organizational learning:

• Operational which is a single-loop learning that consists of correcting actions to obtain better results. The single-loop learning is based on the detection-correction principle. This means that a modification of actions is made according to a comparison between the desired and the obtained outcome. This occurs when an organization detects a mistake, corrects it, and carries on with its present policies and objectives.

• Management which is a double-loop learning that involves the correction of errors at a higher level. The double-loop learning happens when the entity is able to view or modify all the assumptions, policies and values that led to the specific action (the root cause of the action). This occurs when an organization detects a mistake and changes its policies and objectives before it can take corrective actions.

If we take the example of a team in an enterprise having problems in meeting the project deadline. Increasing the working hours per day could be an example of single-loop learning. Although there is a slight improvement, the investigations showed that the team structure and communications between each other also affects the team not meeting the deadline. It is therefore this issue that is the root cause of the problem (double-loop learning).

Thus, an organizational memory appears as a mean to establish an organizational learning. It can include both physical data (e.g. reports and papers) and also representation of information traditionally expressed without physical media (e.g. experience, critical incident, details of the strategic decision-making). However, it is necessary to store these two data types and make them accessible. Ideas generated by employees during their work rarely exceed the circle of a small group or team. This informal knowledge or non-canonical practice is the key to organizational learning [START_REF] Brown | Organizational learning and communities-of-practice: Toward a unified view of working, learning, and innovation[END_REF].

A Learning Organization

The term "learning organization" appeared to denote an organization which is capable to perform the organizational learning. Peter senge in his book "The Fifth Disciplines:

The Art and Practice of the Learning Organization" [START_REF] Senge | The fifth discipline: the art and practice of the learning organization[END_REF] defines the learning organizations as: "organizations where people continually expand their capacity to create the results they truly desire, where new and expansive patterns of thinking are nurtured, where collective aspiration is set free, and where people are continually learning to see the whole together." Peter senge focus on group learning and provide methods to convert organizations into learning ones. These five disciplines are:

• Personal mastery

• Mental models

• Shared vision

• Team learning

• System thinking A 'discipline' is viewed by Peter Senge as a series of principles and practices that we study, master and integrate into our lives.

According to [START_REF] Dodgson | Organizational learning: a review of some literatures[END_REF], a learning organization builds structures and strategies to enhance and maximize organizational learning. A learning organization is one in which the work is grounded in a corporate culture that allows and encourages learning at different levels: individual, group and organizational Sunassee & Haumant (2004).

A learning organization should enable the transfer of knowledge between these different levels. Thus, a learning organization must be able to create, acquire, transfer knowledge and even change its behavior (if necessary) to reflect new knowledge and insights Garvin (1994).

Semantic Web Standards That Supports Organizational Learning

The term Semantic Web was invented by Tim Berners-Lee1 who supervises the development of the Semantic Web recommendations. Tim Berners-Lee defines the Semantic Web as "giving information a well-defined meaning, better enabling computers and people to work in cooperation" [START_REF] Mikroyannidis | Toward a social semantic web[END_REF]. The Semantic Web implements the "Web of data" that links and organizes the information on the Internet. The main goal of the Semantic Web is to guide the evolution of the Web to allow users (without intermediate) to find, share, and combine information more easily. The Semantic Web provides a vision of information that can be readable by humans as by machines. For example, the phrase: "Paris is the capital of France" is understandable by humans, but with the Semantic Web it would be understandable also by machines because the Semantic Web offers a good solution to characterize the resources.

In order to link the data to its information source in the Semantic Web, the data should be qualified [START_REF] Deparis | Creation of new decisional knowledge for an organization by analysing its social and documentary resources[END_REF]. This qualification of data should be based on a formal reference or model. This formal reference should ensure that there is no ambiguity in the vocabulary used for data qualification. This formal reference is usually represented by ontologies. Taking the context of computer science and information science, Gruber (1995) defines the ontology as "an explicit specification of a conceptualization". The conceptualization for [START_REF] Gruber | Toward principles for the design of ontologies used for knowledge sharing?[END_REF] is "an abstract, simplified view of the world that we wish to represent for some purpose". Ontologies are considered as "pillars" of the Semantic Web. This is because the ontologies are used to describe the Semantic Web vocabulary. In order to use the ontology for modeling, we have to take a look about its typology.

According to [START_REF] Heijst | Roles are not classes: a reply to nicola guarino[END_REF], the typology of ontology distinguishes between four levels of ontologies regarding the level of abstraction of the concepts and relations. These levels are:

• High-level ontology (also called top level): A high-level ontology is an ontology that describes the very general concepts which are the same in all areas of knowledge.

This ontology decries general concepts such as entity, time, activity, role, etc.

• Core-ontology: The core-ontology contains the central concepts of a particular domain. For example, the SIOC (Semantically-Interlinked Online Communities) is a core-ontology that contains concepts describing how to interconnect divers discussion methods (e.g. blogs, forums, mailing lists, etc) to each other .

• Domain ontology: The domain ontology contains concepts describing a specific domain. This ontology is built from specifications to either high-level ontology or core-ontology. For example, an ontology of SME defines concepts of physical objects that could be found in SME (e.g. machine, products), or processes held in SME (e.g. sale, manufacture).

• Application ontology: The application ontology contains the concepts necessary to model an application of a particular domain. For example, an ontology for modeling a mechanical SME is an application ontology of the domain ontology that models SME in general.

The question that could be asked at this point is: how could the semantic web support the organizational learning? This issue is argued by [START_REF] Lytras | The semantic learning organization[END_REF] who states that Semantic Web technology is a potential "catalyst" for organizational learning. To discuss this issue, we could retake the four points of organizational learning presented by [START_REF] Huber | Organizational learning: The contributing processes and the literatures[END_REF]: knowledge acquisition, knowledge storage, knowledge sharing and knowledge interpretation. Ontologies are the backbone for implementing these four points. This is because ontologies are interesting and powerful tools for knowledge modeling.

Using ontologies, we can describe the knowledge circulating in a particular organization.

In addition, we can describe how and by whom the knowledge could be shared. Semantic

Web offers many ontology standard models for knowledge modeling and knowledge sharing. Using Semantic Web standard models is advantageous in ontology modeling. Using these standards implies respecting a certain level of formality. This level of formality is required when reusing the model or when applying the ontology reasoner. In this work, we identified the following semantic web standards as being relevant to describe resources of SMEs:

• FOAF (Friend Of A Friend) [START_REF] Brickley | Foaf vocabulary specification[END_REF] -Person:

Here is a concrete example of using FOAF to define a person using FOAF (the person is an agent) (kb is the namespace of the knowledge base):

foaf:Person a foaf:Agent.

kb:ala a foaf:Person.

kb:ala foaf:lastName "Atrash".

kb:ala foaf:firstName "Ala".

kb:ala foaf:gender "male". SIOC uses other ontologies to enrich the description of described information. For example, SIOC uses FOAF ontology to provide the creator of a message using the relation foaf:maker. SIOC also extends some classes in FOAF, for example the class sioc:UserAccount is a specialization of foaf:OnlineAccount. This specialization permits to link the user account of a SIOC by person described by FOAF using the relation foaf:account.

Here is a concrete example of using SIOC to define a user account, his group and its space (kb is the namespace of the knowledge base):

kb:ala account a sioc:UserAccount.

kb:ala foaf:account kb:ala account.

kb:cesaco group a sioc:Usergroup.

kb:cesaco group sioc:has member kb:ala account.

kb:ala account sioc:member of kb:cesaco group. BIBO also uses FOAF for describing the author of a document by using the relation foaf:maker. The meta-data of the document is described in BIBO using the Dublin Core (DC) vocabulary.

Here is a concrete example of using BIBO to describe a scientific paper published in a journal (kb is the namespace of the knowledge base):

-<kb:doi/10.5220/0005082602370244>a bibo:Article;

dc:title "Supporting organizational learning with collaborative annotation";

bibo:pageStart "388";

bibo:pageEnd "391";

dc:creator foaf:ala;

dc:creator foaf:marie helen;

dc:creator foaf:claude; The OA identifies the relation between an annotation and a resource. OA defines the annotation as being a relation between the annotating data and the annotated data. This relation consists of a "body" (the annotating data or the content of the annotation) and a "target" (the annotated data or the resource being annotated).

The "body" of the annotation describes its "target". In OA, the type "body" and the "target" could be a text, a sound, a video, a web page or any resource in the web. The "body" and the "target" could have the same type (e.g. an image annotating another image). The OA uses the Dublin Core (DC) to indicate the format, language, etc. of the "body" and the "target". The OA uses the FOAF ontology to represent who added the annotation.

Here is a concrete example (taken from the official website of OA) of using OA to represent an annotation. The "target" of the annotation is a webpage containing a big picture taken on Venice Beach in California and depicting the musician Harry Perry. The "body" of the annotation is a Wikipedia page about Harry Perry. (kb is the namespace of the knowledge base):

kb:anno a oa:Annotation;

oa:hasTarget <http://www.foaffy.org/gallery2/main.php?g2 itemId=11496>;

oa:hasBody <http://en.wikipedia.org/wiki/Harry Perry %28musician%29>;

oa:annotatedBy kb:ala;

oa:annotatedAt "2015-02-12T15:02:14Z".

-<http://www.foaffy.org/gallery2/main.php?g2 itemId=11496> dc:format "text/html".

-<http://en.wikipedia.org/wiki/Harry Perry %28musician%29> dc:format "text/html". Here is a concrete example of using VCard to describe a VCard for an individual (kb is the namespace of the knowledge base):

• VCard Renato & M. ( 2014
kb:ind a vcard:Individual.

kb:ind name a vcard:Name.

kb:ind name vcard:givenName "Ala".

kb:ind name vcard:familyName "Atrash".

kb:ind telephone a vcard:Telephone.

kb:ind telephone vcard:telephone "33 6 29 35 55 01".

kb:ind telephone rdf:type vcard:Work

kb:ind address a VCard:Address kb:ind address vcard:streetAddress "19 rue pierre d'ailly".

kb:ind address vcard:locality "Compiègne".

kb:ind address vcard:region "Picardie".

kb:ind address vcard:postalCode "60200".

kb:ind address vcard:country "France".

Literature Review for Notes

In this section, we will present the possible definitions of a note and the existing digital tools of taking notes. We will also present the limitations of these tools in terms of sharing and indexing the notes taken.

Note Definition

According to [START_REF] Makany | Optimising the use of note-taking as an external cognitive aid for increasing learning[END_REF], the notes are "what is recorded as being the essential of the information" taken from a certain source. This resource may be a lecture, a discussion, a phone call, a meeting, etc. In such cases , the notes may be the only record of the event. The note for Piolat et al. ( 2005) is a "stable external memory" in order to be useful in the future. For [START_REF] Robertson | Note taking and note sharing while browsing campaign information[END_REF], the note is an important information which is stored either temporarily in a "local memory" (human's brain) or permanently in an "external memory" (paper or digital support).

Current Note Taking Tools

There are numerous digital tools dedicated for note taking. Each tool has its corresponding features and design. The tools presented in this section are the most common note taking tools. They contain all the features that could be found in other note taking tools.

IBM Note

IBM Notes provides business collaboration functionality, including email, calendars, to-do lists, contacts management, team rooms, discussion forums, file sharing, microblogging, instant messaging, blogs, and user directories. IBM Notes also provides access to and integration with other IBM Domino applications and databases. IBM Notes provides a client-server cross-platform application runtime environment; it represents the primary user-interface or client of the IBM Notes and Domino software. Users can employ IBM Notes as an email client without an IBM Domino server, for example, as an IMAP client4 . IBM Notes stores information in databases. Each database contains information about a particular subject such as "Company Policies" or "Product

Information." The person who creates the database decides the type of information the database will contain. Databases can even contain reports for you to complete, such as attendance reports or expense reports. A database usually contains many documents.

Each of these documents is about a particular topic. In a Company Policies database, for example, there may be a topic about parking, one about sick days, and one about donating to charity through the company. Some databases only let you read information, while others let you create documents of your own. You create a document by filling in information on a form the database contains. The form has spaces for you to fill in. These spaces are called fields. Some forms also have buttons for you to click to perform particular actions Vandenbosch & Ginzberg (1996).

Microsoft OneNote

Microsoft Office OneNote (Fig. 3.1) enables users to keep an electronic notebook with multiple tabs and sections, organizing all the notes and information they need at the click of a button. Users can include lists, graphs and images in their class notes using the OneNote software. Notebooks can be divided into sections and pages in order to categorize information. First, a notebook is created and saved. Then, this notebook can be divided into sections to organize information. Finally, information within a section can be divided into pages. Furthermore, information in OneNote can be formatted just like paper notes, in bulleted or numbered lists, or in tables for clear and organized notetaking. Users can share OneNote notebooks with each other in order to work together on assignments or projects. Users also can make notebooks accessible on multiple computers and take their notes with them anywhere. In order to view a shared notebook, users must have the live sharing session address and sharing password for that notebook's live session.

Evernote

Evernote is a suite of software and services designed for note-taking and archiving. A "note" can be a piece of formatted text, a full webpage or a selection out of a webpage, a photograph, a voice memo, or a handwritten note. Notes can also have file attachments. They can be sorted into folders, then tagged, annotated, edited, given comments, searched, and exported as part of a notebook. Evernote supports a number of operating system platforms (including OS X, iOS, Chrome OS, Android, Microsoft Windows, Windows Phone, BlackBerry, and webOS) and also offers online synchronization and backup services.

With Evernote, a user can share a notebook with the public or with Premium account they can give other Evernote users the permission to edit their notes within the shared notebook. Sharing a single note is also possible. A user can use the Share button and click the "Copy Share URL" (on Windows) or "Copy Public Link" (on Mac) to get the public link of the selected note. Then they can give that URL to anyone and they can view the note even without having an Evernote account.

Simplenote

Simplenote is a note taking application. The application works on iOS (iPhone and iPad), Android, Macintosh, and Kindle, and can also be accessed via most browsers as a web service. There is a premium version with extra features that includes synchronizing Simplenote with Dropbox. Text annotation is available as a service in Simplenote App.

Other 3rd party Apps that are synchronized with the Simplenote account can be used to annotate web pages, Emails, Contact and other resources5 .

Limitation of Note Taking Tools

Two limitation aspects are shared between all these presented tools: sharing and indexing notes. Taking IBM Note, the sharing of notes is done only via the mailing system.

In Microsoft OneNote the user can share only pages of notes with no ability to share the note itself. The (Fig. 3.1) shows two notes included in the same page. As the share in Microsoft OneNote is done at the page level, the user can not share a note without sharing the other and he/she is obliged to share the whole page. Concerning Evernote, sharing notes is simple and done without necessarily an account. But Everynote has no indexing system for notes and the search is done only via the tagging system. Simplenote is like Evernote in terms of sharing and indexing.

Literature Review for Annotations

In this section, we will present the possible definitions of an annotation and the existing digital tools of taking annotations. We will also present the limitations of these tools in terms of sharing and indexing the annotations.

Annotation Definition

According to [START_REF] Bringay | A specific tool of annotations for the electronic health record[END_REF], annotations are particular type of notes that have an anchor and a destination. [START_REF] Bringay | A specific tool of annotations for the electronic health record[END_REF] defines the annotation as: "A particular note linked to a target. The target can be an other annotation, a collection of documents, a document or a document segment (a paragraph, a phrase, an image, a part of an image, etc.)". [START_REF] Oren | What are semantic annotations? Citeseer[END_REF] defines the annotation as being a relation between the annotated data and the annotating data, this relation has a type and is done in a particular context. The annotation from the point of view of psycholinguists and cognitive scientists, is a trace of mental status of the reader and a trace of his reactions face-to-face the document. The annotation also transforms the "reader" into "active reader". [START_REF] Marshall | Exploring the relationship between personal and public annotations[END_REF] divides the annotation into two types: private and public. Private annotations concern a single person and not intended to be read by others contrary to public annotations which are addressed to others. But [START_REF] Marshall | Exploring the relationship between personal and public annotations[END_REF] affirms that most of the annotations are public even if they weren't initially. Taking the example of borrowing a book already read and annotated; all its private notes become public. This has two advantages according to [START_REF] Marshall | Exploring the relationship between personal and public annotations[END_REF]: First, It helps a better understanding to the annotated document. Second, it prompts the communication between two persons by transferring knowledge. [START_REF] Slimani | Semantic annotation: The mainstay of semantic web[END_REF] precises four domains on which the annotation could be applied:

• Document annotation: It is the annotation of documents or part of them. Users can take notes, comments, remarks, etc. and share them with others.

• Wiki annotation: Wikis are collaborative authoring of a particular content. Authors could contribute by adding, modifying or deleting the content. Authors could add annotations to describe the wiki. Annotations are added on page level to describe the whole wiki page.

• Blog annotation: A blog is a website or online journal owned by an individual who regularly writes posts which are presented in reverse chronological order.

Contributors to a blog could write comments to a particular post. An annotation in a blog is a statement about a post. For example, posts are classified with simple categories "sport", "research", "teaching", etc. [START_REF] Slimani | Semantic annotation: The mainstay of semantic web[END_REF] considers that blog posts are annotated with these categories.

• Tagging: Tags are descriptive terms (e.g., keywords). For example, Flickr allows tagging an image to describe its content (e.g., "car" for a car image). Slimani ( 2013) considers that tags express some unspecified relation between the resource and whatever the term refers to.

Collaborative Annotation

Collaborative annotation is the process of annotating a particular resource by several users within a collaborative environment [START_REF] Petasis | The sync3 collaborative annotation tool[END_REF]. Within "Palimpsest 6 " project, the collaborative annotation is the process of adding a comment to a shared space (e.g., a document), this comment is either a note, an explanation or a criticism attached to a particular text. In collaborative annotation, users have access to the shared resource on which they could add their annotation. Users also have access to other annotations of the shared resource.

According to us, the collaborative annotation takes place when the annotation itself is shared between individuals who have access to the annotated resource. In this case, the annotations could have an impact on individuals who view it. This annotation could be written by a single author or multi-authors. The annotation becomes collaborative when its content is shared between the collaborators. As mentioned earlier, the annotation "body" could have different forms [START_REF] Euzenat | Eight questions about semantic web annotations[END_REF]: plain text, a document, a chat, etc.

When the annotation "body" is a chat, a wiki or a forum, the annotation is necessarily written by multi-authors. Being multi-authored implies being shared between all the authors so it is collaborative.

The Role Of Collaborative Annotation In Supporting Organizational Learning In SMEs

As mentioned earlier, the organizational learning is done by supporting knowledge sharing and retrieval within an organization. The fact that collaborative annotations are shared between users promotes the organizational learning. The annotations within a collaborative environment reflects the opinions of the annotators about a particular resource. An already annotated resource allows a better understanding of it.

Many research studies illustrated the usefulness of collaborative annotation for facilitating learning within organizations. For example [START_REF] Nokelainen | Evaluating the role of a shared document-based annotation tool in learner-centered collaborative learning[END_REF] affirms that collaborative annotation motivates the individuals ability to learn which in turns enhances the organizational learning process. [START_REF] Marshall | Exploring the relationship between personal and public annotations[END_REF] indicates that collaborative annotation provides an opportunity to facilitate making individual knowledge a public one. As a consequence, the annotations' knowledge value is accumulated when these annotations are shared. The experiment of [START_REF] Su | les échanges de mails permettent-ils de communiquer des données ou de poser des questions à un collègue en déplacement afin qu'il puisse y répondre à son retour. Les plus grandes avancées en ce qui concerne les TIC viennent de la nécessité de s'équiper pour répondre aux clients et accéder à certains gros fournisseurs[END_REF] shows us how a collaborative annotation web platform facilitates knowledge circulation and retrieval between individuals within a collaborative environment. As a result, sharing the annotations by a collaborative annotation platform within an organization plays an important role in the organizational learning process.

Current Annotation Taking Tools

In this section, we present the most common annotation tools. The features included in these tools are representative of features in other annotation tools.

Annotea

Annotea is a W3C LEAD (Live Early Adoption and Demonstration) project under Semantic Web Advanced Development (SWAD). Annotea enhances collaboration via shared metadata based Web annotations, bookmarks, and their combinations 7 . Annotea is part of the Semantic Web efforts. It provides a RDF metadata based extendible framework for rich communication about Web pages while offering a simple annotation and bookmark user interface (Fig. 3.2)8 . The annotation metadata can be stored locally or in one or more annotation servers and presented to the user by a client capable of understanding this metadata and capable of interacting with an annotation server with the HTTP service protocol. To use annotations you need an annotation client, such as Amaya (C1) and a service, such as the W3C public annotation service (S1).

Interested developers can write new clients, plugins or proxies that communicate with the annotation servers, such as the W3C public annotation service. For annotation clients they need to follow the Annotea protocols and understand the annotation schema. For bookmark clients they need to understand the bookmark schema. One of the problems of Annotea is having a centralized server which may present both scalability and privacy problems.

Adobe Reader

Adobe Reader is the tool for opening and using Adobe PDFs that are created in Adobe sticky notes to specific highlights or to a whole page (Fig. 3.4)11 . These annotations can be kept private, shared with a group within Diigo, or be forwarded to someone else via a special link. The name Diigo is an acronym from "Digest of Internet Information, Groups and Other stuff". When something is bookmarked, the user can tag it so it will be grouped with similar articles, or other pages that might be needed for a specific project.The major drawback is that Diigo's premium features are not free, and the free version offers limited usage.

MemoNote

MemoNote is a tool supporting active reading in order to provide the various actors of e-learning, mainly teachers and learners, with a memory of their interaction with documents to be reused later [START_REF] Desmoulins | Memonote, a semantic and personal memory tool based on annotations made on pedagogical documents[END_REF]. This tool is based on annotations directly placed on educational documents during their use. MemoNote is a semantic memory. It means that MemoNote annotations are not full text but refer to concepts which are semantically defined and structured, and agreed in the educational community. Then, remembering can refer to semantic concepts organized into ontologies. This semantic network of concept (and their instances) is part of the memory in addition to documents and annotations. Even if it is semantic, MemoNote does not deal with objective/universal annotations as in the Semantic WEB approach. Only personal annotations and views on pedagogical documents are memorized. In psychology, this type of memory is usually called an "episodic memory" opposed to "semantic memory".

MemoNote is both semantic and episodic, referring subjectively to objective and shared concepts.

MemoNote user can manage the memory content, (documents, ontologies, annotations) and the patterns it uses. The following use cases describe the memory content management:

• Adding documents.

• Deleting documents.

• Adding ontologies.

• Deleting ontologies.

• Receiving annotation given by another user.

• Sending annotation to another user.

• Synchronizing memory.

As annotation can be created using different MemoNote instances (on different comput-

Limitation Of Current Annotation Tools

As for note taking tools, annotation taking tools also have limitations in two main aspects: sharing and indexing. In all these tools, the annotations are strictly attached to their "targets" and the user can not share the annotations as being independent entities. For example, in Adobe reader, when the user shares a particular document, this latter is shared with all its annotations. This means that the user can not address the annotations of the same document to different destinations and the user is obliged to share the whole document to each destination with its appropriate annotations. As the annotations are not separated from their origin document, the only way to access these annotations is only by the document itself. Being attached to their "targets", annotations could not be indexed separately from the "target" that they annotate. In addition, these tools allow only the annotations of documents or parts of it with no ability to annotate subjects related to the context in which the annotation tools is used.

For example, if the annotation tool is used by a mechanical production enterprise, the user could not annotate a certain client to denote its preferred product. The user could also annotate a certain product for indicating that it is not suitable for being used within a particular machine. So annotations in these tools are also done on documents or part of them (Invoices, plans, etc.)

Literature Review for Modeling SMEs

In this section, we will define Small and Medium Sized Enterprises. We will also present the characteristics of these enterprises and the organizational learning process within them. Three enterprise models will be presented: TOVE model, Enterprise project and the organization ontology. These models are not dedicated for SMEs but for enterprises in general.

Definition of SMEs

SMEs Specifications

Due to the small size of SMEs, there is a direct supervision and coordination in these enterprises which is contrary to large enterprises where the coordination is procedural and codified [START_REF] Atrash | Supporting organizational learning with collaborative annotation[END_REF]. The standardized and codified technical supports (numeric or paper versions) are present in large enterprises but they are missing in SMEs.

In addition, the interaction is more codified in large enterprise (e.g. regular group meetings) than in SMEs. The knowledge of SMEs is highly attached to individuals and it is lost when they leave. These individuals in SMEs can play different roles at same time because of their small number. For example, a member can be both a technical manager and designer. This results in a high dependence on members in the enterprise which makes their replacement very difficult and critical to the enterprise.

All these points illustrate that there is an urgent need to organize the knowledge in SMEs. The knowledge must be codified and easily accessible by the members at any time.

Organizational Learning in SMEs

The process of organizational learning is affected by the size of the enterprise and according to [START_REF] Nicolas | Le rôle de la tradition orale et de la confiance dans l'apprentissage organisationnel en pme[END_REF] the organizational learning within small structures is very specific and needs a non-traditional approach.

Mahé & Rieu (1998) proposes a pull approach of knowledge management in order to learn from previous experiments within SMEs. The objective of pull approach is to respond to current projects needs by notifying employees when to look for previous useful knowledge to reuse without having to previously formalize this knowledge. The push approach begins with the formalization of pieces of knowledge and then makes these pieces of knowledge available in a search and retrieval system (it is necessary to come and look for them). In the push approach, knowledge must be chosen (with uncertainty of the future usefulness), formalized and integrated (in a search and retrieval system or directly in processes). Knowledge in push approach is only usable when it is formalized and this formalization could take a long time. The pull approach proposed by [START_REF] Mahé | A pull approach to knowledge management[END_REF] is based on an Automated Information System (AIS) which is accessed by "Access Agents" (software agents) in order to extract useful knowledge and transfer it to people when needed. According to [START_REF] Mahé | A pull approach to knowledge management[END_REF] the pull approach helps to reuse knowledge in the present, while the push approach could only do so in the future and that only if forecasts had chosen the right knowledge to be reused (which is not the easiest thing to do).

Louis-Sidney (2011) indicates that using digital tools for knowledge management is a very common practice within the enterprises. Louis-Sidney ( 2011) proposes a conceptual model for structuring knowledge supporting tools of an organization. This model is based on process logic. This model has led to the development of two demonstrators of information system. The first is IKOES (Inter-Knowledge Exchange System Objects) which automates the exchange of parameter values between parameterized files. The second is PKMS (Process Oriented Knowledge Management System) which provides a knowledge management system taking into account the existing interaction between knowledge supporting tools and business processes of re-designing.

A way of learning in SMEs is explained in [START_REF] Lima | Organizational Learning in SMEs' Strategic Management: A Descriptive and Systemic Approach[END_REF] who considers SMEs as either a behavioral system or an interpretation system. In a behavioral system, the members' short-term behavior is affected by the feedback of impacts generated from other members' action. In an interpretation system, the members search for information throughout the enterprise's environment, interpret this information and learn by generating knowledge.

TSAI (2009) view that there are three aspects to take into consideration for organizational learning in SMEs: individuals (especially the owners-managers), internal routines and external networks. Firstly, the owners-managers play a big role in the enterprise.

They are responsible for the decision making and their knowledge has an impact on the internal and external learning resources. Secondly, the internal routines also affect the learning process in the enterprise. These routines include organizational culture in addition to the internal relationships. Finally, external networks include all external resources that influence the organizational knowledge.

Modeling the Enterprises

As mentioned earlier, there is no model dedicated specially for SMEs. The models presented in this section are for enterprises in general. We studied theses models in order to understand enterprise modeling and then develop a model dedicated to SMEs.

TOVE Model

The TOVE project is first proposed by [START_REF] Fox | The tove project towards a common-sense model of the enterprise[END_REF] who outlined the goals of TOVE project in four points:

1. It provides a shared terminology for the enterprise in a way that every application can understand and use.

2. The first-order logic is used to define the meaning (semantics) of each term in a precise and an unambiguous as possible manner. • People across different enterprises.

• People and implemented computational systems.

• Different Implemented computational systems (like DBMS (database management system) for example).

The enterprise model defines the concepts that could be found in an enterprise and all the relations between these concepts. Enterprise ontology model is divided into five main sections:

• Meta ontology and time: The concepts of Meta ontology are used to describe other concepts in the ontology in addition to time.

• Activity and processes: These concepts describe everything in the enterprise that concerns activities.

• Organization: The main two concepts defined here are Organization Unit (OU)

and Legal-Entity.

• Strategy: This concept is related to strategic purposes and goals that the enterprise aims to achieve.

• Marketing: This concept defines everything which is related to sale (e.g. market, customer, product etc.). • Membership: This aspect concerns about representing the relationship between people and organizations. The representation provided by the organization ontology is to directly state that some individual (represented as a foaf:Agent) is member of an organization (using the relation org:memberOf).

• Location Information: This aspect concerns about the site of the organization.

Each organization has a primary site to indicate the default means by which an organization can be contacted, and a registered site to indicate a legally registered site for the organization. Each site has an address.

• Organizational history (merger, renaming): This aspect concerns about the significant changes that could happen for an organization. Significant changes do not include changes in the organization's personnel or internal structure, but substantial changes e.g. a merger to create a new organization. The organization ontology provides the necessary vocabulary to describe that change over time and the relationship between the original and resulting resources.

Note and Annotation Proposal

According to us, the note is an information resource in its own right. We define the note as being a "transcription of an idea that has a particular content". The content of the note is called its "body". We consider that the "body" of the note could be any resource including plain text, a document (image, video, sound, web page), forum, wiki, etc.

Concerning the annotation, the annotation granularity and form are terms used in the annotation definition. So we need to define these terms

• Annotation granularity (also called "scope" ) [START_REF] Sazedj | Time to evaluate: Targeting annotation tools[END_REF] indicates if the annotated data is a whole resource (e.g., a document) or part of a it (e.g., a section inside a document, a sentence, etc.). When the granularity is high, the annotation could be done to any part of the resource.

• The form of the annotation [START_REF] Euzenat | Eight questions about semantic web annotations[END_REF] indicates the type of annotation, a textual object or a structured object. Textual annotation has a plain text form.

Structured annotation could be a link to a structured object (e.g., html page, xml, rdf, etc.)

We consider the annotation as an information resource in its own right. The annotation for us is a particular note that has a "target" (the annotated data). So an annotation is defined as a "transcription of an idea that has a particular "target" (annotated data) and a "body" (annotating data) which is somehow about the target". We consider that the annotation could have a high granularity [START_REF] Sazedj | Time to evaluate: Targeting annotation tools[END_REF]. This means that it would be possible to annotate the resource itself or any part of it. We consider that the annotation form could be any information resource including plain text, a document (image, video, sound, web page), forum, wiki, etc.

The annotation's "target" must not be confused by the annotation's destination. The "target" is the annotated object whereas the destination is to whom the annotation is addressed. Both notes and annotations have a certain destination which could be the user himself/herself (personal use) or other members, but only annotations have a particular "target". So when the user adds an annotation, he/she intends to comment, explain, etc. a particular thing.

The annotation's "target" is not limited to documents or parts of them. The "target" of the annotation could be any subject or concept related to the using context (e.g. clients, products, machines, etc. for the use by a mechanical production enterprise)

The annotation's "target" must not be confused by the annotation's index. The "target"

is the annotated object whereas the index is the annotation's subject. Both notes and annotations could have one or more indices.

To take an illustrating example, let's consider the commercial is reading an invoice concerning the client C about the command of the product P. The commercial finds a mistake in the invoice calculation. He selects (or highlights) the amount and writes:

"There is a mistake, this should be recalculated". Under this text, he writes: "To the Administrative Director". If we want to apply our definition of the annotation, the different parts would be:

• The annotation's "body": It is the content of the annotation: "There is a mistake, this should be recalculated"

• The annotation's "target": It is the annotated data: the selected part of the invoice which is the miscalculated amount.

• The annotation's destination: It is by whom the annotation would be read:

the Administrative Director

• The annotation's index: It is the subject of the annotation. The commercial could index this annotation by either the client C or the product P or by both of them.

The same scenario is applicable for the note with the only difference that notes do not have a "target". For example, if the commercial writes "I have to visit the client C to talk about the command concerning the product P". He writes "To the Technical

Director". If we want to apply our definition of the note, the different parts would be:

• The note's "body": It is the content of the note: "I have to visit the client C to talk about the command concerning the product P".

• The note's destination: It is by whom the note would be read: the Technical Director

• The note's index: It is the subject of the note. The commercial could index this note by either the client C or the product P or by both of them.

Chapter Summary

In this chapter, we defined the organizational learning and illustrated the role the semantic web standard play in supporting the organizational leaning. We presented the different definitions of notes and annotations. We also presented our point of view concerning notes and annotations. According to us, notes and annotations are information resources on their own rights. We consider notes and annotations as being "transcription of an idea". Both notes and annotations have a content called a "body". The main difference between notes and annotations is that the annotation has a "target" (annotated data) whereas notes do not have "targets". The annotation's "target" is not limited to documents or parts of them. The "target" of the annotation could be any subject or concept related to the using context

We also presented in this chapter the enterprise models: TOVE, Enterprise project and the organization ontology. These models are not dedicated for SMEs but they are generic for any enterprise in general.

Chapter 4

Our Thesis

Orientation That We Took

In chapter 3, we presented notes and annotations taking tools with their limitations in terms of sharing and indexing. These tools do not respond to the special needs of SMEs.

So the direction we take in this work is the development of a digital tool that supports notes and annotation taking. The tool should take into consideration all SMEs needs that were identified in the field study. This means that the tool should be based on a model that takes into account SMEs needs to support organizational learning. The model on which the tool is based should:

• Be based on semantic web standards: As mentioned in chapter 3, semantic web models plays an important role for supporting organizational learning.

• Represent the collaboration in the enterprise: this means representing sharing information resource between users (members of the enterprise).

• Represent notes and annotations: They should be represented as information resources in their own right. In addition, they should be conform to the definition we gave them at the end of chapter 3.

• Represent SMEs specifications: the size of the enterprise, the multi-role for the same member, products, activities, clients, prospects, etc.

Our objective of such approach is to develop a digital tool that has functionalities based on model that is conform to these above points in order to facilitate the organizational learning within SMEs. In next section, we will give a brief description of MEMORAe approach then we will justify the choice of such approach.

A Brief Description of MEMORAe APPROACH

MEMORAe approach is a combination of a model and a web platform to manage all heterogeneous resources of knowledge in an organization. The model and the web platform have the same name as the approach. MEMORAe-core 2 (mc2) is a semantic MEMORAe web platform is based on MEMORAe-core 2 model. The platform is developed using web 2.0 technologies. Being based on MEMORAe core 2 means that the platform is dedicated for collaboration and resource sharing between members of an organization.

The Choice of MEMORAe Approach

MEMORAe approach with its model and web platform seemed as a candidate for knowledge capitalization within SMEs. This is for two reasons. using a modular approach. This would facilitates removing or adding new information resource types as being modules. This is described in next section.

MEMORAe-core 2: Towards a Modular Model

Before explaining the advantages that made us rethink the development of MEMORAecore 2 ontology model using a modular approach, we will give a brief introduction into the modular approach.

The term modularity originally comes from software engineering domain. In such domain, the design and implementation of an application takes into consideration the maintenance and re-usability of different modules. Modules are self-contained, independent and interchangeable units. Each module is responsible to execute only one aspect of the desired functionality.

From an ontology point of view, modularization is seen as a way to structure and organize ontologies. In these recent years, many ontologies have been developed to work across multiple diverse information systems. However, these ontologies are rapidly growing and becoming more and more larger and complex to manage. Here rises the modular approach as an essential need. So many reasons encouraged us to the use a modular approach in the development of MEMORAe-core 2. Firstly, according to Ben Abbes et al. ( 2012), a module is more easy to construct, maintain and replace. Secondly, [START_REF] Pathak | Survey of modular ontology techniques and their applications in the biomedical domain[END_REF] defines two reasons for using a modular approach in ontology construction:

• Parts re-usability: With the increasing development of semantic web models, many ontologies of specific domains were developed these recent years. It is therefore interesting and useful to use these ontologies partially or globally.

• Decrease the level of complexity: increasing the size of an ontology increases its complexity.

Thirdly, [START_REF] Despres | Réflexions sur les étapes de la construction d'une ontologie modulaire[END_REF] considers that ontology modularity has many advantages:

• It reduces the size of ontology components because each component is supposed to represent a sub-domain.

• It facilitates the process of ontology validation. The validation is done independently on each module and on relations between modules.

• It permits the local reasoning for retrieving suggestions on each module as each module is independent and self-contained.

• It enhances the visualization of the global ontology with its modules.

• 2012) also affirms that when choosing the modular approach for ontology construction, the model will be easier to build, maintain, and replace.

In next sections, we define ontology modules, we detail how the modular approach is applied to ontology modeling, we introduce a method for integrating a module to an ontology model. At the end of this section, we present the modular ontology MEMORAecore 2.

Defining the Modularity of Ontology

The modularity as an approach has its origin roots to the software engineering domain.

Modules in software engineering are independent and reusable units. In these recent years, the modular approach started its first steps in the semantic web domain. The use of this approach is more and more adopted for modeling semantic web ontology models. The modularity of ontologies is considered a crucial task to enable ontology reuse on the semantic web. Ontology modularization's main objective is to structure and organize ontologies. [START_REF] Pathak | Survey of modular ontology techniques and their applications in the biomedical domain[END_REF] defines the module as being a subset of a "whole" that makes sense (i.e., is not an arbitrary subset randomly built) and can somehow exist separated from the whole. An ontology module is therefore (according to [START_REF] Pathak | Survey of modular ontology techniques and their applications in the biomedical domain[END_REF]) a a sub-ontology of a "whole" that makes sense. [START_REF] Doran | Ontology module extraction for ontology reuse: An ontology engineering perspective[END_REF] defines the ontology module as being "a reusable component of a larger or more complex ontology, which is self-contained but bears a definite association to other ontology modules, including the original ontology". The ontology module is defined by Despres (2014) as being a "micro-ontology" that covers a particular domain and has connections (relations) with other modules. The connections in this case belong to source module.

There are two main approaches to construct modular ontologies. The first is done by ontology decomposition. In this case, there is an integrated ontology and the objective is to extract modules from this ontology to support a particular use case. The second is done by ontology composition. In this case, each ontology is independently developed and then integrated to the main ontology in a coherent and uniform manner.

Ontology composition is done using two main techniques:

• Ontology integration: In order to apply this technique, we could use: owl:import , The method proposed in this work is based on ontology composition approach. The method proposed is inspired by The Digital Kitchen Ontology [START_REF] Despres | Réflexions sur les étapes de la construction d'une ontologie modulaire[END_REF]. The main objective of The Digital Kitchen Ontology is to develop a modular ontology that could give suggestions for the user about available recipes. The suggestion must consider the user's profile, his/her food practices, nutritional preferences. The developers of the Digital Kitchen ontology have taken the decision (from beginning) to build a modular ontology based on ontology composition approach. The Digital Kitchen Ontology is a modular ontology which is organized as the following:

• A Master Module (MM): This is an ontology whose knowledge is a base for all sub-domain ontologies. This ontology is essential for the completeness of the global ontology. The perspective and the vocabulary of this ontology concepts are common for all sub-domain ontologies. Taking the example of The Digital Kitchen Ontology, the FOOD module could be considered as a master module.

• A Thematic Module (TM): This is an ontology that covers a particular sub-domain.

Taking the example of The Digital Kitchen Ontology, PERSON, PREPARATION and UNITS could be considered as thematic modules.

A TM ontology could import another TM ontology by using owl:import instruction. The owl:import instruction permits to include in the importing TM ontology all the axioms of the imported TM ontology. The hierarchies of TM ontologies are disjoints from each other. However, inter-module relations could be established between the concepts of the disjoint hierarchies. The inter-module relations are essential for the reasoning processes between the modules. These relations belong to the importing ontology.

According to us, owl:import is not enough for module integration. Other axioms and properties should be added to the integrating module. These axioms guarantee the self-independence of the integrated module especially when there is a need to add new properties to the integrated module.

In the next section, we will present a method for integrating a module into an ontology (ontology composition)

A Method for Integrating a Module to Ontology

In this method, there is a generic ontology which is considered as a base ontology (similar to MM ontology in The Digital Kitchen). The generic ontology is called the "Abstract Ontology" i.e. an ontology that SHOULD be completed by one or more modules (according to the need) in order to be used. We use owl:import to import the modules.

However, we consider that owl:import is not enough to integrate a module. We must define an integration method, i.e., the properties and the axioms that we must add to the ontology when a module is integrated. The method is as the following:

• We duplicate the "Abstract Ontology" and keep its namespace. We obtain an "Implementing Ontology" i.e. an ontology which is ready to import modules.

• We import a module (M) (keeping its namespace) to IO

• We add the required elements and modify the required axioms.

If a module M i needs to integrate another module M j , we follow the same method beginning with the M j module as the first abstract ontology

The Modular Ontology MEMORAe-core 2

The modular ontology MEMORAe-core 2 is the modular version of MEMORAe-core 2 model (owl is present in Appendix C). Semantic web standards are now integrated as being modules. So MEMORAe core 2 modular ontology integrates 4 modules: FOAF, SIOC, Note, Annotation. The integration of a module is based on the method already presented. The examples of the following sections will be taken from the following scenario:

Tomas is a commercial working in a small enterprise of mechanical production. Tomas usually takes notes and annotations during his work, specially during a tour to the client.

Tomas needs to prepare this tour to the clients, he needs to organize his agenda and appointments to the client.

The following details the integration of each module into MEMORAe-core 2 using the presented method:

Integrating FOAF Module to mc2:

In FOAF module, an agent is represented by foaf:Agent. The agent could be a person represented by foaf:Person, an organization represented by foaf:Organization or a group represented by foaf:Group. The objective is to enable agent representing in MEMORAe-core 2 (mc2) as being resources. According to our integration method, mc2 plays the role of "Abstract Ontology" (AO). mc2 is duplicated to obtain the "Implementing Ontology" (IO). The module FOAF (M) is integrated to IO. The integration results in the creation of the following triplets (a non underlined item belongs to IO and underlined item belongs to FOAF module):

For each concept that could be instantiated from the FOAF module, a concept in mc2 is created as a specialization. Thanks to this integration, we can add in the knowledge base (that has kb as a prefix)

the following triples:

Returning to Tomas, we can create Tomas as a person agent :

-kb:tomas a mc2foaf:Person Integrating SIOC Module to mc2:

In SIOC Module, a user is represented by sioc:UserAccount and are members of sioc:UserGroup. Users can access a sioc:Space to share resources. The objective is to indirectly link a user in mc2 with a space in mc2 through relations defined by SIOC. According to our integration method, mc2 plays the role of "Abstract Ontology" (AO). mc2 is duplicated to obtain the "Implementing

Ontology" (IO). The module SIOC (M) is integrated to IO. The integration results in the creation of the following triplets (a non underlined item belongs to IO and underlined item belongs to SIOC module):

For each concept that could be instantiated from the SIOC module, a concept in mc2 is created as a specialization.

-mc2sioc:User rdfs:subClassOf sioc:UserAccount Assigning the user account of Tomas to his personal group: :

-kb:tomasAccount sioc:member of kb:tomasGroup -kb:tomasGroup sioc:has member kb:tomasAccount

Assigning the sharing space to the group:

-kb:tomasGroup sioc:usergroup of kb:tomasSpaceOfGroup -kb:tomasSpaceOfGroup sioc:has usergroup kb:tomasGroup Every user has a personal group which has a personal sharing space. Tomas uses this group to add and index personal information resources. Tomas also belongs to another group which is an Instituational Group (It has all the employees of the enterprise).

Creating the Instituational Group and its sharing space.

-kb:enterpriseGroup a mc2sioc:InstituationalGroup -kb:tomasAccount sioc:member of kb:enterpriseGroup -kb:enterpriseGroup sioc:has member kb:tomasAccount So Tomas belongs to two groups, one personal and other shared with his enterprise colleagues. So according to his need, he could choose between the two spaces to share his information resources.

Integrating Note Module to mc2:

In BIBO module, a note is represented by bibo:Note which is a specialization of bibo:Document (the note is considered as a special type of document). In mc2, it is defined that the user could share resources (through the triple : mc2sioc:User mc2sioc:share mc2:Resource). The objective is to enable the user to share notes. According to our integration method, mc2 plays the role of "Abstract

Ontology" (AO). mc2 is duplicated to obtain the "Implementing Ontology" (IO). The module BIBO (M) is integrated to IO. The integration results in the creation of the following triplets (a non underlined item belongs to IO and underlined item belongs to BIBO module):

For each concept that could be instantiated from the BIBO module, a concept in mc2 is created as a specialization.

-mc2bibo:Note rdfs:subClassOf bibo:Note -mc2bibo:Note rdfs:subClassOf mc2bibo:Document -mc2bibo:Note mc2bibo:has body mc2:Resource

The third triple is added to the model the content of the note. Each note has a particular content which could be any resource of the model. The relation mc2bibo:has body links the note to its content.

-mc2bibo:Document rdfs:subClassOf bibo:Document -mc2bibo:Document rdfs:subClassOf mc2:SimpleResource Tomas is at the client C, he is discussing with the client about a new product P. He is drawing on the board at the client. At the end, he takes his mobile phone and takes a photo of the board. This photo is considered as a note.

Thanks to this integration, we can add in the knowledge base (that has kb as a prefix)

the following triples:

Creating the instance of Tomas note:

-kb:tomasNote a mc2bibo:Note Tomas chooses the C client and the P product as an index:

Sharing the note by the user:

-kb:tomasAccount a mc2sioc:share kb:tomasNote For each chosen index, an index is created and the index key is rendered visible to the enterprise sharing space.

Creating the index key for the client C, linking the index key with the client instance and the note instance and rendering it visible for the enterprise space:

-kb:indexKeyForClientC a mc2:IndexKey -kb:indexKeyForClientC mc2:about instance kb:c -kb:indexKeyForClientC mc2:index of kb:tomasNote -kb:indexKeyForClientC mc2:is visible for kb:enterpriseSpaceOfGroup

Creating the index key for the product P, linking the index key with the product instance and the note instance and rendering it visible for the enterprise space:

-kb:indexKeyForProductP a mc2:IndexKey -kb:indexKeyForProductP mc2:about instance kb:p -kb:indexKeyForProductP mc2:index of kb:tomasNote -kb:indexKeyForProductP mc2:is visible for kb:enterpriseSpaceOfGroup

In this way, Tomas has taken a photo note, indexed and shared it.

Integrating Annotation Module to mc2:

The annotation module is represented by Open Annotation (OA) module which is added to MEMORAe-core 2 model within CESACO project. In OA module, an annotation is represented by oa:Annotation.

Each annotation has a target represented by oa:hasTarget and a content represented by oa:hasBody. In mc2, it is defined that the user could share resources (through the triple : mc2sioc:User mc2sioc:share mc2:Resource). The objective is to enable the user to share annotations. According to our integration method, mc2 plays the role of "Abstract Ontology" (AO). mc2 is duplicated to obtain the "Implementing Ontology" (IO).

The module OA (M) is integrated to IO. The integration results in the creation of the following triplets (a non underlined item belongs to IO and underlined item belongs to OA module):

For each concept that could be instantiated from the annotation module, a concept in mc2 is created as a specialization.

-mc2oa:Annotation rdfs:subClassOf oa:Annotation -mc2oa:Annotation rdfs:subClassOf mc2:SimpleResource -mc2oa:Annotation mc2oa:has body mc2:Resource (the content of the annotation could be any resource)

-mc2oa:Annotation mc2oa:has target owl:Thing (we can annotate anything)

Tomas is reading a technical document concerning a product. Tomas has an illustrative photo of this product. He annotate the technical document with this photo. The photo is the content of the annotation ("body") and the technical document is the "target" of the annotation.

Thanks to this integration, we can add in the knowledge base (that has kb as a prefix)

the following triples:

Creating the instance of Tomas annotation:

-kb:tomasAnnotation a mc2oa:Annotation As the model considers the annotation as a resource, the annotation is shared by Tomas the same way he shared a note. Tomas choses by which concept/instance he wants to index the annotation. For each chosen concept/instance, an index key is created and this index key is rendered visible to the sharing space chosen by Tomas.

MEMORAe-SME ontology model and its modules

MEMORAe-SME is an ontology model for knowledge capitalization within Small and Medium-sized Enterprises (SMEs). Regarding the typology of ontologies, MEMORAe-SME is a domain ontology representing the collaboration in Small and Medium-sized Enterprises (SMEs).The ontology takes into account the results of the field study already presented in chapter 2. The model should permits the following:

• Identify the Role of the user e.g. commercial role, technical responsible role, etc.

• Take and share resources (notes, annotations, etc.) about the Client enterprises, Prospect enterprises, Activities and Machines of the enterprise.

• Prepare the Tour of the commercial among the Clients and Prospects of the enterprise.

• Organize the Agenda of the user i.e. the list of Events and appointments.

• Identify the Contacts of the Clients and Prospects.

MEMORAe-SME model is built from the modular ontology MEMORAe-core 2 as a base. The added modules are permits to respond to SMEs need:

Role Module

The Role module is inspired by the role as it is defined in TOVE ontology [START_REF] Fox | An organisation ontology for enterprise modelling: preliminary concepts for linking structure and behaviour[END_REF]. The role (as indicated in TOVE model), defines one or more prototypical job functions in an organization. Each role is associated with (Fig. 4.2):

• Goals: one or several goals that the role is intended to achieve.

• Authority: authority needed for the role to achieve its goals. Authorities include the right of using resources, or performing activities.

• Skills: one or more skills required for the realization of the job functions.

• Resources: the resources allocated to the role.

For each concept that could be instantiated from the Role module, a concept in mc2 is created as a specialization. The integration results in the creation of the following triplets (underlined item belongs to Role module): Thanks to this integration, we can add in the knowledge base (that has kb as a prefix)

the following triples:

Creating the commercial authority:

-kb:commercialAuthority a mc2role:Authority -kb:tomas mc2foaf:plays kb:commercialRole

Agenda and Event Modules

The agenda module and the event module are two separate modules. However, the two modules are considered to be resources (the event is a simple resource and the agenda is a composite resource). The two modules have relations between each others i.e. the agenda is composed of one or more events. The agenda is defined as a "set of events distributed over the time line". The development of the event module is inspired by many ontology models, we can cite:

• The Event Ontology1 .

• LODE: An ontology for Linking Open Descriptions of Events2

The event is defined as "Something that could take place in the future or happened in the past". Each event is assigned to an agent, has resources, has sub-events and has the following attributes (Fig. 4.3): • Duration: a literal indicating the duration of the event e.g. 2 hours.

• Place: a literal indicating the name of the place of the event e.g. enterprise name.

• Address: a literal indicating the address of the place in which the event will take place.

For each concept that could be instantiated from the agenda and event modules, a concept in mc2 is created as a specialization.

The integration results in the creation of the following triplets (underlined item belongs to the event or agenda module):

-mc2event:Event rdfs:subClassOf event:Event Thanks to this integration, we can add in the knowledge base (that has kb as a prefix)

the following triples:

Creating the agenda of Tomas:

-kb:tomasAgenda a mc2agenda:Agenda

Creating an event which is an appointment with the client:

-kb:tomasAppointmentAtClient a mc2event Assigning the two events to the agenda:

-kb:tomasAgenda mc2agenda:composed of kb:tomasAppointmentAtClient -kb:tomasAgenda mc2agenda:composed of kb:tomasAppointmentAtProspect

Tour Module

The tour module represents the tour of the commercial agent among clients and prospects.

The tour is a sequence of appointments. The commercial agent organize tours as a sequence of appointments with clients and prospects. The tour has the following attributes (Fig. 4.4):

• Start date: the start date of the first event in the tour.

• End date: the end date of the last event in the tour.

• Start time: the start time of the first event in the tour.

• Duration: the sum of event's durations.

For each concept that could be instantiated from the tour module, a concept in mc2 is created as a specialization.

The integration results in the creation of the following triplets (underlined item belongs to the tour module):

-mc2tour:Tour rdfs:subClassOf tour:Tour -mc2tour:Tour rdfs:subClassOf mc2:CompositeResource Thanks to this integration, we can add in the knowledge base (that has kb as a prefix)

the following triples:

First appointment (Client A):

- The tour is composed of these three appointments:

-kb:clientTour a mc2tour:Tour

Clients And Prospects Module

Clients and prospects module is inspired by the Enterprise Project Uschold et al. (1998).

Clients and prospects enterprises are considered to be specializations of legal entity concept (Fig. 4.5). A legal entity is an entity that has rights and responsibilities in the world at large and by legal jurisdictions in particular. Legal entities are considered to agents (persons, groups or organizations). In order to represent the address and For each concept that could be instantiated from the clients and prospects module, a concept in mc2 is created as a specialization.

The integration results in the creation of the following triplets (underlined item belongs to the enterprise or vCard modules):

-mc2enterprise:LegalEntity rdfs:subClassOf enterprise:Legal-Entity -kb:client mc2foaf:holds kb:clientVcard

Contact Module

The contact module rises as an essential need for SMEs. The commercial or the designer may need to know their contacts within the clients and prospects enterprises. This means that the contact module has relations with client prospect module. Each client or prospect enterprise could have one or more contacts. The contact module (which is considered to be an agent) is therefore imported. The contact could be a person, a group or an organization (Fig. 4.6).

For each concept that could be instantiated from the contact module, a concept in mc2 is created as a specialization. The integration results in the creation of the following triplets (underlined item belongs to the contact modules): Thanks to this integration, we can add in the knowledge base (that has kb as a prefix)

the following triples:

Creating a contact person:

-kb:contactPerson a mc2contact:PersonContact -kb:contactPerson contact:firstName "Peter" -kb:contactPerson contact:lastName "Brown"

The contact is a resource: As the contact is a resource, it could be indexed. For example, if the contact "Peter

Brown" is a contact about the instance chuck233A, so this contact could be indexed by the instance chuck233A. Creating the index key for the instance chuck233A, linking the index key with the instance and the contact instance and rendering it visible for the enterprise space:

-kb:indexKeyForContact a mc2:IndexKey The contact is not only an instance of PersonContact, it is also an instance of a mc2contact:Contact which is a mc2foaf:Agent. So the contact holds a vCard.

-kb:contactPerson mc2foaf:holds kb:peterVcard

Assigning the contact to the enterprise kb:client (already created in client and prospect module):

-kb:client mc2enterprise:has contact kb:contactPerson

Material Resource Module

Material resource module is a very important module for SMEs. It represents all the material resources (MR). The material resource is defined as a resource that have physical existence. This includes produced resources e.g. products, producing resources e.g. machines, consumed resources e.g. raw material. The MR is considered to be a Simple Resource (Fig. 4.7). The material resource module has relations with the activity module (presented in next section)

The MR has can be specialized to the following concepts:

• ManufacturingResource: Resources that play a certain role during activities, e.g.

Machines can have a specific role during activity (saw machines are used to cut the metal during the manufacturing activity).

• ConsumedResource: Resources that can be consumed during activities, e.g. raw materials that can be consumed during activities (metal is a raw material that is consumed during the manufacturing activity).

• BuySellProduct: Products which are bought by the enterprise to be sold by the SellActivity for profit purpose.

• ProducedResource: The products produced in the enterprise itself by the Manu-facturingActivity to be sold by the SellActivity. There are two specifications of such resources:

1. StandardProduct: All the parameters of the product are already specified by the enterprise.

2. SpecificProduct : The product is manufactured according to user-specific parameters.

For each concept that could be instantiated from the material resource module, a concept in mc2 is created as a specialization. The integration results in the creation of the following triplets (underlined item belongs to the material resource modules):

-mc2mr:MaterialResource rdfs:subClassOf mr:MaterialResource One of the objectives of this integration is to permit the user to annotate material resources e.g. machines, products, etc. As presented in the annotation module, each annotation has a content (body) which is a resource and a target which could be an "Thing". Here is an example of annotating a machine by a user (we can add in the knowledge the following triples):

Creating the machine:

• kb:teteDePercage a mc2mr:Machine

• kb:teteDePercage a mr:Machine By inference:

• kb:teteDePercage a mc2mr:ManufacturingResource

• kb:teteDePercage a mc2mr:MaterialResource

• kb:teteDePercage a mc2:SimpleResource

• kb:teteDePercage a mc2:Resource

• kb:teteDePercage a owl:Thing So kb:teteDePercage is a "Thing" and could be the target of an annotation.

Creating the annotation:

-kb:tomasAnnotation a oa:Annotation -kb:tomasAnnotation a mc2oa:Annotation By inference:

-kb:tomasAnnotation a mc2:SimpleResource -kb:tomasAnnotation a mc2:Resource

The annotation is a resource that could be shared by a user.

Creating the annotation content(a document image of the machine)

-kb:teteDePercageImage a mc2:Document By inference:

-kb:teteDePercageImage a mc2:SimpleResource -kb:teteDePercageImage a mc2:Resource

The image is a resource and it could be the content (body) of the annotation.

Assigning the annotation to its content (image) and target (machine) and sharing it by the user.

-kb:tomasAnnotation mc2oa:has body kb:teteDePercageImage -kb:tomasAnnotation mc2oa:has target kb:teteDePercage -kb:tomasAccount a mc2sioc:share kb:tomasAnnotation

Activity Module

The activity module represents the processes and procedures done over time. Every activity requires at least one role to be preformed. In addition, the activity may be composed of sub-activities (Fig. 4.8).

The Activity has the following data properties:

• Duration: The duration of the activity (year-month-days-hours-minutes)

The specifications of Activity can be:

• ManufacturingActivity: The activity of manufacturing a product.

• SellActivity: The activity of selling a product.

• BuyActivity: The activity of buying a resource.

For each concept that could be instantiated from the activity module, a concept in mc2 is created as a specialization. The integration results in the creation of the following triplets (underlined item belongs to the activity modules):

-mc2activity:Activity rdfs:subClassOf activity:Activity The activity module has relations with the material resource module (Fig. 4.9). These relations are not established directly between the two modules. This means that the relations do not have domains (or ranges) that belong to concepts with mr or activity name spaces. The relations are established between the concepts that have mc2mr or mc2activity name spaces. This justifies why we establish a concept (as a specialization) for each concept that could be instantiated from the module. These concepts are considered as an intermediate between the imported concept from the module and the importing ontology. If we do not create such an intermediate concept, we have to establish the relations directly between the activity and material resource module. This means that two modules are not independent and are tightly coupled which breaks the definition of the module (a self-contained ontology)

The bought by relation:

-mc2mr:ManufacturingResource mc2mr:bought by mc2activity:BuyActivity Thanks to this integration, we can add in the knowledge base (that has kb as a prefix) the following triples:

Creating an activity for buying machines:

-kb:buyMachineActivity a mc2activity:BuyActivity -kb:buyMachineActivity a activity:BuyActivity creating the activity role:

-kb:buyMachineRole a mc2role:Role -kb:buyMachineRole a role:Role

Assigning the role to the activity:

-kb:buyMachineActivity mc2activity:require kb:buyMachineRole Buying the machine teteDePercage (created in previous section)

-kb:teteDePercage mc2mr:bought by kb:buyMachineActivity Creating an activity for manufacturing:

-kb:manufacturingActivity a mc2activity:ManufacturingActivity -kb:manufacturingActivity a activity:ManufacturingActivity creating the activity role:

-kb:manufacturingRole a mc2role:Role -kb:manufacturingRole a role:Role

Assigning the role to the activity:

-kb:manufacturingActivity mc2activity:require kb:manufacturingRole

Involving the machine teteDePercage in the manufacturing activity -kb:teteDePercage mc2mr:involved by kb:manufacturingActivity

The application Ontology for mechanical SMEs

Knowing that our partner in CESACO project is a SME specialized in the mechanical production, developing an application for such enterprises is necessary. This ontology has the mechanical products produced in such enterprises and machines used for the manufacturing. The ontology has three main concepts (owl is presented in Appendix D)

The three concepts are:

• Mandrin (called a chuck in English): It is a specialized type of clamp used to hold an object, usually an object with radial symmetry, especially a cylindrical object (Fig. 4.10). It is most commonly used to hold a rotating tool.

• Mors de serrage: It is used by the mandrin (chucks) for clamping workpieces.

(Fig. 4.11) (Fig. 4.12)

• Accessoire Machine-Outil: Accessories for the machines like pinces (pliers), mandrin (chucks), Etaux (clamps), etc.

The ontology has te as a namespace, the ontology has the following triples:

Chapter Summary

In this chapter, we indicated that the direction we take in this project is the development of digital tool that supports note and annotation taking/sharing. We justified our choice of MEMORAe approach. This approach is comprised of a semantic model (MEMORAecore 2) and a web platform to manage all heterogeneous resources of knowledge in an organization. We illustrated the advantages of redeveloping this model using a modular approach and we proposed a new method for modular integration. We also presented MEMORAe-SME model which is a destined to SMEs by integrating certain modules.

The application ontology concerning the products and machines of mechanical SMEs was also detailed. In next chapter, we will present MEMORAe prototypes (web and mobile).

Chapter 5

Prototypes

In this chapter, we will present MEMORAe web and mobile applications. we will firstly describe the functionalities of these applications and then present a complete usage scenario.

MEMORAe-SME Web Application

MEMORAe-SMEAe web application is part of MEMORAe approach. It is developed Knowing that MEMORAe web platform is based on MEMORAe-core 2 model, this model has become modular. This means that the platform should be developed using a modular approach. When a module is removed from / integrated to MEMORAe-core 2 model, the functionalities related to this module should be removed from / integrated to MEMORAe web platform.

We also integrated the ability to switch between many semantic references:

• Clients map: It is the default when the user logs in. This map has the list of all clients. This map is an extract of MEMORAe-SME model. The user uses this map in order to retrieve / take notes, annotations, appointments and prepare tours related to clients.

• Prospects map This map has the list of all prospects. This map is an extract of MEMORAe-SME model. The user uses this map in order to retrieve / take notes, annotations, appointments and prepare tours related to prospects.

• Products and machines map: The user uses this map in order to retrieve / take notes, annotations, appointments and prepare tours related to products and machines.

Whatever the chosen map is, indexing is done by the focus concept of this map. During next sections, we will detail each functionality of the web application.

Taking Notes

While navigating through the map, the user could consult the notes related (indexed)

by the focus concept. The user could also create new notes. In order to create a note, the user clicks the plus (+) button of the note tab. The user then chooses if it is a text note or a document note (Fig. 5.3). If it is a text note, the creation is done in two phases. In the first phase, the user enters the textual content of the note by keyboard or vocally by the microphone. The vocal note is then transformed to text using a "speech to text" technique. This first phase is important to propose to the user indexes from the semantic map by analyzing the text content of the note. In the second phase, the user has the possibility to modify the default values of: note title (its value is by default from the note content), note index (its value is by default from the focus concept and possible proposed indexes), note sharing space (its value is by default the opened sharing space)

and note tags (no value for the tag by default) (Fig. 5.4). The user could completely change these default values. For example, the user could unselect the focus concept from the list of indexing concepts and select new ones. The user could share the note in a sharing space different from the one opened; or even share the note in more than one sharing space. Concerning the tag, it is a descriptive term created by the user. The objective of tagging the notes is to search these notes by tags. At the second phase, the user clicks on the add button and the note is created. Having default values for title, index, and sharing space accelerates the creation of the note. If the user is ok with the default values, he/she directly clicks the add button.

Taking Annotations

The user of the platform can annotate:

• Text parts of pdf documents using pdfJS viewer tool. While reading a document, the user can choose a text in order to create an annotation (Fig. 5.5). The user chooses the text he/she wants to annotate, the type of annotation (e.g. question, comment, etc.), the indexing concepts and the sharing spaces in which he/she wants to share the annotation. The user then writes the content of the annotation and creates it. The selected text is the annotation "target" and the content of the annotation is its "body". The user can not only create annotations, but also filter the annotations of the document thanks to the search tool which is integrated to the document pdfJS viewer. With such a tool, it is possible to filter the annotations of the document by type, date, author, indexing concept, sharing space (to which the user has access), etc. • All resources : documents, notes, events, tours, contacts and annotations themselves. While opening a resource, the user can view its annotations (if there are annotations) . The number on the button comments indicates the number of its annotations (0 when there are no annotations) (Fig. 5.6). In order to view the annotations of the resource, the user clicks the comments button. A list of the resource annotations is shown with a plus (+) button. The plus (+) button is for creating a new annotation (Fig. 5.7). Like the note, the creation of the annotation is done in two phases. In the first phase, the user enters the textual content of the annotation. This first phase is important to propose to the user the indexes from the semantic map by analyzing the text content of the annotation. In the second phase, the user has the possibility to modify the default values of: annotation title (its value is by default from the annotation content), annotation index (its value is by default from the focus concept and possible proposed indexes), annotation sharing space (its value is by default the opened sharing space) and annotation tags (no value for the tag by default) (Fig. 5.8). The user could completely change • Concepts of the semantic map. When navigating through the map, the user can annotate the focus concept of the semantic map (Fig. 5.9). From the annotation tab of the sharing space, the user clicks the plus (+) button and the same interface for creating the annotation is presented (Fig. 5.10). The "target" of the annotation in this case is the concept itself. Retrieving the annotation: The annotation, either if it is for a part the resource or for the resource itself, is accessed in two ways. The first way is when opening the resource itself, a list of all its annotations is presented. For example, when opening a pdf document using the pdfJS viewer, the annotations made for parts of this document is presented in the viewer (Fig. 5.5). Another example is when opening a resource (e.g. a document), the list of the annotations of this resource is directly presented in the annotation section of the resource (when clicking on the comments button) (Fig. 5.11).

The second way to access the annotation of resource (or part of them) is in the annotation tab in its related sharing space when the focus concept is the annotation's indexing concept. Modeling the annotation as a resource makes it presented in the resources list like the note, document, etc (Fig. 5.12) (Fig. 5.13). These annotations still have the link to their "targets". When the user opens an annotation, he/she still have the ability to access the annotated resource (or the annotated part). This means that the resource is being accessible by its annotations which are indexed by the concepts of the semantic map (Fig. 5.14). The user of the platform can organize the events in which he/she would participate.

Adding the event is done from the event tab in the sharing space. Each event has a subject, a description, a start time, a duration, a date, an address, etc. Modeled as a resource, the event could be indexed by the concepts of the semantic map and shared in a sharing space (Fig. 5.15). When the event is created, the user could either annotate it or add notes to it (Fig. 5.16). When annotating the event, the "target" of the annotation is the event itself. when the user annotates an event, he/she intends to describe it e.g. "This is appointment is very important to gain the client's confidence". Notes are resources related to the event but do not describe it. For example, the commercial could write a note during the appointment at the client's enterprise: "This product offer should be enhanced". This note is taken during the event but it does not describe it.

Organizing The Tour

The tour is organized from the events (appointments) of the agenda. The user gives the tour a title, a start date, index and a sharing space (Fig. 5.17). When the tour is created, the user adds the corresponding appointments to it. The tour could be annotated like any other resource (Fig. 5.18) (Fig. 5.19).

Adding Contacts

The user of the platform could add contacts related to particular subjects. These subjects are the indexing concepts of the semantic map. For example, the commercial in Tour Equipement could add the contact he knows in a particular client. The commercial enters the contact information (name, surname, telephone, e-mail, etc.), choses a sharing space and indexes him/her by the client (Fig. 5.20). If the contact is a member of the same organization of the user, this latter has just to choose the member from the organization members list, choose the sharing space and the index (Fig. 5.21). The user could also add a contact from a registered person who is external to his/her organization.

Contacts could be also imported using a file contact that has xml or Vcard format.

MEMORAe-SME Mobile Application

The main objective of the mobile application is that the user is not obliged to index and share the resource at the creation time. The user could add the resources locally on his/her phone (tablet) and share it later on in MEMORAe. In addition, the mobile application seems like an adequate solution for the commercial's tour at the client. In this case, the commercial could take the application with him/her to the tour. The application permits to add notes (text, photo, audio and video), appointments and the appointment information and index. In order to add a tour, the user selects the appointments of the tour and then adds the tour information and index. Sharing the appointments and the tours is done the same way as sharing the notes: log in and then choose the sharing space.

Usage Scenario

Tomas is a commercial at an enterprise for mechanical products manufacturing. Tomas's main job is to visit the enterprise's clients and prospects in order to develop the enterprise's commercial relations. Tomas organize tours in which he visits the clients and prospects enterprises. In order to organize the tours, Tomas uses either MEMORAe web application or MEMORAe mobile application. For example, if Tomas wants to visit x, y clients and z prospect, he starts by retrieving old notes, annotations, appointments with x, y and z. To organize the new tour, he creates in his agenda appointments with x, y and z and then creates the tour and adds the appointments to it. During the tour, the commercial takes MEMORAe mobile application with him. This would help him to take notes during or after the appointment. For example, during the appointment at the client x, he could take a photo of the machine that needs the mechanical chuck (Mors de serrage) in order to show it to the Technical Director. The photo is considered as a local note in the mobile application. When the commercial considers that he wants to share the note, he logs into MEMORAe, chooses the sharing space of his group with the Technical Director, chooses (or confirms) the indexing concept(s) and shares the note. Tomas could choose the client or the product as indexing concepts. Tomas could also choose to link the note to the appointment. This helps for organizing next appointments to same client, Tomas could retrieve notes not only by its indexes (client and product) but also by the context in which the note is taken (the appointment). The Technical Director could now be updated about chuck that they need to manufacture for the client's machine.

Chapter Summary

In this chapter, we viewed the different functionalities of MEMORAe web and mobile applications. Taking notes and annotations within MEMORAe web platform overcomes the limitations of other note and annotation taking tools. Existing note taking tools still have limitations in terms of indexing and sharing. Sharing notes in these tools is done via the mailing system and there is a remarkable absence of an indexing system. Annotations in current annotation tools are still attached to their targets with no possibility to share and index the annotation itself. Within MEMORAe applications, notes and annotations are considered as resources in their own right. They could be indexed and shared as any other resource. This would facilitate sharing notes and annotations between users and easily retrieve them when needed.

Chapter 6

Experimental Evaluation

In this chapter, we will present two experimentations of MEMORAe web and mobile applications. The first experiment is done within a university course and the second is done within our enterprise partner Tour Equipement.

Evaluating Taking/Sharing Notes and Annotations by

Students Within a University Course

In this section, we will detail the experiment that took place in the university by the students.

Protocol of the Experiment

The about a particular topic and then capitalize knowledge resulting from this "technology watch" within MEMORAe web platform. The students were divided into four groups of (10-13) persons. Each group had a particular topic to work on. The "technology watch" performed by each group had two main objectives:

• Understanding the importance of knowledge capitalization.

• Implementing the collaborative learning among the members of the group who are working about a particular topic.

Students were meeting in the practical part of the course (2 hours per week). The web platform (hosted by the university servers) was also accessible from outside the university, so students could also do an additional work if they need. A report summarizing the work of each group is demanded at the end of the semester. So the first task was to do a "technology watch" in order to build an ontology of their particular topic. This ontology is used to produce the semantic map. The construction of this map was a part of the learning process. The students then started to capitalize and exchange knowledge around this map.

Results of the experiment

At the end of the semester (January 2014), an anonymous questionnaire was organized to get the students' feedback (questionnaire is present in appendix B). All the students responded to the questionnaire. The results of using notes and annotations are as the following:

• 80 % of students found that taking notes and managing them as information resources enhanced knowledge sharing among them. Students pointed out that they were able to retrieve the others' ideas about the topic of the group. Students indicated that this exchanging of notes enriched their knowledge and helped them collaboratively work on the given topic. Students affirmed that the indexing and searching of the notes as other resources facilitated the notes retrieval when needed.

• 73 % of students indicated that considering the annotations as information resources helped them to access the documents' annotations which are added by others. These annotations were available at the resources list outside their target resources. However, the annotations were still linked to their target resources and the students were able to open the target resource by its annotations.

• 88 % of students benefited from the parallel view of knowledge resources (which treat the same subject) in different sharing spaces. They were able to drag notes and annotations as any information resources from one sharing space to another in order to share them with other students when needed.

Tour Equipement Enterprise Test

In this section, we will detail the experiment that took place within our enterprise partner Tour Equipement.

Protocol of the Experiment

Every research project follows a certain methodology. In this research project, we followed a research design approach Trochim (2005). The main objective of such approach is to structure the research by holding its major parts in order to address the central research questions. For example, the research study has many parts (information collection, experimental testing, result analyzing, reactions, etc.), the more these parts are organized by a particular protocol (e.g. a research design) the more this research study is likely to give accurate, reproducible results. There are many types of research design, this work was mainly based on descriptive and experimental types:

• Descriptive Research Design (DRD): The objective of descriptive study is to collect information. This could be done with or without interactions with the studied participants. In CESACO project, we used the descriptive research design in the field study Chapter 2. There were interactions with the enterprise actors (through the interviews) and observations without interaction.

• (5) Presenting the applications to Tour Equipement enterprise in order to practice the applications and to get their feedback. MEMORAe web and mobile applications were presented at Tour Equipement enterprise on July 2015. Three users used the applications: The Technical Director, the Commercial Director and the apprentice student.

Testing in Tour Equipement Enterprise

The prototype (web and mobile applications) was tested in the Tour Equipement enterprise. This test took one day. It was made in the presence of the Commercial Director, a new Technical Director, an apprentice student and the Enterprise Director. The test started by explaining the prototype objective. Then a demonstration of the prototype was made through a usage scenario. Each functionality of the prototype was detailed to the enterprise members. Questions also were asked by the members in order to better understand the functionalities. This exchange of ideas through questions and answers allowed a better comprehension of the prototype usability by the members. Then the prototype was tested directly by Commercial Director in the presence of all other members in order to understand how to use it. The Commercial Director started by the web application. He added two notes (one vocal and one textual) and indexed them by different clients. He then annotated a document (the document was already added to the system), indexed this annotation and shared it. The annotation then was opened from its sharing space as a resource. The Commercial Director then added three appointments with three different clients. He created a tour and indexed it with these three clients and then added the appointments to the tour. In order to test the notes and annotations of an appointment, the Commercial Director choose one appointment and added a note to it and then he annotated it. From the mobile application, the Commercial Director retrieved the resources he added from the web application. He then added a textual note using his voice (speech to text recognition), indexed the shared note within MEMORAe in order to retrieve it back from the web application.

Results of the experiment

The to him, this consultation of notes/annotations is so advantageous for the preparation of the appointments at the clients/prospects.

Chapter Summery

In this chapter, we presented two experimentations of MEMORAe applications. The first is done within a university course in the UTC university. The objective was to test the utility of note and annotation taking tool by young generation to get their feedback.

Students indicated that the modeling of notes and annotations as information resources is so beneficial for knowledge management. This modeling facilitates knowledge sharing/indexing and retrieval among them. Tour Equipement employees also appreciated the use of MEMORAe-web and mobile applications. The applications facilitated the process of organizing the tours by the Commercial Director especially when consulting old notes/annotations indexed by the clients/prospects to visit. The applications facilities the retrieval of knowledge related to products, as the Technical Director has affirmed. We also presented in the chapter the research design methodology that we followed in this work.

Chapter 7

Conlusion, Perspective and

Future Work

In this chapter, we will present the conclusion of this work, we will also present the perspective and possible future work of this project.

Conclusion

This work addresses the problem of knowledge capitalization within SMEs. By knowledge capitalization we mean: having a formal knowledge system with strategies for knowledge sharing. This knowledge sharing resides at the heart of the knowledge capitalization system. The first and direct advantage for having a knowledge capitalization system within an enterprise is to support organizational learning within this enterprise.

The organizational learning within an enterprise will reduce the possible risks caused by "brain drain". Reducing such risks would in turn enhance the competitiveness of an enterprise. The organizational learning as a process is highly affected by the enterprise size and structure and in SMEs it becomes specific and it needs a non-traditional approach.

In order to understand the problem of organizational learning within SMEs, a field study is made within 18 industrial SMEs in addition to our project partner enterprise Tour

Equipement. The field study took the form of interviews with employees and direct observations of their daily activities. The first remarkable result of this field study is the absence of a knowledge management system within SMEs. Digital tools that support such knowledge management systems are usually used by large enterprises and not by SMEs. When asked about the non use of such tools, all SMEs indicated that these tools come with overloaded functionalities which are not adequate for their needs. Managers of SMEs also indicated that having a specialized tool highly exceeds their budgets.

The field study illustrated that SMEs need to capitalize notes and annotations via a digital tool. Employees of SMEs indicated that notes and annotations take an important part of their knowledge. These notes and annotations reflect the specificity of the enterprise' business. Taking notes and annotations using a paper support (like a post-it)

often results in a knowledge-loss situation. So capitalizing these notes and annotations within SMEs using a digital tool seemed like an essential need. Currently digital tools for taking notes and annotations, in spite of their powerful functionalities, still have limitations in terms of indexing and sharing notes and annotations.

In this work, we took the choice of MEMORAe approach for knowledge capitalization.

MEMORAe approach is composed of a MEMORAe-core 2 semantic model (based on semantic web standards) and MEMORAe web platform for capitalizing knowledge resources within an organization. However, MEMORAe-core 2 model do not take into consideration the specific needs of SMEs. The model was redeveloped using a modular approach in order to easily integrate new modules related to SMEs need. The integration of new modules is done using an integration method also developed as a part of this The project started by doing a DRD (through the interviews, observations) and then passing to testing the results through ERD and so on. The functionalities of taking notes and annotations were also tested during a university course at the UTC.

MEMORAe web application was tested by the students within a university course. The main objective of this test was to get the feedback of the students concerning the utility of note and annotation tool. Students affirmed that modeling of notes and annotations as information resources facilitated knowledge sharing/indexing and retrieval among them.

The students were able to retrieve the ideas of others concerning a particular topic which enhanced the collaborative work. They were also able to consult the annotations in the annotations list as any other resources. These annotations were still linked to their origin targets. So students were able to access the resource by its annotations.

MEMORAe web and mobile applications were tested by our partner Tour Equipement.

The objective was the test of the platform in terms of usability and utility. The Technical Director and the Commercial Director affirmed that the platform would facilitate knowledge circulation within the enterprise. The Commercial Director affirmed that the applications facilitate the preparation of tours at the clients/prospects by consulting old notes/annotations about the clients/prospects to visit. The mobile application, according to the Commercial Director, is so advantageous during the tours. The Commercial

Director could now replace his paper-based note taking with photo notes or audio notes which is easier to take, share and retrieve. The Technical Director said that the applications would help him to retrieve knowledge related to products, invoices, client commands, etc. This retrieval by index helps in organizing the knowledge which is time saving. So the test illustrated that the platform could be usable and useful in SMEs.

In next section, we will present possible enhancements and future work related to this work.

Perspective and Future Work

Perspectives are categorized to fall into one of these two categories:

Short and Mid-Term Work:

The platform was not tested by technicians, engineers who work with machines and with products fabrication. So testing the platform by these users could be considered in the future. In addition, the impact of using this platform on organizational learning within SMEs was not evaluated. In order to do such evaluation, the platform should be used for long term. After the long term use, an evaluation study could be conducted to see the impact of using MEMORAe platform on organizational learning. This study could be based on the four points of organizational learning proposed by [START_REF] Huber | Organizational learning: The contributing processes and the literatures[END_REF]:

• knowledge storage: Does the platform facilitate the storage of knowledge in a consistent memory?

• knowledge sharing: Does the platform facilitate/prompt knowledge sharing within the enterprise?

• knowledge acquisition: The users of the platform could be asked if the platformed helped them to acquire new knowledge?

• knowledge interpretation: The users of the platform could be asked if the platform helped them to understand and interpret knowledge.

Long-Term Work:

There are two possible functions that could be interesting to implement. The first is related to annotation and the second is related to tour.

Multi-Target Annotation

The multi-target annotation is the ability to annotate many parts of the same resource Director to be updated. In this case, one annotation is created, indexed and shared. The "target" of the annotation is multiple: the selected reference and the selected price within the same document (the same resource).

• Multi-Target Annotation of Many Resources: While the Technical Director is verifying a technical description concerning a plan of a particular product. The Technical Director finds an error in the plan. Correcting the error implies correcting all the errors of the invoices of this product. The Technical Director selects the document describing the product, selects all the invoices that contain this product and writes: "The distance between A and B in 2cm and not 3cm". The Technical Director indexes the annotation with the product and clients demanding the product, and shares the annotation with the Commercial Director. In this case, one annotation is created, indexed and shared. The "target" of the annotation is multiple: the document describing the product in addition to all clients' invoices (many resources).

We can also imagine the "target" of the annotation could to be more complex: resources and part of resources at the same time. The design of systems basing on (HF&E) takes proper account of the interaction between them and the people who use them. There is no specification of the system to be designed, so it could be industrial design, information design, etc. This is why HCI domain is concerned. HCI specialize in the design and use of computer technology, focusing particularly on the interfaces between people (users) and computers. HCI researchers observe the ways in which humans interact with computers and design technologies that let humans interact easily and friendly with the computers. The design of Multi-Target annotation interface could largely benefits form (HF&E) and HCI.

Proposing The Tour Itinerary

The proposition of the tour itinerary is an aspect related to geolocation domain. The Commercial Director mentioned that this would facilitate his journey to the clients/prospects.

In order to consider such functionality, MEMORAe-SME model should be evolved to consider the itinerary. Considering the itinerary means considering geographic zones, departments, paths, roads, traffics, latitude and longitude, and other geo spatial aspects.

Many works and models could be considered for the geolocation. [START_REF] Bouhana | An integrated case-based reasoning approach for personalized itinerary search in multimodal transportation systems[END_REF] proposes an ontology-based Case Base Reasoning approach for personalized itinerary search systems. In addition, standards of the semantic web could be imported (as modules) to MEMORAe-SME model. For example, the Geospatial Ontology 1 is a semantic web standard that addresses issues of location and geographical properties. An other semantic model that considers the geolocation is the GeoNames Ontology 2 . In addition to semantic models, there are many existing geographic tools that could be used (e.g. google maps). The best way is to integrate the geolocation service within MEMORAe-web platform. By embedding such service, the commercial would only choose the clients/prospects he wants to visit and then the best itinerary is proposed.

This itinerary could be considered as a resource in MEMORAe-SME. Considering the itinerary as a resource means that it could be indexed and shared. The commercial could index the itinerary by the clients/prospects to visit and shares it in MEMORAe system in order to benefit from it for future visits. (Grundstein, et al., 2003) (Golebiowska, 2002) (Tseng, et al., 2005) Chaque PME met à disposition de son personnel une salle de vie avec dans certaines, un frigidaire, un micro-onde, une cafetière où des échanges informels pourraient être

Chapter 7 :

 7 Conclusion and future work are presented in this chapter.

Chapter 8 :

 8 Publications related to this work are in chapter 8.

  commercial tour Commercial Director List of companies to visit and planned schedule Note-taking while visiting a client Commercial Director Notes taken during or imme-of the Commercial in a Tour to the Clients

Figure 2 . 1 :

 21 Figure 2.1: The binders of the commercial director taken for the tour

  competitive advantage and even survive. McEvily & Chakravarthy (2002) Alavi et al. (2010) confirm that organizational learning plays a notable role in promoting the organization performance and in ensuring the well being of the organization. Before talking about organizational learning, we have to know its relation with individual learning.

  : The FOAF project has started in 2000 to describe persons and their social network in a semantic way. So FOAF ontology contains vocabulary and relations describing persons, their activities, the relation between persons and the relation between persons and documents. The following are examples of the classes and relations that could be found in FOAF to describe:

-

  bibo:authorList ( <http://xmlns.com/foaf/0.1/ala> <http://xmlns.com/foaf/0.1/marie helen> <http://xmlns.com/foaf/0.1/claude>). • OA (Open Annotation) Robert et al. (2013): The work on Open Annotation ontology is conducted by the W3C Open Annotation Community Group 3 . This group is founded by the Annotation Ontology initiative and the Open Annotation Collaboration. The main objective of this group is to define a semantic model for annotating digital resources. In 2013, the first specifications of this model is published under the Open Annotation data model (OA).

  ): VCard are a special format for describing business cards of people and organizations. VCard contains name, address, phone numbers, e-mail addresses, URLs, logos, photographs, etc. The VCard ontology's main objective is to provide an equivalent representation of VCard utilizing the Semantic Web. The VCard ontology is created in 2001. Since then, new vocabularies has appeared (FOAF Brickley & Miller (2010), The Organization Ontology Reynolds (2014)). The FOAF ontology describes people and relations between them. The organization ontology focuses on the organization structure. So there are overlaps between the three ontologies FOAF, the organization ontology and VCard. In spite of these overlaps, these ontologies provide useful information and enhanced modeling when used collaboratively. The VCard class is the main class in the VCard model. This class is equivalent to the new Kind class, which is the parent for the four explicit types of VCards (Individual, Organization, Location, Group). Other classes in VCard include Individual, Name, Address, Telephone.

Figure 3 . 1 :

 31 Figure 3.1: Microsoft One Note 2010

Figure 3 .

 3 Figure 3.2: Annotea architecture

Figure 3 . 3 :

 33 Figure 3.3: annotating a pdf with Adobe Reader

Figure 3 . 4 :

 34 Figure 3.4: Annotating a web page with Diigo

  ers) or versions (MemoNote TabletPC, MemoNote LMCS,. . . ) by the same user, this creates different memories on each device/platform. The user can then ask MemoNote to synchronize these memories content. He/she can synchronize only annotations, or ask also for ontologies or document synchronization. MemoNote annotation model is semantic, personal and cognitive. These three aspects are represented in terms of an object with three main facets where each facet describes one of the three aspects (Fig.3.5)[START_REF] Desmoulins | Memonote, a semantic and personal memory tool based on annotations made on pedagogical documents[END_REF].The semantic facet attributes take their values from a formal representation of knowledge, based on ontologies. Then each facet is divided into sub-facets or attributes, to describe the annotator's annotation in terms of personal, cognitive and semantic attributes. In addition, as the annotation is personal, it is important in the case of annotation transmission from a sender to other addressees to keep the sender's view (self-confidence + importance). To describe this personal view, the annotation model includes then a transmission facet.

Figure 3 . 5 :

 35 Figure 3.5: Three facets model of MemoNote

  [START_REF] Gray | Organizational learning and entrepreneurial strategy[END_REF] divided the organizational learning in SMEs into three dimensions. The first dimension is Personal Cognitive Learning (PCL) which includes all enterprise activities that consider the members as individual learners. It focuses on the knowledge that resides in individuals' minds. Its content mainly comes from what members already know and their past experiences. The second dimension is Social Constructive Learning (SCL). It includes all enterprise activities that consider the members as social individuals. In this case, members share their knowledge in every day communications and interactions with other members of the enterprise. The third dimension is an extension of the second one. It is the Institutional Constructive Learning (ICL). In this dimension, knowledge is developed when enterprise members take part in the construction of something external to themselves or considered "universal" to their enterprise (e.g. formal procedures, organizational charts, support systems, authority structure).

3 .

 3 The PROLOG ((PROgramming in LOGic) axioms are used to implement the semantics in order to enable TOVE to automatically deduce the answer to many commonsense questions about the enterprise.4. It defines a symbology for depicting a term, or the concept constructed thereof, in a graphic context. " TOVE models the enterprise as a set of integrated ontologies. Currently these ontologies are:1. Activity, time, and causality[START_REF] Gruninger | A theory of complex actions for enterprise modelling[END_REF] Gruninger & Fox (1994) 2.Resources Fadel et al. (1994) 3. Cost Tham et al. (1994) 4. Quality[START_REF] Kim | Formal models of quality and iso 9000 compliance[END_REF] 5. Organization structureFox et al. (1995a) 6. Product[START_REF] Lin | A requirement ontology for engineering design[END_REF] 3.6.4.2 Enterprise ModelThe role of the enterprise project as specified inUschold et al. (1998) is to act as a communication medium between:

Figure 3 . 6 :

 36 Figure 3.6: The organization ontology

  model built using owl (Web Ontology Language) and based on semantic web standards(FOAF, SIOC, BIBO). Regarding the typology of ontologies, MEMORAe-core 2 is a core ontology representing the collaboration in organizations. The model focuses on modeling resource sharing and indexing between individuals and groups of individuals within an organization[START_REF] Deparis | Creation of new decisional knowledge for an organization by analysing its social and documentary resources[END_REF]. There are two main aspects in MEMORAe-core 2 model:• Modeling the individuals and groups of individuals: MEMORAe-core 2 views the organization as a set of users belonging to groups. Each group has its own sharing space in which users can share or access resources. All resources are indexed by an index key which is visible to a certain sharing space.• Modeling the resources: resources in MEMORAe-core 2 are defined as "vectors of information". The resources are divided into two main categories: simple and composed. A document, an agent, can be direct examples of simple resources.Composed resources are composed of other resources. Each resource is indexed by an index key which is visible for a certain sharing space. The model supports documentary resources (e.g. documents) and social resources (e.g. chat, forum, wiki).

  Firstly, MEMORAe model is a semantic model based on semantic web standards. Secondly, MEMORAe-core 2 model represents collaboration and information sharing within an organization. But MEMORAe-core 2 model is destined to organizations in general and not specifically to SMEs. So MEMORAe model does not take into consideration the special needs of SMEs. As a consequence, the model and the platform should be adapted to respond to the needs of SMEs as identified in field study. This means that MEMORAe core 2 model should represent collaboration and sharing / indexing of notes and annotations by the members of an SME. The model also should not contain social resources like chat or forums because these types of resources are not used within SMEs because of their small sizes. The idea of removing social resources and adding notes and annotations lead us to rethink the development of MEMORAe-core 2 model. The model was re-designed

  It facilitates the management of the ontology evolution by either adding new modules or by enriching existing modules In addition to these points, Despres (2014), Jarrar (2005) indicate that modularity permits the collaborative construction of an ontology. The team working on the global model could be divided into sub-teams each of which on charge of a module of the model. Fourthly, Ben Abbes et al. (2012) affirms that ontology modularization facilitates knowledge reuse across various applications. Ben Abbes et al. (

  partial semantic import Despres (2014) D'Aquin et al. (2009) Grau et al. (2007), Package-based Description Logics (P-DL) Bao et al. (2007).• Ontology mapping: In order to apply this technique, we could use: Distributed Description Logics (DDL)[START_REF] Borgida | Distributed description logics: Assimilating information from peer sources[END_REF], E-connectionsGrau et al. (2006a).Ontology decomposition could be applied either by analyzing the semantics of OWLDL Grau et al. (2006b) or by traversing the ontology's hierarchy (i.e., the set of axioms) to apply heuristics in order to identify sub-graphs. Examples of methodologies which are based on the ontology's hierarchy could include: GALEN segmentation service[START_REF] Seidenberg | Web ontology segmentation: analysis, classification and use[END_REF], ModTool: A module extraction tool Doran et al. (2007), Modularization via dynamic selection D'Aquin et al. (2006), LexValueSets: Heuristicsbased sub-graph extraction Pathak et al. (2008), Taxonomy-based partitioning of gene ontology Kuśnierczyk (2008).

- mc2foaf :

 mc2foaf Agent rdfs:subClassOf mc2:SimpleResource -mc2foaf:Person rdfs:subClassOf foaf:Person -mc2foaf:Person rdfs:subClassOf mc2foaf:Agent -mc2foaf:Organization rdfs:subClassOf foaf:Organization -mc2foaf:Organization rdfs:subClassOf mc2foaf:Agent -mc2foaf:Group rdfs:subClassOf foaf:Group -mc2foaf:Group rdfs:subClassOf mc2foaf:Agent

-

  kb:tomas a foaf:Person (BY INFERENCE ) -kb:tomas foaf:firstName "Tomas" -kb:tomas foaf:lastName "Lepont" Creating a group agent: -kb:friendsGroup a mc2foaf:Group -kb:friendsGroup a foaf:Group (BY INFERENCE ) -kb:friendsGroup a mc2:SimpleResource (BY INFERENCE ) -kb:friendsGroup a mc2:Resource (BY INFERENCE ) Creating an organization agent: -kb:utc a mc2foaf:Organization -kb:utc a foaf:Organization (BY INFERENCE ) -kb:utc a mc2:SimpleResource (BY INFERENCE ) -kb:utc a mc2:Resource (BY INFERENCE )

Figure 4 . 1 :

 41 Figure 4.1: MEMORAe-core 2 with its modules

-

  kb:enterpriseGroup a sioc:UserGroup (BY INFERENCE ) -kb:enterpriseSpaceOfGroup a mc2sioc:Space -kb:enterpriseSpaceOfGroup a sioc:Space (BY INFERENCE ) Assigning the sharing space to the group: -kb:enterpriseGroup sioc:usergroup of kb:enterpriseSpaceOfGroup -kb:enterpriseSpaceOfGroup sioc:has usergroup b:enterpriseGroup Assigning the user account of Tomas to the enterprise group:

-

  kb:tomasNote a bibo:Note (BY INFERENCE ) -kb:tomasNote a mc2bibo:Document (BY INFERENCE ) -kb:tomasNote a mc2:SimpleResource (BY INFERENCE ) -kb:tomasNote a mc2:Resource (BY INFERENCE ) Creating an image document and assigning it to the content of the note: -kb:boardImage a mc2bibo:Document -kb:boardImage a mc2:SimpleResource (BY INFERENCE ) -kb:boardImage a mc2:Resource (BY INFERENCE ) -kb:tomasNote mc2bibo:has body kb:boardImage Tomas now needs to share and index the note. The image is interesting to be consulted by all the members of the enterprise. So Tomas shares the note in the enterprise group.

-

  kb:tomasAnnotation a oa:Annotation (BY INFERENCE ) -kb:tomasAnnotation a mc2:SimpleResource (BY INFERENCE ) -kb:tomasAnnotation a mc2:Resource (BY INFERENCE ) Creating an image document and assigning it to the content ("body") of the annotation: -kb:filmImage a mc2bibo:Document -kb:filmImage a mc2:SimpleResource (BY INFERENCE ) -kb:filmImage a mc2:Resource (BY INFERENCE ) -kb:tomasAnnotation mc2oa:has body kb:filmImage Creating a technical document and assigning it to the "target" of the annotation: -kb:technicalDocument a mc2bibo:Document -kb:technicalDocument a mc2:SimpleResource (BY INFERENCE ) -kb:technicalDocument a mc2:Resource (BY INFERENCE ) -kb:tomasAnnotation mc2oa:has target kb:technicalDocument

- mc2role :

 mc2role Role rdfs:subClassOf role:Role -mc2role:Role mc2role:has resource mc2:Resource -mc2role:Goal rdfs:subClassOf role:Goal -mc2role:Role mc2role:has goal mc2role:Goal -mc2role:Authority rdfs:subClassOf role:Authority -mc2role:Role mc2role:has authority mc2role:Authority -mc2role:Skill rdfs:subClassOf role:Skill -mc2role:Role mc2role:requires skill mc2role:Skill As mentioned earlier, Tomas is a commercial in the enterprise. So the commercial role is created and assigned to Tomas.

-

  kb:commercialAuthority a role:Authority (BY INFERENCE ) -kb:commercialRole mc2role:has authority kb:commercialAuthority Creating the commercial skill: -kb:commercialSKill a mc2role:Skill -kb:commercialSKill a role:Skill (BY INFERENCE ) -kb:commercialRole mc2role:requires skill kb:kb:commercialSKill Creating the goal of the commercial: -kb:contactClients a mc2role:Goal -kb:contactClients a role:Goal (BY INFERENCE ) -kb:commercialRole mc2role:has goal kb:contactClients Assigning the role to Tomas:

Figure 4 . 2 :

 42 Figure 4.2: Integrating the role module to MEMORAe-SME

Figure 4 . 3 :

 43 Figure 4.3: Integrating the agenda and event module to MEMORAe-SME

- mc2agenda :

 mc2agenda Agenda rdfs:subClassOf agenda:Agenda -mc2agenda:Agenda rdfs:subClassOf mc2:CompositeResource -mc2event:Event mc2event:involved agent mc2foaf:Agent -mc2event:Event mc2event:has resource mc2:Resource -mc2agenda:Agenda mc2agenda:composed of mc2event:Event Tomas has his own agenda. He uses the agenda to organize the appointments with the clients.

Figure 4 . 4 :

 44 Figure 4.4: Integrating the tour module to MEMORAe-SME

-

  kb:clientTour mc2tour:composed of kb:tomasAppointmentAtClientA -kb:clientTour mc2tour:composed of kb:tomasAppointmentAtClientB -kb:clientTour mc2tour:composed of kb:tomasAppointmentAtClientC -kb:clientTour tour:has StartDate "11/08/2015" -kb:clientTour tour:has EndDate "11/08/2015" -kb:clientTour tour:has StratTime "11 AM" -kb:clientTour tour:has Duration "4 hours"

Figure 4 . 5 :

 45 Figure 4.5: Integrating the clients and prospects modules to MEMORAe-SME

- mc2enterprise :

 mc2enterprise LegalEntity rdfs:subClassOf mc2foaf:Agent -mc2foaf:Agent mc2foaf:holds mc2vcard:Vcard -mc2vcard:Vcard rdfs:subClassOf vcard:Vcard -mc2vcard:Address rdfs:subClassOf vcard:Address Thanks to this integration, we can add in the knowledge base (that has kb as a prefix) the following triples: Creating the client instance: -kb:client a mc2enterprise:ClientEnterprise -kb:client mc2enterprise:became client on "12/08/2015" Creating the vCard of the client: -kb:clientVcard a mc2vcard:Vcard -kb:clientVcard vcard:workTel "01 22 33 44 55" -kb:clientAddress a mc2vcard:Address -kb:clientAddress a vcard:Address (BY INFERENCE ) -kb:clientAddress vcard:street-address "19 rue pierre d'ailly" -kb:clientAddress vcard:city "Compiègne" -kb:clientAddress vcard:postal-code "60200" -kb:clientVcard mc2vcard:workAdr kb:clientAddress Assigning the vCard to the client:

- mc2contact :

 mc2contact Contact rdfs:subClassOf contact:Contact -mc2contact:Contact rdfs:subClassOf mc2foaf:Agent -mc2enterprise:Enterprise mc2enterprise:has contact mc2contact:Contact -mc2contact:PersonContact rdfs:subClassOf contact:PersonContact -mc2contact:PersonContact rdfs:subClassOf mc2contact:Contact -mc2contact:GroupContact rdfs:subClassOf contact:GroupContact -mc2contact:GroupContact rdfs:subClassOf mc2contact:Contact -mc2contact:OrganizationContact rdfs:subClassOf contact:OrganizationContact -mc2contact:OrganizationContact rdfs:subClassOf mc2contact:Contact To take an example, Peter Brown is specialized in the chuck product. Mr. Brown works at the company which resides at "19 rue pierre d'ailly" (presented in the previous section). Mr. Brown's enterprise is a client of the enterprise in which Tomas works. Mr.Brown is a privileged contact for Tomas concerning the chuck product and especially the chuck233A. So Tomas creates the contact and indexes him by the chuck233A instance.

-

  kb:contactPerson a mc2contact:Contact (BY INFERENCE ) -kb:contactPerson a mc2foaf:Agent (BY INFERENCE ) -kb:contactPerson a mc2:SimpleResource (BY INFERENCE )

Figure 4 . 6 :

 46 Figure 4.6: Integrating the contact module to MEMORAe-SME

-

  kb:indexKeyForContact mc2:about instance kb:chuck233A -kb:indexKeyForContact mc2:index of kb:contactPerson -kb:indexKeyForContact mc2:is visible for kb:enterpriseSpaceOfGroup Creating the vCard for peter contact: -kb:peterVcard a mc2vcard:Vcard -kb:peterVcard vcard:workTel "01 33 44 55 66" -kb:peterAddress a mc2vcard:Address -kb:peterAddress a vcard:Address (BY INFERENCE ) -kb:peterAddress vcard:street-address "19 rue pierre d'ailly" -kb:peterAddress vcard:city "Compiègne" -kb:peterAddress vcard:postal-code "60200" -kb:peterVcard mc2vcard:workAdr kb:clientAddress

- mc2mr :

 mc2mr MaterialResource rdfs:subClassOf mc2:SimpleResource -mc2mr:ConsumedResource rdfs:subClassOf mr:ConsumedResource -mc2mr:ConsumedResource rdfs:subClassOf mc2mr:MaterialResource -mc2mr:ManufacturingResource rdfs:subClassOf mr:ManufacturingResource -mc2mr:ManufacturingResource rdfs:subClassOf mc2mr:MaterialResource -mc2mr:BuySellProduct rdfs:subClassOf mr:BuySellProduct -mc2mr:BuySellProduct rdfs:subClassOf mc2mr:MaterialResource -mc2mr:ProducedResource rdfs:subClassOf mr:ProducedResource -mc2mr:ProducedResource rdfs:subClassOf mc2mr:MaterialResource

Figure 4 . 7 :

 47 Figure 4.7: Integrating the material resource module to MEMORAe-SME

- mc2activity :

 mc2activity Activity rdfs:subClassOf mc2:SimpleResource -mc2activity:Activity mc2activity:has subActivity mc2activity:Activity -mc2activity:BuyActivity rdfs:subClassOf activity:BuyActivity -mc2activity:BuyActivity rdfs:subClassOf mc2activity:Activity -mc2activity:SellActivity rdfs:subClassOf activity:SellActivity -mc2activity:SellActivity rdfs:subClassOf mc2activity:Activity -mc2activity:ManufacturingActivity rdfs:subClassOf activity:ManufacturingActivity

Figure 4 . 8 :

 48 Figure 4.8: Integrating the activity module to MEMORAe-SME

Figure 4 . 9 :

 49 Figure 4.9: Relations between activity and material resource modules

Figure

  Figure 4.10: A chuck

Figure 4 .

 4 Figure 4.12: A chuck

  using web 2.0 technologies. MEMORAe web platform is based on MEMORAe-SME model. The platform aims to facilitate knowledge sharing and capitalization within SMEs (Fig. 5.1). MEMORAe web platform supports sharing the resources modeled in MEMORAe-SME model (section 4.3) (documents, notes, annotations, agenda, tours, contacts) (Fig. 5.2). All these resources are indexed by the concepts of an ontology that represents either the application ontology of an organization (e.g. the application ontology for mechanical SMEs presented in chapter 5), or another semantic reference based on the knowledge base (e.g. clients, prospects). This ontology is presented as a semantic map which is present in the middle of the web page. The semantic map defines a common reference shared between all users. The user can navigate through the map to view the shared resources in the sharing spaces to which he/she has access. When the user is on a concept, this concept becomes the focus concept. When the user is on a focus concept, he/she could open a sharing space to see different resources indexed by this focus concept and shared in this sharing space. He could open the sharing spaces on parallel while navigating through the map. This parallel view is advantageous because the user can see the resources indexed by the same focus concept and shared in different sharing spaces.

Figure 5 . 1 :

 51 Figure 5.1: Main interface of MEMORAe web application

Figure 5 . 3 :

 53 Figure 5.3: Taking note (phase one): entering the note content

Figure 5 . 5 :

 55 Figure 5.5: Annotations using pdfJS viewer

Figure 5 . 6 :

 56 Figure 5.6: The document to be annotated

Figure 5 . 7 :

 57 Figure 5.7: Taking annotation (phase one): entering the annotation content

Figure 5 . 10 :

 510 Figure 5.10: Entering the annotation title, type, index, sharing space and tag

Figure 5 . 11 :

 511 Figure 5.11: The annotation presented within its target

Figure 5 . 15 :

 515 Figure 5.15: Taking an appointment

Figure 5 . 17 :

 517 Figure 5.17: Creating a new tour

Figure 5 . 21 :

 521 Figure 5.21: Adding a contact using the organization members list

  organize tours.The (Fig. 5.22) shows the interface of the mobile application for adding a new note. By default, the content of the note is a textual. But the user could change the content to sound, image or video. After choosing and adding the content of the note, the user indexes the note locally on his device. In order to index, the user first choses if the index is a client, a prospect or a product (Fig.5.23). When the user chooses by what he/she would index the note, a list of indexes is shown in order to choose one or more indexes coming from the chosen knowledge map (Fig.5.24) (Fig.5.25). When the

Figure 5 .

 5 Figure 5.22: Adding a note using MEMORAe mobile application

Figure 5 . 23 :

 523 Figure 5.23: Choosing if the index is a client, prospect or a product

Figure 5 . 27 :

 527 Figure 5.27: Choosing the sharing space

  test took place at the department of computer engineering at the University of Technology of Compiègne. The main objective of the test was to test the platform and to see the interest of the annotation and the note taking tool by students. The interest of testing the platform by the students is that they are habituated to use ICT and they could give interesting feedback about MEMORAe platform by comparing it to what they actually use. The students were following a course in "The Techniques of Modeling, Capitalization, and Knowledge management". This course aims to analyze the problem of knowledge capitalization. It also performs a study of the methods and technologies of processing information that could be mobilized. The test lasted three months (October to December 2014). The students had to perform a "technology watch"

  Experimental Research Design: (ERD) Unlike a descriptive study, an experiment is a study in which a treatment, procedure, or program is intentionally introduced and a result or outcome is observed. The American Heritage Dictionary of the English Language defines an experiment as a test under controlled conditions that is made to examine the validity of a hypothesis. The protocol of the experiment of MEMORAe web and mobile applications is mainly based on the experimental research design. The DRD and ERD are the "backbone" of this research project. The application of DRD and ERD was circular and sequential. The project started by doing a DRD (through the interviews, observations) and then passing to testing the results through ERD. After the application of an ERD, a DRD was applied taken into consideration the the results of the experiment. The following is a concrete description of the application of DRD and ERD during CESACO project: 1. DRD 1: The study illustrated that SMEs need for digitizing and capitalizing nonformal knowledge represented by notes and annotations (First and second interview sessions presented in field study Chapter 2). 2. ERD 1: This includes: (1) Modeling notes and annotations in MEMORAe-core 2 model (section 4.2.3). (2) Adding the functionality of taking notes and annotation to MEMORAe web platform and presenting it to Tour Equipement enterprise. 3. DRD 2: The study identified the practices of notes and annotations in details (Third interview sessions presented in field study Chapter 2). The study illustrated that notes and annotations could have different types of contents (text, image, video and any type of resource) and that annotations should have targets. These notes and annotations are regularly taken concerning a material resource or an activity. 4. ERD 2: This includes: (1) modifying note and annotation models to take into consideration the "body" and the "target" (section 4.2.3). (2) Modeling the material resource and the activities (4.3.6 and 4.3.7 sections). (3) Modifying the functionalists of taking notes and annotations to include contents of different resource types. (4) Developing a mobile application of taking notes and annotations.

5. DRD 3 :

 3 This study took the form of observation during the tour of the commercial to the clients/prospects enterprises. The study illustrated the importance of integrating tour organization into the web and mobile applications. Tours were identified as a sequence of appointments. The commercial took the notes about the clients and prospects enterprise that he visited. This show that notes and annotations could be indexed by clients and prospects.6. ERD 3: This includes:(1) Modeling the role, the event, the tour, the clients and prospects and the contact into MEMORAe-core 2 model(4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.2.5 sections). (2) Adding the functionalists of organizing tours and indexing resources by clients and prospects to MEMORAe web and mobile applications.

  employees of the Tour Equipement enterprise have appreciated MEMORAe-web and mobile applications. The Commercial Director has affirmed that the application would help in organizing his tours around the clients and the prospects. The Commercial Director has also indicated that the mobile application of MEMORAe would replace his paper-based notes especially with the functionality of taking audio notes by the mobile application. The Technical Director indicated that the platform would facilitate the access of knowledge related to products (e.g. plans) fabricated within the enterprise.The Technical Director mentioned that with the platform he would be able to take notes/annotations related to clients' commands and invoices estimation. The Technical Director said that he would consult the notes taken by the Commercial Director after the tours in order to be up to date about what happened during the appointments with the clients and the prospects. When the Commercial Director wants to organize the tours, Chapter 6. Experimental Evaluation 123 he said that he would consult his old notes/annotations about the clients/prospects to visit in addition to the notes/annotations taken by the Technical Director. According

(

  or even many resources) with the same annotation content ("body"). The annotation model that we presented confirms with multi-target annotation. The followings are examples of possible scenarios: • Multi-Target Annotation of Many parts in the Same Resource: While the Commercial Director is verifying an invoice estimation of the client's command, he finds an error of the product reference. Changing the reference would change the price of the command. The Commercial Director selects the reference and the price and adds the following annotation for the two selections: "The product reference is wrong, the correct one is Ref53654. This changes the price from 55 euros to 70 euros". The Commercial Director indexes the annotation by the correct product and the demanding client and then shares the annotation with a the Technical

  For example, in the previous scenario the Technical Director may not choose the describing document as a whole. He might only choose the part of the document where the error resides, in addition to other invoices. The challenge in Multi-Target annotation is not in the model, because the presented annotation model conforms with Multi-Target annotation. The challenge resides in the interface design that should enable adding a Multi-Target annotation. The interfaces should enable a flexible and easy way to add the annotation. The user should be able to keep a visual track of the selected targets whether they are in the same resource or in different resources. This guides us to take into consideration two research domains: Human factors and ergonomics (HF&E) and Human-computer interaction (HCI). In Human factors and ergonomics we look for comfort design and user-friendly systems.

  précisent que le processus de détermination des connaissances cruciales est une action difficile à mener. L'objectif des entretiens a été de comprendre comment les entreprises connaissent les connaissances présentes en leur sein avec un questionnement sur le repérage et l'identification de leurs compétences clefs, le fondement de ce qu'ils pensent être leur avantage compétitif et leur savoir-faire secret . En dehors d'une des entreprises qui est certifiée ISO et qui a donc en place un processus de repérage des compétences clefs, aucune des personnes interrogées n'a pu clairement les énoncer si ce n'est en citant les métiers exercés dans l'entreprise : mes compétences clefs, à vrai dire je ne sais pas vraiment. Nous, on fait de la construction mécanique sur plans, de la machine spéciale et un petit peu d'usinage rapide. C'est ce qu'on sait faire annonce un des interlocuteurs. Je peux vous dire ce qu'on fait ou ce qu'on a fait , explique un autre dirigeant de PME. En fait quand le client vient et qu'il a besoin d'une pièce on s'adapte. Si c'est du standard on la lui fournit, si c'est du spécifique on la conçoit et lui développe. Des fois on fait aussi la machine. C'est un prototype, une machine unique. C'est ça qu'on sait faire . Lors des échanges avec les uns et les autres, il est assez clairement apparu que nos interlocuteurs ne savaient pas en détail quelles connaissances spécifiques sont mobilisées dans l'activité de leur entreprise et tous assurent ne pas détenir de savoir-faire secrets. A partir du moment où on a tous le même type d'employés, y a pas de raison qu'on sache faire autre chose que les autres. Ils ont tous suivi le même cursus. C'est l'expérience qui fera la différence. Alors notre avantage compétitif il vient plus de notre disponibilité et réactivité que d'un savoir-faire particulier nous confie un directeur technique. Nos clients connaissent notre histoire. Ils viennent avec une demande qu'on est à même de faire parce qu'on l'a déjà faite. Notre avantage compétitif vient surtout par le fait que nos clients ils nous demandent que des choses qu'on a déjà faites et qu'il faut adapter, renforcer. On part quasi jamais de rien et c'est pour ça qu'ils viennent chez nous. . . on a déjà fourni la preuve qu'on sait faire assure un autre dirigeant. C ¸a se passe par ricochées, c'est parce qu'on a fourni une pièce difficile à un client, qu'un autre client vient nous solliciter. Notre différenciation, c'est bien de savoir faire la pièce complexe. Plus c'est tordu, plus c'est pour nous. . . , énonce avec fierté notre interlocuteur.Notre PME partenaire du projet peut par contre plus facilement identifier son avantage compétitif car elle est dans un secteur de niche avec peu de concurrents directs et dit se différencier par la fourniture possible de toute la gamme avec un service logistique très rapide : on a une réponse à tous les équipements qui sont en exploitation dans l'industrie aujourd'hui, même pour les plus anciens. Cette capacité à une réponse très large dans des délais rapides est vraiment notre point fort car les usines elles attendent nos pièces pour produire. Et on n'est pas pléthore sur ce marché à faire ce type de produits explique notre partenaire.On peut ainsi dire qu'au regard des entreprises rencontrées les compétences clefs finalement assez peu repérées se résument essentiellement en la capacité à répondre vite à des demandes diversifiées et à un niveau de technicité élevé, sans que rien ne vienne véritablement les différencier.A.1.2 Préserver les ConnaissancesC'est-à-dire les acquérir auprès des détenteurs de connaissances, les modéliser, les formaliser et les conserver. A cette étape nous avons cherché à vérifier comment les entreprises tentent de préserver les connaissances/savoir-faire et avec quels outils. Nous les avons interrogées sur la question de la codification, tant sur le point technique de codification que sur les objets à codifier. Les connaissances tacites et non codifiables ont été abordées comme point d'interrogation de la préservation des connaissances. Enfin l'aspect communication interne pour un partage des données formalisées a été appréhendé pour mieux cerner le partage ou non des connaissances et préparer la facette de la valorisation. Toutes les entreprises rencontrées existent depuis plusieurs décennies même si les dirigeants ont changé et les structures évolué. A les entendre, les interlocuteurs semblent tous savoir exactement ce que font les uns et les autres. Ils assurent qu'ils gardent en mémoire les expériences, les réussites par un système d'archivage classique. Tous organisent cet archivage par année, par client et par date avec pour trois d'entre eux le nom des personnes qui y ont travaillé inscrit sur le dossier. L'entreprise classée ISO recense de façon plus précise les étapes et les responsabilités engagées dans chaque processus. Mais à chaque fois, l'entrée est commerciale et non technique. C'est en fait un archivage organisé selon l'obligation légale et fiscale. Tous sont désormais équipés de logiciels d'archivages mais entretiennent également un archivage papier des dossiers. Certains profitent de périodes plus calmes de l'activité pour les ranger faute de place pour tous les garder. D'autres avouent les stocker plus ou moins en vrac pour le cas où ils auraient un contrôle. Cet archivage formel organisé autour de la commande rassemble les éléments basiques et communs à tous comme le devis, le cahier des charges, le bon de commande, la fiche de coût et quelquefois quelques schémas mais jamais de données très spécifiques, d'accords verbaux, de traces d'astuces développés pour la commande archivée, de notes prises sur un point spécifique qu'il soit technique ou organisationnel. Les documents conservés sont des documents standards. Nous, on garde tout, les dossiers de A à Z. D'abord parce que pour les machines spéciales, par exemple, je dois garder le dossier au moins pendant la période de garantie et de maintenance, c'est obligatoire pour le client , explique un des interlocuteurs. Et puis qui sait ? C ¸a pourra peut-être me resservir pour une autre fois, si on me commande une machine qui ressemble ? , poursuit-il. L'archivage des données dans ces PME est pour la plupart double avec d'une part un logiciel souvent développé en interne et d'autre part un archivage papier plus archaïque mais plus complet car regroupant quasiment tout ce qui a été fait et écrit sur l'affaire. Le plus gros problème vient essentiellement de la difficulté à retrouver ces informations. On peut trouver ça bizarre pour une si petite boite d'avoir développé notre logiciel nous-mêmes mais sur le marché, c'était toujours trop lourd avec plein de fonctions qui me disaient rein. Alors un jour j'ai profité d'un ingénieur informaticien chez mon soustraitant automaticien pour lui faire créer mon logiciel. C ¸a nous a pris plus d'un an mais c'est comme je le voulais. C'est classé au départ par date et client mais en dessous tout est trié par ensemble techniques et sous-ensembles techniques. . . ., nous raconte un dirigeant et il ajoute toutefois : Mais heureusement que quand même j'ai une bonne mémoire car quand on lance une recherche, comme on travaille avec le même jargon quelque soit la commande, presque toutes ressortent à chaque fois car archivées avec les mêmes mots-clefs. . . finalement c'est moi qui dit où il faut chercher parce que je me souviens de tel ou tel détail, de ce que j'avais noté sur un bout de papier pendant la visite de l'atelier ou en sortant d'un rendez-vous client sur un post-it . Un autre dirigeant confirme la nécessité de ces logiciels d'archivage pour garder des traces mais minimise leur capacité à retrouver les informations car toutes les affaires répondent quasiment aux mêmes mots-clefs : Des fois c'est quelqu'un qui dit dans l'équipe, ça ressemble pas au projet d'il y a deux ans chez Monsieur X ? . . . ensuite c'est bien le logiciel qui retrouve tous les éléments mais il a bien fallu lui donner un os à ronger pour que la recherche soit efficace . En fait nos interlocuteurs reconnaissent que c'est souvent sur des petits trucs que la différence se fait d'une commande à l'autre et que c'est par ces petits trucs qu'ils s'en souviennent : malheureusement ces petits trucs on les archive pas, surtout s'ils sont trouvés sur le tas, dans l'atelier et pas dans la phase de dessins car là eux ils peuvent être archivés si on a gribouillé dessus explique un responsable technique. C'est sûr, ça nous aiderait des fois de tout garder mais dans des petites boites comme la nôtre, il faut produire et livrer vite et tout archiver c'est un sacré temps à passer, on l'a pas ! regrette un des dirigeants, et puis des fois on pense qu'on fait une production juste pour une fois, on n'imagine pas qu'on devra refaire presque la même deux ans après. . . c'est parfois inattendu et on sait pas l'anticiper . Enfin la transmission d'expériences, de connaissances acquises lors de commandes antérieures reste pour tous essentiellement assurée par l'échange oral avec les anciens, par la mémoire souvent assez exceptionnelle (même si cloisonnée) de quelques acteurs clefs dans l'entreprise. Dans chaque entreprise rencontrée avec plus ou moins d'intensité, l'un d'entre eux est la mémoire de l'entreprise : Quand on sait plus un truc on va voir un tel, lui, il se souvient toujours , raconte un responsable de production. Avant de commencer un devis ou un plan je vais toujours le voir il sait toujours si on a déjà fait quelque chose de rapprochant ou si le client a des exigences spécifiques qu'il a pas dites . D'une manière générale les PME/TPE sont équipées de logiciels orientés affaires qui ne permettent pas d'archiver les spécificités techniques pourtant sources de la plus-value de l'offre ou levier de l'amélioration de la réactivité et de la rentabilité. Les données archivées le sont dans des dossiers codifiés communs à toute entreprise en réponse à la législation mais ne permettent pas facilement de retrouver les historiques pertinents pour capitaliser sur des expériences. Chacun reconnait que la traçabilité tant commerciale acteur incontournable pour ne pas être isolé mais aussi pour accéder à des informations de type législative. De même alors que chaque entreprise a un logiciel de suivi de dossiers, voire une véritable GPAO (Gestion de Production Assistée par Ordinateur) les accès aux données sont particulièrement contrôlés par des codes d'accès et des mots de passe. Les dirigeants insistent sur la nécessité de garantir la confidentialité pour les clients et d'aucuns rajoutent ne pas vouloir que leurs ouvriers aient accès aux données commerciales et donc aux prix appliqués dans les différentes affaires : chacun son métier et la boite tournera , conclut un des dirigeants, Si certains connaissaient les prix de vente ils ne comprendraient pas qu'ils soient peu payés, ils n'ont pas vraiment conscience des charges . . . Il est souvent difficile d'exploiter l'ensemble des connaissances rassemblées dans l'entreprise car elles ne sont pas forcément faciles à associer. Les acteurs savent que plusieurs données vont ensemble mais n'ont pas nécessairement la capacité à les regrouper. Les quelques logiciels mentionnés semblent ne pas répondre à la nécessité de croiser, regrouper et confronter l'ensemble des informations. Moi je rentre des données sur les clients et lui il rentre des données sur une machine mais en fait le logiciel comme il est commercial il ne prend pas en compte les données machine et du coup on doit faire manuellement le rapprochement et encore seulement quand on les a ressaisies , regrette le directeur commercial. Enfin ces PME font régulièrement appel à des intérimaires faute de ne pouvoir embaucher et proposer une activité suffisante pour tous toute l'année. Par souci d'efficacité ces intérimaires sont accueillis par des anciens et doivent se reporter dans certaines PME à des fiches de poste plus ou moins détaillées. Tous reconnaissent que ces fiches de poste datent un peu (sauf chez notre partenaire où l'arrivée d'un nouveau dirigeant a permis de lancer ces démarches de formalisation) et qu'elles ne sont pas mises à jour avec les dernières astuces ou que les détails sur l'affaire ne sont pas donnés aux intérimaires qui restent essentiellement des exécutants affectés à une tâche en particulier sous le regard des anciens. L'appel assez régulier pour ces PME à des intérimaires qui eux-mêmes tournent dans plusieurs entreprises pourrait permettre d'introduire de nouvelles façons de faire ou de s'organiser. Les dirigeants reconnaissent néanmoins que cette source est pauvre car les compétences des intérimaires à occuper les postes ne sont pas remises en cause mais leur capacité à analyser pour ensuite exploiter est très faible : Dans un sens c'est rassurant car si les intérimaires nous racontaient ce qu'ils vivent chez les autres quelquefois concurrents, ça voudrait dire qu'ils racontent ce qu'ils voient chez nous . Nous avons cherché à savoir quels liens l'entreprise entretient pour accéder aux connaissances, comme l'accès à des réseaux, l'intégration dans des communautés. Les PME accumulent au fil du temps un certain nombre de données et d'informations sur ses clients et ses fournisseurs. Le monde change rapidement et du coup il faut sans cesse les réactualiser et alors il semble que les entreprises rencontrent des difficultés à cette mise à jour. Quand on veut en savoir plus ou se mettre à jour sur une entreprise c'est un véritable parcours du combattant, il y a des infos partout mais elles sont rarement à jour. Même les supports officiels comme le Kompass ou les pages jaunes sont décalés, regrette un interlocuteur. Quand j'ai besoin d'obtenir une information plus précise afin de proposer la pièce la plus adaptée, c'est dans un jeu de pistes qu'on se lance, on trouve une référence sur une machine qui nous rattache à un code qui nous renvoie à un dossier et finalement c'est une personne qui a la réponse parce qu'elle se souvient. En général, heureusement qu'il y a toujours un ancien, ça fait gagner bien du temps et c'est pas les logiciels de gestion qui nous aident, ils ont plein d'infos dans les logiciels mais jamais celles qui nous faut poursuit un autre dirigeant. De l'extérieur les PME recueillent peu de nouvelles données essentiellement par faute de temps. En effet les quelques salons spécialisés dans leur activité ne leur permettent pas d'y exposer car ils sont beaucoup trop chers et chronophages. Ils s'y rendent en visiteurs et y rencontrent alors des concurrents, des fournisseurs et certains clients. Même si trop rares, c'est néanmoins une source valorisante de recherche d'informations, de prises de contacts, de relances de contacts et même une forme de rewarding pour ceux qui y vont. Dans les entreprises rencontrées peu de dirigeants ont intégré un réseau du secteur d'activité. En effet ces anciennes PME travaillent refermées sur elles-mêmes, s'autorisent certaines visites de salon mais ne s'inscrivent pas en membre actif d'un réseau. Le nouveau dirigeant de la PME partenaire du projet est membre du Centre des Jeunes Dirigeants (CJD) et accède à ce titre à des informations plus générales sur la gestion de l'entreprise et peut lors de rencontres formelles échanger sur des sujets transversaux. Ce n'est a priori pas la tendance majoritaire des PME en mécanique, aux dires des autres dirigeants. A.1.5 Manager les Connaissances C'est-à-dire manager des activités et des processus permettant d'amplifier la création et l'utilisation des connaissances dans l'entreprise, en répondant aux questions suivantes : comment repérer, préserver, valoriser et actualiser les connaissances cruciales de l'entreprise selon le point de vue managérial. Cette facette est traitée en général par les chercheurs en sciences de gestion. Nous pouvons citer les travaux de (Baumard, 1996) (Davenport, et al., 1998) (Dudezert, 2007) (Lorino, 2000). D'autres gestionnaires s'intéressent plus particulièrement à la problématique de gestion des connaissances dans les industries et de capitalisation des connaissances inter-projets : les travaux de (Le Masson, 2001) (Moisdon, et al., 2000) sont des exemples. Cette facette aborde davantage la stratégie de l'entreprise et la gestion des personnes sous l'aspect développement des connaissances. Nous avons alors interrogé les entreprises sur la fonction de Knowledge Management et sa prise en charge ciblée sur une personne ou diffuse dans l'entreprise. Nous nous sommes intéressés aux espaces de vie collective, au travail comme dans les salles de réunion ou en pause comme autour de la machine à café. Nous les avons questionnées sur les occasions informelles d'échanges mais aussi sur l'anticipation ou non de l'absence d'une personne clef. Nous n'avons observé aucun poste spécifique dans les PME pour traiter de la veille. Cela dépend essentiellement du dirigeant de la PME et de un ou deux de ses collaborateurs s'ils ont cette fibre là. Même si le sujet est abordé lors des entretiens sa mise en oeuvre est complètement abandonnée aux éventuelles opportunités de rencontres (lors d'un rdv client ou chez un sous-traitant ou lors de la visite d'un salon) sans que ce soit planifié. Le retour des ces informations obtenues est le plus souvent oral sans formalisation aucune. Quant aux réunions, en plénière avec tout le personnel elles n'existent pas sauf lorsque l'entreprise rencontre des difficultés telles qu'il est nécessaire de rassurer et d'encourager pour que l'activité se poursuive. Dans un courant d'affaires continu, peu de réunions sont organisées au mieux des rencontres ad hoc sur un sujet sont improvisées sur un coin de table : pourquoi faire des réunions, chez nous c'est petit quand je parle haut et fort tout le monde l'entend. Je passe dans les ateliers tous les jours, ça me remonte des infos et après à deux ou trois on voit ce que l'on en fait . Néanmoins aux dires des dirigeants interrogés sur ce sujet, ils reconnaissent qu'ils gagneraient à rassembler davantage les équipes pour créer une émulation, rassurer quand nécessaire et déconcentrer les informations auprès d'un tout petit nombre. Mais la nécessité de produite vite pour assurer la rentabilité de l'entreprise ne favorise pas ces envolées.

  Acrobat. Although users can't create PDFs in Reader, they can use Reader to view, print, and manage PDFs. After opening a PDF in Reader, users have various tools to help you find information quickly. If they receive a PDF form, they can complete it online and submit it electronically. If they receive an invitation to review a PDF, it is possible to use the commenting and markup tools to annotate it. Reader multimedia tools can be used to play video and music in a PDF. And if a PDF contains sensitive information, it can be signed or certified with a digital ID. Users who open PDFs with Adobe Reader cannot edit the file. Reader allows users to fill out forms in PDFs, but they can't change any existing text or formatting. This makes PDF files a poor choice for saving rough drafts of documents or for working collaboratively with others 9 .

  According to The European Commission (EC), an enterprise is considered mediumsized if it has less than 250 salaried, and small-sized if it has less than 50 salaried. In addition, there are two other criteria to choose from: either the annual turnover must not exceed 50 million Euros or the total balance sheet must not exceed 43 million Euros (Commission Recommendation of 6 May 2003).

Washington, D.C.-based consulting group specializing in business intelligence, data warehousing and knowledge management.

CESACO in French stands for: Capitalisation d'ExpertiseS et Apprentissage en Contexte Organisationnel

inventor of the World Wide Web and director of the World Wide Web Consortium (W3C)

https://www.w3.org/community/openannotation/

http://www-03.ibm.com/software/products/en/ibmnotes

http://simplenote.com/

http://www.programhouse.com/pal/

http://www.w3.org/2001/Annotea/

http://www.w3.org/2001/Annotea/Papers/www10/annotea-www10.html

https://helpx.adobe.com/reader.html

https://www.diigo.com/

https://www.diigo.com/learn_more/research

http://motools.sourceforge.net/event/event.html

http://linkedevents.org/ontology/

C'est-à-dire les rendre accessibles selon certaines règles de confidentialité et de sécurité, les diffuser à des fins pédagogiques et d'apprentissage au besoin, les exploiter dans un but de formation des pairs vers les apprentis, les combiner et créer de nouvelles connaissances. Les sciences et technologies de l'information et de la communication (STIC) s'intéressent à l'amélioration de l'échange des informations et des connaissances entre des personnes situées au sein d'une entreprise ou bien entre des personnes localisées dans des entreprises différentes. Nous pouvons citer comme exemple le développement des systèmes basés sur le web sémantique, les serveurs terminologiques, les techniques de traçabilité de communication (e-mail, forum de discussion, blog, etc.), les communautés de pratique(Wenger, et al., 2002).Dans ce cadre la question lors des entretiens a été de voir en quoi les connaissances sont mises en avant dans l'entreprise, comment on y accède qui y accède et par quels moyens. Très vite l'ensemble des entretiens montrent que dans une PME l'accès aux connaissances, qu'elles soient archivées par le biais des dossiers clients ou qu'elles parviennent de l'extérieur à travers essentiellement des magasines professionnels, spécialisés, est réservé à un très petit nombre de personnes qui gravitent autour de la direction. Les acteurs des ateliers ne sont pas impliqués ou très rarement à des échanges construits autour de tendances ou d'offres nouvelles. Ils sont le plus souvent laissés à la production seule.On est quelques-uns à accéder aux fiches, en fait, on est deux quand j'y pense, le commercial et moi. Lui, il en a besoin avant ses visites chez le client et moi pour concevoir l'offre. Trois entreprises annoncent être abonnées à des magasines professionnels afin de se tenir informées des nouveautés techniques et tendances des marchés. Les dirigeants expriment le regret que leurs équipes ne s'intéressent pas plus au secteur d'activité qui les concerne : les journaux quand je les ai lus je les laisse à l'accueil sur la petite table devant la machine à café mais j'ai pas l'impression qu'ils les lisent vraiment, alors quand j'ai lu une information intéressante, quand je passe dans l'atelier j'en parle et comme je passe tous les jours, ça tourne pas mal . Le syndicat professionnel de l'Union des Industries Mécaniques et métallurgiques (UIMM) est cité dans chaque entreprise comme un

Acknowledgements

que technique d'une affaire avec toutes les aspérités qui la démarquent des autres affaires repose en grande partie sur un ou deux anciens, dont la mémoire est le véritable capital reconnu de l'entreprise.

A.1.3 Valoriser les Connaissances

wholeheartedly thank my supervisor Mme Marie-Hélène Abel for the aca-I would also thank the funders of this work which is co-funded by the Picardie region and the European Union. Europe is engaged in Picardie with the FEDER (Fond européen de développment régional). I am grateful to my lovely wife Maha for her support during my three years work in PH.D.

<rdf:RDF xmlns="http://www.hds.utc.fr/mc2/sme/tbox#" xml:base="http://www.hds.utc.fr/mc2/sme/tbox" xmlns:ns="http://www.w3.org/2003/06/sw-vocab-status/ns#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:terms="http://purl.org/dc/terms/" xmlns:bibo="http://purl.org/ontology/bibo/" xmlns:event="http://purl.org/NET/c4dm/event.owl#" xmlns:wot="http://xmlns.com/wot/0.1/" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sioc="http://rdfs.org/sioc/ns#"> <owl:

Ontology rdf:about="http://www.hds.utc.fr/mc2/sme/tbox"> <dc:modified rdf:datatype="&xsd;dateTime">2013-02-22T21:40:51+01:00</dc:modified> <dc:title xml:lang="en">SIOC Core Ontology Namespace</dc:title> <dc:description>The Friend of a Friend (FOAF) RDF vocabulary, described using W3C RDF Schema and the Web Ontology Language.</dc:description> <owl:versionInfo>Revision: 1.35</owl:versionInfo> <owl:versionInfo>0.9.20130208</owl:versionInfo> <owl:versionInfo>http://purl.org/ontology/bibo/1.3/</owl:versionInfo> <dc:title>Friend of a Friend (FOAF) vocabulary</dc:title> <dc:title>The Bibliographic Ontology</dc:title> <dc:title xml:lang="en">Open Annotation Data Model</dc:title> <dc:creator xml:lang="en">Robert Sanderson</dc:creator> <dc:description xml:lang="en">SIOC (Semantically-Interlinked Online Communities) is an ontology for describing the information in online communities. This information can be used to export information from online communities and to link them together. The scope of the application areas that SIOC can be used for includes (and is not limited to) weblogs, message boards, mailing lists and chat channels.</dc:description> <dc:contributor xml:lang="en">Stian Soiland-Reyes</dc:contributor> <dc:description xml:lang="en">The Bibliographic Ontology describes bibliographic things on the semantic Web in RDF. This ontology can be used as a citation ontology, as a document classification ontology, or simply as a way to describe any kind of document in RDF. It has been inspired by many existing document description metadata formats, and can be used as a common ground for converting other bibliographic data sources.</dc:description> <rdfs:comment xml:lang="en">The Open Annotation Core Data Model specifies an interoperable framework for creating associations between related resources, annotations, using a methodology that conforms to the Architecture of the World Wide Web. This ontology is a non-normative OWL formalization of the textual OA specification at http://www.openannotation.org/spec/core/20130208/index.html Note that OWL imports are disabled in the published version in order to reduce external implications, improve OWL 2 Profile conformity and increase interoperability. Some OWL tools might thus misleadingly show this ontology as (re)defining properties like skos:prefLabel.</rdfs:comment> <dc:description xml:lang="en">The Open Annotation Core Data Model specifies an interoperable framework for creating associations between related resources, annotations, using a methodology that conforms to the Architecture of the World Wide Web. Open Annotations can easily be shared between platforms, with sufficient richness of expression to satisfy complex requirements while remaining simple enough to also allow for the most common use cases, such as attaching a piece of text to a single web resource.

An Annotation is considered to be a set of connected resources, typically including a body and target, where the body is somehow about the target. The full model supports additional functionality, enabling semantic annotations, embedding content, selecting segments of resources, choosing the appropriate representation of a resource and providing styling hints for consuming clients.</dc:description> <dc:creator xml:lang="it">Paolo Ciccarese</dc:creator> <dc:creator xml:lang="vls">Herbert Van de Sompel</dc:creator> <owl:imports rdf:resource="http://purl.org/ontology/bibo/"/> <rdfs:seeAlso rdf:resource="http://rdfs.org/sioc/spec"/> <owl:imports rdf:resource="http://rdfs.org/sioc/ns#"/> <rdfs:seeAlso rdf:resource="http://www.openannotation.org/spec/core/20130208/index.html"/> <owl:imports rdf:resource="http://www.openannotation.org/spec/core/20130208/oa.owl"/> <owl:imports rdf:resource="http://xmlns.com/foaf/0.1/"/> </owl:Ontology> <!--/////////////////////////////////////////////////////////////////////////////////////// // // Annotation properties // /////////////////////////////////////////////////////////////////////////////////////// --> <!--http://purl.org/dc/terms/creator --> <owl:AnnotationProperty rdf:about="&terms;creator"/> <!--http://purl.org/dc/terms/date --> <owl:AnnotationProperty rdf:about="&terms;date"/> <!--http://purl.org/dc/terms/description --> <owl:AnnotationProperty rdf:about="&terms;description"/> <!--http://purl.org/dc/terms/identifier --> <owl:AnnotationProperty rdf:about="&terms;identifier"/> <!--http://purl.org/dc/terms/title --> <owl:AnnotationProperty rdf:about="&terms;title"/> <!--http://www.w3.org/2002/07/owl#deprecated --> <owl:AnnotationProperty rdf:about="&owl;deprecated"/> <!--http://www.w3.org/2003/06/sw-vocab-status/ns#term_status --> <owl:AnnotationProperty rdf:about="&ns;term_status"/> <!--http://www.w3.org/2004/02/skos/core#changeNote --> <owl:AnnotationProperty rdf:about="&skos;changeNote"/> <!--http://www.w3.org/2004/02/skos/core#editorialNote --> <owl:AnnotationProperty rdf:about="&skos;editorialNote"/> <!--http://www.w3.org/2004/02/skos/core#example --> <owl:AnnotationProperty rdf:about="&skos;example"/> <!--http://www.w3.org/2004/02/skos/core#historyNote --> <owl:AnnotationProperty rdf:about="&skos;historyNote"/> <!--http://www.w3.org/2004/02/skos/core#note --> <owl:AnnotationProperty rdf:about="&skos;note"/> <!--http://www.w3.org/2004/02/skos/core#scopeNote --> <owl:AnnotationProperty rdf:about="&skos;scopeNote"/> <!--http://xmlns.com/foaf/0.1/membershipClass --> <owl:AnnotationProperty rdf:about="&foaf;membershipClass"> <rdfs:label>membershipClass</rdfs:label> <rdfs:comment>Indicates the class of individuals that are a member of a Group</rdfs:comment> <ns:term_status>unstable</ns:term_status> <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/"/> </owl:AnnotationProperty> <!--http://xmlns.com/foaf/0.1/name --> <owl:AnnotationProperty rdf:about="&foaf;name"> <rdfs:subPropertyOf rdf:resource="&rdfs;label"/> <rdfs:domain rdf:resource="&owl;Thing"/> </owl:AnnotationProperty> <!--http://xmlns.com/wot/0.1/assurance --> <owl:AnnotationProperty rdf:about="&wot;assurance"/> <!--http://xmlns.com/wot/0.1/src_assurance --> <owl:AnnotationProperty rdf:about="&wot;src_assurance"/> <!--/////////////////////////////////////////////////////////////////////////////////////// // // Object Properties // /////////////////////////////////////////////////////////////////////////////////////// --> <!--http://rdfs.org/sioc/ns#account_of --> <owl:ObjectProperty rdf:about="&sioc;account_of"> <rdfs:label xml:lang="en">account of</rdfs:label> <rdfs:comment xml:lang="en">Refers to the foaf:Agent or foaf:Person who owns this sioc:UserAccount.</rdfs:comment> <rdfs:domain rdf:resource="&sioc;UserAccount"/> <rdfs:range rdf:resource="&foaf;Agent"/> <owl:inverseOf rdf:resource="&foaf;account"/> </owl:ObjectProperty> <!--http://rdfs.org/sioc/ns#has_administrator --> <owl:ObjectProperty rdf:about="&sioc;has_administrator"> <rdfs:label xml:lang="en">has administrator</rdfs:label> <rdfs:comment xml:lang="en">A UserAccount that is an administrator of this Site.</rdfs:comment> <rdfs:domain rdf:resource="&sioc;Site"/> <rdfs:range rdf:resource="&sioc;UserAccount"/> </owl:ObjectProperty> <!--http://rdfs.org/sioc/ns#has_creator --> <owl:ObjectProperty rdf:about="&sioc;has_creator"> <rdfs:label xml:lang="en">has creator</rdfs:label> <rdfs:comment xml:lang="en">This is the UserAccount that made this resource.</rdfs:comment> <rdfs:range rdf:resource="&sioc;UserAccount"/> </owl:ObjectProperty> <!--http://rdfs.org/sioc/ns#has_member --> <owl:ObjectProperty rdf:about="&sioc;has_member"> <rdfs:label xml:lang="en">has member</rdfs:label> <rdfs:comment xml:lang="en">A UserAccount that is a member of this Usergroup.</rdfs:comment> <rdfs:range rdf:resource="&sioc;UserAccount"/> <rdfs:domain rdf:resource="&sioc;Usergroup"/> </owl:ObjectProperty> <!--http://rdfs.org/sioc/ns#has_usergroup --> <owl:ObjectProperty rdf:about="&sioc;has_usergroup"> <rdfs:label xml:lang="en">has usergroup</rdfs:label> <rdfs:comment xml:lang="en">Points to a Usergroup that has certain access to this Space.</rdfs:comment> <rdfs:domain rdf:resource="&sioc;Space"/> <rdfs:range rdf:resource="&sioc;Usergroup"/> </owl:ObjectProperty> <!--http://rdfs.org/sioc/ns#member_of --> <owl:ObjectProperty rdf:about="&sioc;member_of"> <rdfs:label xml:lang="en">member of</rdfs:label> <rdfs:comment xml:lang="en">A Usergroup that this UserAccount is a member of.</rdfs:comment> <rdfs:domain rdf:resource="&sioc;UserAccount"/> <rdfs:range rdf:resource="&sioc;Usergroup"/> <owl:inverseOf rdf:resource="&sioc;has_member"/> </owl:ObjectProperty> <!--http://rdfs.org/sioc/ns#space_of --> <owl:ObjectProperty rdf:about="&sioc;space_of"> <rdfs:label xml:lang="en">space of</rdfs:label> <rdfs:comment xml:lang="en">A resource which belongs to this data Space.</rdfs:comment> <rdfs:domain rdf:resource="&sioc;Space"/> </owl:ObjectProperty> <!--http://rdfs.org/sioc/ns#usergroup_of --> <owl:ObjectProperty rdf:about="&sioc;usergroup_of"> <rdfs:label xml:lang="en">usergroup of</rdfs:label> <rdfs:comment xml:lang="en">A Space that the Usergroup has access to.</rdfs:comment> <rdfs:range rdf:resource="&sioc;Space"/> <rdfs:domain rdf:resource="&sioc;Usergroup"/> <owl:inverseOf rdf:resource="&sioc;has_usergroup"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#about_class --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#about_class"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#IndexKey"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#bought_by --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#bought_by"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#BuySellResource"/> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2activity/sme/tbox#BuyActivity"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2mr/sme/tbox#ConsumedResource"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2mr/sme/tbox#ManufacturingResource"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#composed_of --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#composed_of"> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2activity/sme/tbox#Activity"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2activity/sme/tbox#Activity"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#consumed_by --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#consumed_by"> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2activity/sme/tbox#ManufacturingActivity"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2mr/sme/tbox#ConsumedResource"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#containes --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#containes"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#CompositeResource"/> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#Resource"/> </owl:ObjectProperty>

<!--http://www.hds.utc.fr/mc2/sme/tbox#hasBody --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#hasBody"> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#Resource"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2oa/sme/tbox#Annotation"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#hasTarget --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#hasTarget"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2oa/sme/tbox#Annotation"/> <rdfs:range rdf:resource="&owl;Thing"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#index --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#index"> <rdfs:label>index</rdfs:label> <dc:description xml:lang="fr">Permet de définir un lien entre une certaine clé d'indexation et une ressource</dc:description> <owl:inverseOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#indexed_by"/> <rdfs:range> <owl:Restriction> <owl:onProperty rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#index"/> <owl:someValuesFrom rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#Resource"/> </owl:Restriction> </rdfs:range> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#indexed_by --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#indexed_by"> <rdfs:label xml:lang="en">indexed by</rdfs:label> <rdfs:label xml:lang="fr">indéxé par</rdfs:label> <dc:description xml:lang="fr">Permet de lier une ressource à une certaine clé d'indexation</dc:description> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#IndexKey"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#Resource"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#involved_agent --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#involved_agent"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2event/sme/tbox#Event"/> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2foaf/sme/tbox#Agent"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#involved_by --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#involved_by"> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2activity/sme/tbox#ManufacturingActivity"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2mr/sme/tbox#ManufacturingResource"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#is_visible_for --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#is_visible_for"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#IndexKey"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#produced_by --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#produced_by"> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2activity/sme/tbox#ManufacturingActivity"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2mr/sme/tbox#ProducedResource"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#require --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#require"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2activity/sme/tbox#Activity"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#share --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#share"> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#Resource"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2soic/sme/tbox#User"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#sold_by --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#sold_by"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#BuySellResource"/> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2activity/sme/tbox#SellActivity"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2mr/sme/tbox#BuySellProduct"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2mr/sme/tbox#ProducedResource"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2role/sme/tbox#has_authority --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2role/sme/tbox#has_authority"> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2role/sme/tbox#Authority"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2role/sme/tbox#Role"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2role/sme/tbox#has_goal --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2role/sme/tbox#has_goal"> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2roal/sme/tbox#Goal"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2role/sme/tbox#Role"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2role/sme/tbox#has_resource --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2role/sme/tbox#has_resource"> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#Resource"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2event/sme/tbox#Event"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2role/sme/tbox#Role"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2role/sme/tbox#requires_skill --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2role/sme/tbox#requires_skill"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2role/sme/tbox#Role"/> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2role/sme/tbox#Skill"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/mc2vcard/sme/tbox#workAdr --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/mc2vcard/sme/tbox#workAdr"> <rdfs:range rdf:resource="http://www.hds.utc.fr/mc2vcard/sme/tbox#Address"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/mc2vcard/sme/tbox#Vcard"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/tour/sme/tbox#composed_OfEvents --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/tour/sme/tbox#composed_OfEvents"> <rdfs:range rdf:resource="http://www.hds.utc.fr/event/sme/tbox#Event"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/tour/sme/tbox#Tour"/> </owl:ObjectProperty> <!--http://www.hds.utc.fr/vcard/sme/tbox#workAdr --> <owl:ObjectProperty rdf:about="http://www.hds.utc.fr/vcard/sme/tbox#workAdr"> <rdfs:range rdf:resource="http://www.hds.utc.fr/vcard/sme/tbox#Address"/> <rdfs:domain rdf:resource="http://www.hds.utc.fr/vcard/sme/tbox#Vcard"/> </owl:ObjectProperty> <!--http://www.w3.org/ns/oa#hasBody --> <owl:ObjectProperty rdf:about="http://www.w3.org/ns/oa#hasBody"> <rdfs:label xml:lang="en">hasBody</rdfs:label> <rdfs:comment xml:lang="en">The relationship between oa:Annotation and body. The body is somehow "about" the oa:hasTarget of the annotation.

The Body may be of any media type, and contain any type of content. The Body SHOULD be identified by HTTP URIs unless they are embedded within the Annotation.

Embedded bodies SHOULD be instances of cnt:ContentAsText and embed their content with cnt:chars. They SHOULD declare their media type with dc:format, and MAY indicate their language using dc:language and a RFC-3066 language tag.

There is no OA class provided for "Body" as a body might be a target of a different annotation. However, there SHOULD be 1 or more content-based classes associated with the body resources of an Annotation, and the dctypes: vocabulary is recommended for this purpose, for instance dctypes:Text to declare textual content. </rdfs:comment> <rdfs:isDefinedBy rdf:resource="http://www.w3.org/ns/oa#"/> <rdfs:domain rdf:resource="http://www.w3.org/ns/oa#Annotation"/> </owl:ObjectProperty> <!--http://www.w3.org/ns/oa#hasTarget --> <owl:ObjectProperty rdf:about="http://www.w3.org/ns/oa#hasTarget"> <rdfs:label xml:lang="en">hasTarget</rdfs:label> <rdfs:comment xml:lang="en">The relationship between oa:Annotation and target. The target resource is what the oa:hasBody is somewhat "about". The target may be of any media type, and contain any type of content. The target SHOULD be identified by HTTP URIs unless they are embedded within the Annotation.

Embedded targets SHOULD be instances of cnt:ContentAsText and embed their content with cnt:chars. They SHOULD declare their media type with dc:format, and MAY indicate their language using dc:language and a RFC-3066 language tag.

There is no OA class provided for "Target" as a target might be a body in a different annotation. However, there SHOULD be 1 or more content-based classes associated with the target resources of an Annotation, and the dctypes: vocabulary is recommended for this purpose, for instance dctypes:Text to declare textual content.</rdfs:comment> <rdfs:isDefinedBy rdf:resource="http://www.w3.org/ns/oa#"/> <rdfs:domain rdf:resource="http://www.w3.org/ns/oa#Annotation"/> </owl:ObjectProperty> <!--http://xmlns.com/foaf/0.1/account --> <owl:ObjectProperty rdf:about="&foaf;account"> <rdfs:label>account</rdfs:label> <ns:term_status>testing</ns:term_status> <rdfs:comment>Indicates an account held by this agent.</rdfs:comment> <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/"/> <rdfs:range rdf:resource="&foaf;OnlineAccount"/> </owl:ObjectProperty> <!--/////////////////////////////////////////////////////////////////////////////////////// // // Data properties // /////////////////////////////////////////////////////////////////////////////////////// --> <!--http://rdfs.org/sioc/ns#first_name --> <owl:DatatypeProperty rdf:about="&sioc;first_name"> <rdfs:label xml:lang="en">first name</rdfs:label> <owl:deprecated rdf:datatype="&xsd;boolean">true</owl:deprecated> <rdfs:comment xml:lang="en">First (real) name of this User. Synonyms include given name or christian name.</rdfs:comment> <owl:versionInfo>This property is deprecated. Use foaf:name or foaf:firstName from the FOAF vocabulary instead.</owl:versionInfo> <rdfs:domain rdf:resource="&sioc;UserAccount"/> <rdfs:range rdf:resource="&rdfs;Literal"/> </owl:DatatypeProperty> <!--http://rdfs.org/sioc/ns#last_name --> <owl:DatatypeProperty rdf:about="&sioc;last_name"> <rdfs:label xml:lang="en">last name</rdfs:label> <owl:deprecated rdf:datatype="&xsd;boolean">true</owl:deprecated> <owl:versionInfo>This property is deprecated. Use foaf:name or foaf:surname from the FOAF vocabulary instead.</owl:versionInfo> <rdfs:comment xml:lang="en">Last (real) name of this user. Synonyms include surname or family name.</rdfs:comment> <rdfs:domain rdf:resource="&sioc;UserAccount"/> <rdfs:range rdf:resource="&rdfs;Literal"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/contact/sme/tbox#contactfirstName --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/contact/sme/tbox#contactfirstName"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/contact/sme/tbox#Contact"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/contact/sme/tbox#gendre --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/contact/sme/tbox#gendre"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/contact/sme/tbox#Contact"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/event/event/tbox#has_StartTime --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/event/event/tbox#has_StartTime"/> <!--http://www.hds.utc.fr/event/sme/tbox#has_Address --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/event/sme/tbox#has_Address"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/event/sme/tbox#Event"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/event/sme/tbox#has_Duration --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/event/sme/tbox#has_Duration"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/event/sme/tbox#Event"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/event/sme/tbox#has_EndDate --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/event/sme/tbox#has_EndDate"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/event/sme/tbox#Event"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/event/sme/tbox#has_Place --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/event/sme/tbox#has_Place"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/event/sme/tbox#Event"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/event/sme/tbox#has_StartDate --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/event/sme/tbox#has_StartDate"/> <!--http://www.hds.utc.fr/mc2/sme/tbox#has_Email --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#has_Email"> <rdfs:range rdf:resource="&rdfs;Literal"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#has_Login --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#has_Login"> <rdfs:range rdf:resource="&rdfs;Literal"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#has_Office --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#has_Office"> <rdfs:range rdf:resource="&rdfs;Literal"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#has_Page --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#has_Page"> <rdfs:range rdf:resource="&rdfs;Literal"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#has_Password --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#has_Password"> <rdfs:range rdf:resource="&rdfs;Literal"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#has_PhoneNumber --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#has_PhoneNumber"> <rdfs:range rdf:resource="&rdfs;Literal"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#has_subjet --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#has_subjet"> <rdfs:range rdf:resource="&rdfs;Literal"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/mc2/sme/tbox#postal-code --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#postal-code"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/vcard/sme/tbox#Address"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/tour/sme/tbox#has_Duration --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/tour/sme/tbox#has_Duration"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/tour/sme/tbox#Tour"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/tour/sme/tbox#has_EndDate --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/tour/sme/tbox#has_EndDate"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/tour/sme/tbox#Tour"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/tour/sme/tbox#has_StartDate --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/tour/sme/tbox#has_StartDate"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/tour/sme/tbox#Tour"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/tour/sme/tbox#has_StartTime --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/tour/sme/tbox#has_StartTime"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/tour/sme/tbox#Tour"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/vcard/sme/tbox#city --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/vcard/sme/tbox#city"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/vcard/sme/tbox#Address"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/vcard/sme/tbox#street-address --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/vcard/sme/tbox#street-address"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/vcard/sme/tbox#Address"/> </owl:DatatypeProperty> <!--http://www.hds.utc.fr/vcard/sme/tbox#workTel --> <owl:DatatypeProperty rdf:about="http://www.hds.utc.fr/vcard/sme/tbox#workTel"> <rdfs:domain rdf:resource="http://www.hds.utc.fr/vcard/sme/tbox#Vcard"/> </owl:DatatypeProperty> <!--http://xmlns.com/foaf/0.1/familyName --> <owl:DatatypeProperty rdf:about="&foaf;familyName"> <rdfs:label>familyName</rdfs:label> <rdfs:comment>The family name of some person.</rdfs:comment> <ns:term_status>testing</ns:term_status> <rdfs:range rdf:resource="&rdfs;Literal"/> <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/"/> </owl:DatatypeProperty> <!--http://xmlns.com/foaf/0.1/family_name --> <owl:DatatypeProperty rdf:about="&foaf;family_name"> <rdfs:label>family_name</rdfs:label> <rdfs:comment>The family name of some person.</rdfs:comment> <ns:term_status>archaic</ns:term_status> <skos:scopeNote xml:lang="en">This is the property we choose to use to describe the family name of a person related to a bibliographic resource.</skos:scopeNote> <rdfs:range rdf:resource="&rdfs;Literal"/> <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/"/> </owl:DatatypeProperty> <!--http://xmlns.com/foaf/0.1/firstName --> <owl:DatatypeProperty rdf:about="&foaf;firstName"> <rdfs:label>firstName</rdfs:label> <ns:term_status>testing</ns:term_status> <rdfs:comment>The first name of a person.</rdfs:comment> <rdfs:range rdf:resource="&rdfs;Literal"/> <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/"/> </owl:DatatypeProperty> <!--http://xmlns.com/foaf/0.1/gender --> <owl:DatatypeProperty rdf:about="&foaf;gender"> <rdf:type rdf:resource="&owl;FunctionalProperty"/> <rdfs:label>gender</rdfs:label> <ns:term_status>testing</ns:term_status> <rdfs:comment>The gender of this Agent (typically but not necessarily 'male' or 'female').</rdfs:comment> <rdfs:range rdf:resource="&rdfs;Literal"/> <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/"/> </owl:DatatypeProperty> <!--http://xmlns.com/foaf/0.1/givenName --> <owl:DatatypeProperty rdf:about="&foaf;givenName"> <rdfs:label>Given name</rdfs:label> <rdfs:comment>The given name of some person.</rdfs:comment> <ns:term_status>testing</ns:term_status> <rdfs:range rdf:resource="&rdfs;Literal"/> <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/"/> </owl:DatatypeProperty> <!--http://xmlns.com/foaf/0.1/givenname --> <owl:DatatypeProperty rdf:about="&foaf;givenname"> <rdfs:label>Given name</rdfs:label> <ns:term_status>archaic</ns:term_status> <rdfs:comment>The given name of some person.</rdfs:comment> <skos:scopeNote xml:lang="en">This is the property we choose to describe the given name of a Person related to a bibliographic resource. This is the first name of a person.</skos:scopeNote> <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/"/> </owl:DatatypeProperty> <!--http://xmlns.com/foaf/0.1/lastName --> <owl:DatatypeProperty rdf:about="&foaf;lastName"> <rdfs:label>lastName</rdfs:label> <rdfs:comment>The last name of a person.</rdfs:comment> <ns:term_status>testing</ns:term_status> <rdfs:range rdf:resource="&rdfs;Literal"/> <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/"/> </owl:DatatypeProperty> <!--/////////////////////////////////////////////////////////////////////////////////////// // // Classes // /////////////////////////////////////////////////////////////////////////////////////// -->

<!--http://purl.org/dc/terms/Agent --> <owl:Class rdf:about="&terms;Agent"> <owl:equivalentClass rdf:resource="&foaf;Agent"/> <skos:editorialNote xml:lang="en">BIBO assert that a dcterms:Agent is an equivalent class to foaf:Agent. This means that all the individuals belonging to the foaf:Agent class also belongs to the dcterms:Agent class. This way, dcterms:contributor can be used on foaf:Person, foaf:Organization, foaf:Agent and foaf:Group. Even if this link is not done in neither the FOAF nor the DCTERMS ontologies this is a wide spread fact that is asserted by BIBO.</skos:editorialNote> </owl:Class> <!--http://purl.org/ontology/bibo/Document --> <owl:Class rdf:about="&bibo;Document"> <rdfs:label xml:lang="en">Document</rdfs:label> <owl:equivalentClass rdf:resource="&foaf;Document"/> <rdfs:isDefinedBy rdf:datatype="&xsd;anyURI">http://purl.org/ontology/bibo/</rdfs:isDefinedBy> <rdfs:comment xml:lang="en">A document (noun) is a bounded physical representation of body of information designed with the capacity (and usually intent) to communicate. A document may manifest symbolic, diagrammatic or sensory-representational information.</rdfs:comment> <ns:term_status>stable</ns:term_status> </owl:Class> <!--http://purl.org/ontology/bibo/Note --> <owl:Class rdf:about="&bibo;Note"> <rdfs:label xml:lang="en">Note</rdfs:label> <rdfs:subClassOf rdf:resource="&bibo;Document"/> <rdfs:isDefinedBy rdf:datatype="&xsd;anyURI">http://purl.org/ontology/bibo/</rdfs:isDefinedBy> <ns:term_status>stable</ns:term_status> <rdfs:comment xml:lang="en">Notes or annotations about a resource.</rdfs:comment> </owl:Class> <!--http://rdfs.org/sioc/ns#Site --> <owl:Class rdf:about="&sioc;Site"> <rdfs:label xml:lang="en">Site</rdfs:label> <rdfs:subClassOf rdf:resource="&sioc;Space"/> <rdfs:comment xml:lang="en">A Site can be the location of an online community or set of communities, with UserAccounts and Usergroups creating Items in a set of Containers. It can be thought of as a web-accessible data Space.</rdfs:comment> </owl:Class> <!--http://rdfs.org/sioc/ns#Space --> <owl:Class rdf:about="&sioc;Space"> <rdfs:label xml:lang="en">Space</rdfs:label> <owl:disjointWith rdf:resource="&sioc;User"/> <owl:disjointWith rdf:resource="&sioc;UserAccount"/> <owl:disjointWith rdf:resource="&sioc;Usergroup"/> <rdfs:comment xml:lang="en">A Space is a place where data resides, e.g. on a website, desktop, fileshare, etc.</rdfs:comment> </owl:Class> <!--http://rdfs.org/sioc/ns#User --> <owl:Class rdf:about="&sioc;User"> <rdfs:label xml:lang="en">User</rdfs:label> <owl:equivalentClass rdf:resource="&sioc;UserAccount"/> <rdfs:subClassOf rdf:resource="&foaf;OnlineAccount"/> <owl:disjointWith rdf:resource="&sioc;Usergroup"/> <owl:deprecated rdf:datatype="&xsd;boolean">true</owl:deprecated> <owl:versionInfo>This class is deprecated. Use sioc:UserAccount from the SIOC ontology instead.</owl:versionInfo> <rdfs:comment xml:lang="en">UserAccount is now preferred. This is a deprecated class for a User in an online community site.</rdfs:comment> </owl:Class> <!--http://rdfs.org/sioc/ns#UserAccount --> <owl:Class rdf:about="&sioc;UserAccount"> <rdfs:label xml:lang="en">User Account</rdfs:label> <rdfs:subClassOf rdf:resource="&foaf;OnlineAccount"/> <owl:disjointWith rdf:resource="&sioc;Usergroup"/> <rdfs:comment xml:lang="en">A user account in an online community site.</rdfs:comment> </owl:Class> <!--http://rdfs.org/sioc/ns#Usergroup --> <owl:Class rdf:about="&sioc;Usergroup"> <rdfs:label xml:lang="en">Usergroup</rdfs:label> <rdfs:comment xml:lang="en">A set of UserAccounts whose owners have a common purpose or interest. Can be used for access control purposes.</rdfs:comment> </owl:Class> <!--http://www.hds.utc.fr/activity/tbox#Activity --> <owl:Class rdf:about="http://www.hds.utc.fr/activity/tbox#Activity"/> <!--http://www.hds.utc.fr/activity/tbox#BuyActivity --> <owl:Class rdf:about="http://www.hds.utc.fr/activity/tbox#BuyActivity"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/activity/tbox#Activity"/> </owl:Class> <!--http://www.hds.utc.fr/activity/tbox#ManufacturingActivity --> <owl:Class rdf:about="http://www.hds.utc.fr/activity/tbox#ManufacturingActivity"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/activity/tbox#Activity"/> </owl:Class> <!--http://www.hds.utc.fr/activity/tbox#SellActivity --> <owl:Class rdf:about="http://www.hds.utc.fr/activity/tbox#SellActivity"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/activity/tbox#Activity"/> </owl:Class> <!--http://www.hds.utc.fr/agenda/sme/tbox#Agenda --> <owl:Class rdf:about="http://www.hds.utc.fr/agenda/sme/tbox#Agenda"/> <!--http://www.hds.utc.fr/contact/sme/tbox#Contact --> <owl:Class rdf:about="http://www.hds.utc.fr/contact/sme/tbox#Contact"/> <!--http://www.hds.utc.fr/contact/sme/tbox#GroupContact --> <owl:Class rdf:about="http://www.hds.utc.fr/contact/sme/tbox#GroupContact"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/contact/sme/tbox#Contact"/> </owl:Class> <!--http://www.hds.utc.fr/contact/sme/tbox#OrganizationContact --> <owl:Class rdf:about="http://www.hds.utc.fr/contact/sme/tbox#OrganizationContact"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/contact/sme/tbox#Contact"/> </owl:Class> <!--http://www.hds.utc.fr/contact/sme/tbox#PersonContact --> <owl:Class rdf:about="http://www.hds.utc.fr/contact/sme/tbox#PersonContact"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/contact/sme/tbox#Contact"/> </owl:Class> <!--http://www.hds.utc.fr/enterprise/sme/tbox#Corporation --> <owl:Class rdf:about="http://www.hds.utc.fr/enterprise/sme/tbox#Corporation"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/enterprise/sme/tbox#Legal-Entity"/> </owl:Class> <!--http://www.hds.utc.fr/enterprise/sme/tbox#Legal-Entity --> <owl:Class rdf:about="http://www.hds.utc.fr/enterprise/sme/tbox#Legal-Entity"/> <!--http://www.hds.utc.fr/enterprise/sme/tbox#Partnership --> <owl:Class rdf:about="http://www.hds.utc.fr/enterprise/sme/tbox#Partnership"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/enterprise/sme/tbox#Legal-Entity"/> </owl:Class> <!--http://www.hds.utc.fr/enterprise/sme/tbox#Person --> <owl:Class rdf:about="http://www.hds.utc.fr/enterprise/sme/tbox#Person"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/enterprise/sme/tbox#Legal-Entity"/> </owl:Class> <!--http://www.hds.utc.fr/event/sme/tbox#Event --> <owl:Class rdf:about="http://www.hds.utc.fr/event/sme/tbox#Event"/> <!--http://www.hds.utc.fr/mc2/sme/tbox#BuySellResource --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#BuySellResource"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#SimpleResource"/> <dc:description xml:lang="en">Products which are bought by the enterprise to be sold for profit purpose.</dc:description> </owl:Class> <!--http://www.hds.utc.fr/mc2/sme/tbox#Chat --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#Chat"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#CompositeResource"/> </owl:Class> <!--http://www.hds.utc.fr/mc2/sme/tbox#CompositeResource --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#CompositeResource"> <rdfs:label xml:lang="en">Composite Resource</rdfs:label> <rdfs:label xml:lang="fr">Ressource composée</rdfs:label> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#Resource"/> <dc:description xml:lang="fr">Une ressource composée peut être vide ou composée d'une ou plusieurs ressources.</dc:description> </owl:Class> <!--http://www.hds.utc.fr/mc2/sme/tbox#Forum --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#Forum"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#CompositeResource"/> </owl:Class> <!--http://www.hds.utc.fr/mc2/sme/tbox#IndexKey --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#IndexKey"/> <!--http://www.hds.utc.fr/mc2/sme/tbox#NoteCluster --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#NoteCluster"> <rdfs:label xml:lang="en">Note Cluster</rdfs:label> <rdfs:label xml:lang="fr">Groupement de notes</rdfs:label> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#CompositeResource"/> <dc:description xml:lang="en">A Note Cluster could be empty or composed by one or more other Note Clusters and/or Notes</dc:description> <dc:description xml:lang="fr">Un cluster de notes peut être vide ou composé d'un ou plusieurs clusters de notes et/ou d'une ou plusieurs notes</dc:description> </owl:Class> <!--http://www.hds.utc.fr/mc2/sme/tbox#Resource --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#Resource"> <rdfs:label xml:lang="en">Resource</rdfs:label> <rdfs:label xml:lang="fr">Ressource</rdfs:label> <dc:description xml:lang="fr">Une ressource est un vecteur d'informations</dc:description> </owl:Class> <!--http://www.hds.utc.fr/mc2/sme/tbox#SimpleResource --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#SimpleResource"> <rdfs:label xml:lang="en">Simple Resource</rdfs:label> <rdfs:label xml:lang="fr">Ressource unitaire</rdfs:label> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#Resource"/> </owl:Class> <!--http://www.hds.utc.fr/mc2/sme/tbox#Space --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#Space"> <rdfs:subClassOf rdf:resource="&sioc;Space"/> </owl:Class> <!--http://www.hds.utc.fr/mc2/sme/tbox#WikiPage --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#WikiPage"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2bibo/sme/tbox#Document"/> </owl:Class> <!--http://www.hds.utc.fr/mc2/sme/tbox#wiki --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2/sme/tbox#wiki"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#CompositeResource"/> </owl:Class> <!--http://www.hds.utc.fr/mc2activity/sme/tbox#Activity --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2activity/sme/tbox#Activity"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/activity/tbox#Activity"/> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#SimpleResource"/> </owl:Class> <!--http://www.hds.utc.fr/mc2activity/sme/tbox#BuyActivity --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2activity/sme/tbox#BuyActivity"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/activity/tbox#BuyActivity"/> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2activity/sme/tbox#Activity"/> </owl:Class> <!--http://www.hds.utc.fr/mc2activity/sme/tbox#ManufacturingActivity --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2activity/sme/tbox#ManufacturingActivity"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/activity/tbox#ManufacturingActivity"/> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2activity/sme/tbox#Activity"/> </owl:Class> <!--http://www.hds.utc.fr/mc2activity/sme/tbox#SellActivity --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2activity/sme/tbox#SellActivity"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/activity/tbox#SellActivity"/> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2activity/sme/tbox#Activity"/> </owl:Class> <!--http://www.hds.utc.fr/mc2agenda/sme/tbox#Agenda --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2agenda/sme/tbox#Agenda"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/agenda/sme/tbox#Agenda"/> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#CompositeResource"/> </owl:Class> <!--http://www.hds.utc.fr/mc2bibo/sme/tbox#Document --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2bibo/sme/tbox#Document"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#SimpleResource"/> </owl:Class> <!--http://www.hds.utc.fr/mc2bibo/sme/tbox#Note --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2bibo/sme/tbox#Note"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2bibo/sme/tbox#Document"/> </owl:Class> <!--http://www.hds.utc.fr/mc2contact/sme/tbox#Contact --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2contact/sme/tbox#Contact"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/contact/sme/tbox#Contact"/> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2foaf/sme/tbox#Agent"/> </owl:Class> <!--http://www.hds.utc.fr/mc2contact/sme/tbox#GroupContact --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2contact/sme/tbox#GroupContact"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/contact/sme/tbox#GroupContact"/> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2contact/sme/tbox#Contact"/> </owl:Class> <!--http://www.hds.utc.fr/mc2contact/sme/tbox#OrganizationContact --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2contact/sme/tbox#OrganizationContact"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/contact/sme/tbox#OrganizationContact"/> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2contact/sme/tbox#Contact"/> </owl:Class> <!--http://www.hds.utc.fr/mc2contact/sme/tbox#PersonContact -->

<owl:Class rdf:about="http://www.hds.utc.fr/mc2contact/sme/tbox#PersonContact"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/contact/sme/tbox#PersonContact"/> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2contact/sme/tbox#Contact"/> </owl:Class> <!--http://www.hds.utc.fr/mc2enterprise/sme/tbox#ClientEnterprise --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2enterprise/sme/tbox#ClientEnterprise"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2enterprise/sme/tbox#Enterprise"/> </owl:Class> <!--http://www.hds.utc.fr/mc2enterprise/sme/tbox#Enterprise --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2enterprise/sme/tbox#Enterprise"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2enterprise/sme/tbox#PrivateLegalEntity"/> </owl:Class> <!--http://www.hds.utc.fr/mc2enterprise/sme/tbox#LegalEntity --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2enterprise/sme/tbox#LegalEntity"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/enterprise/sme/tbox#Legal-Entity"/> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2foaf/sme/tbox#Agent"/> </owl:Class> <!--http://www.hds.utc.fr/mc2enterprise/sme/tbox#PrivateLegalEntity --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2enterprise/sme/tbox#PrivateLegalEntity"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2enterprise/sme/tbox#LegalEntity"/> </owl:Class> <!--http://www.hds.utc.fr/mc2enterprise/sme/tbox#ProspetEnterprise --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2enterprise/sme/tbox#ProspetEnterprise"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2enterprise/sme/tbox#Enterprise"/> </owl:Class> <!--http://www.hds.utc.fr/mc2enterprise/sme/tbox#PublicLegalEntity --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2enterprise/sme/tbox#PublicLegalEntity"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2enterprise/sme/tbox#LegalEntity"/> </owl:Class> <!--http://www.hds.utc.fr/mc2event/sme/tbox#Event --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2event/sme/tbox#Event"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/event/sme/tbox#Event"/> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#SimpleResource"/> </owl:Class> <!--http://www.hds.utc.fr/mc2foaf/sme/tbox#Agent --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2foaf/sme/tbox#Agent"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2/sme/tbox#SimpleResource"/> <rdfs:subClassOf rdf:resource="&foaf;Agent"/> </owl:Class> <!--http://www.hds.utc.fr/mc2foaf/sme/tbox#Group --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2foaf/sme/tbox#Group"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2foaf/sme/tbox#Agent"/> <rdfs:subClassOf rdf:resource="&foaf;Group"/> </owl:Class> <!--http://www.hds.utc.fr/mc2foaf/sme/tbox#Organization --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2foaf/sme/tbox#Organization"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2foaf/sme/tbox#Agent"/> <rdfs:subClassOf rdf:resource="&foaf;Organization"/> </owl:Class> <!--http://www.hds.utc.fr/mc2foaf/sme/tbox#Person --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2foaf/sme/tbox#Person"> <rdfs:subClassOf rdf:resource="http://www.hds.utc.fr/mc2foaf/sme/tbox#Agent"/> <rdfs:subClassOf rdf:resource="&foaf;Person"/> </owl:Class> <!--http://www.hds.utc.fr/mc2mr/sme/tbox#BuySellProduct --> <owl:Class rdf:about="http://www.hds.utc.fr/mc2mr/sme/tbox#BuySellProduct">

• 73 % of students have appreciated the organization of knowledge resources (including notes and annotations) around a semantic map. This indexation by the concepts of a semantic map facilitated the retrieval of notes and annotations that treat a particular subject.

The results of the questionnaire highlight the importance of notes and annotations contribution as resources within a collaborative learning platform. However, students pointed out some technical issues concerning the sharing of resources. Originally, before the test the resource is added with only one indexing concept and the user has the ability to add indexing concepts to the resource. Students suggested adding one or more indexing concepts while creating the resource. Students also raised an issue about the visibility of the map when it is very big and contains a lot of concepts. A filter of the map is actually being implemented to enable viewing of concepts according to some criteria (e.g. hierarchy level) Let's consider a student (called Kevin) who belongs to the "smart city" group. Kevin also belongs to the "All students" group to which belong all the students of the course.

Supposing that Kevin shares a document with "smart city" group and indexes it by "smart economy" concept of the semantic map. Another student (called Pierre) is a member of "smart city" group. While Pierre is reading the document shared by Kevin, he finds an interesting sentence about the economy saving aspect. He decides to annotate the document by a commentary saying "interesting". Pierre choses the sentence and adds his annotation. By considering this annotation as a resource, Pierre can share his annotation with others. The annotation could be shared only in the sharing space of the containing document ("smart city" in this case). Pierre choses to index his annotation by the "economy saving" concept of the semantic map. Now this annotation is visible / accessible by the members of "smart city" group when the focus concept is "economy saving". The students of the "smart city" group can see the sentence chosen by Pierre with his commentary ("interesting"). Students can also open the containing document if they need.

Considering the annotation as information resource enabled Pierre to share and index his annotation in order to be accessible by others. Students were able to access the document by the annotation of Pierre. With other collaborative learning platforms, the annotation of Pierre is considered to be as an integral part of the document. As a result, the indexing and sharing of the annotation in other platforms is not possible and the only way to access the annotations is to open the annotated document itself.