EP2807616A1 - Procédé d'édition de formulaires pour la saisie de données en différents points de collecte - Google Patents

Procédé d'édition de formulaires pour la saisie de données en différents points de collecte

Info

Publication number
EP2807616A1
EP2807616A1 EP13701980.8A EP13701980A EP2807616A1 EP 2807616 A1 EP2807616 A1 EP 2807616A1 EP 13701980 A EP13701980 A EP 13701980A EP 2807616 A1 EP2807616 A1 EP 2807616A1
Authority
EP
European Patent Office
Prior art keywords
data
product
forms
manufacture
triplestore
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP13701980.8A
Other languages
German (de)
English (en)
Inventor
David WERLEN
Bruno ALVES
Gilles CHERIX
Christian GAPANY
Michael Schumacher
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Icare Institut de Recherche en Informatique
Original Assignee
Icare Institut de Recherche en Informatique
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Icare Institut de Recherche en Informatique filed Critical Icare Institut de Recherche en Informatique
Publication of EP2807616A1 publication Critical patent/EP2807616A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/101—Collaborative creation, e.g. joint development of products or services
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • G06Q10/0875—Itemisation or classification of parts, supplies or services, e.g. bill of materials
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management

Definitions

  • the present invention relates to a method for editing forms for data entry at different data collection points.
  • 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.
  • 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.
  • 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.
  • WO201 1 124951 describes a process for the certification and traceability of organic food. The data from the various producers and
  • FR2776790 describes 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • EP1902606 discloses a method for graphically representing the processing chain of agricultural products, including the various locations of storage and processing.
  • US7184892 relates to another method for ensuring the traceability of agricultural products using unique product identifiers and intermediary identifiers.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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,
  • each data collector having access to a data form according to the type of collection point
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • the method of the invention is implemented using a computer system organized in a new way.
  • An example of a system An example of a system
  • the computer 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.
  • RDF store Resource Description Framework
  • 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.
  • 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.
  • REST RepresentationalState Transfer
  • 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.
  • JSON JavaScript Object Notation
  • 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
  • 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.
  • the system comprises several data collectors 103 at different collection points, different data collectors may have access rights.
  • 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.
  • the data collector 103 has a
  • the 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.
  • 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 104 dispose 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
  • 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
  • a 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • entering a field can be optional at one collection point, but mandatory in another.
  • 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.
  • 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
  • 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 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
  • 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.
  • 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.
  • This manufacturer 21 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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 simplifiedunecommand-> made of lots -> made of articles -> made of parts -> made of fabric made> made of fabric -> made of thread -> made of cotton lot etc.
  • 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.
  • 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.
  • this organization enables the creation of forms for the mobile terminals or the other terminals used by the operators 103 to feed the database.
  • the definition of forms is itself described using an ontology.
  • an ontology to define the different collection points and which data can be edited at each collection point.
  • 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.
  • the access rights of the users 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.
  • 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.
  • FIG. 6 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.
  • 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.
  • the data collection points include, for example:
  • 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
  • the logistics manager 22 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
  • 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 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Procédé d'édition de formulaires pour la saisie en différents points de collecte de données relatives à la traçabilité de produits, comportant: définition d'une ontologie pour définir différentes propriétés dudit produit, et comment ces propriétés peuvent être modifiées en différents endroits au cours de la fabrication dudit produit; création d'un triplestore (100) basé sur ladite ontologie, ledit triplestore contenant pour chaque produit des informations relatives à la fabrication dudit produit accessibles par des terminaux de consommateurs (104) et; édition au moyen d'un module de création et d'édition de formulaires (107) d'une pluralité de formulaires distincts permettant à des collecteurs de données (103) répartis en différents points de collecte de collecter des données relatives à la fabrication dudit produit, mise à disposition desdits formulaires auxdits collecteurs de données (103), chaque collecteur de données ayant accès à un formulaire de données selon le type de point de collecte. Le module de création et d'édition de formulaire (107) détermine sur la base de l'ontologie quelles informations relatives audit produit peuvent être éditées au moyen de chaque formulaire disponible en chaque point de collecte.

Description

Procédé d'édition de formulaires pour la saisie de données en différents points de collecte.
Domaine technique
[0001] La présente invention concerne un procédé permettant d'éditer des formulaires pour la saisie de données en différents points de collecte de données.
Etat de la technique
[0002] On connaît dans l'état de la technique des systèmes de gestion de données dans lesquelles des données sont collectées en différents points de collecte de données, stockées dans un système de gestion de base de données et mises à disposition d'utilisateurs sous forme de formulaires, d'états, de pages web etc. De tels systèmes sont par exemple utilisés pour garantir la traçabilité de produits agricoles et/ou manufacturés. Dans ce cas, différents producteurs ou intermédiaires impliqués dans la production du produit introduisent des données dans une base données mise à disposition du distributeur, du marchant et/ou du consommateur. [0003] Il existe par exemple un besoin pour un système de traçabilité de produits textiles. Par exemple, il serait souhaitable de permettre à un consommateur d'accéder à des données stockées dans une base de données alimentée par les différents producteurs impliqués dans la fabrication d'un habit, et de vérifier par exemple l'origine biologique et/ou équitable du coton impliqué, la ou les certifications de qualité attachées à différentes étapes de production, ou de s'assurer que ce vêtement a été produit en respectant des règles éthiques de production.
[0004] Ce besoin qui est parfaitement satisfait pour des produits obéissant à une logistique de fabrication relativement simple n'est satisfait que de manière insatisfaisante pour des produits impliquant une logistique de fabrication complexe. Une des difficultés vient de la nécessité d'adapter le système de saisie de données à la logistique mise en place par chaque fabricant pour chaque type de produit.
[0005] De nombreux produits industriels ou agricoles sont suivis au moyen d'un système de traçabilité basé sur le code EAN 128 (European Article Numbering) ou SSCC (code sériel pour les palettes) qui permet d'identifier et de tracer des produits et services dans la partie aval de la distribution. Cette identification à l'unité donne des informations à usage interne (type de produit, matière, taille, coloris, ...), mais ne concerne en général que la logistique de distribution, une fois le produit fabriqué, conditionné et expédié. Ces systèmes très répandus ne donnent pas d'information concernant l'origine des matières premières du produit, ou ses conditions de production.
[0006] WO201 1 124951 décrit un procédé pour la certification et la traçabilité de nourriture biologique. [0007] Les données provenant des différents producteurs et
intermédiaires sont encore le plus souvent collectées au moyen de formulaires papiers et de fax. La distribution de ces formulaires papiers, puis la saisie des données dans des systèmes informatiques, implique cependant un travail fastidieux et est source d'erreurs fréquentes. Il serait souhaitable de pouvoir saisir ces données depuis le lieu de collecte au moyen de terminaux portables, par exemple d'ordinateurs portables, de smartphones, de PDAs, de tablettes munies d'une connexion internet, etc.
[0008] Des solutions partielles existent dans ce but. FR2776790décrit un procédé pour assurer la traçabilité de produits alimentaires ; ce procédé met en œuvre des terminaux à disposition des producteurs et des intermédiaires, ainsi qu'une banque de données centrale conventionnelle. Les produits tracés portent un code d'identification, par exemple un code- barre.
[0009] US201 10016144est une autre demande de brevet décrivant un procédé pour assurer la traçabilité dans le domaine des céréales. Les données sont collectionnées par des capteurs ou par les agriculteurs dans une base de données à laquelle le consommateur peut se connecter via internet.
[0010] US7900835 concerne un procédé permettant d'assurer la traçabilité de produits agricoles à l'aide de formulaires électroniques ; le procédé inclut une vérification sur la base d'analyse des ingrédients, par exemple des analyses d'ADN.
[0011] US20070203724 concerne un procédé permettant d'assurer la traçabilité de produits agricoles à l'aide de formulaires électroniques remplis à différents échelons, et consultables via des pages web par le consommateur final.
[0012] US20020082982 décrit un procédé pour assurer la traçabilité dans l'industrie des céréales, et de vérifier l'usage de pesticides, de céréales modifiées génétiquement, de graines modifiées génétiquement, etc. Les informations sont introduites dans une base de données au moyen d'un palmtop ou d'un formulaire papier par l'agriculteur et par différentes entités externes, y compris des laboratoires.
[0013] US7440901 décrit un procédé pour assurer la traçabilité dans l'agriculture. Ce procédé implique la collecte de données au moyen de différents dispositifs, y compris des terminaux radioportables, tout au long de la chaîne de production. Un rapport est généré sous forme de graphique et indique notamment si le produit satisfait à des critères prédéfinis.
[0014] FR2813683décrit un procédé de gestion d'informations relatives au chemin de vie de produits alimentaires. Le procédé implique une gestion des droits de la part de plusieurs intermédiaires autorisés à écrire ou lire des données. Une solution similaire est décrite dans US20050027726.
[0015] EP1902606 décrit un procédé permettant de représenter graphiquement la chaîne de traitement de produits agricoles, notamment les différents lieux de stockage et de transformation. [0016] EP1498835décrit un procédé permettant d'assurer la traçabilité de produits agricoles à l'aide d'identificateurs uniques de produits et d'identificateurs d'intermédiaires.
[0017] US7184892 concerne un autre procédé permettant d'assurer la traçabilité de produits agricoles à l'aide d'identificateurs uniques de produits et d'identificateurs d'intermédiaires.
[0018] US20030182144 concerne un procédé de traçabilité dans l'agriculture, permet à différents acteurs tout au long de la chaîne de production d'introduire des données rassemblées au moyen d'un réseau. [0019] Marcelo Arenas et al. décrivent dans l'article du 30 août 2009 "Foundations of RDF databases, reasoning web semantic technologies for information Systems, la théorie des bases de données RDF ainsi qu'un langage d'interrogations de bases RDF. Une description similaire est aussi donnée dans Jorge Péerez et al., "QueryingSemantic Web Data with SPARQL", Department of Computer Science, Universidad de Chile, 1 5 JUIN 201 1 , qui concerne plus spécifiquement le langage d'interrogation SPARQL qui permet d'interroger des bases de données sémantiques RDF. Toutefois ces documents sont très généraux et ne fournissent aucune solution au problème de la traçabilité des différentes étapes de la fabrication d'un produit, ni de la multitude de formulaires qui doivent être créés et édités afin de permettre aux divers intervenants de collecter des informations relatives au produit en cours de fabrication.
[0020] Il existe donc un nombre important de solutions permettant de collecter des données à différents niveaux ou stades de la production d'un produit, et de mettre ces données à disposition du consommateur par exemple.
[0021] La réalisation d'un tel système de collecte de données en plusieurs points de collecte distribués au moyen de terminaux
informatiques de types différents nécessite cependant un travail considérable pour la création et l'édition des formulaires de saisie de données. Par exemple, les formulaires doivent être adaptés aux différents systèmes d'exploitation et aux formats et nombre de couleurs des écrans des différents terminaux employés par les collecteurs de données. D'autre part, le nombre de points de collecte ainsi que le type d'information qui doit être saisi en chaque point, ou qu'un utilisateur ou producteur a le droit d'introduire ou de modifier, dépend de l'organisation de la production du produit. Certains produits nécessitent peu d'opérations effectuées en un nombre limité de points de transformation ; dans ce cas, un nombre limité de points de collecte de données peut être défini pour saisir l'ensemble des données nécessaires à la traçabilité et auquel le consommateur ou utilisateur final veut avoir accès. D'autres produits passent par un nombre de transformations importants, effectuées en différents points de
traitement ; les informations pertinentes doivent alors être collectées en de nombreux points de collecte différents. [0022] La mise en place d'un système de traçabilité pour des produits impliquant une logistique de fabrication complexe est difficile. Par exemple, la production d'un produit textile en coton fait intervenir un nombre important d'intermédiaires et de sous-traitants très spécialisés, souvent répartis dans différents pays. Le fil de coton est souvent produit à partir de lots de coton provenant de différents producteurs et de
différentes origines, pour des raisons de qualité du fil. Du coton d'origine biologique est souvent mélangé avec du coton non biologique. Qui plus est, dans la même industrie chaque marque ou distributeurorganise la logistique de façon un peu différente. La certification d'origine biologique ou équitable est souvent faite sur la base de contrôles effectués par des organismes de certification qui effectuent des contrôles ponctuels, par exemple tous les six mois ou chaque année. Les certificats attribués sont difficiles à distribuer à tous les intermédiaires impliqués en aval de la chaîne de production, jusqu'au consommateur. Par conséquent, la traçabilité complète d'un produit constitueune tâche complexe, et les solutions actuelles ne permettent en pas au consommateur de s'assurer que toute la chaîne implique par exemple un travail équitable et biologique. De la même façon, il est difficile de calculer le coût carbone (empreinte C02) pour la production d'un produit industriel via de nombreux partenaires et sous-traitants. Le calcul de la consommation en eau constitue également une métrique importante vu son utilisation massive dans certains processus de fabrication, notamment en agriculture et pour les processus de fabrication de textile. [0023] Les systèmes mis en place dans l'art antérieur sont en général adaptés à une organisation de la production particulière, par exemple pour tracer la production d'un type de produit particulier dans une chaîne de production donnée. Il n'est en revanche pas possible d'adapter facilement un système de contrôle de traçabilité de produits existant à un autre produit, parce que la logistique de production est très différente et que les données à saisir sont différentes, ainsi que les points de collecte des données. Une telle adaptation implique notamment la création ou la modification de nombreux formulaires de saisie de données, ce qui constitue une opération particulièrement fastidieuse. [0024] Ces formulaires doivent aussi être adaptés lorsque la chaîne logistique d'un fabricant est réorganisée ou modifiée.
[0025] Les systèmes de traçabilité courants sont basés sur des bases de données relationnelles. Les données sont stockées sous forme de tables liées entre elles par des relations. L'organisation de la logistique de production et le type de requêtes souhaitées détermine dans une large mesure les relations entre ces tables. Par exemple, si une même société regroupe des activités de récolte de coton et des activités d'égrenage du fil, une seule table pourra être utilisée pour stocker l'ensemble des données relatives à cette société. Si l'organisation est modifiée et que l'égrenage est confié à une société indépendante des récoltants, il sera en général plus efficace de prévoir une table de récoltant, une table d'égreneurs, et une table intermédiaire producteurs-égreneurs pour indiquer quels égreneurs travaillent avec quels producteurs et permettre ainsi la création de relations multiple-à-multiple. [0026] Les modifications de la logistique de production impliquent donc souvent une modification de la structure de la base de données relationnelle utilisée pour stocker les données nécessaires à la traçabilité. Ce changement de structure implique à son tour que les requêtes d'accès à cette table doivent être réécrites, et que les formulaires de saisie de données basés sur ces requêtes soient refaits. Si la modification est importante, il est parfois plus simple de reprogrammer toute la base de données relationnelle. C'est notamment le cas si l'on veut adapter une base de données existante et destinée à la traçabilité d'un produit particulier (par exemple une pièce de textile) au contrôle de la traçabilité d'un autre produit (par exemple un composant automobile) obéissant à une logistique de production complètement différente. C'est fréquemment aussi le cas en cas de réorganisation de la chaîne logistique de fabrication.
Bref résumé de l'invention
[0027] Un but de la présente invention est de donc proposer un procédé d'édition de formulaires pour la saisie en différents points de collecte de données relatives à la traçabilité de produits qui soit exempt des limitations des procédés connus.
[0028] Un autre but de l'invention est de proposer un procédé d'édition de formulaires pour la saisie en différents points de collecte de données relatives à la traçabilité de produits qui permette de simplifier et
d'accélérer la génération de nouveaux formulaires et la modification de formulaires existants.
[0029] Un autre but de l'invention est de proposer un procédé d'édition de formulaires pour la saisie en différents points de collecte de données relatives à la traçabilité de produits qui permette de simplifier l'adaptation de formulaires aux modifications de l'organisation de la production du produit.
[0030] Selon l'invention, ces buts sont atteints notamment au moyen d'un procédé d'édition de formulaires pour la saisie en différents points de collecte de données relatives à la traçabilité de produits, y compris d'informations, comportant : définition d'une ontologie pour définir différentes propriétés dudit produit, et comment ces propriétés peuvent être modifiées en différents endroits au cours de la fabrication dudit produit ;
création d'une base de données centrale basée sur ladite ontologie, ladite base de données contenant pour chaque produit des informations de traçabilité accessibles par des consommateurs et relatives à la fabrication dudit produit ;
édition à distance au moyen d'un module de création et d'édition de formulaires d'une pluralité de formulaires distincts permettant à des collecteurs de données répartis en différents points de collecte de collecter des données relatives à la fabrication dudit produit,
mise à disposition desdits formulaires auxdits collecteurs, chaque collecteur de données ayant accès à un formulaire de données selon le type de point de collecte,
dans lequel ledit module de création et d'édition de formulaire détermine sur la base de ladite ontologie quelles propriétés dudit produit peuvent être éditées au moyen de chaque formulaire disponible en chaque point de collecte.
[0031] L'utilisation d'une ontologie permet de définir de façon très précise et flexible les propriétés du produit que l'on souhaite tracer, et comment ces propriétés peuvent être modifiées en différents endroits au cours de la fabrication du produit. Différentes ontologies peuvent être définies pour différents produits. L'ontologie peut aussi être adaptée aux modifications de l'organisation de la fabrication d'un même produit. [0032] Une base de données basée sur cette ontologie permet de stocker de manière centralisée les données relatives à la traçabilité du produit. Cette base de données peut utiliser par exemple des outils de base de données sémantique très performants pour créer et modifier des requêtes.
[0033] Des formulaires peuvent être édités, par exemple créés ou modifiés, au moyen d'un module de création et d'édition de formulaires. Ces formulaires déterminent sur la base de l'ontologie quelles propriétés de quel formulaire peuvent être saisies ou modifiées en quel point de collecte. Un service web unique peut par exemple être mis à disposition pour la création et l'édition de formulaires aux utilisateurs qui disposent des droits d'accès appropriés. [0034] Des bases de données sémantiques, par exemple basées ur RDF et employant une ontologie, sont connues dans l'art antérieur ; il est aussi connu de les peupler au moyen de formulaires. Toutefois, l'utilisation inattendue d'une telle ontologie pour définir différentes étapes de modification d'un produit au cours de sa fabrication permet de concevoir la collecte de données au moyen de formulaires décentralisés de manière entièrement nouvelle, en simplifiant considérablement la création et l'édition de formulaires de saisie de propriétés en différents points de collecte.
[0035] Les formulaires ainsi créés sont ensuite utilisés en différents points de collecte par des collecteurs de données répartis, afin de collecter des données relatives à la fabrication dudit produit,
[0036] Les données stockées dans la base de données sémantique centrale peuvent être mises à la disposition d'utilisateurs, par exemple de consommateurs, de marchants, d'importateurs, etc, afin d'accéder aux informations saisies par les opérateurs aux différents points de collecte de données. Les pages présenteront par exemple du texte explicatif sur les étapes de fabrication et la provenance des matières premières, ainsi que des illustrations. Les informations peuvent être présentées sous forme de table, de requête, d'état, de page web, de graphique, de données cartographiques, de photo, de film vidéo, de reproduction de certificat ou d'autres documents, etc. L'idée est de présenter différentes pages racontant l'histoire de la fabrication du produit en partant de la production et en remontant jusqu'au produit fini. Brève description des figures
[0037] Des exemples de mise en œuvre de l'invention sont indiqués dans la description illustrée par les figures annexées dans lesquelles :
[0038] La figure 1 illustre une vue schématique de l'infrastructure matérielle d'un système selon l'invention. [0039] La figure 2 illustre de manière schématique les transactions lors de la fabrication d'un produit, dans cet exemple une pièce de textile.
[0040] La figure 3 illustre de manière schématique les opérations effectuées lors de la fabrication d'un produit, dans cet exemple une pièce de textile. [0041] La figure 4 est un diagramme partiel qui illustre comment la logistique préalablement décrite en relation avec les figures 2 et 3 est modélisée et stockée de manière sémantique à l'aide de classes. Elle montre également au moyen de lettres l'ordre indicatif dans lequel sont instanciées les classes lors de la saisie des données au moyen de formulaires.. [0042] La figure 5 illustre un exemple de formulaire de saisie de données destiné à un collecteur de données et affiché sur un terminal mobile.
[0043] La figure 6 illustre une copie d'écran d'une application montrant des indicateurs provenant de la base de données sémantique, et pouvant permettre de requêter la base sémantique.. [0044] La figure 7 illustre une copie d'écran d'une application exécutée sur le terminal d'un consommateur ou utilisateur lors du scannage d'un code-barre sur un produit.
[0045] La figure 8 illustre une copie d'écran montrant un exemple d'informations provenant de la base de données sémantique et qui peuvent être affichées sur le terminal d'un consommateur ou utilisateur suite au scannage d'un code-barre sur un produit.
[0046] La figure 9 illustre une autre copie d'écran montrant un exemple de photo d'un producteur provenant de la base de données sémantique et qui peut être affichée sur le terminal d'un consommateur ou utilisateur suite au scannage d'un code-barre sur un produit.
[0047] La figure 10a-10bmontreune copie d'écran d'un exemple de module de création et d'édition de formulaire.
Exemple(s) de mode de réalisation de l'invention
[0048] Le procédé de l'invention est mis en œuvre à l'aide d'un système informatique organisé de façon nouvelle. Un exemple de système
informatique est illustré sur la figure 1 . Il comporte un système central, ou back end, formé dans cet exemple d'au moins un serveur de base de données 100 et d'au moins un serveur d'applications 101. Les serveurs peuvent être constitués par des machines physiques ou virtuelles, ou par des serveurs distribués dans une architecture de type cloud. Le serveur de base de données 100 comporte par exemple un serveur de base de données sémantique, par exemple un RDF store (Resource Description Framework), qui peut être accompagné par un serveur de base de données relationnel conventionnel pour stocker d'autres données. Une base de données de type triplestore peut être utilisée afin de stocker des données RDF.
[0049] Un serveur d'applications 101 assure l'interface entre les données stockées dans le serveur 100 et des utilisateurs externes 103, 104, 105 qui accèdent à ces données via le réseau internet 102.
[0050] La communicationentre la base de données sémantique 100 et le serveur d'applications 101 passeavantageusement par une interface. Dans un mode de réalisation avantageux, cette interface est réalisée au moyen d'un service web, par exemple un service REST (RepresentationalState Transfer) qui permet d'opérer une traduction des données entre les serveurs 100 et 101 et ainsi de séparer les données de leur représentation. Dans un mode de réalisation, le service REST sérialise les données
sémantiques de la base de données sémantique 100 en données, par exemple en données JSON (JavaScript Object Notation) ou XML, qui peuvent être utilisées par différentes applications du serveur d'applications 101, notamment pour construire des formulaires de saisie de données au moyen d'un éditeur de formulaires. L'interface REST fait aussi la
transformation inverse; elle reçoit des données JSON ou XML décrivant par exemple des formulaires et/ou des données saisies au moyen de ces formulaires, et les traduit en triplet en vue de mettre à jour la base de données sémantique 100.
[0051] L'utilisateur 103 est un opérateur front end (ou collecteur de données) qui saisit des données relatives à un produit en un point de collecte. Le collecteur de données est typiquement un producteur ou un autre opérateur ou intermédiaire impliqué dans la fabrication d'un produit. Dans un mode de réalisation fréquent, le système comporte plusieurs collecteurs de données 103 en différents points de collecte différents, différents collecteurs de données pouvant avoir des droits d'accès
différents. Le serveur d'application 101 génère des formulaires que le collecteur de données 103 peut afficher dynamiquement puis remplir sur son terminal, par exemple sur un ordinateur ou un terminal portable tel qu'un smartphone, une tablette, un palmtop, etc. Dans un mode de réalisation préférentiel, le collecteur de données 103 dispose d'un
smartphone ou d'une tablette comportant une application qui permet la saisie de données même lorsque le terminal de l'utilisateur est offline ; un mécanisme de synchronisation de données entre ce terminal et la base de données 100 permet de mettre à jour les données de chaque côté lorsque l'opérateur est à nouveau en ligne ou lorsque le collecteur de données 103 demande explicitement une telle synchronisation. Dans une applicationà la traçabilité de produits textiles, le collecteur de données 103 peut être par exemple un récoltant de coton, un teinturier, un atelier de tissage, etc.
[0052] L'utilisateur 104 est par exemple un consommateur qui souhaite accéder à des données concernant la traçabilité d'un article donné, par exemple des données relatives à la fabrication d'un T-shirt. Cet utilisateur 104dispose par exemple d'un smartphone ou autre terminal connecté à internet avec un appareil photo ou un lecteur de tags par exemple, qui lui permet de scanner un code-barres, un datamatrix, un tag électronique, etc, associé à un article, comme illustré sur la figure 7. Le code-barres,
datamatrix ou tag lié au produit est décodé, de préférence localement dans le smartphone au moyen d'une application dédiée, et employée dans une requête envoyée via internet 102 au serveur d'application 101 afin d'obtenir des informations complémentaires sur le produit scanné et stockées dans la base de données centrale 100 par les collecteurs de données 103. Les données peuvent être affichées et présentées sur le terminal portable du consommateur104 via une application dédiée ou générique orientéeinternet des objets et permettant de décoder un code- barre à une ou deuxdimensions (EAN, Datamatrix, QR-Code, etc). Les figures 8 et 9 présentent des exemples d'information de traçabilité qui peut être restituées par le terminal mobile 104 du consommateur, par exemple des informations de base sur l'article scanné (figure 8), une photo ou une carte de l'endroit où le coton nécessaire à la production a été récolté (figure 9), des informations relatives à d'autres étapes du processus de fabrication, des certificats de conformité, etc.
[0053] L'utilisateur 105 est un utilisateur professionnel, par exemple un opérateur ou administrateur de base de données, ou un opérateur autorisé à introduire des requêtes plus complexes au moyen d'un terminal tel qu'un ordinateur, ou éventuellement un terminal mobile. L'opérateur 105 peut par exemple introduire des requêtes à l'aide d'une application de
requêtage illustrée sur la figure 6. Il peut de préférence aussi accéder à un tableau de bord pour suivre un article ou un lot d'article tout au long de la fabrication, ou pour suivre et contrôler les activités d'un producteur.
L'opérateur 105 peut aussi modifier l'ontologie qui sous-tend la base de données 100, et créer au moyen d'un ordinateur ou d'un terminal mobile des formulaires de saisie de données utilisés par les collecteurs de données (producteurs) 103 et par les consommateurs 104. [0054] Différentes applications logicielles nouvelles permettent au procédé de l'invention de s'exécuter dans cette infrastructure.
L' « opérateur backend » est une application exécutée de façon centrale afin de gérer les données collectées depuis différents points de collecte répartis. L' « opérateur front end » est une application mobile, par exemple une application exécutée sur un smartphone ou une tablette, ou une application web utilisée par les producteurs- collecteurs de données 103 en différents points de collecte pour saisir les données et les synchroniser avec celles de la base de données centrale. Le "Backend B2B" est une base de données (ou base de connaissance) qui contient l'information saisie par les collecteurs de données 103 et permet le data mining. Cette base de données peut aussi être répartie et le terme de base de données centrale signifie simplement que la totalité des informations peuvent être accédées à une seule adresse logique. Le "Frontend B2B" est une interface
utilisateur, par exemple sous forme d'application ou de page web dynamique, qui permet à un utilisateur 105 d'accéder à des informations stockées dans la base 100 sous forme de tableau de bord ou via des requêtes.
[0055] La référence 107 désigne un module de création et d'édition de formulaires (ou concepteur visuel de formulaires) qui permet à l'opérateur 105,par exemple, d'éditer les formulaires spécialisés et l'interface graphique mis à disposition des collecteurs de données 103 au travers de l'opérateur backend 101 . Comme mentionné, le module de création et d'édition de formulaire 107 peut avantageusement être réalisé comme application résidant dans le serveur d'application 101 , et communiquer avec la base de données 100 au moyen d'une interface de type REST, par exemple, afin de convertir les données saisies par les formulaires et la structure des formulaires eux-mêmes en triplets stockés dans cette base 100, et vice- versa. [0056] Le module de création et d'édition de formulaires 107 comporte par exemple une interface graphique web qui permet à l'opérateur 105 de créer et de mettre en page les différents formulaires de saisie nécessaires aux différents points de collecte de données afin de permettre aux collecteurs de données 103 de saisir des données. Le module de création et d'édition de formulaires peut être utilisé par un utilisateur sans formation informatique particulière et qui n'a pas besoin d'être un informaticien pour concevoir ou modifier la définition des formulaires. Il peut être exécuté sur un ordinateur ou sur un terminal mobile.
[0057] Un exemple d'interface 102offerte à l'opérateur 105 par le module 107 est illustré sur la figure 10. La colonne de gauche 1200 inclut une boîte à outil (toolbox) qui permet à l'opérateur de sélectionner des objets à placer sur le formulaire illustré sur la partie centrale 1201 . Les objets sélectionnâmes peuvent comprendre par exemple des champs de saisie de données. Les objets sélectionnables incluent aussi par exemple des champs texte fixe, multi-lignes et riche, des champs de type date, des listes de données simples ou multiples et éventuellement d'autres objets comme des éléments graphiques, des images etc. Dans un mode de réalisation, la liste de champs de saisie de données à dispositionpeut dépendredu point de collecte pour lequel le formulaire est destiné, et éventuellement de l'opérateur-collecteur de données 103 particulier si différents collecteurs de données (ou groupe de collecteurs de données) au même point de collecte possèdent des droits d'accès différents. La liste des champs de saisie de données dépend donc de l'organisation logistique de production telle quemodélisée dans la base de données sémantique par une ontologie et traduite par l'interface REST.
[0058] La partie centrale 1201 permet à l'opérateur 105 qui crée un formulaire de disposer les différents objets sélectionnés dans la colonne de gauche 1200 sur l'interface graphique qui est destinée à être affichée sur le terminal du collecteur de données 103. Les caractéristiques de l'interface graphique, par exemple la largeur et la hauteur du formulaire, le nombre de couleurs disponibles, ou des options html, peuvent être dépendantes du terminal sur lequel le formulaire est destiné à être affiché. Dans une variante, la mise en page est adaptée dynamiquement lors de l'affichage aux ressources à disposition sur le terminal du collecteur de données. [0059] La colonne de droite 1202 permet à l'opérateur qui édite le formulaire de définir des propriétés associées à l'ensemble du formulaire et/ou à chaque objet particulier. Les propriétés ajustables dépendent de chaque objet, par exemple de chaque champ de saisie de données. Dans un mode de réalisation, le choix de certaines propriétés dépend du point de collecte. Par exemple, le formulaire destiné à un tisserand pourrait permettre la sélection d'un identificateur de fil, mais pas la sélection de la couleur de ce fil qui doit être définie en amont. De la même façon, la saisie d'un champ peut être facultative en un point de collecte, mais obligatoire dans un autre. Il est également possible de paramétrer les critères de validation des différents champs afin d'en contrôler le type et le format. Cette validation peut par exemple être effectuée sur la base de l'évaluation d'expressions régulières. L'ontologie, par exemple des liaisons dans la base de données sémantique 100, permet de définir à quel attribut et à quelle classe est lié un champ du formulaire et de définir quelles propriétés de quel champ de saisie de données sont ajustables en fonction de chaque point de collecte auquel le formulaire est destiné.
[0060] Le formulaire créé par le module de création et d'édition de formulaire 107 intègre avantageusement des contrôles de droits d'accès automatique, afin par exemple d'interdire à un collecteur de données la saisie, la modification ou la lecture de données pour lesquels il ne dispose pas des droits d'écriture, de modification ou de lecture nécessaires en fonction de l'ontologie. Ces droits d'accès peuvent être vérifiés par le formulaire ou de préférence par le serveur d'application 101 . A nouveau, les droits d'accès pour chaque point de collecte et/ou pour chaque collecteur de données sont stockés sous forme de données sémantiques à l'aide de triplets dans la base de données 100.
[0061] La structuredes formulaires créés à l'aide du module de création et d'édition de formulaire 107 est convertie en données sémantiques par l'interface REST et enregistrée de façon centralisée sous forme de triplets dans la base de données 100. La définition des formulaires ainsi créés peut alors être téléchargéepar l'opérateur backenddans les terminaux 103 pour pouvoir être utilisée également en mode offline. A partir de cette définition, les formulaires sont de préférence générés dynamiquement lors de leur utilisation, dans le terminal 103, ou de façon centrale.
[0062] Le collecteur de donnéesdispose de préférence d'une application de collecte générique téléchargée et installée dans son terminal ; cette application générique est indépendante de son métier et des données qu'il doit et peut saisir. Elle est donc rarement mise à jour. L'ensembledes collecteurs de données sur le terrain possèdent en principe la même version de cette application, ou une application dépendant de chaque terminal ou du système d'exploitation de ce terminal. [0063] Au lancement de l'application, le collecteur de données 103 est prié de s'identifier par exemple avec un mot de passe afin d'accéder au système et pouvoir également rentrer encommunication avec le serveur d'applications 101 dans l'opérateur backend.Une fois l'utilisateur
authentifié, l'opérateurbackendest capable de déterminer le métier du collecteur de données en fonction de ses autorisations (spécifiées au sein del'opérateur backend). Il est ainsi possible de déterminer aisément à quel point de collecte il appartient et quel formulaire il doit utiliser pour saisir des données et introduire des documents. Le point de collecte étant identifié automatiquement, le collecteur de données peut générer la création dynamique d'un formulaire basé sur la définition de formulaire stockée puis démarrer lacréation d'un nouveau "document" en vue d'assurer la traçabilité escomptée de sesactions / opérations.
[0064] La définition du formulaire de saisie spécifique (ou spécialisé) qui a été paramétréepar l'opérateur 105 (par exemple un collaborateur du fabricant 21 ) est ainsi transmise à l'application cliente exécutée dans le terminal 103 et qui génère dynamiquement un formulaire basé sur cette définition et le présente au collecteur de données. Ceci s'effectue
audémarrage de l'application cliente si une connexion àl'opérateur backend estpossible. Ce formulaire est stocké localement dans le terminal du collecteur de données et pourra être utilisé même si ce terminal est offline, c'est-à-dire non connecté au web. [0065] Le collecteur de données 103 peut alors saisir l'information demandée, valider son travail et transmettre les données à la base de données 100 via le serveur d'applications 101 et l'interface de conversion REST. Si le terminal n'est pas connecté au web, les données saisies sont stockées localement dans le terminal du collecteur de données 103, et seront synchronisées automatiquement avec la base de données 100 à la prochaine connexion.
[0066] De manière périodique, l'application cliente a également pour rôle (en modeconnecté), de vérifier les éventuelles mises à jour des formulaires sur le "opérateur Backend " et au besoin télécharger les nouvelles versions.
[0067] Nous allons maintenant décrire à titre d'exemple illustré sur les figures 1 à 10un exemple decréation d'une ontologie et de mise en œuvre du procédé de l'invention appliqué à la traçabilité dans l'industrie du textile, selon un exemple d'organisation logistique convenant à cette industrie. D'autres ontologies pourraient être définies pour la fabrication d'autres produits, ou de produits textiles selon une autre logistique ; un des intérêts de l'invention réside précisément dans la flexibilité et la possibilité de l'adapter à différentes industries sans devoir reprogrammer tout le système.
[0068] Dans une première étape illustrée schématiquement et à titre d'exemple sur la figure 2, on définitles transactions qui peuvent exister dans une industrie donnée, ici lors de la fabrication d'une pièce de textile en coton. [0069] La référence 20 illustre un distributeur, par exemple une chaîne de magasin, une marque de textile etc. Cette marque demande à un fabricant 21 de se charger de la conception et de la réalisation de
vêtements. Ce fabricant 21 charge à son tour un responsable de la logistique 22 d'organiser la fabrication des textiles désirés, en respectant un cahier des charges définis par le fabricant 21. Ce responsable de la logistique 22 va organiser la logistique et la répartition du travail entre différents producteurs mandatés pour l'occasion, par exemple un fileur 23, un tricoteur et/ou tisserand 24, un teinturier 25, un ennoblisseur 26, un brodeur 27, un couturier, etc. Le fileur 23 lui-même se procure le fil auprès d'un égreneur 28 qui achète le coton auprès d'une coopérative 29 regroupant plusieurs producteurs 30. Le textile ainsi fabriqué sous la coordination du responsable de la logistique 22 est livré au fabricant 21 par une société de livraison 31 . Un des buts de la présente invention est d'assurer la traçabilité des multiples opérations impliquées dans la fabrication de chaque pièce de textile ainsi fabriquées à travers cette organisation complexe.
[0070] La figure 3 illustre de manière schématique les opérations effectuées lors de la fabrication d'un produit, dans cet exemple une pièce de textile. Tout part depuis une commande (ordre) 40 donné par exemple par le distributeur 20 ou le fabricant 21 , et concernant un lot (batch) 41 d'articles 42, par exemple un lot de 500 T-shirts. Chaque article comporte une ou plusieurs parties 43, par exemple un corps et deux manches. Une broderie peut être brodée par un brodeur 47. Un motif 44 peut être imprimé par exemple chez un sérigraphe 45. Les parties 43 du vêtement proviennent de tissus fabriqués 48 à partir de tissus bruts 49, les opérations comportant typiquement une coloration 50 obtenue à l'aide de teinture 53 effectuée par un teinturier 54 en employant des produits chimiques 56. Le tissu brut 49 est fabriqué par un tisseur 52 à l'aide de fil de coton 51 provenant d'un lot de mélanges de coton 57, créé à partir de lots de fil 58 fournis par un égreneur 59 à l'aide du coton livré par une coopérative 60 comportant le producteur de coton 61 . La référence 55 désigne un certificat qui peut se rapporter par exemple au lot mélangé de coton 57, à la couleur 50 etc, et délivré par exemple par un organisme de certification de la production biologique ou équitable de ces éléments.
[0071] La figure 4 est un diagramme partiel qui illustre le chaînage entre les classes constituantes de l'ensemble de connaissance relatif à la
fabrication de chaque article. Elle présente également, à l'aide de symboles alphabétiques, l'ordre indicatif dans lequel les objets sont insérés dans la base 100 au moment du remplissage par le collecteur de données 103. La logistique préalablement décrite en relation avec les figures 2 et 3 est modélisée et également stockée de manière sémantique à l'aide de classes dans la base de données sémantique 100. La description de l'ontologie donnée ici à titre d'exemple sur la figure 4 dans le cas particulier de la production d'un produit textile est uniquement informative, et
probablement incomplète ; un cas réel pourra comprendre un nombre de classes et de règles nettement plus importants selon la complexité de l'organisation du travail.
[0072] Ce modèle de données constitue une ontologie, c'est-à-dire un réseau sémantique basé sur l'organisation illustrée sur la figure 3, et propre à l'organisation du travail dans la production d'un produit particulier. Les relations entre les différentes classes sont de type sémantique et expriment par exemple qu'un document a une description, une désignation, un identificateur (id) unique et un chemin d'accès dans un réseau (URI). Une transaction a une date de livraison, une date de commande, une société qui commande, une société à qui l'on commande, et un identificateur, etc.
[0073] Sur la base de ce modèle, les données saisies par les opérateurs peuvent donc être stockées de manière structurée sous la forme d'un ensemble de tripletsRDFs (Resource Description Framework). Chaque triplet est une association de type (sujet, prédicat, objet) dans laquelle le sujet décrit une ressource (ou instance d'une classe) à décrire, le prédicat un type de propriété applicable à cette ressource, et l'objet une donnée ou une autre ressource. Par exemple, un triplet peut indiquer que la commande ordre_id<est fait du> batch batchid, ou que la transaction
transaction_id<contient> le document document_id. Un autre triplet peut indiquer que le producteur de coton X fait partie de la coopérative du producteur Y. Un troisième triplet peut indiquer que le lot de coton Z provient du producteur Y, etc.
[0074] Chaque classe peut être instanciée comme ressource, et peut de préférence être identifiée par un identificateur URI. Chaque prédicat peut également être identifié par une URI. Un objet peut être identifié par une URI par exemple s'il constitue lui-même une ressource. Avantageusement, il est possible d'accéder directement à ces données via une adresse URI du type http://domain/onto/order/orderlD oùdomain désigne un domaine particulier dans internet. [0075] La base de données contenant des triplets RDF peut être écrite en différentes syntaxes, y compris en XML, ou stockée dans différents types de triplestores appropriés.
[0076] La définition des classes selon la figure 4 est organisée pour permettre de répondre efficacement à des requêtes envoyées par une application ou une page web sur le mobile du consommateur, par exemple des requêtes du type « qui est responsable de telle opération de
transformation nécessaire à la fabrication de tel produit ? » ou « montre- moi le certificat de production biologique du coton employé dans cet article ». De telles requêtes peuvent par exemple être formulées en SPARQL et utilisées pour sous-tendre les formulaires de saisie de données utilisés sur les terminaux mobiles des collecteurs de données 103, ou les terminaux des opérateurs de frontend 105.
[0077] L'ontologie peut aussi contenir des propriétés de données correspondant aux attributs des différentes classes. Une des forces de ce modèle sémantique est la possibilité de définir de nouvelles relations basées sur des règles. Par exemple, une règle pourrait définir que si le fil (« yarn ») est rouge et que le tissu (« fabric ») n'a pas de couleur définie, alors la couleur du tissu travaillé (« processedfabric ») est rouge.
[0078] Une organisation de données similaire pourrait théoriquement être décrite par un modèle de base de données relationnelle. Toutefois, dans un modèle relationnel, les différentes tables sont liées par des relations qui doivent être définies de manière fixe lors de la conception de la table. La création de nouvelles relations, ou l'édition de relations existantes, implique en général de réécrire un nombre important de requêtes basées sur les tables concernées. D'autre part, des relations de type multiple-à-multiple (n-to-n) impliquent en général la création d'une table intermédiaire. Ainsi, dans un modèle relationnel, les lots (batches) et les commandes (orders) devraient par exemple être liés entre eux par une table additionnelle OrdersandBatches pour associer différentes commandes avec différents batches. Des adaptations au modèle relationnel sont donc nécessairement complexes et impliquent la création, suppression et modification de tables et de relations, et la réécriture des requêtes. D'autre part, la création de relations basées sur des règles est impossible ou en tout cas beaucoup moins flexible qu'en employant un modèle de base de données basé sur une ontologie.
[0079] Une organisation des données dans la base 100 à l'aide d'un modèle sémantique basée sur une ontologie permet une plus grande flexibilité et des adaptations généralement plus simples à l'organisation de la production d'un produit donné. Par exemple, il est relativement facile de modifier l'ontologie pour exprimer qu'une transformation du produit autrefois effectuée par un seul opérateur est dorénavant décomposée en deux opérations effectuées par deux opérateurs distincts, qui peuvent se trouver en deux points de collecte différents. [0080] Seules les relations sémantiques doivent être modifiées, sans qu'il soit nécessaire de systématiquement créer de nouvelles tables. Des requêtes peuvent ensuite être formulées avec un puissant langage tel que SPARQL.
[0081] Dans un mode de réalisation, les identificateurs de commande (order_id)permettant d'identifier unecommande particulière passée par un fabricant ou un responsable de la logistique sont liés par une chaîne de relations aux identificateurs correspondant à chaque processus de
transformation, respectivement à chaque matière ou composant nécessaire à la fabrication du produit.
[0082] Une première relation permet au consommateur 105 client d'un marchand 20 d'être lié au fabricant 21 . Le consommateur peut par exemple scanner avec son téléphone mobile une étiquette avec un code barre, un code-barres 2D ou un tag, lié au produit, pour récupérer un identificateur associé au fabricant 21 .La figure 7 illustre un exemple de code scanné. L'identificateur peut par exemple contenir un identificateur de commande et un identificateur de lot ou d'article. [0083] Afin d'obtenir un produit, le fabricant 21 , ou le responsable logistique 22, place unecommande pour commander une certaine quantité de fil. Ce fil a certaines propriétés, par exemple une taille et une qualité. Le fileur 23 reçoit unecommande depuis le fabricant 21 ou depuis le
responsable logistique 22, cettecommande contenant un numéro de commande qui peut ensuite être associé à ce fil. Le fileur 23 utilise ce numéro pour chaque donnée qu'il stocke dans la base de données 100 au moyen de son terminal 103, afin de caractériser son travail.
[0084] De la même façon, le fabricant 21 ou le responsable logistique 22 envoie unecommande au teinturier 25 avec un numéro de commande; les informations relatives à l'opération de coloration des articles concernés par cette commande sont associées à ce numéro de commande. Des
commandes du même type sont aussi envoyées par exemple au tricoteur ou tisserand 25, à l'ennoblisseur 26, au brodeur 27, qui utilisent les numéros de commande associés avec ces différentes commandes pour caractériser les données qu'ils introduisent dans la base de données 100. Des
transformateurs 23 à 27 peuvent eux-mêmes envoyer des commandes, avec leurs propres numéros de commande, à des sous-traitants. Par exemple, un fileur 23 produit des rouleaux de fil à partir de lots créés à partir de balles de coton associées à un identificateur et fournies par un égreneur. [0085] Cette organisation permet notamment de fournir des données relatives à un article : depuis le producteur de coton vers l'égreneur qui produit les balles de coton, le fileur qui produit le fil, le tissu fabriqué, la coloration avec une teinte particulière et des produits chimiques donnés, etc. L'ontologie comporte donc des chaînes de propriétés relativement longues afin de remonter à un producteur de coton depuis un numéro d'article par exemple. Cette ontologie emploie notamment un nombre important de relations de type « fait de » dans les triplets : par exempleunecommande-> faite de lots -> fait d'articles -> fait de parts -> fait de tissu fabriqués > faits de tissu -> fait de fil -> fait de lot de coton etc. Afin de simplifier l'ontologie et les requêtes, une propriété « fait de » générique peut être définie pour indiquer qu'un individu peut être fait de différents éléments. Par exemple, un tissu fabriqué peut être fait d'un tissu ET d'une teinte.
[0086] L'utilisation d'une base de données sémantique basée sur une ontologie permet notamment de générer au moyen du module de création et d'édition de formulaire 107 des interfaces utilisateur pour les terminaux 103, 104, 105, de façon plus simple et plus flexible que dans l'art antérieur. En particulier, cette organisation permet defaciliter la création de formulaires pour les terminaux mobiles ou les autres terminaux utilisés par les opérateurs 103 afin d'alimenter la base de données.
[0087] Dans ce but, la définition des formulaires (notamment l'interface graphique utilisateur, la liste des champs de saisie de données, leur disposition et format sur l'écran) est elle-même décrite à l'aide d'une ontologie pour définir les différents points de collecte et quelles données peuvent être éditées en chaque point de collecte. Par exemple, l'ontologie peut permettre de définir que le point de collecte correspondant au teinturier 25 permet d'indiquer la couleur du tissu, et les produits chimiques employés pour la coloration, mais pasla provenance
géographique du coton. Cette ontologie est donc directement dépendante et liée à l'ontologie employée pour définir la manière dont les données sont organisées dans la base de données 100. [0088] Les points de collecte autorisés pour chaque information sont eux-mêmes stockés dans la base de données 100 comme triplets RDF. Dans un mode de réalisation, ces méta-données sont stockées comme
sujets/objets d'un triplet, et non pas comme prédicat. Les droits d'accès des utilisateurs (qui peut saisir, modifier ou lire quoi) sont de préférence également stockés sous forme de triplets RDF, et contrôlés au niveau de l'interface graphique, par exemple par le serveur d'application 101 . [0089] L'ontologie nécessaire à la définition des formulaires est avantageusement stockée dans le même triplestore que l'ontologie nécessaire. Dans une variante, si l'ontologie nécessaire à la définition des formulaires ralentit trop les autres requêtes, cette ontologie peut être stockée dans un autre triplestore, par exemple dans la même base de données 100 ou dans une autre base de données.
[0090] Le module de création et d'édition de formulaires 107 utilise l'ontologie relative à la définition des formulaires pour déterminer quelles propriétés peuvent être modifiées par quel opérateur 103 en quel point de collecte, et comment les champs de saisie de données correspondant doivent être affichés. Les formulaires définissent par exemple des options html et contiennent des instructions visant à modifier l'apparence et l'affichage du formulaire. Un exemple de formulaire de saisie créé au moyen de ce module est illustré sur la figure 5, ce formulaire permet à un opérateur 103 sur le terrain de saisir, au moyen de son terminal, des informations relative à son activité.
[0091] Le diagramme illustré sur la figure 6 est à l'intention de l'opérateur 105 ; il permet de suivre la progression d'unecommande. Ce module de l'application " Backend opérateurs" permet au mandataire initial de vérifier l'état, l'avancement et le contenu des différentes commandes pour sa chaîne d'approvisionnement. Cet outil se présente comme un tableau de bord (dashboard) apportant différentes métriques utiles pour le pilotage de la chaîne d'approvisionnement.
[0092] Comme indiqué, l'ontologie détermine aussi les points de collecte des informations par les opérateurs ou collecteurs de données 103. Un point de collecte correspond par exemple à un groupe d'utilisateurs exerçant le même métier, mais pas nécessairement au même endroit géographique ni pour la même compagnie. Il est toutefois aussi possible de définir différents droits d'accès pour différents utilisateurs au même point de collecte. [0093] Dans le cas de l'exemple d'organisation du travail illustré sur les figures 2 à 4, les points de collecte de données incluent par exemple :
[0094] Le fabricant 21
[0095] Une règle de l'ontologie détermine que les données collectées en ce point sont utilisées pour créer une nouvelle commande(ordre) et certaines transactions qui devront ensuite être effectuées par le fabricant 21 et/ou le responsable logistique 22. Le formulaire de création de commande mis à disposition du fabricant 21 comporte donc par exemple des champs de saisie de données pour l'identificateur unique de
commande, la date de la commande, le responsable, la société à qui la commande est donnée, et éventuellement des liens vers des documents relatifs à cette commande.
[0096] Le responsable logistique 22
[0097] Le responsable logistique 22 reçoit un formulaire qui lui permet de compléter les informations relatives à la commande du fabricant 21 , de créer une transaction (y compris la date, les documents associés), et d'introduire des données relatives au tissu commandé (y compris
l'identificateur du fil, la couleur du tissu traité, etc), au traitement de ce tissu, aux lots employés (y compris les références d'article), etc. [0098] Le tisserand 24
[0099] Le tisserand 24 est responsable d'introduire des informations relatives au tissu qu'il fournit, y compris par exemple le poids, la longueur, des informations qualitatives, l'identificateur des fils employés, et des informations relatives à la transaction entre le responsable logistique 22 et ce tisserand.
[00100] Le fileur 23 [00101] Le fileur est responsable d'introduire des données relatives à la fabrication du fil depuis un lot de coton jusqu'au fil fini. Les données introduites contiennent une identification du lot de coton employé, et une description qualitative et quantitative du fil [00102] Ces points de collecte et les données collectées en chaque point de collecte sont indiqués à titre d'exemple uniquement. En pratique, dans un système de production plus complexe, d'autres points de collecte peuvent être définis, et d'autres données peuvent être saisies en chaque point de collecte.

Claims

Revendications
1 . Procédé d'édition de formulaires pour la saisie en différents points de collecte de données relatives à la traçabilité de produits, comportant : définition d'une ontologie (200) pour définir différentes propriétés dudit produit, et comment ces propriétés peuvent être modifiées en différents endroits au cours de la fabrication dudit produit ;
création d'un triplestore(100) basé sur ladite ontologie, ledit triplestore contenant pour chaque produit des informations relatives à la fabrication dudit produit accessibles par des terminaux de consommateurs (105);
édition au moyen d'un module de création et d'édition de formulaires (107) d'une pluralité de formulaires distincts permettant à des collecteurs de données(103) répartis en différents points de collecte de collecter des données relatives à la fabrication dudit produit,
mise à disposition desdits formulaires auxdits collecteurs de données (103), chaque collecteur de données ayant accès à un formulaire de données selon le type de point de collecte,
caractérisé en ce que
ledit module de création et d'édition de formulaire (107) détermine sur la base de ladite ontologie quelles informations relatives audit produit peuvent être éditées au moyen de chaque formulaire disponible en chaque point de collecte.
2. Le procédé de la revendication 1, dans lequel la définition desdits formulaires est basée sur des triplets stockés dans le même triplestore que les dites données relatives à la fabrication du produit.
3. Le procédé de la revendication 1, dans lequel la définition desdits formulaires est basée sur des triplets stockés dans un triplestore différent de celui employé pour stocker les dites données relatives à la fabrication du produit.
4. Le procédé de l'une des revendications 1 à 3, dans lequel les droits d'accès des dits collecteurs de données sont stockés sous forme de triplets, et vérifiés par le serveur d'application (101 ).
5. Le procédé de l'une des revendications 1 à 4, comprenant :
installation dans des terminaux mobiles (103) desdits collecteurs de données d'une application générique :
identification dudit collecteur de données ;
téléchargement dans ledit terminal mobile de la définition d'un dit formulaire spécifique choisi en fonction de ladite identification et créé de manière centralisée avec ledit éditeur de formulaire.
6. Le procédé de l'une des revendications 1 à 5, comprenant la saisie de données de traçabilité au moyen dudit formulaire offline, et la
synchronisation des données saisies avec les données stockées dans ledit triplestore lorsque le terminal (103) utilisé pour la saisie des données est à nouveau on-line.
7. Système (100, 101 , 107) de gestion pour la traçabilité de produits, comprenant :
un triplestore (100) basé sur une ontologie, ledit triplestore contenant pour chaque produit des informations relatives à la fabrication dudit produit accessibles par des terminaux de consommateurs (105) et ;
un module de création et d'édition de formulaires (107) permettant d'éditer une pluralité de formulaires distincts destinés à des collecteurs de données (103) répartis en différents points de collecte pour collecter des données relatives à la fabrication dudit produit, et de mettre lesdits formulaires à disposition desdits collecteurs de données (103) en assurant que chaque collecteur de données a accès à un formulaire de données dépendant du type de point de collecte,
caractérisé en ce que
ledit module de création et d'édition de formulaire (107) détermine sur la base de ladite ontologie quelles informations relatives audit produit peuvent être éditées au moyen de chaque formulaire disponible en chaque point de collecte.
8. Le système de la revendication 7, dans lequel la définition desdits formulaires est basée sur des triplets stockés dans le même triplestore que les données relatives à la fabrication du dit produit.
9. Le système de la revendication 7, dans lequel la définition desdits formulaires est basée sur des triplets stockés dans un triplestore différent de celui employé pour stocker les données relatives à la fabrication du dit produit.
10. Le système de l'une des revendications 7 à 9, dans lequel les droits d'accès des dits collecteurs de données sont stockés sous forme de triplets, et dans lequel ledit module de création et d'édition de formulaire (107) génère des formulaires permettant de contrôler lesdits droits d'accès.
1 1 . Le système de l'une des revendications 7 à 10, comprenant :
des moyens d'installation dans des terminaux mobiles (103) desdits collecteurs de données d'une application générique :
des moyens d'identification dudit collecteur de données ;
de moyen de téléchargement dans ledit terminal mobile d'un dit formulaire spécifique choisi en fonction de ladite identification.
12. Le système de l'une des revendications 7 à 1 1 , comprenant des moyens de synchronisation des données saisies en mode offline par lesdits collecteurs de données puis transmises au dit système avec les données stockées dans ledit triplestore.
13. Le système de l'une des revendications 7 à 1 1, comprenant des moyens de requêtage permettant à un opérateur de saisir des requêtes pour interroger les données dans ledit triplestore.
EP13701980.8A 2012-01-25 2013-01-23 Procédé d'édition de formulaires pour la saisie de données en différents points de collecte Withdrawn EP2807616A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CH00104/12A CH706039A1 (fr) 2012-01-25 2012-01-25 Procédé d'édition de formulaires pour la saisie de données en différents points de collecte.
PCT/EP2013/051245 WO2013110662A1 (fr) 2012-01-25 2013-01-23 Procédé d'édition de formulaires pour la saisie de données en différents points de collecte

Publications (1)

Publication Number Publication Date
EP2807616A1 true EP2807616A1 (fr) 2014-12-03

Family

ID=47630301

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13701980.8A Withdrawn EP2807616A1 (fr) 2012-01-25 2013-01-23 Procédé d'édition de formulaires pour la saisie de données en différents points de collecte

Country Status (3)

Country Link
EP (1) EP2807616A1 (fr)
CH (1) CH706039A1 (fr)
WO (1) WO2013110662A1 (fr)

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2776790B1 (fr) 1998-03-24 2001-04-20 Bernard Jouglard Dispositif et procede permettant de retracer l'historique d'un produit alimentaire au sein d'une filiere de production, de transformation et de commercialisation
FR2813683B1 (fr) 2000-09-07 2003-01-17 Lionel Guivarch Procede de gestion d'informations relatives au chemin de vie d'une pluralite de produits alimentaires
US7440901B1 (en) 2000-11-02 2008-10-21 Sureharvest Method and system to communicate agricultural product information to a consumer
US20020082982A1 (en) 2000-12-22 2002-06-27 Mock James J. Crop integrity auditing and reporting system and method
FR2836257A1 (fr) 2002-02-20 2003-08-22 Agreen Tech Procede, systeme et serveur pour assurer la tracabilite des produits dans une chaine logistique
US7761334B2 (en) 2002-03-20 2010-07-20 Deere & Company Method and system for automated tracing of an agricultural product
US7184892B1 (en) 2003-01-31 2007-02-27 Deere & Company Method and system of evaluating performance of a crop
EP1498835A1 (fr) 2003-06-20 2005-01-19 Bfi Procédé d'identification et de traçabilité de produits alimentaires
WO2007049344A1 (fr) 2005-10-26 2007-05-03 Mitsubishi Denki Kabushiki Kaisha Traceur de produits alimentaires, systeme de traçage de produits alimentaires et procede de traçage de produits alimentaires
US8131599B2 (en) 2006-02-27 2012-03-06 Trace Produce, LLC Methods and systems for accessing information related to an order of a commodity
DE102006044730A1 (de) 2006-09-20 2008-04-03 Claas Selbstfahrende Erntemaschinen Gmbh Verfahren zur Steuerung und Überwachung einer Prozesskette zur Behandlung landwirtschaftlicher Produkte
US20110016144A1 (en) 2007-10-04 2011-01-20 Growers Express, Llc Crop Production, Planning, Management, Tracking and Reporting System and Method
WO2011124951A1 (fr) 2010-04-09 2011-10-13 International Traceability Systems Limited Gestion électronique de production biologique et de certification

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2013110662A1 *

Also Published As

Publication number Publication date
WO2013110662A1 (fr) 2013-08-01
CH706039A1 (fr) 2013-07-31

Similar Documents

Publication Publication Date Title
US20220066772A1 (en) System and Method for Code and Data Versioning in Computerized Data Modeling and Analysis
US10275502B2 (en) System and method for interactive reporting in computerized data modeling and analysis
US8195698B2 (en) Hierarchy manager for master data management
US9607056B2 (en) Providing a multi-tenant knowledge network
JP2025004045A (ja) ウェブ構築システムサービスにユーザフィードバックを統合するシステム及び方法
US7580946B2 (en) Smart integration engine and metadata-oriented architecture for automatic EII and business integration
US20100114691A1 (en) Managing a marketing template used in an e-mail marketing campaign
CA3009641A1 (fr) Systeme et procede de developpement et de deploiement rapides de code analytique reutilisable destine a etre utilise pour une modelisation et une analyse de donnees informatisees
FR2859552A1 (fr) Procede et systeme de manipulation de donnees issues de bases de donnees multidimensionnelles a l&#39;aide d&#39;un tableur
NL1025547C2 (nl) Inhoudsbeheerportaal en werkwijze voor het beheren van digitale waarden.
CN114386986A (zh) 一种产品全生命周期数据的追溯平台
FR2931274A1 (fr) Procede de gestion de donnees pour atelier oriente service collaboratif
US8832601B2 (en) ETL tool utilizing dimension trees
US20150379529A1 (en) System, service and methodology of data collection, processing, analysis and effective delivery of dashboard snapshot presentations of organized customer proprietary information on an individualized secure basis to multiple customers
Weber Business Analytics and Intelligence
EP3202115B1 (fr) Procédé et dispositif de mise en relations d&#39;un ensemble d&#39;informations
FR2931276A1 (fr) Procede de gestion de processus dans un atelier oriente service collaboratif
EP2807616A1 (fr) Procédé d&#39;édition de formulaires pour la saisie de données en différents points de collecte
US20130163028A1 (en) Accessing current data by using code images
Stodder Modernizing Data and Information Integration for Business Innovation
Galliano The importance of data visualization tools in modern enterprises. cost-effective solutions and empowering of an open source project
Catarci User-centered data management
Nguyen Online T-shirts Store: E-Commerce Web Application
Yu et al. A Dynamic Framework for e-Commerce Portals
Braun et al. Insights collaboration space: a team collaboration app for the design of data-driven services

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20140821

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: ALVES, BRUNO

Inventor name: SCHUMACHER, MICHAEL

Inventor name: WERLEN, DAVID

Inventor name: CHERIX, GILLES

Inventor name: GAPANY, CHRISTIAN

RIN1 Information on inventor provided before grant (corrected)

Inventor name: CHERIX, GILLES

Inventor name: WERLEN, DAVID

Inventor name: GAPANY, CHRISTIAN

Inventor name: ALVES, BRUNO

Inventor name: SCHUMACHER, MICHAEL

17Q First examination report despatched

Effective date: 20170117

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170728