Fahad R Golra

Fabien Dagnat

Jeanine Souquières

Imen Sayar

Sylvain Guerin

Bridging the gap between informal requirements and formal specifications using model federation

Software development projects seeking a high level of accuracy reach out to formal methods as early as the requirements engineering phase. However the client perspective of the future system is presented in an informal requirements document. The gap between the formal and informal approaches (and the artifacts used and produced by them) adds further complexity to an already rigorous task of software development. Our goal is to bridge this gap through a fine-grained level of traceability between the client-side informal requirements document to the developer-side formal specifications using a semi-formal modeling technique, model federation. Such a level of traceability can be exploited by the requirements engineering process for performing different actions that involve either or both these informal and formal artifacts. The effort and time consumed in developing such a level of traceability pays back in the later phases of a development project. For example, one can accurately narrow down the requirements responsible for an inconsistency in proof obligations during the analysis phase. We illustrate our approach using a running example from a landing gear system case study. 4

Introduction

General software development methods do not lend themselves to the kind of rigorous analysis necessary for ensuring the degree of assurance required for safety (or life) critical systems [START_REF] Coram | The impact of agile methods on software project management[END_REF]. Formal methods attain that level of quality through proper documentation and significant analysis. In projects using formal methods, we usually come across domain artifacts (feasibility reports, existing models and software, standards, etc.), user requirements document (also serves as a frame of reference for the agreement between client and supplier) and the specifications document (used for formally defining the requirements). The specification documents are prepared to concretize the software development team's perspective of the software under development [START_REF] Clark | Formal specifications of user requirements[END_REF]. Where requirements document is an informal description of the system, a specification document uses rigorous formal methods that serve for verification and prototyping of a designed system.

As a development project progresses, artifacts contributing to its goal are produced. Traceability is the ability to link these artifacts together, so that one can identify the relationship between them and trace back/forward to them. Due to the gap between the informal and formal approaches, a requirement is taken as a single unit of reference for traceability [START_REF] Giese | From informal to formal specifications in UML[END_REF]. This amounts to a coarsegrained traceability that overlooks individual concepts in each requirement [START_REF] Seater | Requirement progression in problem frames: deriving specifications from requirements[END_REF]. We argue that a fine-grained level of traceability that can link individual concepts in formal specifications to the individual concepts of informal requirements shall help reduce this gap. Different approaches propose using a controlled natural language [START_REF] Mavin | Easy approach to requirements syntax (EARS)[END_REF] to solve this issue. Even though the use of controlled natural language helps reduce requirements ambiguity, it hardly offers any support for improving the level of traceability between the requirements and specifications.

In a previous work, we proposed a concept-level traceability between the informal requirements and the formal specifications [START_REF] Sayar | La validation dans les premires étapes du processus de développement[END_REF]. As an extension to that work, we use semi-formal models to formalize this traceability mechanism. We chose model federation [START_REF] Golra | Addressing modularity for heterogeneous multi-model systems using model federation[END_REF] to realize a framework for the development and coevolution of requirements and specifications. Model federation is an approach that enables binding a set of models from heterogeneous paradigms together. This binding is defined through a behavior that specifies the evolution of federated models in the development of a software system. Using this approach we developed an open source tool that can link requirements documented in various formats (word processors, spreadsheets, databases, xml files or Reqif supporting tools) to the formal specifications. We illustrate the use of our framework using examples from the landing gear system case study [START_REF] Boniol | The landing gear system case study[END_REF].

The rest of this paper is organized as follows. First, we describe the gap between the informal and formal approaches in Section 2. The model federation approach in presented in Section 3. In Section 4, we explain the structural core and in Section 5, we describe the methodological aspects of our framework. We share the lessons learned in various case studies, in Section 6. Then in Section 7 we discuss the state of the art. Finally, we conclude this paper in Section 8.

The gap

Formal methods serve as the backbone of software engineering for critical and complex systems [START_REF] Rierson | Developing safety-critical software: a practical guide for aviation software and DO-178C compliance[END_REF]. They guarantee the correctness of the system under development and help in early validation/verification of requirements. For example, Event-B [START_REF] Abrial | Modeling in Event-B: System and Software Engineering[END_REF] is a formal method for modeling and reasoning about large reactive and distributed systems. It is centered on the notion of transitions. Models are developed using two basic constructs: contexts and machines. Building a specification is a gradual process that uses context extension and machine refinement. Rodin [START_REF] Abrial | Rodin: an open toolset for modelling and reasoning in Event-B[END_REF], an Eclipse based IDE for Event-B provides effective support for refinement and mathematical proofs.

When working on a critical and complex system, one has to deal with both informal and formal models during requirements engineering and/or early architecture design. The most obvious informal model is the requirements document that lists the requirements of the system to be built using natural language. Even though some approaches propose a controlled structure for writing the requirements [START_REF] Mavin | Easy approach to requirements syntax (EARS)[END_REF], the requirements document remains informal. Tools like spreadsheets and word processors are still extensively used for maintaining the requirements [START_REF] Behutiye | Non-functional requirements documentation in agile software development: Challenges and solution proposal[END_REF]. Such tools along with other requirements management tools (e.g. Rational DOORS 4 ) may provide the necessary flexibility for requirements management, but they offer little support when it comes to traceability. Other tools specifically designed for requirements traceability (e.g. Reqtify 5 ) offer a very coarse-grained traceability. They consider a requirement as a unit concept and link it to other artifacts of software development. This makes it hard to keep track of individual concepts that form the core of a system design.

Unless the traceability approaches can pin down the concepts that lead to problems in specifications (e.g. conflicting requirements), the problem of gap between the informal and formal approaches in early software development can not be resolved. Imposing formal languages for documenting requirements is not possible because requirements elicitation is often a shared responsibility of clients and suppliers. In an earlier work, we also shared the case where the requirements document was almost completely prepared by the client organization [START_REF] Golra | Continuous requirements engineering using model federation[END_REF]. Sometimes, the clients of critical and complex industry, especially from aviation and defense sectors, prepare the requirements documents in advance and then call for an open bidding for the projects. In requirement engineering, especially for critical and complex systems, where formal specification helps ensuring the correctness of the system, these informal requirements become the Achilles heel of the complete process. Coarse-grained traceability to the requirements level is not sufficient enough to cover this gap of informal to formal models. We argue that a very fine-grained level of forward and backward traceability to/from the specifications can reduce this gap. With such an approach at hand, one can even look forward to semi-automatic co-evolution of requirements and specifications.

Model federation

Model Federation is a modeling approach where the focus is shifted from models to group of models. Instead of manipulating a single large model, it promotes using a set of interdependent models. This approach stems from the fact that a model is not an isolated entity, rather it depends on other models. For example one can federate a document file (.docx) with a list of states and a minimalistic state automaton (xml file format of UPPAAL). A model federation is therefore a chosen group of models reifying their dependencies to serve an intention. In the context of the automaton federation example , it aims at ensuring the consistency of the textual list of states and the automaton . An action on a member of a federation might impact the whole federation. Hence, each action on a model must be considered as an action on the federation. For instance, changing the name of a state is an action both on the document file and the automaton.

While this conceptual approach can be applied in any discipline using models, it is at its best when dealing with heterogeneous models pertaining to different

The list of states of the system is: Co-evolution is difficult in such a scenario [START_REF] Hebig | On the Complex Nature of MDE Evolution[END_REF], especially if one wants to keep the various members of the federation in their respective paradigms [START_REF] Golra | Addressing modularity for heterogeneous multi-model systems using model federation[END_REF]. It is often easier to act directly on the federation rather than acting on it members first and then recovering the consistency. The role of the federation therefore is to reify the process of ensuring consistency between the models of the federation. Notice that the level of consistency can vary, depending on the intention of its designer. Some federations may constrain the possible actions on the models of the federation to ensure a strict level of consistency. While others may choose to gather the inconsistencies and require human intervention to resolve them. The approach is relatively young but we have designed a framework with associated methods and tools. This framework relies on the following architecture. A federation gathers a set of conceptual models, named virtual models and a set of federated models. Each federated model pertains to a technological space and uses the language of its specific paradigm while a virtual model is built using the Federation Modeling Language (FML). Each federated model can be viewed as an autonomous component while the virtual models serve as control components. Figure 1 presents a simplified version of the automaton federation example that groups these different models. The upper half of the figure illustrates the design of a federation with a model coming from the Word technological space (.docx file), another coming from the XML technological space (UPPAAL file) and one virtual model reifying the dependencies between the textual data and the corresponding automaton. A technology adapter (TA) is a reusable library that defines connections between the FML execution engine and a particular technological space.The model federation framework provides ways to define TA. The automaton virtual model, shown in Figure 1 relies on the two technology adapters (Docx TA and XML TA) for accessing the models of respective technological spaces.

• Alpha • Bravo Word technological space State txtItem:• uppaalState:• rename() next WordUPPAL @A • • @B
U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A AA A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A UPPAAL technological space
FML is a language designed to define virtual models. A virtual model is composed of a set of concepts, while itself being a concept. Hence, virtual model are structuring units while concepts are the core entities. A concept has a set of roles and behaviors. A parallel to object-oriented approach can be useful to understand FML 6 . A concept corresponds to a class, its roles to the attributes of the class and its behaviors to the methods of the class. In our example, a concept State is presented with two roles, txtItem and uppaalState. These roles have types defining the kind of value the role will point to at runtime. Our example illustrates three forms of such types i.e. another concept for next , a type defined in a TA for txtItem or a type defined in an external model for uppaalState . Whenever a type external to the federation space (from a TA or an external model) is used, one needs to use a model slot. A model slot is a mediation entity, associated with a TA, in charge of giving access to external elements of the corresponding technological space. A model slot defines a view on an external model by interpreting it as a set external concepts. Notice that a model slot can limit its interpretation to the needed part of the external model.

FML is designed to define not only the structure of the virtual models but also their behavior. Beware, here the behavior means the collection of actions an engineer will be able to perform on a model federation. It is different from the behavior of the System Under Study. The rename operation already cited for the automaton federation is an example of this behavior. One could also define operations to add or remove states, transitions , etc. The renaming operation is defined by a rename behavior in the concept State. It uses the setText action of the Word TA and rename from the XML TA. When the FML execution engine runs a federation, it creates virtual model instances containing concept instances. Some concept instances are connected to external elements through model slot instances. The lower part of the figure 1 illustrates this runtime phase.

The tool support for model federation framework, Openflexo7 , is developed as an open source initiative with active community around it. This tool offers a FML execution engine with an interactive virtual model design environment. It has been used in several use-cases including model mapping, multi-paradigm process modeling and enterprise architecting. It has also been used to build a tool, the freemodeling editor that has been put to practice in industrial projects [START_REF] Golra | Using free modeling as an agile method for developing domain specific modeling languages[END_REF]. As of today, this tool offers some mature technology adapters (docx and excel for documents, EMF and OWL for modeling languages, JDBC for databases, REST and XMLRPC for external services and one for diagramming tools) and some other rudimentary ones (pdf, http, XML and powerpoint).

Linking requirements to specifications

In order to overcome the informal to formal barrier, as described in Section 2, we developed an approach to link requirements and formal specifications using a fine-grained level of traceability. We develop a model federation using three virtual models in federation space i.e. requirements, specification and glossary virtual models. For the requirements, this federation connects to any of the three technological spaces shown in

Requirement Virtual Model

We benefit from the strength of model federation by developing a virtual model for requirements. Instead of rewriting the requirements using a formal grammar or transforming the requirements into another (formal or semi-formal) model, the requirement virtual model interprets the textual requirements for our specific use of traceability. It allows identifying and tracing back to individual concepts within the textual description. For our specific use, we only need two concepts from a requirement i.e. the requirement identifier and its textual description. Functional and non-functional requirements are treated the same way, as long as there is a corresponding concept in both the requirement and the specification. Using existing Technology Adapters, requirement virtual model can connect to heterogeneous platforms to get any requirements from a word processor, spreadsheet or RIF/ReqIF compliant XML formats (e.g. DOORS, ProR, etc.).

Requirement concept of requirement virtual model, as illustrated in Figure 3 gets the identifier and the textual description of the requirement from the connected Requirements Technological Space. It also contains two boolean type roles isValidated and isConsidered that are used to relay back the information to the concerned stakeholders about the status of a requirement; whether or not it was included in the specification and does it pose any proof obligation issue. The IdentifiedConcept refers to a word/sub-phrase in the textual description of the requirements document which carries an equivalent formal concept in the system specification. The exploration and selection of concepts ensuring the conformity to the defined needs is a progressive activity carried out for the development of specifications in complex software development. For example, the European Cooperation for Space Standardization details a complete process in ECSS-E-ST-10-06C, starting from the identification of possible concepts to the establishment of technical specifications [START_REF]ECSS: Space Engineering -Technical Requirements Specification[END_REF]. The behavior part of this model, not shown in the figure, allows to describe the operations like relaying the information to the stakeholders, observing any change in the requirements, triggering certain behavior in the connected Glossary VM, etc.

Specification Virtual Model

Specification VM interprets a specification with the intention of linking it to the requirements. The long-term objective of this virtual model is to interpret specifications from different (lightweight) formal methods, however we have focused on the Event-B specifications for the moment. Still, the use of model federation offers tool independence by allowing us to use the same virtual model for Atelier B, Rodin or B-Toolkit. Figure 4 illustrates the key concepts of the specification virtual model. The notions of local variable, action, variants and invariants, etc. are abstracted behind EventProperty and MachineProperty for brevity.

The goal of interpreting an Event-B model is to gather the formal concepts from a specification and to identify the kind of those concepts. A formal concept can be of any kind e.g. a machine, variable, constant, etc. We believe that the behavior of a trace link between an informal concept and a formal concept depends on the kinds of those concepts. For example, when an informal concept in a requirement is traced to a constant concept of a specification, one can define the behavior of the trace link such that a change in an informal concept automatically changes the formal concept, but a change in formal concept requires a validation of a requirement engineer to be propagated to the informal concept. For such federation level behavior, the user can add an operation in Specification VM that triggers the behavior of the linked virtual models. Specification VM already contains the behavior for observing the Event-B technological Space and triggering various behaviors of the Glossary VM.

Glossary Virtual Model

Glossary VM is the key model that binds Requirement VM and Specification VM. from where it gets the informal keyword of the concept. This keyword can be of any kind specified by the InformalCKind. For the moment, we have left it to the user to choose the kind of the concept, but for an industrial application, one can integrate Natural Language Processing techniques (e.g. [START_REF] Arora | Automated checking of conformance to requirements templates using natural language processing[END_REF]) that can parse, extract and categorize the concepts from the requirement descriptions.

The FormalConcept of the glossary virtual model is linked to the Specification VM, from where it gets the formalKeyword. It also specifies the kind of the concept amongst the ones described by the FormalCKind. Where InformalConcept only defines the basic manipulation behaviors like create, update and delete, the FormalConcept also defines the refine and isPOTrue behaviors. The refine behavior carries the information about the refinement of an Event-B machine to the corresponding requirement in the requirements document. The isPOTrue behavior notifies the concerned stakeholders of the requirement, whether or not the proof obligations of the corresponding Event-B machine are validated. Trace binds the InformalConcept with the FormalConcept. Each trace has a unique identifier. The create and update behaviors assign a kind to the trace amongst the ones defined by TraceKind :

-A Fact connects an informal concept of Noun, Number or String kind to a formal concept of Constant, Set, Variable, etc. These trace links are used by requirements that specify facts about the future system. -A Functionality connects an informal concept of Verb kind to a formal concept of Event kind. A requirement linked to this kind of trace describes an expected functionality of the system under development. -An Obligation connects an informal concept of String kind to a formal concept of Axiom, Invariant, Theorem and Guard kinds. These trace links are used for preconditions or postconditions on the functioning of a system. -A Behavior is a collection of Functionality links, such that their events must be performed in a temporal order. The informal concept is a String (a sub phrase) that contains the functionality concepts along with their order and links them to each of their corresponding formal concepts. The informal concept in the requirement specifies a behavior expected of the future system.

It is important to note here that our objective is not to exhaustively define the behavior of all kinds of trace links, but to propose a mechanism where such behavior can be specified. The three virtual models i.e. RVM, SVM and GVM, are used by the tool providers. An end user defines its traceability links with a set of available behavioral templates provided by the tool provider. The virtual models are instantiated in the background. Unless the user needs a customized behavior, she does not need to work with the virtual models. A strong motivation for choosing model federation was its ability to decouple the technological dependence from the core behavior of the methodology. For example, the behavior chosen for a trace link between a requirement and Event-B machine does not depend on the tool used for documenting the requirements. The technological aspects of a requirement coming from DOORS or from an Excel spreadsheet do not alter this behavior. They are confined in the Technology Adapter.

Process driven approach

To witness the full potential of our framework, one needs to define the process that integrates the building blocks from the models presented in the previous section. Using the Openflexo tool, we have developed a process modeling editor that serves for defining the process, as shown in Figure 6. Once defined, each activity is linked with the behaviors of individual virtual models for the execution. The user has the liberty to define a desired behavior for each activity.

As the tool follows a process driven approach, it does not impose a specific behavior to the user. We demonstrate the use of our framework by discussing few examples of the activities from the landing gear system case study [START_REF] Boniol | The landing gear system case study[END_REF].

1. Initializing a machine: At the start of the specification process, there exists no corresponding Event-B machine for the concepts identified in the requirements document. The user identifies an informal concept, for which (s)he plans to develop an Event-B machine. Same thing happens, when a concept found in the requirements document does not correspond to any existing machine and the development of a new machine is intended. In the example of Figure 7, the user identifies "landing system" as informal concept. As per the process of Figure 6, when no corresponding machine exists, the framework offers to create a new one. Specification VM can be used for creating a stub for the new machine. Once the machine is created, "Landing system" is identified as a machine concept of Specification VM and it is linked to the informal concept "landing system".

@ Trace1 kind = Fact

Req. id Description FR-3

The landing system goal is maneuvering gears and their associated doors 2. Updating a trace link: The default behavior of the framework when the name of an Event-B machine (e.g. Landing System) changes is to update the glossary and maintain the trace link. Conversely, when the name of the informal concept landing system changes, the framework generates a notification for the system analyst to check for probable inconsistencies. Even though the framework provides a default behavior for the activities associated with tracing, thanks to the model federation approach, the user has the flexibility to define a different behavior. Usually the behavior of such activities is encoded within the tool implementations, and changing the behavior is impossible or at least difficult in case of open source software. For model federation, this behavior is not coded in the tool, rather defined in the model itself.

Adding new trace links:

The process of linking requirements to formal specifications is fairly flexible and varies from case to case. One can choose an informal concept and link it to an existing formal concept. But it can also go the other way round, when one selects an existing formal concept and links it to a concept from a requirement. In Figure 7, we see that "gears" from FR-3 is linked to the "gears pos" in Landing System machine. Once this link is formed, the user goes in the reverse direction for linking this formal concept to other identified concepts from the requirements that refer to it. Similarly, the user links the informal concepts "extending" and "extend gears" to a corresponding formal concept "extend gears" through a trace link of type functionality, as shown in Figure 8. It is important to know that multiple derivatives of a single informal concept (e.g. extending, extend gears, etc.) do not need to have different corresponding formal concepts. One can notice in the figure that the complete description of FR-18 forms an informal concept linked to the guard of the Landing System machine. 4. Early requirements validation: The process of tracing the requirements to the formal specifications forms the basis of validation. A requirement can have trace links to multiple Event-B machines and similarly a machine can have links to multiple requirements. The process of validation does not need to wait till the requirements document is complete. Hence, as the requirement document is under development, the formal specification process can start in parallel. This way requirements are traced to the specifications as and when they arrive. The isPOTrue property of the formal concept in the Glossary VM keeps track of the proof obligations of the linked Event-B machine. If the proof obligations of all the machines traced by a requirement's concepts are proved, the isValidated property of the requirement virtual model returns true. If a requirement is linked to the glossary but the trace is not complete to the formal specification, the isConsidered property of the requirement virtual model return false. This way the information about the validity of the requirements is relayed back to the stakeholders. 5. Refinement of requirements and specifications: Requirement elicitation is a gradual process that involves the refinement of abstract level requirements to the concrete level requirements.

Update 27

This process can be carried out at requirements or specifications. When an informal requirement is refined, all the informal concepts reappearing in the refined requirements with their corresponding formal concepts are notified to the stakeholder for possibly new trace links. In case of a refinement of an Event-B machine, the information is passed through the refine property of the glossary virtual model. The goal is to trigger new trace links from the requirements to the new machine.

The tool implementation for this approach also supports requirements elicitation, links to domain models, ontologies and goal models, etc. but they are out of scope for this article 9 . The intention is to show parts of the default process and the possibility to define user-specific processes. The tool being modular, we have linked this requirement to specification traceability module with our previous modules e.g. goal modeling and requirements elicitation modules [START_REF] Golra | Continuous requirements engineering using model federation[END_REF].

Lessons learned

During the early development of the approach, we focused on two case studies i.e. the landing gear system [START_REF] Boniol | The landing gear system case study[END_REF] and the hemodialysis machine [START_REF] Mashkoor | The hemodialysis machine case study[END_REF]. Finally we implemented our approach on a real-life case study provided by our industrial partner from aviation and aerospace industry, under a research project, FOR-MOSE, funded by French National Research Agency (ANR) 10 . Based on our experiences with these implementations, we share the following lessons learned:

1. Parallel incremental development of requirements and specifications: During our case studies, we found out that it is not necessary to wait for the require- ments document to start the specifications. As soon as requirements start to pour in, the development of specifications can start. The parallel and incremental development of both these artifacts helps requirements elicitation. 2. Fine-grained traceability: We applied a very fine-grained level of traceability going down to the concept level, within each requirement. Such a level of traceability helped the analysts to associate proper requirements to the justifications of each concept at the specification level. It also helped in categorizing the requirements according to their corresponding implementations in the formal specifications. Prioritization of requirements from the clients perspective is a common practice, but when combined with the specification view of priorities, it helps stakeholders to take informed decisions. 3. The validation of the informal requirements: Late validation of requirements after the requirements engineering phase increases the cost of corrective measures. The proposed framework helped in bringing the validation process close to requirements elicitation so much that the validation of requirements is done in parallel with the requirements document development. Once developed, it helps in proving the correctness of the formal specification in relation to the concepts present in the informal requirements, all along the development process. Maintaining the trace links in a glossary reduces the effort of validating complex specification models through refinement. 4. Automation of traces: One of the main reasons for using model federation for the linking informal requirements to formal specifications was the possibility of operationalizing the trace links. A trace link is not just a pointer from an informal concept to a formal concept, it contains a behavior. This allows to (semi-)automate some tasks of linking the two artifacts. Some behaviors we came across during the case studies were automatic update of constants, triggering notifications to the stakeholders, generating requests for proof obligations, changing the state of requirements from valid to conflicting, etc. 5. Verification of requirements: Because the traceability of requirements to formal specification was taken to a fine-grained level, the introduction of corresponding concepts helped in the verification of formal specifications. We found out that such traceability helps in detecting omissions in the requirements (initial states, implicit undescribed requirements, or absence of scenarios) or contradictions between the specifications and requirements. 6. Specification versions of clients documents: An interesting finding of the implementation of our framework to the industrial project was that the specification stakeholders relate more with the formal text than the informal one.

The available trace links made it very easy to generate a version of requirements document where the informal concepts were replaced with the formal ones, as shown in Figure 9. This eased their comprehension of requirements and improved the communication within the team.

Related work

The gap between the informal requirements and the formal specifications was acknowledged and has been a topic of research interest for the past three decades. Deriving VDM specifications from Structural Analysis (mostly Data Flow Diagrams) [START_REF] Fraser | Informal and formal requirements specification languages: bridging the gap[END_REF], Object Constraint Language (OCL) specifications from UML use cases [START_REF] Giese | From informal to formal specifications in UML[END_REF] and system specifications from Problem Frame descriptions [START_REF] Seater | Requirement progression in problem frames: deriving specifications from requirements[END_REF] are few of the examples to bridge this gap. However, most of such efforts are tools and technology specific endeavors. They lack a generic methodology that can be applied in a variety of configurations. The main focus of our work is to reduce the technology dependence from the methodology of linking informal requirements to formal specifications. From the requirements perspective, we accept requirements coming from any tool or described in any formalism. For the specifications, we only implemented Event-B model for now. This is an implementation shortcoming but it does not alter the proposed methodology.

KAOS is a refinement-based goal-oriented methodology for deriving specifications formalized using Linear Temporal Logic from informal requirements [START_REF] Van Lamsweerde | Requirements engineering: From system goals to UML models to software[END_REF]. KAOS facilitates the derivation of system specifications through refinements, but imposes its own requirements description (goal modeling) methodology and constrains the language used for formal specifications. Besides, KAOS suffers from the lack of support for non-functional requirements. Li et al. [START_REF] Li | From stakeholder requirements to formal specifications through refinement[END_REF] present another refinement based approach for the transformation of informal requirements to formal specifications, that can handle NFRs. They use a requirement ontology for classification and propose a requirements modeling language. The advantage of the proposed methodology is that the user is not restricted to any specific requirements specification method or tool.

Our work is notably closest to the approach of Jastram et al. where their requirement model differentiates between phenomena (state space and transitions of the system) and artifacts (the restriction on states and transitions) [START_REF] Jastram | An approach of requirements tracing in formal refinement[END_REF]. They classify the artifacts into Domain Knowledge (W), Requirements (R), Specifications (S),Program (P) and Programming Platform (M). Once formalized, these elements of requirements are mapped to Event-B, using ProR [START_REF] Jastram | ProR, an Open Source Platform for Requirements Engineering based RIF[END_REF]. The main difference with our approach is that we propose explicit definition of traceability behavior in the trace links. Apart from mapping the concepts of informal requirements to formal specifications, we classify different kinds of trace links. The behavior of each kind of trace link is then reused for providing semi-automatic co-evolution of requirements and formal specifications.

Heisel et al. proposed a requirements elicitation process that is independent of the specification language [START_REF] Heisel | A method for requirements elicitation and formal specification[END_REF]. An extension to their work using Rodin and ProR offers a fine-grained traceability between informal requirements and formal specifications [START_REF] Sayar | La validation dans les premires étapes du processus de développement[END_REF]. We have proposed yet another extension to this work using model federation. The advantage of this extension is that the trace links are now fine-grained to a concept level and that they contain the behavior of the trace, rendering them executable. The main limitation of our approach is the cost it incurs. Indeed, the process of maintaining the consistency between the requirements and the formal specifications must be reified. A method engineer has to define the corresponding behavior. Furthermore, the specification engineer needs to invest time for linking individual concepts of informal requirements to the formal specifications. However, this investment provides improved clarity and the possibility of automating certain activities in case of requirements change. Notice also that probably common behaviors would emerge and provide a set of reusable federation behaviors, lowering the cost of their design.

Conclusion and future work

We proposed a framework for linking informal requirements to formal requirements specifications. The main contributions of our approach are: (i) fine-grained traceability between individual concepts in a requirement and individual concepts in a formal specification, (ii) a mechanism for the incorporation of behavior within the trace links, and (iii) tooling and methodology for the incremental development and co-evolution of requirements and formal specifications. We are currently working on an operational semantics of FML using a process calculus encoding similar to [START_REF] Wong | Formalisations and applications of BPMN[END_REF]. The aim of this semantics is twofold. First, we plan to check the correctness of our FML interpreter. Second, we would be able to prove properties about behaviors, for example, a modification of an artifact leads to a corresponding modification of artifacts depending on it. Proving properties of the process alongside the product would help certification of critical systems.

Fig. 1 .

 1 Fig.1. An example of a model federation paradigms. Co-evolution is difficult in such a scenario[START_REF] Hebig | On the Complex Nature of MDE Evolution[END_REF], especially if one wants to keep the various members of the federation in their respective paradigms[START_REF] Golra | Addressing modularity for heterogeneous multi-model systems using model federation[END_REF]. It is often easier to act directly on the federation rather than acting on it members first and then recovering the consistency. The role of the federation therefore is to reify the process of ensuring consistency between the models of the federation. Notice that the level of consistency can vary, depending on the intention of its designer. Some federations may constrain the possible actions on the models of the federation to ensure a strict level of consistency. While others may choose to gather the inconsistencies and require human intervention to resolve them.The approach is relatively young but we have designed a framework with associated methods and tools. This framework relies on the following architecture. A federation gathers a set of conceptual models, named virtual models and a set of federated models. Each federated model pertains to a technological space and uses the language of its specific paradigm while a virtual model is built using the Federation Modeling Language (FML). Each federated model can be viewed as an autonomous component while the virtual models serve as control components. Figure1presents a simplified version of the automaton federation example that groups these different models. The upper half of the figure illustrates the design of a federation with a model coming from the Word technological space (.docx file), another coming from the XML technological space (UPPAAL file) and one virtual model reifying the dependencies between the textual data and the corresponding automaton. A technology adapter (TA) is a reusable library that defines connections between the FML execution engine and a particular technological space.The model federation framework provides ways to define TA. The automaton virtual model, shown in Figure1relies on the two technology adapters (Docx TA and XML TA) for accessing the models of respective technological spaces.FML is a language designed to define virtual models. A virtual model is composed of a set of concepts, while itself being a concept. Hence, virtual model are structuring units while concepts are the core entities. A concept has a set of roles and behaviors. A parallel to object-oriented approach can be useful to

Figure 2 .Fig. 2 .

 22 Fig. 2. Model federation for requirements to specification tracing spaces for which the tool offers a technology adapter e.g. databases, EMF, service oriented platforms, etc. For formal specifications, currently we are supporting Event-B technological space through XML technology adapter.

Fig. 3 .Fig. 4 .

 34 Fig. 3. Simplified requirement virtual model

Fig. 5 .

 5 Fig. 5. Glossary virtual model

Fig. 6 .

 6 Fig. 6. Enterprise architecture editor

FR- 3 Fig. 7 .

 37 Fig. 7. Virtual Model Instance -Initialization 8

Fig. 8 .

 8 Fig. 8. Virtual Model Instance -Traces 8

Fig. 9 .

 9 Fig. 9. Specification version of requirements document

  The InformalConcept from this model is linked to the Requirement VM,

					Glossary VM
		<<InformalCKind>>	InformalConcept	FormalConcept	<<FormalCKind>>
		Verb	informalKeyword: String	formalKeyword: String	System
		Noun	kind: InformalCKind	kind: FormalCKind	Machine
	…	Number String <<TraceKind>> to Requirement VM Fact Functionality Obligation Behavior	create() update() delete() id: String Trace informal end kind: TraceKind create() update() delete()	path: String create() update() delete() refine() isPOTrue() formal end	Context Variable Constant Event MachineProperty EventProperty Guard Predicate Set to Specification VM	…

Beware, even though useful for comprehension, this correspondence is not reliable, as some aspects of FML do not map to object oriented concepts

http://openflexo.org and https://github.com/openflexo-team

FORMOD tool is available at https://downloads.openflexo.org/Formose

Bound by a non-disclosure agreement, we can't share the details of this case study.

https://www.ibm.


Gamze Saygi
email: gamze.saygi@map.cnrs.fr

Jean-Yves Blaise
email: jean-yves.blaise@map.cnrs.fr

Iwona Dudek
email: iwona.dudek@map.cnrs.fr

Temporal hints in the cultural heritage discourse: what can an ontology of time as it is worded reveal?

Time is an indispensable component of cultural heritage (CH) information: implementing appropriate knowledge models carry crucial importance in order to provide deeper understanding of heritage elements' evolution, to uncover concurrences, and to weigh quality factors. It is a challenging task though due to the uncertain characteristics of temporal data, and to the wording of time in the CH discourse. Existing KR models are either not designed for these distinctive characteristics, or spatial aspects tend to upstage the temporal dimension. This research aims at deciphering and proposing a formal representation of the way temporal hints are formalized in historical narratives. An OWL temporal ontology is introduced that provides a core support mechanism allowing for a semantic representation of temporal statements, and for structural analysis. The objective is to facilitate the cross-examination of temporal hints in and across CH collections so that specialists can have extensive reading possibilities of heritage information.

Introduction

As pointed out by [START_REF] Jurisica | Ontologies for knowledge management: an information systems perspective[END_REF], with more and more computer-readable pieces of information analysts today need to rethink their knowledge extraction strategies. Ontologies offer significant capabilities for knowledge management, especially in large volumes of information [START_REF] Davies | Towards the semantic web: ontologydriven knowledge management[END_REF] by providing controlled and consistent vocabularies defined as a set of representational primitives (information types, their properties and relationships) coherent with the meanings and constraints in a domain of knowledge [START_REF] Gruber | A translation approach to portable ontology specifications[END_REF].

On the other hand, time is a feature that appears in many pieces of information [START_REF] Faucher | Temporal Knowledge Acquisition and Modeling[END_REF], and ontologies of time can be of concern for various disciplines. In this research, we focus on the concept of time in the cultural heritage (CH) discourse: temporal aspects are there an inseparable and central role-player for historical analysis, and in any reasoning task performed on the evolution, transformation, reuse, status of heritage assets. But in the CH discourse past events or facts are anchored in time in a large variety of forms (e.g., […] it goes back to the second half of the 13 th or 14 th Century, […] after the Revolution, etc.). These wordings do not fit into "classical" quantification systems such as date formats in DB management systems (e.g., "1942-03-19").

In order to reach a more accurate representation of the temporal dimension of historic narratives, it is important to analyze with care the actual wording of the temporal hints. Only once this analysis has been carried out and confronted to the reality of the historical data sets, can one expect to build a generic formal model, providing interoperable means to decipher and represent temporal structures.

The idea behind the research is that, as analysts of historical evidence, and prior to any interpretation steps, we first need to understand and depict in a structured and sharable manner the nature of the data we handle, in particular of temporal statements.

Such a formalization targets reasoning tasks on verbalization patterns: correlating them to types of information providers, to historical periods they concern, to particular geographic or cultural areas, to particular authors, etc. The background objective of this research is to do a comprehensive analysis of the temporal hints in the CH discourse. To do so, we introduce a hands-on application scenario, encompassing the extraction of "real" hints from "real" data and an experimental implementation using the OWL (Web Ontology Language) / Protégé technological suite [START_REF] Musen | The Protégé project: A look back and a look forward[END_REF]. Such an ontology not only helps reaching a formal model of time as it is worded but also renews the way heritage specialists extract different interpretations from the data they handle.

We however make no claim that we have developed a generic ontological framework that would be suited to historic sciences at large. We do acknowledge the fact that temporalities, and the way they are worded, can be dependent on distinctive parameters such as region, typology or collection. Nevertheless, we highlight particular tendencies of wording in the CH discourse and focus on typical challenges while acquiring and formalizing temporal information in the domain. In Section 2, we draw the outline of the research context in a twofold manner; first by outlining how the time concept is handled in the general research context, and second by focusing on what has been experimented so far in the specific context of the CH domain. Section 3 introduces our approach to the representation of time as it is worded: concepts, notions, and their interrelations. Section 4 discusses the technical implementation and its experimental evaluation. In the final section, we list outcomes and shortcomings at this stage of the research, and some lessons learnt from the experiment.

State-of-the-art

Useful standards, definitions, specifications and recommendations already exist aiming at diverse concerns and steps of temporal information processing. Time-oriented data analysis is a concern within many research communities, such as the TIME community that deals with temporal theories, logics, representation languages, reasoning and ontologies [START_REF] Ermolayev | Ontologies of time: Review and trends[END_REF]. ISO 8601 describes a standardized way of presenting dates and times, whereas ISO 19108 sets the information technology standards for the interchanging of temporal information. ISO TimeML targets a very crucial concern; Natural Language Processing (NLP) tasks for creating controlled temporal expressions from unstructured text. It does not only take into account quantities but also relevant semantic operators. OWL-Time, which is a candidate W3C recommendation, aims at providing a vocabulary for expressing facts about topological relations among temporal instants and intervals. It has been recently extended [START_REF] Cox | Time Ontology Extended for Non-Gregorian Calendar Applications[END_REF] to support the encoding of temporal reference systems other than the Gregorian calendar. There is a growing interest on extending regular time concept to a wider nonabsolute perspective, i.e., research dealing with dirty datasets. For instance, [START_REF] Tao | est verbalisée pose des problèmes de formalisation non triviaux. Pourtant, cette verbalisation[END_REF] develop an ontology called CNTRO for representing temporal information in clinical narratives as RDF (Resource Description Framework) triples supporting time oriented queries in semantic web. [START_REF] Anagnostopoulos | CHRONOS: A reasoning engine for qualitative temporal information in OWL[END_REF] draw attention to the frequency of qualitative expressions in temporal expressions (e.g., before, after), and develop a reasoner named CHRONOS for uncovering temporal relations. [START_REF] Golden | Nanopublication beyond the sciences: the periodo period gazetteer[END_REF] eases the task of linking among datasets that define temporal periods differently. Poveda-Villal et al. (2014) highlight the importance of integrating recurrent events, whereas [START_REF] Diallo | HuTO: an Human Time Ontology for Semantic Web Applications[END_REF] consider different granularities in addition to recurrences. [START_REF] Faucher | Temporal Knowledge Acquisition and Modeling[END_REF] experiments a pipeline from bottom to top, i.e., for acquiring temporal knowledge from texts in order to populate a constrained computable model.

Nevertheless, uncertainty, vagueness and imprecision in the wording of temporal hints (e.g., late 1980s, end of November) remain tough to represent formally. Besides, none of the above mentioned research works yet take into account contradictory notations or alternative wordings that can be combined, even in a single source (e.g., in the 14 th Century, probably around 1380), although such ways of saying are common in the CH discourse.

In the CH Domain, the CIDOC CRM, also known as ISO 21127, is a core ontological model aiming at creating semantic glue between different sources of information, such as that published by museums, libraries and archives. In CRM model spatiality and temporality go hand in hand. Particular to CRM based experimentations, some researchers represented temporal periods on 4 dimensional volumes [START_REF] Papadakis | Fuzzy times on space-time volumes[END_REF], being associated with spatio-temporalities [START_REF] Hiebel | CRMgeo: A spatiotemporal extension of CIDOC-CRM[END_REF]. Approximate, definite and indefinite bounds of periods are considered. Although, they state the approach could be embedded in an information system such as GIS, there is no solid test-case, yet. Moreover, [START_REF] Papadakis | Fuzzy times on space-time volumes[END_REF] point out that their model does not allow representing periods which retreat to the same place several times (i.e., recurrent events) or occur at disjoint places (e.g., festive events). This is a quite critical issue in CH, considering for example sets of transformations/additions/extensions shaping a heritage artefact's lifespan. They focus on modeling reality using only material evidence about past periods or events derived from the observation of traces. However although time may leave physical traces on tangible heritage assets it does not always do so, in particular in the case of intangible heritage (e.g., practices, traditions, festive events). [START_REF] Binding | Implementing Archaeological Time Periods Using CIDOC CRM and SKOS[END_REF] adopt CRM entities and properties for controlled vocabularies, and demonstrate a temporal reasoning method for modelling temporal relationships for archaeological records. They make use of conventional agreements for temporal subdivisions. This allows aligning data records with known time periods and representing the approximate lower and upper bounds of the time periods with numeric values. For instance, they split centuries into years of 01-32 if indicated early, 33-66 for mid or 67-100 for late with reference to advice received from English Heritage. As shown in Section 3 our contribution reuses this concept of conventional mapping (agreements), but extends it in terms of granularities, and proposes a level of flexibility that allows for a user-chosen or user-specific conventional mapping. [START_REF] Kauppinen | Determining relevance of imprecise temporal intervals for cultural heritage information retrieval[END_REF] stress the imprecision of temporal information in the CH discourse. They deal with fuzzy boundaries and exact boundaries of time intervals, and formalize each temporal interval by constraining the earliest and latest possible start and end dates. Nevertheless, they do not take into account open-end indications like before and after statements. Besides they solely analyze the potential overlapping of intervals. [START_REF] Nurminen | Representation and retrieval of uncertain temporal information in museum databases[END_REF] discuss representation and retrieval of uncertain temporal information in museum databases with a specific focus on anchored time intervals. They underline the shift from item-centric (i.e., structured around physical entities) to event-centric cataloguing (i.e., concentrating on various events) of museum artefacts. It is particularly important when considering events as clusters linking heritage entities to the cultural actions of human beings and the social setting.

Generally speaking a large number of research efforts on temporal reasoning build on the concepts introduced by [START_REF] Allen | Maintaining knowledge about temporal intervals[END_REF]Allen ( , 1990)), and there is no doubt that such efforts are welcome for instance in the context of artificial intelligence applications. But there is quite a distance between the way historical hints are actually worded, and a sound application of Allen's formal relations. Our research fits in that gap: temporal statements (both quantitative values and lexical modifiers) first need to undergo a process of extraction in order to uncover their structure, and a fine-grain analysis so that scientists can get a critical understanding of how doubts pervade their reasoning processes. This key challenge in historical sciences was taken on in the context of heritage data cross-examination and visualization [START_REF] Blaise | Architectural transformations on the Market Square in Krakow -A systematic visual catalogue[END_REF]) but an in-depth investigation of how it can be addressed in the KR context remains to be carried out. Efficient temporal reasoning, based on Allen's relations or not, will only be possible if a complete formal model of the specific wordings of historians has been introduced. In order to fulfill this aspect, a basic approach could be following the footsteps of a standard temporal ontology (such as OWL-Time) by extending it or reusing the spatiotemporal ontology by CIDOC CRM. Nevertheless, the way time is verbalized in the historical discourse would require a very significant move away from these standards' original versions. The approach presented in this paper is not to work on the concept of time itself, or on spatio-temporal entities, but to try and assess the potential added-value of a formal representation of temporal statements as worded in the CH discourse.

Analysis and representation of temporal statements

In this section we discuss the formal model of temporal statements. To start with we define the main notions, the top-level organization and relations, and detail the time-related concepts classification.

Main notions and general organization of the formal model

A TemporalStatement is some sequence of words that tell us when something happened and/or how long something lasted within a temporal reference. A TemporalStatement's semantic field is the notion of time alone, it does not extend to the concept of spatial/physical property which it affects or refers to. Any TemporalStatement is composed of one or more Time-related concepts (points, intervals, etc.), which may be accompanied by one or more LexicalOperators (during, before, end of, etc.).

There is a set of basic but important elements we associate to a temporal statement. First and foremost, granularity describes the mapping of time into conventional units upon human decision. That mapping is basically aimed at dealing with time in an easier way, and can be specified in multiple ways (in larger or smaller units) depending on the needs of the analyst [START_REF] Aigner | Visualization of Time-Oriented Data[END_REF]. In a TemporalStatement like "The first quotation dates back to 20 April 1687", the temporal granularity can be fixed to "a day". But the day can be subdivided into smaller segments such as 24 hours or 1440 minutes (and incidentally the "standardization" of time dates back to 1884, with the definition of an "average" hour in response to the multiplic-ity and variability of solar hours, hence serious interpretation bottlenecks when observing such statements today). The non-decomposable unit for a given granularity is called chronon, a term coined by Robert Lévi in 1927. For instance, in Java, date class uses milliseconds as chronon. Naturally in the historical discourse there can be a disjunction between a statement's intrinsic granularity and the temporality of the fact that is reported. For instance, in a temporal statement like "A great fire damaged the building extensively in the winter of 1920", the granularity of the statement is a season whereas the "great fire" mentioned in the statement most probably lasted some days at most or even some hours. The notion of Un-foldableTimePoint (see section 3.1.3) is a pragmatic answer to that concern.

FIG. 1 -Components of a TemporalStatement and their interrelations.

A difference is made between Temporal Reference Systems (calendars, part of OWL-Time) and the notion of periodization in history, that can be used as a reference in the wording of temporal hints but that is not a systematic discretization of time (e.g., Gothic appears before Renaissance in European architectural styles, nevertheless we can not specify the exact temporal boundaries of these stylistic trends). This notion is mapped in a concept called NamedTimePeriod.

Consequently, the proposed model is organized as follows:

-A LexicalOperator concept matching the "verbal modifiers" (around, before, etc.), -A utility concept called ConventionalMapping used to interpret qualitative expressions when needed, and turn them into workable quantities, -Classes that represent the time-related concepts present in the TemporalStatements.

LexicalOperator

Lexicals refining the qualitative extent of time and supporting the anchoring of Tempo-ralStatements are defined as LexicalOperators (table 1). These qualitative components of the hint determine the "extent" of a TemporalStatement. TAB. 1-Types of LexicalOperators acting as potential components of temporal statements.

ConventionalMapping

Prior to any conversion of a temporal statement containing a lexical operator into a workable quantity, an ad-hoc convention should be established: this is the role played by Conven-tionalMapping (agreements). The quantification of any LexicalOperator is subject to Con-ventionalMapping. For instance, "end of the 15 th century" can be translated into a userchosen quantified time slot as "1480-1500", and the analyst needs to formalize in a sustainable manner such a decision.

Time-related Concepts

Time-related concepts are represented through three classes or hierarchy of classes: NamedTimePeriod, QuantifiedTemporalStatement, CompoundTemporalStatement. In this section, we address their definitions, properties and specifications.

NamedTimePeriod.

NamedTimePeriods correspond to TemporalStatements that provide an ordered reference rather than a temporal coordinate system (e.g. after the reign of rather than between X and Y). The sequence of NamedTimePeriods can overlap on each other. It can be related to diverse frame of references such as art movements (e.g., Art Nouveau), political events (e.g., 30 Year Wars, WWII) or natural facts. A NamedTimePeriod, whether it is accompanied with a LexicalOperator or not, always implies the use of Conven-tionalMapping. The concept matches the notion of periodization in historical analyses.

QuantifiedTemporalStatement.

A QuantifiedTemporalStatement is a temporal hint expressed in numbers (or with universally accepted lexicals such as a decade). It can represent either a TimePoint, an Interval or an UnanchoredDuration. A QuantifiedTemporalStatement has two properties: a temporal reference system, and a chronon. Although the Quanti-fiedTemporalStatement is the quantified part of a hint, its value should still be interpreted in relation with any LexicalOperator present in the statement, e.g., "before 1650" does not point out to "the year of 1650" itself, but to a "time slot that precedes 1650".

TimePoint: definition and subclasses

At the conceptual level a time point represents an instant, with a zero length. Depending on the granularity, a TimePoint de facto can have a temporal extent, but the verbalization of the statement is this of a point. Three concepts refin-ing the classic TimePoint (tp) Class are introduced to deal with temporal statements that are verbalized as TimePoints (table 2).

Temporal hints in the cultural heritage discourse

Interval: definition and subclasses. At the conceptual level a time interval represents a segment of time with a duration. Six concepts are introduced to deal with temporal statements that are verbalized as time intervals (table 3). They share common features: they are defined by one or two TimePoints and are anchored in time. OneSideBoundedIntervalStatement (iOSB) is a wording that refers to an occurrence expressed by a TimePoint (tp), and accompanied by a LexicalOperator such as "before" or "after". The TimePoint acts as a boundary (beginning or end) and the LexicalOperator's effect is to create an undefined duration on one side. A conventional value for the duration can be defined by ConventionalMapping.

Example

Elle a été construite après 1720 par souscription publique.

It was built after 1720 by public subscription.

Extraction [tp]=1720 and [d] is related to ConventionalMapping

RelativeIntervalStatement (iR) is a wording where a TimePoint is used to anchor an occurrence located at a distance in the past or in the future of the TimePoint. The "temporal gap" between the time point and the occurrence is expressed, but the duration of the occurrence is not. Temporal hints in the cultural heritage discourse UnanchoredDuration An UnanchoredDuration represents any temporal statement that mentions a segment of time with a duration but without explicit boundaries (anchored in time). This concept is used to represent hints such as "the renovation lasted for 40 days."

CompoundTemporalStatement It is quite common to have multiple temporal indications within one TemporalStatement, e.g., "it dates back to the 13 th or 14 th century". Com-poundTemporalEntity represents such cases in which the statement contains two or more alternative QuantifiedTemporalEntities, may they overlap or not, and may they be consistent in terms of wording or not.

OWL Implementation, results and limitations

We implemented an open-source solution, by using OWL 2, built upon RDF in which data is represented by sets of "triples". We populated the ontology with information sets extracted from online resources published by different stakeholders (e.g., public archives, cultural societies, etc.) harvested in the context of a research initiative1 on minor tangible and intangible heritage. These information sets, being verbalized by various parties, correspond to the heterogonous, imprecise and uncertain nature of the temporal information often met in the CH domain. We selected 1576 temporal statements and in addition to standard OWL data types, we reused OWL-time datatypes such as time:generalDay, time:generalMonth.

At this still early stage of the research, the formalization effort does shed light on some significant verbalization patterns, but also on where the effort needs to be consolidated. For instance, 90 TemporalStatements correspond to the concept of CompoundTemporalStatement but their classification as such is motivated either by contradictory indications (e.g., "[…] datées du XIème ou du XIIème siècle") or by a sort-of caution in the wording (e.g., […] doit remonter au XVIIe siècle (vers 1668-1670)"). Incidentally, the use of wordings classified as CompoundTemporalStatement apparently gets more common when occurrences are located farther in the past, which is a rather expected pattern. A majority of the overall statements considered fall into one class: the FuzzyTemporalStatement class. This also is rather expected since the granularity alignment between a hint and an occurrence is quite often out of reach in Historical Sciences, and in particular when dealing with Minor Heritage. Some more question-opening tendencies can be observed also, for instance when observing the variety of linguistic figures used to verbalize one same situation: bounding the "beginning" of an occurrence. But it has to be said clearly that tendencies observed could very well be related to the particular dataset we have worked on, or to biases introduced in the model itself, and therefore they should be taken for what they are worth. Our purpose is certainly not to draw out of such early observations a Historical-Sciences related general conclusion but by contrast to use the observations as a mean to question the model. In addition, one of the lessons learnt from the experimentation was that some "contemporary" hints as found in citizenbirthed e-sources harvested on the net, such as "the edifice was reconstructed in last years", are far from being the easiest to deal with.

Briefly said, our formalization efforts do highlight the extreme diversity of temporal information in the CH discourse, but also uncover some significant patterns such as a relative disconnection between lexical operators and temporal granularity (operators used whatever granularity). As a consequence, it appears clearly that what the research also underlines is the amount of unsaid in the reasons why this or that verbalization modality has been chosen by an information provider.

Conclusions and Future Works

In this paper, we analyzed imperfect temporal statements used in the CH discourse, and introduced an ontology for enabling and encoding temporal knowledge. Our contribution, small though it may be, aims at facilitating the cross-examination by analysts of historical evidence of the temporal evidence itself, prior to interpretation steps. Our experimental results show that the ontology carries the potential to shed light on (ill-defined) temporal information effectively. Nevertheless, we acknowledge the necessity to validate the ontology on larger datasets, and test its extraction capability in heritage collections where regional and typological parameters are extensively circumscribed.

In addition, we acknowledge the necessity to inspect the proposed ontology by external domain experts. However the services expected, as well as the information providers, correspond to a variety of domains ranging from linguistics ("wording as such") to museology, ethnology, art history (if not historical sciences at large), etc. Hence a robust validation helping to recalibrate the proposition will require a multidisciplinary investigation, and is definitely part of the research agenda we have ahead of us. Future works will include a critical analysis of the applicability of the approach beyond the initial corpus (rules of assignment in particular), a visualization effort, and a deeper attention to the interdisciplinary issue of elicitation: not only how a temporal statement is worded but also why. comme portant une question de fond allant au-delà du cas d'espèce. La contribution détaille d'abord la grille d'analyse d'indices temporels proposée, puis relate l'expérimentation concrète associée (ontologie OWL). Il n'est pas fait état d'une quelconque prétention à un résultat généralisable stricto sensu, mais cette expérience peut contribuer à nourrir de façon pragmatique un débat nécessaire sur la formalisation d'indices temporels dans les sciences historiques.

FuzzyTemporalStatement

  (tpF) is a wording that refers to an event confined in an ambiguous way to a TimePoint. The fuzziness of the information delivered by such a TemporalStatement comes from a doubt concerning the alignment of the granularity possibly needed to analyze the event and this of the TimePoint.ExampleElle a été reconstruite au milieu du 18e siècle.It was rebuilt in the middle of the 18 th century. Extraction [tpF] = middle of the 18 th century and [gW]= a century ≥ [gE]= a year UnfoldableTemporalStatement (tpU) is a wording that refers to an event expressed as a TimePoint. Unlike in the case of FuzzyTemporalStatement the duration of the event is here for sure shorter than the chronon corresponding to the TimePoint. Example La toiture a été emportée par l'avalanche de 1978. The roof was washed away by the avalanche of 1978 Extraction [tpU]= the avalanche of 1978 and [gW]= a year ˃ [gE]= a minute RecurrentTemporalStatement (tpR) is dedicated to TemporalStatements for periodic/cyclic occurrences. Its structure is the same as this of a TimePoint but with frequency descriptors (f). Example Aujourd'hui, Notre-Dame-de-Vie fait toujours l'objet d'un pèlerinage annuel le 15 août. Today, Notre-Dame-de-Vie is still the subject of an annual pilgrimage on August 15 th . Extraction [tpR]= August 15 th and [f]= annual TAB. 2 -Subclasses of TimePoint.

ProperIntervalStatement

  (iPR) is a wording corresponding to an Interval expressed 2 TimePoints (beginning boundary tpB, and end boundary tpE). These two TimePoints are connected by an ExplicitOperator. Example [...] Bâti en pierre entre 1815 et 1825. [...] Built in stone between 1815 and 1825. Extraction [tpB] = 1815 and [tpE] = 1825 implies d = 11 years OnePointAnchoredIntervalStatement (iOPA) is a wording that refers to an occurrence expressed by a TimePoint, and accompanied by a LexicalOperator such as "around". The LexicalOperator's effect is to create two equal durations (d) on both sides of the point. The value of the durations is user-chosen (ConventionalMapping). Example Bâtiment actuel édifié autour de 1645. Current building is built around 1645. Extraction [tpM] = 1645 and [d] is related to ConventionalMapping

  Exampleen 1706: la chapelle ste Anne au hameau appellé Toron, bâtie depuis plus de 60 ans. in 1706: the chapel ste Anne in the hamlet called Toron, built more than 60 years ago.Extraction [tp]=1706 and [d] = more than 60 years PertinentIntervalStatement (iP) is a wording where one only boundary is defined, and by an instance of NamedTimePeriod ("WWII", "the great plague", etc.). The concept is used to refine iOSB and iR when the anchoring cannot be done through a TimePoint, but is done through an instance of NamedTimePeriod (ntp). Example [...] remaniements après la Révolution. [...] rearrengements after the Revolution. Extraction [ntp] = the Revolution and ([ntp] and [d]) are related to ConventionalMapping UnfoldableIntervalStatement (iu) is a wording expressed with two TimePoints, and where the duration of the occurrence is for sure shorter than the distance separating the two TimePoints. Example 1160-1164 [...] seigneurs [...] pour y construire une abbaye [...] acte signé [...] 1160-1164 [...] lords [...]to build an abbey [...] deed signed [...] Extraction [tpB]= 1160 and [tpB]= 1164 implies [d] = 5 years ˃ [dEVENT] TAB. 3 -Subclasses of Interval.

The ontology is available on the Territographie projet web site (http://map.cnrs.fr/territographie/), portal of an exploratory research project on citizen science and minor heritage conducted in co-operation with MuCEM (Museum of European and Mediterranean Civilizations) and funded by the région Provence-Alpes-Côte d'Azur authorities.