WO2013110662A1 - Method for editing forms for data entry at various collection points - Google Patents

Description

 Method of editing forms for entering data at different collection points

Technical area

The present invention relates to a method for editing forms for data entry at different data collection points.

State of the art

[0002] Data management systems are known in the state of the art in which data are collected at different data collection points, stored in a database management system and made available to users under form of forms, reports, web pages etc. Such systems are for example used to guarantee the traceability of agricultural and / or manufactured products. In this case, different producers or intermediaries involved in the production of the product introduce data into a database provided to the distributor, the market and / or the consumer. For example, there is a need for a traceability system for textile products. For example, it would be desirable to allow a consumer to access data stored in a database fed by the various producers involved in the manufacture of a garment, and to verify, for example, biological and / or equitable origin. involved cotton, the quality certification (s) attached to different stages of production, or to ensure that the garment has been produced respecting ethical rules of production.

This need which is perfectly satisfied for products obeying a relatively simple manufacturing logistics is unsatisfactorily satisfied for products involving complex manufacturing logistics. One of the difficulties comes from the need to adapt the logistics data entry system set up by each manufacturer for each type of product.

Many industrial or agricultural products are monitored by means of a traceability system based on the EAN 128 (European Article Numbering) code or SSCC (serial code for pallets) which makes it possible to identify and trace products and products. services in the downstream part of the distribution. This identification to the unit gives information for internal use (type of product, material, size, color, ...), but generally concerns only the distribution logistics, once the product manufactured, packaged and shipped. These widely used systems do not give information about the origin of the raw materials of the product, or its conditions of production.

[0006] WO201 1 124951 describes a process for the certification and traceability of organic food. The data from the various producers and

intermediaries are still most often collected by means of paper forms and faxes. The distribution of these paper forms, and the data entry into computer systems, however, involves tedious work and is a source of frequent errors. It would be desirable to be able to enter this data from the collection site by means of portable terminals, for example laptops, smartphones, PDAs, tablets with an internet connection, etc.

Partial solutions exist for this purpose. FR2776790describes a process for tracing food products; this method uses terminals available to producers and intermediaries, as well as a conventional central database. The traced products bear an identification code, for example a bar code.

[0009] US201 10016144 is another patent application describing a method for ensuring traceability in the field of cereals. The data are collected by sensors or by farmers in a database to which the consumer can connect via the internet.

[0010] US7900835 relates to a method for tracing agricultural products using electronic forms; the method includes verification on the basis of ingredient analysis, for example DNA analyzes.

[0011] US20070203724 relates to a method making it possible to ensure the traceability of agricultural products by means of electronic forms filled in at different levels, and consultable via web pages by the final consumer.

[0012] US20020082982 describes a process for ensuring traceability in the cereal industry, and verifying the use of pesticides, genetically modified cereals, genetically modified seeds, etc. The information is entered into a database by means of a palmtop or paper form by the farmer and by different external entities, including laboratories.

US7440901 describes a method for ensuring traceability in agriculture. This process involves the collection of data by means of different devices, including radioportable terminals, throughout the production chain. A report is generated in graphical form and indicates whether the product meets predefined criteria.

[0014] FR2813683describes a method for managing information relating to the life path of food products. The process involves rights management by several intermediaries authorized to write or read data. A similar solution is described in US20050027726.

EP1902606 discloses a method for graphically representing the processing chain of agricultural products, including the various locations of storage and processing. EP1498835describes a method for tracing agricultural products using unique identifiers of products and intermediary identifiers.

US7184892 relates to another method for ensuring the traceability of agricultural products using unique product identifiers and intermediary identifiers.

[0018] US20030182144 relates to a traceability process in agriculture, allows different actors throughout the production chain to introduce data collected by means of a network. Marcelo Arenas et al. describe in the August 30, 2009 article "Foundations of RDF databases, reasoning web semantic technologies for information systems, the theory of RDF databases and an RDF database query language." A similar description is also given in Jorge Péerez et al., "QueryingSemantic Web Data with SPARQL", Department of Computer Science, Universidad de Chile, JUNE 1, 201 1, which relates more specifically to the SPARQL query language that makes it possible to query RDF semantic databases. However, these documents are very general and provide no solution to the problem of the traceability of the various stages of the manufacture of a product, nor the multitude of forms that must be created and edited to allow the various stakeholders to collect information on to the product being manufactured.

There are therefore a large number of solutions for collecting data at different levels or stages of the production of a product, and to make these data available to the consumer for example.

The realization of such a data collection system at several collection points distributed by means of terminals

of different types, however, requires considerable work for the creation and editing of data entry forms. data. For example, the forms must be adapted to the different operating systems and the formats and number of colors of the screens of the different terminals used by the data collectors. On the other hand, the number of collection points as well as the type of information that must be entered in each point, or that a user or producer has the right to introduce or modify, depends on the organization of the product production. Some products require few operations at a limited number of processing points; in this case, a limited number of data collection points can be defined to capture all the data necessary for traceability and which the consumer or end user wants to have access to. Other products go through a number of important transformations, made at different points of

treatment ; the relevant information must then be collected at many different collection points. The establishment of a traceability system for products involving complex manufacturing logistics is difficult. For example, the production of a cotton textile product involves a large number of highly specialized intermediaries and subcontractors, often in different countries. Cotton yarn is often produced from batches of cotton from different producers and from

different origins, for reasons of wire quality. Organic cotton is often mixed with non-organic cotton. What's more, in the same industry each brand or distributor organizes the logistics a little differently. Certification of biological or equitable origin is often made on the basis of checks carried out by certification bodies that carry out spot checks, for example every six months or every year. The certificates awarded are difficult to distribute to all the intermediaries involved downstream of the production chain, up to the consumer. Therefore, the complete traceability of a product is a complex task, and current solutions do not allow the consumer to ensure that the entire chain involves for example a fair and biological work. In the same way, it is difficult to calculate the carbon cost (CO2 footprint) for the production of an industrial product via many partners and subcontractors. The calculation of water consumption is also an important metric given its massive use in certain manufacturing processes, especially in agriculture and for textile manufacturing processes. The systems set up in the prior art are generally adapted to a particular production organization, for example to trace the production of a particular type of product in a given production line. On the other hand, it is not possible to easily adapt an existing product traceability control system to another product, because the production logistics are very different and the data to be captured are different, as well as the collection points. Datas. Such an adaptation notably involves the creation or the modification of many data entry forms, which constitutes a particularly tedious operation. These forms must also be adapted when the supply chain of a manufacturer is reorganized or modified.

Current traceability systems are based on relational databases. Data is stored as tables linked together by relationships. The organization of the production logistics and the type of queries you want determines to a large extent the relationships between these tables. For example, if the same company includes cotton harvesting activities and ginning activities, only one table can be used to store all the data relating to that company. If the organization is changed and the ginning is done by a farmer-independent company, it will usually be more efficient to have a harvesting table, a ginner table, and a producer-ginner table to indicate which ginners work with which producers and thus allow the creation of multiple-to-multiple relationships. Changes in production logistics therefore often involve a change in the structure of the database relational used to store the data needed for traceability. This change of structure in turn implies that requests for access to this table must be rewritten, and that the data entry forms based on these requests are redone. If the change is important, it is sometimes easier to reprogram the entire relational database. This is particularly the case if one wants to adapt an existing database intended for the traceability of a particular product (for example a piece of textile) to the control of the traceability of another product (for example a component automobile) obeying a completely different production logistics. This is frequently also the case in case of reorganization of the manufacturing supply chain.

Brief summary of the invention

An object of the present invention is therefore to provide a method for editing forms for the capture at different collection points of data relating to the traceability of products that is free from the limitations of known methods.

Another object of the invention is to provide a method of editing forms for the input into different collection points of data relating to the traceability of products that simplifies and simplifies the process.

Speed up the generation of new forms and the modification of existing forms.

Another object of the invention is to provide a method for editing forms for entering different collection points of data relating to the traceability of products that simplifies the adaptation of forms to modifications of the organization of the production of the product.

According to the invention, these objects are achieved in particular by means of a method of editing forms for the input into different collection points of data relating to the traceability of products, including information, comprising: defining an ontology to define different properties of said product, and how these properties can be modified at different locations during the manufacture of said product;

 creating a central database based on said ontology, said database containing for each product traceability information accessible by consumers and relating to the manufacture of said product;

 remote editing by means of a module for creating and editing forms of a plurality of separate forms enabling data collectors distributed at different collection points to collect data relating to the manufacture of said product,

 provision of said forms to said collectors, each data collector having access to a data form according to the type of collection point,

 wherein said form creation and editing module determines on the basis of said ontology which properties of said product can be edited using each form available at each collection point.

The use of an ontology makes it possible to define in a very precise and flexible manner the properties of the product that one wishes to trace, and how these properties can be modified in different places during the manufacture of the product. Different ontologies can be defined for different products. The ontology can also be adapted to the modifications of the organization of the manufacture of the same product. A database based on this ontology can centrally store the data relating to the traceability of the product. This database can use, for example, high-performance semantic database tools for creating and modifying queries.

[0033] Forms may be edited, for example created or modified, by means of a module for creating and editing forms. These forms determine on the basis of the ontology what properties of which form can be entered or modified at which collection point. For example, a single web service can be made available for creating and editing forms to users who have the appropriate access rights. Semantic databases, for example based on RDF and using an ontology, are known in the prior art; it is also known to populate them with forms. However, the unexpected use of such an ontology to define different stages of modification of a product during its manufacture makes it possible to design data collection by means of decentralized forms in an entirely new way, considerably simplifying the creation and the production of data. editing of property entry forms at different collection points.

The forms thus created are then used at different collection points by distributed data collectors, in order to collect data relating to the manufacture of said product,

The data stored in the central semantic database can be made available to users, for example consumers, merchants, importers, etc., in order to access the information entered by the operators at the various points. data collection. The pages will present, for example, explanatory text on the manufacturing stages and the provenance of the raw materials, as well as illustrations. The information can be presented as a table, query, status, web page, graph, map data, photo, video, certificate reproduction or other documents, etc. The idea is to present different pages telling the story of the production of the product from the production and going back to the finished product. Brief description of the figures

Examples of implementation of the invention are indicated in the description illustrated by the appended figures in which:

[0038] Figure 1 illustrates a schematic view of the hardware infrastructure of a system according to the invention. Figure 2 schematically illustrates the transactions during the manufacture of a product, in this example a piece of textile.

Figure 3 schematically illustrates the operations performed during the manufacture of a product, in this example a piece of textile. Figure 4 is a partial diagram illustrating how the previously described logistics in relation to Figures 2 and 3 is modeled and stored semantically using classes. It also shows by means of letters the indicative order in which the classes are instantiated when entering the data by means of forms. FIG. 5 illustrates an example of a data entry form intended for a data collector. and displayed on a mobile terminal.

FIG. 6 illustrates a screen shot of an application showing indicators coming from the semantic database, and which can make it possible to request the semantic base. [0044] FIG. 7 illustrates a screen copy of FIG. an application running on the terminal of a consumer or user when scanning a barcode on a product.

FIG. 8 illustrates a screen shot showing an example of information coming from the semantic database and which may be displayed on the terminal of a consumer or user following the scanning of a barcode on a product.

Figure 9 illustrates another screenshot showing an example of a photo of a producer from the semantic database and which can be displayed on the terminal of a consumer or user following the scanning of a code -barre on a product.

FIG. 10a-10b shows a screenshot of an example of a module for creating and editing a form.

Example (s) of embodiment of the invention

The method of the invention is implemented using a computer system organized in a new way. An example of a system

computer is illustrated in Figure 1. It comprises a central system, or back end, formed in this example of at least one database server 100 and at least one application server 101. The servers may be constituted by physical or virtual machines, or distributed servers in a cloud architecture. The database server 100 comprises for example a semantic database server, for example an RDF store (Resource Description Framework), which may be accompanied by a conventional relational database server for storing other data. A triplestore database can be used to store RDF data.

An application server 101 provides the interface between the data stored in the server 100 and external users 103, 104, 105 which access these data via the internet network 102.

The communication between the semantic database 100 and the application server 101 is advantageously through an interface. In an advantageous embodiment, this interface is implemented by means of a web service, for example a RepresentationalState Transfer (REST) service which makes it possible to operate a translation of data between servers 100 and 101 and so separate the data from their representation. In one embodiment, the REST service serializes the data

semantics of the semantic database 100 in data, for example in JSON (JavaScript Object Notation) or XML data, which can be used by different applications of the application server 101, in particular for constructing data entry forms by means of a form editor. The REST interface also makes the

inverse transformation; it receives JSON or XML data describing, for example, forms and / or data entered using these forms, and translates them into a triplet in order to update the semantic database 100.

The user 103 is a front end operator (or data collector) who enters data relating to a product at a collection point. The data collector is typically a producer or other operator or intermediary involved in the manufacture of a product. In a frequent embodiment, the system comprises several data collectors 103 at different collection points, different data collectors may have access rights.

different. The application server 101 generates forms that the data collector 103 can dynamically display and then fill on its terminal, for example on a computer or a portable terminal such as a smartphone, a tablet, a palmtop, etc. In a preferred embodiment, the data collector 103 has a

smartphone or tablet including an application that allows data entry even when the user's terminal is offline; a data synchronization mechanism between this terminal and the database 100 makes it possible to update the data on each side when the operator is again online or when the data collector 103 explicitly requests such synchronization. In an application to the traceability of textile products, the data collector 103 may be for example a cotton harvester, a dyer, a weaving mill, etc.

The user 104 is for example a consumer who wishes to access data concerning the traceability of a given article, for example. example of data relating to the manufacture of a T-shirt. This user 104dispose for example a smartphone or other terminal connected to the internet with a camera or a tag reader for example, which allows it to scan a barcode, a datamatrix, an electronic tag, etc., associated with an article , as shown in Figure 7. The barcode,

datamatrix or tag linked to the product is decoded, preferably locally in the smartphone by means of a dedicated application, and used in a request sent via the internet 102 to the application server 101 in order to obtain additional information on the scanned product and stored in the central database 100 by the data collectors 103. The data can be displayed and presented on the consumer's portable terminal 104 via a dedicated or generic internet-oriented application of the objects and making it possible to decode a barcode with one or two dimensions ( EAN, Datamatrix, QR-Code, etc.). FIGS. 8 and 9 show examples of traceability information that can be retrieved by the consumer's mobile terminal 104, for example basic information on the scanned article (FIG. 8), a photo or a map of the place where the cotton needed for production has been harvested (Figure 9), information on other stages of the manufacturing process, certificates of conformity, etc.

The user 105 is a professional user, for example an operator or database administrator, or an operator authorized to introduce more complex requests by means of a terminal such as a computer, or possibly a mobile terminal. . The operator 105 can, for example, introduce requests using an application of

Figure 6 may also have access to a dashboard for tracking an article or batch of material throughout the manufacturing process, or for monitoring and controlling the activities of a producer.

The operator 105 can also modify the ontology underlying the database 100, and create by means of a computer or a mobile terminal data entry forms used by the data collectors (producers). and by consumers 104. Various new software applications allow the method of the invention to run in this infrastructure.

The "backend operator" is a centrally executed application to manage data collected from different distributed collection points. The "front end operator" is a mobile application, for example an application running on a smartphone or a tablet, or a web application used by the data collector producers 103 at different collection points to enter the data and synchronize it with those of the central database. The "B2B Backend" is a database (or knowledge base) that contains the information entered by data collectors 103 and allows for data mining. This database can also be distributed and the central database term simply means that all information can be accessed at a single logical address. The "B2B Frontend" is an interface

user, for example as an application or dynamic web page, which allows a user 105 to access information stored in the database 100 as a dashboard or via requests.

Reference 107 designates a module for creating and editing forms (or visual forms designer) which allows the operator 105, for example, to edit the specialized forms and the graphical interface made available to users. data collectors 103 through the backend operator 101. As mentioned, the form creation and editing module 107 can advantageously be implemented as an application residing in the application server 101, and communicate with the database 100 by means of a REST type interface, for example to convert the data entered by the forms and the structure of the forms themselves into triples stored in this database 100, and vice versa. The module for creating and editing forms 107 includes for example a graphical web interface that allows the operator 105 to create and layout the various input forms required for the various data collection points in order to allow data collectors 103 to enter data. The module for creating and editing forms can be used by a user without specific computer training and who does not need to be a computer scientist to design or modify the definition of forms. It can be run on a computer or on a mobile device.

An example of an interface 102offered to the operator 105 by the module 107 is illustrated in FIG. 10. The lefthand column 1200 includes a toolbox which allows the operator to select objects to place. on the form shown on the central part 1201. Selected objects may include, for example, data entry fields. Selectable objects also include, for example, fixed, multi-line and rich text fields, date fields, simple or multiple data lists, and possibly other objects such as graphic elements, images, and so on. In one embodiment, the list of data entry fields available may depend on the collection point for which the form is intended, and possibly the particular data collector-operator 103 if different data collectors (or group of collectors of data) at the same collection point have different access rights. The list of data entry fields therefore depends on the production logistic organization as modeled in the semantic database by an ontology and translated by the REST interface.

The central portion 1201 allows the operator 105 which creates a form to have the various objects selected in the left column 1200 on the graphical interface which is intended to be displayed on the data collector terminal 103. GUI characteristics, such as the width and height of the form, the number of colors available, or html options, may be dependent on the terminal on which the form is intended to be displayed. In one variant, the layout is adapted dynamically when displaying the resources available on the terminal of the data collector. The right column 1202 allows the operator editing the form to define properties associated with the entire form and / or each particular object. The adjustable properties depend on each object, for example each data entry field. In one embodiment, the choice of certain properties depends on the collection point. For example, the form for a weaver could allow the selection of a thread identifier, but not the selection of the color of that thread to be defined upstream. In the same way, entering a field can be optional at one collection point, but mandatory in another. It is also possible to set the validation criteria for the various fields in order to control their type and format. This validation can for example be carried out on the basis of the evaluation of regular expressions. The ontology, for example links in the semantic database 100, makes it possible to define to which attribute and to which class a field of the form is linked and to define which properties of which data input field are adjustable according to each collection point to which the form is intended.

The form created by the module for creating and editing form 107 advantageously integrates automatic access rights controls, for example to prevent a data collector from entering, modifying or reading data. for which it does not have the rights of writing, modification or reading necessary according to the ontology. These access rights can be verified by the form or preferably by the application server 101. Again, the access rights for each collection point and / or for each data collector are stored as semantic data using triplets in the database 100.

The formforms created using the form creation and editing module 107 are converted into semantic data by the REST interface and stored centrally as triplets in the database 100. The definition forms thus created can then be downloaded by the backend operator in the terminals 103 to be used also in offline mode. From this definition, the forms are preferably generated dynamically when they are used, in the terminal 103, or centrally.

The data collector preferably has a generic collection application downloaded and installed in its terminal; this generic application is independent of its business and the data it needs and can seize. It is therefore rarely updated. All data collectors in the field have in principle the same version of this application, or an application depending on each terminal or the operating system of this terminal. At the launch of the application, the data collector 103 is required to identify itself for example with a password in order to access the system and also to be able to communicate with the application server 101 in the operator backend.Once the user

authenticated, the operatorbackend is able to determine the data collector's business according to its permissions (specified within the backend operator). This makes it easy to determine at what collection point it belongs and what form it should use to enter data and to enter documents. Because the collection point is automatically identified, the data collector can generate the dynamic creation of a form based on the stored form definition and then start the creation of a new "document" to ensure the expected traceability of its actions / operations. .

The definition of the specific (or specialized) input form which has been parameterized by the operator 105 (for example a collaborator of the manufacturer 21) is thus transmitted to the client application executed in the terminal 103 and which dynamically generates a form based on this definition and presents it to the data collector. This is done

startup of the client application if a connection to the backend operator is possible. This form is stored locally in the terminal of the data collector and can be used even if this terminal is offline, that is to say not connected to the web. The data collector 103 can then enter the requested information, validate its work and transmit the data to the database 100 via the application server 101 and REST conversion interface. If the terminal is not connected to the web, the entered data is stored locally in the data collector terminal 103, and will be automatically synchronized with the database 100 at the next connection.

Periodically, the client application also role (in modeconné), to check for any updates of the forms on the "Backend operator" and if necessary download new versions.

We will now describe by way of example illustrated in Figures 1 to 10un example of creation of an ontology and implementation of the process of the invention applied to traceability in the textile industry, according to an example logistics organization suitable for this industry. Other ontologies could be defined for the manufacture of other products, or textile products according to another logistics; one of the interests of the invention lies precisely in the flexibility and the possibility of adapting it to different industries without having to reprogram the whole system.

In a first step illustrated schematically and by way of example in Figure 2, we define the transactions that may exist in a given industry, here during the manufacture of a piece of cotton textile. Reference 20 illustrates a distributor, for example a store chain, a textile brand, etc. This mark requires a manufacturer 21 to take charge of the design and production of

clothing. This manufacturer 21 in turn instructs a logistics manager 22 to organize the manufacture of the desired textiles, respecting a specification defined by the manufacturer 21. This logistics manager 22 will organize the logistics and distribution of work between various producers mandated for the occasion, for example a spinner 23, a knitter and / or weaver 24, a dyer 25, a ennobler 26, an embroiderer 27, a designer, etc. The spinner 23 itself acquires the yarn from a ginner 28 who buys the cotton from a cooperative 29 grouping several producers 30. The fabric thus manufactured under the coordination of the logistics manager 22 is delivered to the manufacturer 21 by a delivery company 31. One of the aims of the present invention is to ensure the traceability of the multiple operations involved in the manufacture of each piece of textile thus manufactured through this complex organization.

Figure 3 schematically illustrates the operations performed during the manufacture of a product, in this example a piece of textile. Everything starts from a command (order) 40 given for example by the distributor 20 or the manufacturer 21, and concerning a lot (batch) 41 of articles 42, for example a batch of 500 T-shirts. Each article has one or more parts 43, for example a body and two sleeves. An embroidery may be embroidered by an embroiderer 47. A pattern 44 may be printed, for example, in a screen 45. The parts 43 of the garment come from fabrics made from raw fabrics 49, the operations typically having a coloring obtained from the fabric. dyeing aid 53 performed by a dyer 54 using chemicals 56. The raw fabric 49 is made by a weaver 52 using cotton yarn 51 from a batch of cotton blends 57, created from batches of yarn 58 supplied by a ginner 59 using the cotton delivered by a cooperative 60 comprising the cotton producer 61. The reference 55 designates a certificate which may relate, for example, to the mixed cotton batch 57, to the color 50, etc., and issued for example by a certification body for the biological or equitable production of these elements.

FIG. 4 is a partial diagram illustrating the chaining between the constituent classes of the knowledge set relative to the

manufacture of each article. It also presents, by means of alphabetic symbols, the indicative order in which the objects are inserted into the base 100 at the time of filling by the data collector 103. previously described in connection with Figures 2 and 3 is modeled and also stored semantically using classes in the semantic database 100. The description of the ontology given here by way of example in Figure 4 in the particular case of the production of a textile product is only informative, and

probably incomplete; a real case may include a much larger number of classes and rules depending on the complexity of the work organization.

This data model constitutes an ontology, that is to say a semantic network based on the organization illustrated in Figure 3, and specific to the organization of work in the production of a particular product. The relations between the different classes are of semantic type and express for example that a document has a description, a designation, a unique identifier (id) and a path in a network (URI). A transaction has a delivery date, an order date, a company that orders, a company that is ordered, and an identifier, and so on.

On the basis of this model, the data entered by the operators can therefore be stored in a structured manner in the form of a set of tripletsRDFs (Resource Description Framework). Each triplet is an association of type (subject, predicate, object) in which the subject describes a resource (or instance of a class) to be described, the predicate a type of property applicable to that resource, and the object a datum or another resource. For example, a triplet can indicate that the command order_id <is made of> batch batchid, or that the transaction

transaction_id <contains> the document document_id. Another triplet may indicate that the cotton producer X is part of producer Y's cooperative. A third triplet may indicate that cotton lot Z comes from producer Y, etc.

Each class can be instantiated as a resource, and can preferably be identified by a URI identifier. Each predicate can also be identified by a URI. An object can be identified by a URI for example if it is itself a resource. Advantageously, he It is possible to access this data directly via a URI of the type http: // domain / onto / order / orderlD wheredomain is a particular domain in the internet. The database containing RDF triplets can be written in different syntaxes, including XML, or stored in different types of appropriate triplestores.

The definition of the classes according to FIG. 4 is organized so as to be able to respond efficiently to requests sent by an application or a web page on the mobile of the consumer, for example requests of the type "who is responsible for such a transaction.

transformation needed to manufacture such a product? Or "show me the organic cotton production certificate used in this article". Such requests may for example be formulated in SPARQL and used to underlie the data entry forms used on the mobile terminals of the data collectors 103, or the terminals of the frontend operators 105.

The ontology may also contain data properties corresponding to the attributes of the different classes. One of the strengths of this semantic model is the ability to define new rules-based relationships. For example, a rule could define that if the yarn is red and the fabric does not have a defined color, then the processedfabric color is red.

A similar data organization could theoretically be described by a relational database model. However, in a relational model, the different tables are linked by relations that must be defined in a fixed way during the design of the table. Creating new relationships, or editing existing relationships, typically involves rewriting a significant number of queries based on the relevant tables. On the other hand, multiple-to-many (n-to-n) relationships typically involve the creation of an intermediate table. Thus, in a relational model, the batches and the orders should for example be linked together by an additional OrdersandBatches table to associate different commands with different batches. Adaptations to the relational model are therefore necessarily complex and involve the creation, deletion and modification of tables and relationships, and the rewriting of queries. On the other hand, creating rules-based relationships is impossible or at least much less flexible than using an ontology-based database model.

An organization of the data in the database 100 using a semantic model based on an ontology allows greater flexibility and generally simpler adaptations to the organization of the production of a given product. For example, it is relatively easy to modify the ontology to express that a transformation of the product formerly done by a single operator is now broken down into two operations performed by two different operators, which can be at two different collection points. Only the semantic relations must be modified, without it being necessary to systematically create new tables. Queries can then be formulated with a powerful language such as SPARQL.

In one embodiment, the order identifiers (order_id) for identifying a particular command passed by a manufacturer or a logistics manager are linked by a chain of relationships to the identifiers corresponding to each process of

transformation, respectively to each material or component necessary for the manufacture of the product.

A first relationship allows the consumer 105 customer of a merchant 20 to be linked to the manufacturer 21. The consumer can for example scan with his mobile phone a label with a barcode, a 2D barcode or tag, linked to the product, to retrieve an identifier associated with the manufacturer 21. Figure 7 illustrates an example of scanned code. The identifier may for example contain a command identifier and a batch or item identifier. In order to obtain a product, the manufacturer 21, or the logistics manager 22, places a command to order a certain amount of wire. This thread has some properties, for example a size and a quality. The spinner 23 receives a command from the manufacturer 21 or from the

logistics manager 22, this command containing an order number which can then be associated with this thread. The spinner 23 uses this number for each data item that it stores in the database 100 by means of its terminal 103, in order to characterize its work.

In the same way, the manufacturer 21 or the logistics manager 22 sends a command to the dyer 25 with an order number; the information relating to the coloring operation of the articles concerned by this command are associated with this order number. of the

Orders of the same type are also sent, for example, to the knitter or weaver 25, to the ennobler 26, to the embroiderer 27, who use the order numbers associated with these various commands to characterize the data that they introduce into the database 100 From

Transformers 23 to 27 can themselves send orders, with their own order numbers, to subcontractors. For example, a spinner 23 produces rolls of yarn from batches created from cotton bales associated with an identifier and provided by a ginner. This organization makes it possible in particular to provide data relating to an article: from the cotton producer to the ginner who produces the cotton bales, the spinner who produces the yarn, the fabric produced, the coloring with a particular hue, and given chemicals, etc. The ontology therefore has relatively long chains of properties in order to go back to a cotton producer from an article number for example. This ontology notably uses a large number of relations of the type "made of" in the triplets: by exempleunecommand-> made of lots -> made of articles -> made of parts -> made of fabric made> made of fabric -> made of thread -> made of cotton lot etc. In order to simplify the ontology and the queries, a generic "fact" property can be defined to indicate that an individual can be made of different elements. For example, fabric made can be made of fabric AND color.

The use of a semantic database based on an ontology makes it possible in particular to generate, by means of the module for creating and editing the form 107, user interfaces for the terminals 103, 104, 105, in a simpler way. and more flexible than in the prior art. In particular, this organization enables the creation of forms for the mobile terminals or the other terminals used by the operators 103 to feed the database.

For this purpose, the definition of forms (including the graphical user interface, the list of data entry fields, their layout and format on the screen) is itself described using an ontology. to define the different collection points and which data can be edited at each collection point. For example, the ontology may make it possible to define that the collection point corresponding to the dyer 25 makes it possible to indicate the color of the fabric, and the chemicals used for coloring, but not the origin.

geographical area of cotton. This ontology is therefore directly dependent and linked to the ontology used to define the way in which the data are organized in the database 100. The collection points authorized for each piece of information are themselves stored in the database. 100 as RDF triplets. In one embodiment, these meta-data are stored as

subjects / objects of a triplet, and not as a predicate. The access rights of the users (who can enter, modify or read what) are preferably also stored in the form of RDF triplets, and controlled at the level of the graphical interface, for example by the application server 101. The ontology necessary for the definition of the forms is advantageously stored in the same triplestore as the necessary ontology. In a variant, if the ontology necessary for the definition of the forms slows too much the other requests, this ontology can be stored in another triplestore, for example in the same database 100 or in another database.

The module for creating and editing forms 107 uses the ontology relating to the definition of the forms to determine which properties can be modified by which operator 103 at which collection point, and how the corresponding data input fields must be displayed. For example, forms define html options and contain instructions to change the appearance and display of the form. An example of an input form created by means of this module is illustrated in FIG. 5, this form enables a field operator 103 to enter, by means of his terminal, information relating to his activity.

The diagram illustrated in Figure 6 is for the operator 105; it tracks the progress of a command. This module of the "Backend Operators" application allows the initial representative to check the status, progress and content of the various orders for his supply chain. This tool is like a dashboard providing different metrics useful for supply chain management.

As indicated, the ontology also determines the data collection points by the operators or data collectors 103. A collection point corresponds for example to a group of users exercising the same trade, but not necessarily in the same place. geographically or for the same company. However, it is also possible to define different access rights for different users at the same collection point. In the case of the organization example of the work illustrated in FIGS. 2 to 4, the data collection points include, for example:

The manufacturer 21

An ontology rule determines that the data collected at this point is used to create a new order (order) and certain transactions which will then have to be carried out by the manufacturer 21 and / or the logistics manager 22. The form creation of command made available to the manufacturer 21 therefore comprises, for example data input fields for the unique identifier of

order, the date of the order, the person in charge, the company to whom the order is given, and possibly links to documents relating to this order.

The logistics manager 22

The logistics manager 22 receives a form that allows him to complete the information relating to the manufacturer's order 21, to create a transaction (including the date, the associated documents), and to enter data relating to the fabric ordered. (including

wire identifier, the color of the treated fabric, etc.), the treatment of this fabric, the batches used (including article references), etc. The weaver 24

The weaver 24 is responsible for introducing information relating to the fabric that he provides, including, for example, the weight, the length, the qualitative information, the identifier of the threads used, and information relating to the transaction between the logistics manager 22 and this weaver.

The spinner 23 [00101] The spinner is responsible for introducing data relating to the manufacture of yarn from a cotton batch to the finished yarn. The data entered contain an identification of the lot of cotton used, and a qualitative and quantitative description of the yarn. These collection points and the data collected at each collection point are given by way of example only. In practice, in a more complex production system, other collection points can be defined, and other data can be entered at each collection point.

Claims

claims 1. A method of editing forms for entering different product traceability data collection points, comprising: defining an ontology (200) to define different properties of said product, and how these properties can be modified in different locations during the manufacture of said product;  creating a triplestore (100) based on said ontology, said triplestore containing for each product information relating to the manufacture of said product accessible by consumer terminals (105);  editing by means of a module for creating and editing forms (107) of a plurality of separate forms enabling data collectors (103) distributed at different collection points to collect data relating to the manufacture of said product ,  providing said forms to said data collectors (103), each data collector having access to a data form according to the type of collection point,  characterized in that  said form creation and editing module (107) determines on the basis of said ontology which information relating to said product can be edited by means of each form available at each collection point. 2. The method of claim 1, wherein the definition of said forms is based on triplets stored in the same triplestore as said data relating to the manufacture of the product. 3. The method of claim 1, wherein the definition of said forms is based on triplets stored in a triplestore different from that used to store said data relating to the manufacture of the product. The method of one of claims 1 to 3, wherein the access rights of said data collectors are stored as triplets, and verified by the application server (101). The method of one of claims 1 to 4, comprising:  installing in mobile terminals (103) said data collectors of a generic application:  identifying said data collector;  downloading into said mobile terminal the definition of a said specific form chosen according to said identification and created centrally with said form editor. The method of one of claims 1 to 5, comprising entering traceability data by means of said offline form, and synchronization of the data entered with the data stored in said triplestore when the terminal (103) used for the data entry is again on-line. 7. Management system (100, 101, 107) for traceability of products, comprising:  a triplestore (100) based on an ontology, said triplestore containing for each product information relating to the manufacture of said product accessible by consumer terminals (105) and;  a form creation and editing module (107) for editing a plurality of separate forms for data collectors (103) distributed at different collection points to collect data relating to the manufacture of said product, and making said forms available to said data collectors (103) by ensuring that each data collector has access to a data form depending on the type of collection point,  characterized in that  said form creation and editing module (107) determines on the basis of said ontology which information relating to said product can be edited by means of each form available at each collection point. 8. The system of claim 7, wherein the definition of said forms is based on triplets stored in the same triplestore as the data relating to the manufacture of said product. 9. The system of claim 7, wherein the definition of said forms is based on triplets stored in a triplestore different from that used to store data relating to the manufacture of said product. The system of one of claims 7 to 9, wherein the access rights of said data collectors are stored as triplets, and wherein said form creation and editing module (107) generates forms for controlling said access rights. 1 1. The system of one of claims 7 to 10, comprising:  means for installing in mobile terminals (103) said data collectors of a generic application:  means for identifying said data collector;  downloading means in said mobile terminal of a said specific form chosen according to said identification. 12. The system of one of claims 7 to 11, comprising means for synchronizing the data entered in offline mode by said data collectors and then transmitted to said system with the data stored in said triplestore. 13. The system of one of claims 7 to 11, comprising querying means for an operator to enter queries to query the data in said triplestore.