WO2009115695A1 - Procede d'enrichissement de sources de donnees - Google Patents

Procede d'enrichissement de sources de donnees Download PDF

Info

Publication number
WO2009115695A1
WO2009115695A1 PCT/FR2009/000204 FR2009000204W WO2009115695A1 WO 2009115695 A1 WO2009115695 A1 WO 2009115695A1 FR 2009000204 W FR2009000204 W FR 2009000204W WO 2009115695 A1 WO2009115695 A1 WO 2009115695A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
source
attributes
information
alternative
Prior art date
Application number
PCT/FR2009/000204
Other languages
English (en)
Inventor
Enrico Maim
Original Assignee
Enrico Maim
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
Priority claimed from PCT/EP2008/052274 external-priority patent/WO2008107338A1/fr
Application filed by Enrico Maim filed Critical Enrico Maim
Priority to US12/919,375 priority Critical patent/US20110106791A1/en
Publication of WO2009115695A1 publication Critical patent/WO2009115695A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24553—Query execution of query operations
    • G06F16/24554—Unary operations; Data partitioning operations
    • G06F16/24556—Aggregation; Duplicate elimination

Definitions

  • the present invention aims to provide enhancements without fundamentally changing the way a user navigates, that is to say by letting him naturally access his favorite data sources.
  • the present invention proposes a method implemented in a computer environment for identifying enrichment information with respect to starting information, characterized in that it comprises the following steps:
  • a method implemented in a computer environment for identifying enrichment information with respect to starting information characterized in that it comprises the following steps:
  • SUBSTITUTE SHEET (Rule 26) (a) network accessing a first data source to collect a first set of structured data according to a plurality of first attributes in response to a first request;
  • mapping source (b) applying context information to a mapping source to identify at least a second data source capable of delivering data capable of enriching the first data
  • the invention proposes a method implemented in a computer environment for identifying enrichment information with respect to starting information, characterized in that it comprises the following steps:
  • said alternative values are selectively displayed as a function of the position of a pointer device on a value of the first data set, the alternative values according to the attribute corresponding to the value on which points the pointer device being displayed.
  • the invention proposes a method implemented in a computer environment for automatically enriching organized data in a multiplicity of (multidimensional) attributes provided by a data source such as a website, characterized in that it includes the following steps: (a) accessing a first data source to obtain first data;
  • said third data source providing complementary data to the first data source may be the second data source itself.
  • step (c) further comprises obtaining from the first or third source complementary data of said alternative data obtained from the second source.
  • step (b) furthermore comprises obtaining, from the first source, alternative data to the alternative data obtained from the second source, comparable with them, the latter alternative data obtained being also enriched with the step (c).
  • step (c) comprises a substep detecting the existence of alternative type attributes in the first or second data source.
  • the method further comprises a step of converting the data from the data sources into structured data sets according to a plurality of attributes.
  • the method further comprises a step of graphically processing the presentation of the first data provided by the first source to include the alternative data and the complementary data.
  • the alternative data and the complementary data are selectively presented according to the presented value attributes selected by the user with the help of a pointer device at the presentation of the origin of the first data.
  • the method comprises mapping or mapping of attributes for each pair of sources whose data is to be combined.
  • step (b) comprises a filtering on one or more attributes.
  • step (c) comprises taking into account metadata of dependence between attributes.
  • the method further comprises a step of automatically obtaining complementary data from the alternative data.
  • the method further comprises a step of automatically obtaining alternative data to the complementary data.
  • the method further comprises a step of automatically obtaining complementary data from the complementary data.
  • the method further comprises a step of automatically obtaining alternative data to the alternative data.
  • Data sources are chosen from conventional multidimensional data sources, and data sources whose values according to attributes can be represented by value domains or value constraints.
  • the said constraints depend on variables representing references to attribute values for the same multidimensional data set or for another data set.
  • step (d) * said other data set is included in step (d) only in the presence of a set of consistent constraints.
  • the method includes the use of a constraint solver.
  • Data sources from which data from the first data source is likely to be enriched include resources belonging to a user configurable context.
  • the user context includes active web pages in other tabs of a web browser, said browser constituting the means of access to the data sources.
  • the user context includes web pages belonging to a recent browsing history in a web browser that provides the means of accessing the data sources.
  • the user context includes web pages belonging to the user context of another user having a proximity link with the user in question.
  • the user context includes geolocation information of the user.
  • the user context is determined from the content of data sources previously accessed by the user.
  • Step (d) includes a selective grouping / deployment of data sets from the first data source and the enrichment data sources.
  • step (d) likewise aggregates sets of data for enriching the first data.
  • Figure 1 presents (in a "pop-up widget" with tabs, in its first tab) alternative information provided by a first secondary source.
  • Figure 2 shows (in a second tab of the same "pop-up widget") alternative information provided by a second secondary source.
  • FIG. 3 illustrates the fact that the user slides the mouse cursor over the representation of an attribute that corresponds to a functional or multivalued dependency key from another source that is available in the context, from which data are then presented to him with their complementary attributes.
  • Figures 4 and 5 schematically illustrate different cases of creating a mapping between sources that are already in the form of tables of data.
  • Figure 6 schematically illustrates a classic web page (left) showing products (books sorted by authors) and the extraction result (right) as a table (having the columns: Photo, Author, ISBN, Title, Language) ; the bidirectional arrow indicates extraction (from left to right) and synthesis (from right to left) as allowed by the method of the invention.
  • Figure 7 shows a Web page showing aircraft flights for which the user selects a "Vol Aller" attribute to extract.
  • Figure 8 shows that the extractor then creates the first "Vol Aller" column of the extracted array, corresponding to this attribute.
  • Figure 9 shows the complete table thus constructed.
  • Figure 10 shows a table constructed using the same method for another aviation company page.
  • FIG. 11 illustrates the creation by the user of a mapping between two pages of websites of aviation companies for which extractors already exist: having these two pages respectively opened in two different tabs of the browser, the user selects the 'Map with' option to create a mapping between the current page and the other page which will then be presented one under the other.
  • Figure 12 shows the fact of taking the graphic object "Paris - Charles de Gaulle (CDG)" located in the second half of the page, and drag it to the top of the figure.
  • CDG Para - Charles de Gaulle
  • Figure 13 shows the fact of depositing the slipped object on the graphic object "Paris" located on the first half of the page.
  • a method of automatically enriching a multidimensional data source 1 such as a website in particular enabling
  • the alternative data includes alternative attributes, i.e., which are not independent of the source. For example, for two sources of product sales (these products being common products made by third parties), attributes such as typically "price” and “delivery time” may be alternative, while product attributes themselves will be independent of the source (as these attributes depend on the manufacturers and not the sellers). Alternate attributes can be automatically detected as those that potentially have a value that contradicts the other source.
  • the data sources are enriched with complementary data (independent of the source) and alternative data (dependent on the source).
  • the method includes a step of converting the data sources into structured data sets according to a a plurality of attributes (in a "table") 2 and conversely the structured datasets resulting from the enrichments are converted back, so that for the visible part 1 of the source of access accessed, the enrichments are presented to the user. user directly within the (original) presentation of the source of departure.
  • These enhancements are presented to him selectively, according to said attributes selected by the user directly at the level of the original presentation.
  • the dimensions of multidimensional data sources are called attributes.
  • source and means “source data structured according to a plurality of attributes”; each data of a source is a “line” (or “dataset”); the terms “attribute” and “column” are used interchangeably.
  • An attribute value of a line can be characterized by constraints representing a possible set of values (this set is called “domain”).
  • “Attribute” means, depending on the context, “attribute” or “attribute value” or “possible attribute values” (the term “attribute value” is explicitly used only in ambiguous cases, to distinguish the attribute itself from the value it takes).
  • MTD refers to “Functional Dependence” and “Multivalued Dependence” respectively.
  • User means the user (human) or programmatic access instead of the user.
  • the visible part is the set of data presented to the user, the source itself being in general much wider than the part presented to the user.
  • the algorithm presented below and predetermined information comprising (i) the direct or indirect mapping (mapping) of attributes for each pair of sources to be combined, and (ii), associated with each source independently, one or more attributes serving as "filter” 5 (or a plurality of candidate filters) and / or attribute dependency meta-data 6 .
  • the method of the invention thus makes it possible to enrich alternative data obtained from one source by complementary information obtained from another source (which may even be the first), and conversely to enrich complementary data obtained from other sources.
  • a source with alternative data obtained from another which may even be the first one
  • also to enrich alternative data with other alternative data even from the first source
  • additional data by d other complementary data (even from the first source).
  • the method of the invention works equally well on conventional sources and sources comprising attributes represented by domains or constraints, i.e., disjunctions (or ranges) of explicitly given possible values and / or domains. implicitly represented by constraints such as equations and inequations, the constraints may contain variables representing references to attributes of the same line or other lines (as in a spreadsheet 7 ).
  • a validity start date (BS, "Belief Start") and an end of validity date (BE, "Belief End”) are optionally associated (as meta-attributes) with the lines, in order to memorize and manage in time 8 the enrichments made and invalidate (by instantiating the end of validity) said other stored lines that no longer correspond to the current enrichment.
  • the implementation of the method is described below using conventional solvers (stress solvers) 9 .
  • the method is suitable to be used with generic constraint solvers regardless of the domains (that is, the types of values that the attributes assume) on which they work: reals, integers, Booleans, strings of characters, lists, etc.
  • mapping may be based on semantic metadata; the filter or candidate filters will be those allowed by the data source in question; Dependencies can sometimes be determined automatically by assuming the closed world ...
  • an attribute can be specified by a plurality of constraints such as " ⁇ A10 + 2 * B27,>C15", here AlO B27 and C15 representing attributes of other lines of the same source.
  • Temporal data management makes it possible to compare several enrichments made over time (for example, to compare forecasts of future expenditures made at different times) and to automatically determine differences between aggregated values of the latter.
  • the sources enriching the source of departure are those in the context of the user.
  • the context definition is configurable by the user.
  • the context may for example include the pages in the other tabs of the current instance of the web browser (as illustrated in Figures 1 and 2 described later), or may be composed of the recently accessed pages, or may consist of the union of "close" user contexts, their proximity being able to be calculated in different ways as described in the last section of this text.
  • the selection of sources enriching a current source accessed also takes into account local context information such as geolocation or the very content of the sources comprising the context of the user himself or his "relatives" 10 .
  • Figure 1 presents (in a "pop-up widget” with tabs, in its first tab) other flights provided by a first source S2 and Figure 2 presents (in a second tab of the same "pop-up widget ") A flight provided by a second source S2.
  • mapping serves to indicate to the system that such and such attributes of Sl mean the same thing as such and such attributes of S2, possibly after transformations.
  • explicit mapping of attributes we will describe the implementation of explicit mapping of attributes.
  • the user can provide the system with a mapping by very simple operations of mappings of objects presented on the screen, including simple drag and drop.
  • Figures 4 to 13 schematically illustrate different cases of creation of a mapping, firstly between sources that are already in the form of tables of data, then between sources that are web sites but that the respective extractors know how to translate into tables and see the multidimensional data they provide.
  • FIG. 4 shows that since the Col5 column of S2 is slid-deposited on the Col2 column of Sl, the user indicates to the system that these columns contain values that can be combined, so the values from Col5 will be displayed in the resulting table. (SIr) in column "Col2 (Col5)”.
  • Figure 5 shows a case of adding a missing S2 attribute in Sl.
  • Column S2 of S2 being slid-deposited between columns Col2 and Col3 of Sl, the values from Col5 of S2 will be displayed in the resulting table (SIr) in a new column Col5 placed between Col2 and Col3.
  • a map can also be created directly from the original presentation of the sources in question.
  • Figures 11 to 13 show the method of mapping to web pages which have previously associated data extractors.
  • FIG. 6 schematically illustrates a classic web page (left) presenting books sorted by authors (Al, A2, etc.) and the extraction result (right) as a table (having the columns: Photo, Author, ISBN, Title, Language); bidirectional arrow indicates extraction (from left to right) and synthesis (from right to left) as allowed by the process that will now be described.
  • the provision, by means of the synthesizer, of the enrichment data in their original presentation may be inserted into pop-up widgets superimposed on another page, as already illustrated in FIGS. 3, and as will be described later with many examples.
  • An extractor provides a table from the data coming from a web page. It must therefore indicate on the one hand the request (url, GET or POST parameters) and on the other hand how to extract the data from the page. It can also manage paging and automatically download multiple pages of results.
  • the method of creating an extractor from a web page containing a multidimensional data set is semi-automatic.
  • the user selects in the web page one or more objects each corresponding to a row of the table, and indicates which object of the page corresponds to which row of the table to generate.
  • the system compares the paths of these objects and builds a generic path covering at least all the objects specified by the user. 14, the system can determine the values for each object, and present the table thus obtained to the user.
  • the synthesizer is the inverse of the extractor, it is created automatically at the moment of the creation of the corresponding extractor, and allows to display the data of a table in the presentation style of the Web page, graphic areas being placed at the location of the objects containing the values of the array to allow them to be deployed or collapsed as well as drag and drop them to create a mapping as described later and illustrated in FIGS. 11-13.
  • the system establishes, for each attribute, a pair (column name, path), the path being relative to the model object, and records this information in the extractor.
  • a copy of ol (and thus also of oJ for all J> l) is created, its attributes objects are modified to reflect the current line, and it is inserted as a result (as brother) of the last copy of ol to have been placed in the document.
  • the user can request to modify a synthesizer.
  • the same procedure above is then applied based on a one-row array containing column names instead of values, with special markings to distinguish them from normal text (eg, "$ ⁇ author") in the author column, and so on).
  • the model object is marked by special marks (for example ⁇ model-object> ... ⁇ / model-object>).
  • the user can modify the resulting document as he wishes, for example using a text editor, and return it to the system.
  • the above method now uses this new structure (provided that there is exactly one area bounded by the model object markers). Note, however, that it is allowed to delete or duplicate attribute markers.
  • Figure 11 illustrates the creation by the user of a mapping between two pages of aviation companies for which extractors already exist. (The extractors having for example been constructed as illustrated in Figures 7 to 10). Having these two pages respectively opened in two different tabs of the browser, the user selects the option "Map with" to create a mapping between the current page and the other page.
  • Figure 12 shows the fact of taking the graphic object "Paris - Charles de Gaulle (CDG)" located in the second half of the figure, and drag it upwards.
  • Figure 13 shows the fact of depositing the slipped object on the graphic object "Paris” located on the first half of the figure.
  • Sl source data source
  • CDG Paris
  • DEL Delhi
  • AF12 filters on a given flight number
  • AF12 the "visible part” of Sl
  • S2 A second source whose mapping with the first exists, is in the context and will enrich it. For ease of understanding it is assumed here that between Sl and S2 the names of attributes are the same and therefore the mapping is trivial here (and for the missing columns all their values are implicitly null).
  • Sl and S2 have the following attributes 18 :
  • the respective filters of the sources are underlined.
  • the column Class is missing but to the extractor of S2 is associated the meta-data that for this attribute the value is "Economy" (whatever the lines).
  • the Flight attribute determines the Company attribute in functional dependency (FD).
  • the starting data 19 are as follows:
  • the initial goal of the user is to obtain alternative offers for departure (Dep) and arrival (AIT) cities presented in the visible part of Sl and these are the attributes that constitute the filter (F) applied to S2.
  • an R line of S2 is selected to enrich a line L of Sl, if for the (or) key attribute F, the (or) map attribute (F) of S1 after transformation the optionally associated with mappage- implies F S2, that is to say that any value may take map (F) may also be taken by 24 F.
  • An attribute A of a selected R line of S2 is alternative if
  • the map attribute (A) corresponding to A is present (that is, this attribute may have a non-zero value or may take a value from a set of possible values, as opposed to attributes not present in Sl and therefore necessarily have the default value NULL 25 ) and
  • map (A) is potentially different from A 26 (and preferably 27 does not exist in Sl line L '(other than L) where the value map (A) 28 is equal to that of A).
  • map (A) has-or can take-a value different from that which-or can take-A. This nuance is necessary since attributes can have sets of possible values rather than values instantiated.
  • Source information requires to have in SIr an additional column for each attribute provided as enrichment by functional dependence or multivalued, which is not shown here in the SIr tables (to avoid overloading them). Sl (not visible part)
  • Airplane depends on Flight in FD; Legroom depends on Flight and Class in FD; Meal depends on Flight and Class in MVD.
  • Meal attribute is multivalued (Flight and Class determine Meal in MVD, in fact each flight corresponds to several dishes, such as "Veg” and “Non-veg”, and this according to the classes), a line must be added for each additional value of Meal:
  • Enrich (by S2) an enrichment result resulting from Sl, sr, Sl ", etc. (Sl 'being the result of enriching Sl, Sl” the enrichment result of Sl', and so on) potentially takes advantage of the plurality of candidate filter sets and / or dependency keys associated with all of the different sources involved.
  • the contents of the pop-up widgets shown schematically in Figures 14 to 18 can be generated by a synthesizer (described above) to take advantage of the original presentations of the respective sources (as shown in Figures 1 to 3 ).
  • the two enrichments (respectively by S3 and S2) presented schematically in FIG. 18 can be presented in two separate tabs of the same widget pop-up, each tab having as its label the source (S2 or S3) in question and presenting its content. as in the original source (as in the graphical style of Figures 1 and 2).
  • the source information (Source) requires to have in SIr an additional column for each attribute provided as dependency enrichment ... S2 (suppose there are only these 6 lines in S2)
  • the cells of S2 each have an identifier composed of the letter of the column and the line number, as in a spreadsheet.
  • lines 3 and 4 of S2 can not be enriched (by functional dependency) by any line of Sl (Sl providing no line with Flight AF14 or AF15).
  • lines 3 and 4 of S2 are part of the set of lines relevant to the user because they have a reference to at least one line (of S2) enriching Sl. Note that if in Sl there are lines with a reference to lines added in SIr whose Source is Sl, they are also added in SIr, and then new lines of S2 (alternatives to them) are added to their turn (to the extent that they are not invalidated by functional dependencies of Sl), and so on ... 39
  • Each line of these sources concerns, say, an action, from a given group, carried out in a given country, to a certain date for a certain price.
  • the Date attribute of S2 is specified as having the type "Real Time", which means that this attribute represents the date of actual occurrence of the data to be enriched, which makes it possible to have the constraint Date> NOW when is (tentatively) added to the result because of a reference to (or to) another line added in the result, as long as it is not combined with the other source which then gives it its actual date of occurrence.
  • S2 is used here to specify scenarios; each scenario being a model of prediction over time for a given group (Group) of actions.
  • group group of actions.
  • sequence constraints such as C2> C1, C2 ⁇ C3
  • maximum durations between them such as C2 ⁇ C1 + 12
  • default data such as default: Cl + 12
  • the first line of S2 can here unite with that of Sl 42 and bring with it the other lines of S2 which have a direct or indirect reference:
  • Constraints "> NOW” have been added for the Date attribute because this attribute is of type "Real Time” and these lines are not yet enriched by a line of Sl.
  • the first line of S2 unifies with that of Sl " we mean:
  • the constraints given respectively on these attributes in the first line of S2 are ' added to the set of constraints for the respective corresponding attributes of the line in question of Sl.
  • the method may comprise a last step which (optionally) unifies the lines of SIr that can be (ie when the combination of their respective constraints does not lead to an inconsistency), in which occurrence lines 4 and 6:
  • SIr table SIr
  • the presentation of the results can allow the selective grouping / deployment of lines of Sl (or S2) and the SIr lines are then grouped / deployed accordingly.
  • the lines of Sl (or S2) group together a plurality of lines and aggregate their values, SIr aggregates the enriched lines in the same way.
  • the attributes are a person, his sibling, his parent.
  • the lines Conditions have the role of extended key, in the sense that all their columns must be involved by lines of the other source, to allow the lines referring to it to be eligible to enrich the other source.
  • Non-determinism the combinatorial of the possible sets of lines to be added to SIr
  • the context is the set of sources S2 to take into account to enrich Sl as far as a mapping with Sl is available.
  • the method provides that the mode of constituting the context is user-configurable and may in particular include the pages in the same instance of the browser and / or the most recently accessed pages, possibly sorted according to their content and / or their metadata. data.
  • the selection of context sources to enrich a current source accessed may take into account "local context” information such as geolocation, which will be used as criteria for selecting S2 sources based on their metadata or content.
  • the said selection also takes into account the content of the sources comprising the context of the user himself or of his "relatives", said proximity including geographical proximity criteria, explicitly given relations and / or usage counts. effective mappings as described on the next page.
  • mappings when a user creates a mapping between two extractors, we will offer it first. When a user has used a mapping, we want to resubmit it when the opportunity arises. Each user must store all the mappings he (recently) used.
  • the server thus stores a table containing these three numbers for each mapping.
  • mapping usage counts more if one or more of the mapped columns have the same value as in the current case.
  • Store a table on the server side (source page, mapping identifier, Filter or Key column identifier, source values, number of mappings, number of suggestions).
  • Filter or Key column identifier When there is only one Filter column, the counter is incremented for the corresponding line.
  • each column-value pair has its own counter and all are incremented independently. In order to avoid this table becoming too big, the lines having the lowest frequencies of use are deleted (the frequency being the ratio of the usage counter on the time of existence of the line in the table)
  • the proximity of the other users if two users are close it is supposed that they will want to establish the same mappings, and therefore one can weight their counts of use, creation and refusal by the proximities to the current user.
  • the proximity between two users can be calculated by comparing the differences between the sets of mappings they used. A complete list of mappings made by a certain number of "representative" users is therefore kept in the server. When the number of users is reduced, they are all considered representative. When it increases, we look for a pair of users who are very close to each other and remove one of the two from the set of representatives. We store for all the users their proximities to all the representative users.
  • a user is considered close to another if their proximity vectors to representative users are close (the proximity p (t, u) of two users t and u is l / ⁇ (ti-ui) 2 , where ti is the proximity This is obtained by the ratio of the number of mappings used in common (intersection) to the total number of mappings used by the two users (union).
  • Each user thus stores all of his close users, whom he asks again from the server at regular intervals (indeed, this set may change over time, for example when user has not been seen online for too long it can be removed from all nearby user sets, and new users must be found to "replace” it).
  • the server chooses a user I different from A (ideally a user known to have good bandwidth and who is not already engaged in this protocol with other users).
  • the server provides I with the IP addresses of A and B with a connection number, informing it that it has been chosen as an intermediary.
  • the server sends A to the I address and the login ID.
  • Machine A sends the data to I, which can then relay them to B without A knowing the address of B, and without knowing the user ID of B (he knows only his IP address).
  • Transitivity when proposing an AB and B mapping would propose a BC mapping, we may want to propose AC directly.
  • the score of such a chain of e mappings is obtained by multiplying the scores of the elements of the chain and dividing by M ⁇ (nl), where M is the largest score sv encountered (among all the mappings considered) and n is the number of elements in the chain. This is equivalent to calculating if * s2 / M * s3 / M * ..., where each factor except the first is smaller than or equal to 1 (M being the maximum of the scores encountered), and the set of "ifs" scans all the scores of the elements of the chain.
  • the score is therefore smaller or equal to the score of all the elements of the chain, and the score of a string of length 1 is precisely the score of the single element that it contains.
  • Two strings with the same endings and whose combination of column mappings provide the same result are considered equivalent, and in this case only one string is offered, the one with the highest score.
  • new data sources can be automatically combined by default, provided they have already been (mapped and) combined previously.
  • a user himself creates a "Seller2" data source (for example from an already existing source, in this case from "Seller!) And presents the offer for sale of a book “Authorl” "Titrel” (for example a secondhand book he would like to resell).
  • Another user accessing "Sellerl” learns of the "Seller2" offer simply because a relatively large number of other users have already combined "Seller2" with “Sellerl” and matched their respective columns. .
  • a selection criterion may be the meta-attribute BS ("Valid From") already described, representing the time of first appearance of the line. If the offer of "Seller2" is the most recent, the said other user will see the offer of "Seller2” instead of the offers of the other sellers; otherwise, he will be able to see it by moving in the past (by moving a temporal cursor "Wall-clock time”). In this default combinations approach, a graphical means will be offered to the user to remove from the display values from a combined source, that is to say to refuse the combination in question, or to undo Column mapping performed by default, and these rejections are counted in counts, as described above, to influence the determination of subsequent suggestions.
  • BS Value From
  • An extractor provides a "Yamazuki" data source from the website of the great Yamazuki motorcycle manufacturer, which presents all the motorcycles of this brand, with all their characteristics.
  • An individual publishes a "I sell" source containing a line presenting the type of motorcycle (as a key value), the details, the price and the place of sale of a recent Yamazuki motorcycle that it sells.
  • the scenario is as follows: The end user accesses in the same session not only the site “Yamazuki” but also a site “Castles” in which the user selects the line Fontainebleau. In this case, since the source "I sell" is automatically combined by default with these two sites, the offer of the bike of the individual is presented:
  • search engine provides, in a column “Domain”, the domain (in this case “fly fishing") corresponding to the keyword ("fly") given.
  • domain in this case "fly fishing”
  • search Engine source "Sellerl”
  • ellerl is a seller specialized book in the field “Fly fishing”
  • Each data source 51 is associated with the degree of fineness of the information to be taken into account during the counts.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La présente invention propose selon un premier aspect un procédé mis en œuvre dans un environnement informatique pour identifier des informations d'enrichissement par rapport à des informations de départ, caractérisé en ce qu'il comprend les étapes suivantes : (a) accéder par réseau à une première source d'informations en vue d'en recueillir des premières informations en réponse à une première requête; (b) convertir lesdites premières informations en un premier jeu de données structurées selon une pluralité de premiers attributs; (c) appliquer à une source de mappage des informations de contexte en vue d'identifier au moins une deuxième source d'informations susceptible de délivrer des informations capables d'enrichir les premières informations; (d) accéder par réseau à la deuxième source d'informations en vue d'en recueillir des deuxièmes informations en réponse à une deuxième requête contenant un ou plusieurs critères contenus dans la première requête et/ou une ou plusieurs valeurs d'attributs du premier jeu de données structurées; (e) convertir lesdites deuxièmes informations en un deuxième jeu de données structurées selon une pluralité de deuxièmes attributs dont au moins certains sont liés à des premiers attributs par des informations de mappage entre attributs fournis par la source de mappage, et (f) présenter des données comprenant des données du premier jeu de données et des données du deuxième jeu de données, combinées en fonction desdites informations de mappage.

Description

PROCEDE D'ENRICHISSEMENT DE SOURCES DE DONNEES Etat de la technique
De nos jours, les seuls moyens d'enrichir des sources de données avec d'autres sources de données sont celles de l'art des systèmes de gestion de bases de données, grâce à des instructions spécifiques permettant notamment de combiner ensemble des données sous forme de tableaux.
Et lorsque les sources de données sont celles auxquels ont recours des services Web, il n'existe aucun moyen de combiner automatiquement des données de départ avec des données d'enrichissement.
On mentionnera pour mémoire les méta-moteurs de recherche, par exemple d'achat en ligne, permettant de comparer des prix, mais ces méta-moteurs s'exécutent nécessairement dans un environnement spécifique et dédié.
La présente invention vise à proposer des enrichissements sans modifier fondamentalement la façon de naviguer d'un utilisateur, c'est-à-dire en le laissant accéder naturellement à ses sources de données préférées.
Résumé de l'invention
La présente invention propose selon un premier aspect un procédé mis en œuvre dans un environnement informatique pour identifier des informations d'enrichissement par rapport à des informations de départ, caractérisé en ce qu'il comprend les étapes suivantes :
(a) accéder par réseau à une première source d'informations en vue d'en recueillir des premières informations en réponse à une première requête ; . . ,
(b) convertir lesdites premières informations en un premier jeu de données structurées selon une pluralité de premiers attributs ;
(c) appliquer à une source de mappage des informations de contexte en vue d'identifier au moins une deuxième source d'informations susceptible de délivrer des informations capables d'enrichir les premières informations ;
(d^ accéder par réseau à la deuxième source d'informations en vue d'en recueillir des deuxièmes informations en réponse à une deuxième requête contenant un ou plusieurs critères contenus dans la première requête et/ou une ou plusieurs valeurs d'attributs du premier jeu de données structurées ;
(e) convertir lesdites deuxièmes informations en un deuxième jeu de données structurées selon une pluralité de deuxièmes attributs dont au moins certains sont liés à des premiers attributs par des informations de mappage entre attributs fournis par la source de mappage, et
(f) présenter des données comprenant des données du premier jeu de données et des données du deuxième jeu de données, combinées en fonction desdites informations de mappage.
Selon un deuxième aspect de l'invention, on propose un procédé mis en œuvre dans un environnement informatique pour identifier des informations d'enrichissement par rapport à des informations de départ, caractérisé en ce qu'il comprend les étapes suivantes :
FEUILLE DE REMPLACEMENT (Règle 26) (a) accéder par réseau à une première source de données en vue d'en recueillir un premier jeu de données structurées selon une pluralité de premiers attributs en réponse à une première requête ;
(b) appliquer à une source de mappage des informations de contexte en vue d'identifier au moins une deuxième source de données susceptible de délivrer des données capables d'enrichir les premières données ;
(c) accéder par réseau à la deuxième source de données en vue d'en recueillir un deuxième jeu de données structurées selon une pluralité de deuxièmes attributs en réponse à une deuxième requête contenant un ou plusieurs critères contenus dans Ia première requête et/ou une ou plusieurs valeurs d'attributs du premier jeu de données structurées, les deuxièmes attributs étant liés à des premiers attributs par des informations de mappage fournies par la source de mappage ; et
(d) présenter des données comprenant des données du premier jeu de données et des données du deuxième jeu de données, combinées en fonction d'attributs clés prédéterminés parmi les deuxièmes attributs.
L'invention propose selon un troisième aspect un procédé mis en oeuvre dans un environnement informatique pour identifier des informations d'enrichissement par rapport à des informations de départ, caractérisé en ce qu'il comprend les étapes suivantes :
(a) accéder par réseau à une première source de données en vue d'en recueillir un premier jeu de données structurées selon une pluralité de premiers attributs en réponse à une première requête ;
(b) appliquer à une source de mappage des informations de contexte en vue d'identifier au moins une deuxième source de données susceptible de délivrer des données capables d'enrichir les premières données ; ,:
(c) accéder par réseau à la deuxième source de données en vue d'en recueillir un deuxième jeu de données structurées selon une pluralité de deuxièmes attributs en réponse à une deuxième requête contenant un ou plusieurs critères contenus dans la première requête et/ou une ou plusieurs valeurs d'attributs du premier jeu de données structurées, les deuxièmes attributs étant liés à des premiers attributs par des informations de mappage fournies par la source de mappage ; et
(d) présenter des données comprenant des données du premier jeu de données et des données du deuxième jeu de données, combinées en réponse à l'existence de valeurs alternatives, dans le deuxième jeu de données, de deuxièmes attributs mappés sur des premiers attributs.
Dans le procédé ci-dessus, il est avantageux que lesdites valeurs alternatives soient sélectivement affichées en fonction de la position d'un dispositif pointeur sur une valeur du premier jeu de données, les valeurs alternatives selon l'attribut correspondant à la valeur sur laquelle pointe le dispositif pointeur étant affichées.
Selon un quatrième aspect, l'invention propose un procédé mis en œuvre dans un environnement informatique pour enrichir automatiquement des données organisées en une multiplicité d'attributs (multidimensionnelles) fournies par une source de données telle qu'un site web, caractérisé en ce qu'il comprend les étapes suivantes : (a) accéder à une première source de données pour obtenir des premières données ;
(b) obtenir automatiquement des données alternatives aux premières données, comparables avec elles, à partir d'au moins une deuxième source de données ;
(c) obtenir automatiquement des données complémentaires des premières données, à partir d'une troisième source de données ; et
(d) combiner lesdites données alternatives et lesdites données complémentaires aux premières données, de manière à sélectivement présenter lesdites premières données, les données alternatives et les données complémentaires.
Certains aspects préférés mais non limitatifs de ce procédé sont les suivants :
* ladite troisième source de données fournissant des données complémentaires à Ia première source de données peut être la deuxième source de données elle-même.
* l'étape (c) comprend en outre l'obtention à partir de la première ou la troisième source, des données complémentaires desdites données alternatives obtenues de la deuxième source.
* l'étape (b) comprend en outre l'obtention, à partir de la première source, de données alternatives aux données alternatives obtenues à partir de la deuxième source, comparables avec elles, ces dernières données alternatives obtenues étant également enrichies à l'étape (c).
* les données alternatives correspondent à des attributs de type alternatif, dont les valeurs dépendent de la source, lesdites premières données comprennent des données selon des attributs dont les valeurs sont indépendantes de la source, et l'étape (c) comprend une sous-étape de détection de l'existence d'attributs de type alternatif dans la première ou la deuxième source de données.
* le procédé comprend en outre une étape de conversion des données issues des sources de données en des jeux de données structurées selon une pluralité d'attributs.
* le procédé comprend en outre une étape de traitement graphique de la présentation des premières données fournies par la première source pour y inclure les données alternatives et les données complémentaires.
* les données alternatives et les données complémentaires sont présentées sélectivement en fonction des attributs de valeurs présentées sélectionnées par l'utilisateur à l'aide d'un dispositif pointeur au niveau de la présentation d'origine des premières données.
* le procédé comprend une mise en correspondance ou mappage d'attributs pour chaque paire de sources dont les données sont à combiner.
* l'étape (b) comprend un filtrage sur un ou plusieurs attributs.
* l'étape (c) comprend la prise en compte de méta-données de dépendance entre attributs.
* le procédé comprend en outre une étape consistant à obtenir automatiquement des données complémentaires des données alternatives.
* le procédé comprend en outre une étape consistant à obtenir automatiquement des données alternatives aux données complémentaires.
* le procédé comprend en outre une étape consistant à obtenir automatiquement des données complémentaires des données complémentaires. * le procédé comprend en outre une étape consistant à obtenir automatiquement des données alternatives aux données alternatives.
* les sources de données sont choisies parmi les sources de données multidimensionnelles classiques, et les sources de données dont des valeurs selon des attributs peuvent être représentés par des domaines de valeurs ou des contraintes sur valeurs.
* lesdites contraintes dépendent de variables représentant des références à des valeurs d'attributs pour le même jeu de données multidimensionnelles ou pour un autre jeu de données.
* lorsqu'un attribut d'un jeu de données d'une source qui enrichit une première source comprend une référence à un attribut d'un autre jeu de données, ou réciproquement lorsqu'un attribut d'un autre jeu de données comprend une référence à un attribut d'une jeu de données qui enrichit un jeu de données de la première source, ledit autre jeu de données est ajouté dans les données combinées (SIr), même lorsqu'aucun jeu de données de la première source n'y correspond.
* ledit autre jeu de données n'est inclus dans l'étape (d) qu'en présence d'un ensemble de contraintes cohérent.
* il existe des attributs de type « Temps Réel » et sur ces attributs des contraintes de validité/péremption, et le procédé est mise en œuvre en tenant compte des contraintes sur attributs de type « Temps Réel » pour permettre une gestion des enrichissements par données alternatives et données complémentaires prenant en compte le temps.
* le procédé comprend le recours à un solveur de contraintes.
* les sources de données à partir desquelles les données de la première source de données sont susceptibles d'être enrichies comprennent des ressources appartenant à un contexte d'utilisateur paramétrable.
* le contexte d'utilisateur comprend des pages Web actives dans d'autres onglets d'un navigateur Web, ledit navigateur constituant le moyen d'accès aux sources de données.
* le contexte d'utilisateur comprend des pages Web appartenant à un historique de navigation récent dans un navigateur Web constituant le moyen d'accès aux sources de données.
* le contexte d'utilisateur comprend des pages Web appartenant au contexte d'utilisateur d'un autre utilisateur ayant un lien de proximité avec l'utilisateur en cause.
* le contexte d'utilisateur comprend des informations de géolocalisation de l'utilisateur.
* le contexte d'utilisateur est déterminé à partir du contenu de sources de données précédemment accédées par l'utilisateur.
* l'étape (d) comprend un regroupement/déploiement sélectif de jeux de données provenant des de la première source de données et des sources de données d'enrichissement.
* lorsque lesdites premières données regroupent une pluralité de jeux de données de ladite première source et agrègent leurs valeurs, alors l'étape (d) agrège de la même manière des jeux de données d'enrichissement des premières données. Brève description des dessins
La figure 1 présente (dans un « pop-up widget » muni d'onglets, dans son premier onglet) des informations alternatives fournies par une première source secondaire.
La figure 2 présente (dans un deuxième onglet du même « pop-up widget ») des informations alternatives fournies par une deuxième source secondaire.
La figure 3, illustre le fait que l'utilisateur glisse le curseur de Ia souris sur la représentation d'un attribut qui correspond à une clé de dépendance fonctionnelle ou multivaluée d'une autre source qui disponible dans le contexte, à partir de laquelle des données lui sont alors présentées avec leurs attributs complémentaires.
Les figures 4 et 5 illustrent schématiquement différents cas de créations d'un mappage entre sources qui sont déjà sous forme de tableaux de données.
La figure 6 illustre schématiquement une page Web classique (à gauche) présentant des produits (des livres triés par auteurs) et le résultat d'extraction (à droite) sous forme de tableau (ayant les colonnes : Photo, Auteur, ISBN, Titre, Langue) ; la flèche bidirectionnelle indique l'extraction (de gauche à droite) et Ia synthèse (de droite à gauche) comme le permet le procédé de l'invention.
La figure 7 présente une page Web présentant des vols d'avion pour laquelle l'utilisateur sélectionne un attribut « Vol Aller » à extraire.
La figure 8 montre le fait que l'extracteur crée alors la première colonne « Vol Aller » du tableau extrait, correspondant à cet attribut.
La figure 9 présente le tableau complet ainsi construit.
La figure 10 montre un tableau construit selon la même méthode pour une autre page de compagnie d'aviation.
La figure 11 illustre la création par l'utilisateur d'un mappage entre deux pages de sites Web de compagnies d'aviations pour lesquelles des extracteurs existent déjà : ayant ces deux pages respectivement ouvertes dans deux onglets différents du navigateur, l'utilisateur sélectionne l'option « Map with » pour créer un mappage entre la page courante et l'autre page qui vont alors être présentées l'une sous l'autre.
La figure 12 montre le fait de prendre l'objet graphique « Paris - Charles de Gaulle (CDG) » situé dans la deuxième moitié de la page, et le glisser vers le haut de la figure.
La figure 13 montre le fait de déposer l'objet glissé, sur l'objet graphique « Paris » situé sur la première moitié de la page. Début de la description
Procédé d'enrichissement automatique d'une source de données multidimensionnelle1 telle qu'un site web, permettant notamment
• lors de l'accès à un site web, d'obtenir automatiquement des données alternatives à partir d'autres sites (par exemple pour obtenir de différentes compagnies aériennes une liste de vols pour une même destination) afin de pouvoir les comparer,
• et de combiner automatiquement des informations de types différents provenant de plusieurs sites (par exemple, en visitant le site d'une compagnie aérienne, automatiquement l'utilisateur se voit proposer des hôtels à la destination et aux dates choisies).
Les données alternatives comprennent des attributs alternatifs, c'est-à-dire qui ne sont pas indépendants de la source. Par exemple, pour deux sources de vente de produits (ces produits étant des produits communs fabriqués par des tiers), les attributs tels que typiquement le « prix » et le « délai de livraison » pourront être alternatifs, alors que les attributs caractérisant les produits eux-mêmes seront indépendants de la source (vu que ces attributs dépendent des fabricants et pas des vendeurs). Les attributs alternatifs peuvent être détectés automatiquement comme étant ceux qui potentiellement ont une valeur contredisant l'autre source.
Ainsi les sources de données sont enrichies de données complémentaires (indépendantes de la source) et de données alternatives (dépendantes de la source).
Dans le cas d'un accès à une source telle qu'un site Web, les données n'étant pas fournies de manière structurée et immédiatement exploitable, le procédé comprend une étape de conversion des sources de données en des jeux de données structurées selon une pluralité d'attributs (en un « tableau »)2 et inversement les jeux de données structurées résultant des enrichissements sont converties en retour, de manière à ce que pour la partie visible1 de la source de départ accédée, les enrichissements soient présentés à l'utilisateur directement au sein de la présentation (d'origine) de la source de départ. Ces enrichissements lui sont présentés sélectivement, en fonction desdits attributs sélectionnés par l'utilisateur directement au niveau de la présentation d'origine.
Dans l'état de la technique, pour effectuer de telles combinaisons de sources, des requêtes -comprenant notamment des unions et des jointures (du calcul relationnel) ou opérations analogues- spécifiques nécessitent d'être définies et mises en œuvre explicitement. Le procédé de l'invention, quant à lui, est générique et transparent et se déclenche (spontanément en fonction du contexte) sur la base de
1 Dans la suite, les dimensions des sources de données multidimensionnelles sont appelées des attributs.
2 Dans la suite, par « source » on entend ainsi « source de données structurées selon une pluralité d'attributs » ; chaque donnée d'une source est une « ligne » (ou « jeu de données ») ; les termes « attribut » et « colonne » sont utilisés de manière interchangeable.
De même, les termes « table » (composée de lignes et colonnes) et « tableau » sont utilisés de manière interchangeable.
Une valeur d'attribut d'une ligne peut être caractérisée par des contraintes représentant un ensemble de valeurs possible (cet ensemble est appelé « domaine »). Par « attribut » on entend, selon le contexte, « attribut » ou « valeur d'attribut » ou encore « valeurs possibles d'attribut » (le terme « valeur d'attribut » n'est explicitement utilisé que dans les cas ambigus, pour distinguer l'attribut lui-même de la valeur qu'il prend).
Par ailleurs, les termes « mappage » et « mise en correspondance » sont aussi interchangeables. Par « FD » et
« MVD », on entend « Dépendance Fonctionnelle » et « Dépendance Multivaluée » respectivement. Enfin, par
« utilisateur » on entend l'utilisateur (humain) ou encore un accès programmatique en lieu et place de l'utilisateur.
3 La partie visible est l'ensemble des données présentée à l'utilisateur, la source elle-même étant en général bien plus large que la partie présentée à l'utilisateur. l'algorithme présenté ci-après et d'informations prédéterminées" comprenant (i) la mise en correspondance (mappage) direct ou indirect d'attributs pour chaque paire de sources à combiner, et (ii), associé à chaque source prise indépendamment, un ou plusieurs attributs servant de « filtre »5 (ou une pluralité de filtres candidats) et/ou des méta-données de dépendances6 entre attributs.
Le procédé de l'invention permet ainsi d'enrichir des données alternatives obtenues à partir d'une source par des informations complémentaires obtenues d'une autre source (qui peut même être la première), et réciproquement d'enrichir des données complémentaires obtenues d'une source par des données alternatives obtenues d'une autre (qui peut même être la première), et aussi d'enrichir des données alternatives par d'autres données alternatives (même à partir de la première source) et des données complémentaires par d'autres données complémentaires (même à partir de la première source).
Le procédé de l'invention fonctionne aussi bien sur des sources classiques et des sources comprenant des attributs représentés par des domaines ou des contraintes, c'est-à-dire des disjonctions (ou intervalles) de valeurs possibles données explicitement et/ou des domaines représentés implicitement par des contraintes telles que des équations et des inéquations, les contraintes pouvant contenir des variables représentant des références à des attributs de la même ligne ou d'autres lignes (comme dans un tableur7).
Lorsqu'un attribut d'une ligne d'une source (qui enrichit une source de départ), comprend une référence à un attribut d'une autre ligne, ou réciproquement lorsqu'un attribut d'une autre ligne a une référence à un attribut d'une ligne qui enrichit une ligne de départ, ladite autre ligne est tentativement ajoutée dans le résultat d'enrichissement, même lorsqu'aucune ligne de la source de départ n'y correspond. Toutefois, elle est rejetée dès que l'ensemble de contraintes devient inconsistant. Pour chaque attribut de type « Temps Réel » de ladite autre ligne, une contrainte « >N0W » (date supérieure au temps présent) y est ajouté pour permettre de tenir compte de contraintes de séquence entre lignes, et d'éviter de générer des autres lignes violant de telles contraintes. Par ailleurs une date de début de validité (BS, « Belief Start ») et une date de fin de validité (BE, « Belief End ») sont optionnellement associés (comme méta- attributs) aux lignes, afin de permettre de mémoriser et gérer dans le temps8 les enrichissements effectués et d'invalider (en instanciant la fin de validité) lesdites autres lignes mémorisées qui ne correspondent plus à l'enrichissement courant.
On décrit plus loin la mise en œuvre du procédé à l'aide de solveurs (solveurs de contraintes) classiques9. Le procédé est apte à être utilisé avec des solveurs de contraintes génériques quelque soient les domaines (c'est-à-dire les types de valeurs que prennent les attributs) sur lesquels ils fonctionnent : les réels, les entiers, les booléens, les chaînes de caractères, les listes, etc..
4 Prédéterminés par des procédés automatiques ou pas, notamment : le mappage peut être basé sur des méta- données sémantiques ; le filtre ou les filtres candidats seront ceux que permet la source de données en question ; les dépendances peuvent parfois être déterminées automatiquement en faisant l'hypothèse du monde clos...
5 (analogue à une clé de jointure - des données alternatives (c'est-à-dire des données ayant des attributs alternatifs) étant automatiquement recherchées par rapport audit filtre)
6 Les concepts de dépendance fonctionnelle (FD) et de dépendance multivaluée (MVD) (un ou plusieurs attributs clé déterminant un ou plusieurs autres attributs) sont bien connus dans le domaine de la normalisation des bases de données relationnelles (voir notamment les articles de Ronald Fagin).
7 Comme dans une feuille de calcul d'un tableur, mais à la différence des tableurs qui ne permettent que d'exprimer des formules telles que « =A10+2*B27 », un attribut peut être spécifié par une pluralité de contraintes telles que « < A10+2*B27, > C15 », ici AlO B27 et C15 représentant des attributs d'autres lignes de la même source.
8 La gestion temporelle de données permet de comparer plusieurs enrichissements effectués dans le temps (par exemple de comparer des prévisions de dépenses futures effectuées à différents moments) et de déterminer automatiquement des écarts entre des valeurs agrégées de ces dernières.
9 Tels que ceux utilisés dans la mise en œuvre de langages Prolog avec Contraintes. Les sources enrichissant la source de départ sont celles se trouvant dans le contexte de l'utilisateur. La définition du contexte est configurable par l'utilisateur. Le contexte peut par exemple comprendre les pages se trouvant dans les autres onglets de l'instance courante du navigateur web (comme illustré dans les figures 1 et 2 décrites plus loin), ou peut être composé des pages récemment accédées, ou encore être constitué de l'union des contextes d'utilisateurs « proches », leur proximité pouvant être calculé de différentes manières comme on le décrit à la dernière section de ce texte. La sélection des sources enrichissant une source courante accédée tient aussi compte des informations de contexte local telles que la géolocalisation ou encore du contenu même des sources composant le contexte de l'utilisateur lui- même ou de ses « proches »10.
Illustrations
On va maintenant illustrer le concept d'enrichissement d'une source dé départ Sl par une pluralité de sources S2 du contexte courant (représenté ici par les onglets du même navigateur).
Comme le présente les figures 1 et 2, lorsque l'utilisateur glisse le curseur de la souris11 sur la représentation d'un attribut correspondant (par mappage) à un attribut alternatif d'une autre source disponible dans le contexte, le système lui présente les données de cette dernière avec ses attributs alternatifs12. En l'occurrence l'attribut alternatif en question dans ces figures est le prix du vol, ainsi d'autres vols (et éventuellement aussi le même vol) sont présentés avec leurs prix alternatifs.
La figure 1 présente (dans un « pop-up widget » muni d'onglets, dans son premier onglet) d'autres vols fournis par une première source S2 et la figure 2 présente (dans un deuxième onglet du même « pop-up widget ») un vol fourni par une deuxième source S2.
En revanche, comme l'illustre la figure 3, lorsque l'utilisateur glisse le curseur de la souris sur la représentation d'un attribut qui correspond (par mappage) à une clé (clé de dépendance fonctionnelle ou multivaluée) d'une autre source disponible dans le contexte, le système lui présente les données de cette dernière avec leurs attributs complémentaires. En l'occurrence l'attribut clé en question est la destination du vol et les informations complémentaires présentées sont les hôtels disponibles à cette destination. Bien entendu, dans certains cas (non montrés dans ces figures) des attributs alternatifs et complémentaires sont présentés ensemble (par exemple dans des onglets différents d'un même pop-up widget). Il est à noter que les enrichissements ne se font pas directement avec les parties visibles13 respectives des sources S2, mais en accédant à ces sources (à nouveau) pour fournir les lignes compatibles aux lignes de la partie visible de Sl.
Mappage
Essentiellement un mappage (ou mapping) entre Sl et S2 sert à indiquer au système que tel et tel attributs de Sl signifient la même chose que tel et tel attributs de S2, éventuellement après transformations. Différentes méthodes existent pour donner la sémantique des attributs, notamment dans les contenus des sources elles-mêmes (comme les micro-formats par exemple). On va ici se décrire la mise en œuvre de mises en correspondance explicite d'attributs.
L'utilisateur peut fournir au système un mappage par des opérations très simples de mises en correspondance d'objets présentés à l'écran, notamment par de simples glisser-déposer.
10 (ce terme incluant mais ayant un sens plus large que la proximité géographique)
11 (ou simplement sélectionne)
12 (qui peuvent être mis en évidence, par exemple en les surlignant, mais ceci n'est pas le cas dans les figures)
13 (sauf bien sûr dans les cas où la partie visible de S2 contient déjà les lignes compatibles aux lignes de la partie visible de Sl) Les figures 4 à 13 illustrent schématiquement différents cas de créations d'un mappage, d'abord entre sources qui sont déjà sous forme de tableaux de données, ensuite entre sources qui sont des sites web mais que les extracteurs respectifs savent traduire en tableaux et y voir ainsi les données multidimensionnelles qu'elles fournissent.
La figure 4 montre que la colonne Col5 de S2 étant glissée-déposée sur la colonne Col2 de Sl, l'utilisateur indique au système que ces colonnes contiennent des valeurs qui peuvent être combinées, ainsi les valeurs provenant de Col5 seront affichées dans le tableau résultant (SIr) dans la colonne « Col2(Col5) ».
La figure 5 montre un cas d'ajout d'un attribut de S2 manquant dans Sl. La colonne Col5 de S2 étant glissée-déposée entre les colonnes Col2 et Col3 de Sl, les valeurs provenant de Col5 de S2 seront affichées dans le tableau résultant (SIr) au sein d'une nouvelle colonne Col5 placée entre Col2 et Col3.
Ces figures (4 et 5) illustrent schématiquement les régions (délimitées en traitillés dans les figures) permettant de distinguer, lors de la détection de l'événement « déposer », ces deux cas de glisser- déposer.
Un mappage peut aussi être créé directement à partir de la présentation d'origine des sources en question. Les figures 11 à 13 montrent le procédé de mappage sur des pages web auxquelles on a au préalable associé des extracteurs de données.
Extraction / Synthèse
On va maintenant décrire le procédé d'extraction/synthèse de données qui permet d'effectuer des enrichissements directement au niveau des pages Web. En effet, les données peuvent être fournies dans la même présentation que celle de la page Web qui sert de source. La figure 6 illustre schématiquement une page Web classique (à gauche) présentant des livres triés par auteurs (Al, A2, etc.) et le résultat d'extraction (à droite) sous forme de tableau (ayant les colonnes : Photo, Auteur, ISBN, Titre, Langue) ; la flèche bidirectionnelle indique l'extraction (de gauche à droite) et la synthèse (de droite à gauche) comme le permet le procédé que l'on va maintenant décrire. Il est à noter que la fourniture, au moyen du synthétiseur, des données d'enrichissement dans leur présentation d'origine pourra être insérée dans des pop-up widgets superposés à une autre page, comme on l'a déjà illustré aux figures 1 à 3, et comme on va le décrire plus loin avec de nombreaux des exemples.
Un extracteur fournit un tableau à partir des données en provenance d'une page web. Il doit donc indiquer d'une part la requête (url, paramètres GET ou POST) et d'autre part comment extraire les données de la page. Il peut également gérer la pagination et télécharger automatiquement plusieurs pages de résultats.
Le procédé de création d'un extracteur, à partir d'une page Web contenant un ensemble de données multidimensionnelles, est semi-automatique. Tout d'abord, l'utilisateur sélectionne dans la page Web un ou plusieurs objets correspondant chacun à une ligne du tableau, et indique quel objet de la page correspond à quelle ligne du tableau à générer. Le système compare les chemins de ces objets et construit un chemin générique couvrant au moins tous les objets indiqués par l'utilisateur.14 Le système peut ainsi déterminer les valeurs pour chaque objet, et présenter le tableau ainsi obtenu à l'utilisateur.
14 Dans une mise en œuvre préférée, tous les objets correspondant au chemin ainsi construit sont mis en évidence et l'utilisateur peut affiner le chemin en indiquant des objets additionnels ou en désélectionnant des objets mis en évidence. Le système affine alors le chemin pour respecter ces contraintes. Lorsque l'utilisateur est satisfait de la sélection d'objets, il précise pour l'un de ces objets (I' « objet modèle ») tous les attributs qui correspondront aux colonnes du tableau. Pour chaque attribut, un objet dans la page, un nom de colonne (qui peut être pris par défaut de la page elle-même) et, si nécessaire, l'attribut HTML à extraire (par exemple, pour les liens, il a le choix entre la La figure 7 présente une page Web présentant des vols d'avion pour laquelle l'utilisateur sélectionne un attribut « Vol Aller » à extraire. La figure 8 montre le fait que l'extracteur crée alors la première colonne « Vol Aller » du tableau extrait, correspondante à cet attribut. La figure 9 présente le tableau complet ainsi construit. La figure 10 montre un tableau construit selon la même méthode pour une autre page de compagnie d'aviation.
Le synthétiseur est l'inverse de l'extracteur, il est créé automatiquement au moment de la création de l'extracteur correspondant, et permet d'afficher les données d'un tableau dans le style de présentation de la page Web, des zones graphiques étant placées à l'emplacement des objets contenant les valeurs du tableau pour permettre de les déployer ou réduire ainsi que de les glisser-déposer pour créer un mappage comme décrit plus loin et illustré dans les figures 11 à 13.
Il est créé comme suit : L'utilisateur choisit un objet modèle correspondant à une ligne du tableau15. Tous les objets correspondant à d'autres lignes du tableau sont retirés de la page et tous les objets référencés par des objets correspondant à des lignes du tableau mais pas par l'objet modèle sont supprimés. Les valeurs contenues dans l'objet modèle sont modifiées pour correspondre à la première ligne du tableau, et une copie de l'objet est insérée à la suite avec les valeurs de chaque autre ligne à afficher.16
Pour un synthétiseur donné, à chaque colonne (affichée au moins une fois) peut être associé le plus petit objet ol (et donc le plus grand I, avec l≤l≤N) contenant tous les marqueurs d'attributs correspondant à cette colonne. Ceci permet d'ordonner les colonnes selon l'importance leur étant attribuée par le synthétiseur (une petite valeur de I indique une importance plus élevée). On peut ainsi estimer dans quelle mesure un synthétiseur est approprié pour un ordre de déploiement de colonnes, en comparant l'ordre de déploiement avec l'ordre d'importance de ces colonnes selon le synthétiseur. Lorsque le système donne la liste des synthétiseurs pour une source donnée, cette liste pourra être triée selon ce critère, en fonction de déploiements déjà effectués par l'utilisateur, afin de permettre la sélection du synthétiseur.
valeur de l'attribut href ou le texte du lien). Le système établit, pour chaque attribut, une paire (nom de colonne ; chemin), le chemin étant relatif à l'objet modèle, et enregistre cette information dans l'extracteur.
15 (celui ayant servi comme modèle au moment de la création de l'extracteur, comme décrit dans la note précédente)
16 Une approche de mise en œuvre est la suivante : appelons « objet synthétisé » le plus petit objet contenant l'objet modèle ainsi que tous les objets correspondant à un attribut de la ligne modèle (appelons ces objets « objets attributs »), et soit ol, o2, ..., oN la séquence d'objets dont chacun est parent du suivant, le premier est égal à l'objet synthétisé et le dernier égal à l'objet modèle. Une copie de l'objet synthétisé est effectuée, puis (dans le document lui-même) ses objets attributs sont modifiés pour correspondre à la première ligne affichée du tableau. Pour chaque ligne du tableau, est déterminé, dans l'objet synthétisé, le plus grand I (avec l≤l≤N) tel que ol contient tous les objets attributs correspondant à des cellules non vides de la ligne courante. Une copie de ol (et donc également de oJ pour tous les J>l) est créée, ses objets attributs sont modifiés pour refléter la ligne courante, et elle est insérée à la suite (comme frère) de la dernière copie de ol à avoir été placée dans le document.
A noter que L'utilisateur peut demander à modifier un synthétiseur. Le même procédé ci-dessus est alors appliqué en se basant sur un tableau à une ligne contenant les noms des colonnes au lieu de valeurs, avec des marques spéciales permettant de les distinguer de texte normal (par exemple, « ${auteur) » dans la colonne auteur, et ainsi de suite). L'objet modèle est repéré par des marques spéciales (par exemple <model-object>...</model-object>). L'utilisateur peut modifier le document résultant à sa guise, par exemple à l'aide d'un éditeur de texte, et le renvoie au système. Pour afficher la page synthétisée, le procédé ci-dessus utilise désormais cette nouvelle structure (à condition qu'il y ait exactement une zone délimitée par les marqueurs d'objet modèle). A noter cependant qu'il est autorisé à supprimer ou dupliquer des marqueurs d'attributs. Il peut supprimer l'affichage d'un attribut qu'il juge peu important, et un exemple de duplication est de placer un attribut une fois à l'intérieur de l'objet modèle et une fois à l'extérieur, afin d'avoir une entête utilisant cet attribut, tout en affichant la valeur de l'attribut à chaque ligne de la liste affichée. Une autre application est de mettre la même valeur « url » comme texte et adresse d'un lien hypertexte (i.e. <a href="Surl">$url</a>). Mappage d'Extracteurs
On va maintenant illustrer la création par l'utilisateur d'un mappage entre deux extracteurs préexistants. La figure 11 illustre la création par l'utilisateur d'un mappage entre deux pages de compagnies d'aviations pour lesquelles des extracteurs existent déjà. (Les extracteurs ayant par exemple été construits comme illustré dans les figures 7 à 10). Ayant ces deux pages respectivement ouvertes dans deux onglets différents du navigateur, l'utilisateur sélectionne l'option « Map with » pour créer un mappage entre la page courante et l'autre page.
Les deux pages sont alors présentées ensemble (l'un sous l'autre) et l'utilisateur peut ainsi mettre en correspondance les attributs présentées par l'extracteur pour ces deux pages par de simples glisser- déposer (figures 12 et 13). La figure 12 montre le fait de prendre l'objet graphique « Paris - Charles de Gaulle (CDG) » situé dans la deuxième moitié de la figure, et le glisser vers le haut de la figure. La figure 13 montre le fait de déposer l'objet glissé, sur l'objet graphique « Paris » situé sur la première moitié de la figure.
Description du Procédé de base de l'invention
Le scénario suivant sera utilisé en premier pour décrire le procédé de base de l'invention17. L'utilisateur accède à une source de données de départ (Sl) concernant des vols de Paris (CDG) à Delhi (DEL) et filtre sur un numéro de vol donné (AF12) ; une ligne présentant ce vol s'affiche (c'est la « partie visible » de Sl). Une deuxième source (S2) dont un mappage avec la première existe, se trouve dans le contexte et va l'enrichir. Pour faciliter la compréhension on suppose ici qu'entre Sl et S2 les noms d'attributs sont les mêmes et que donc le mapping est ici trivial (et pour les colonnes manquantes toutes leurs valeurs sont implicitement nulles). Sl et S2 ont les attributs suivants18 :
Sl : Flieht Dep Arr Class Price S2 : Flight Dep Arr Company (Class=Economy) Price
Les filtres respectifs des sources sont soulignés. Dans S2 il manque la colonne Class mais à l'extracteur de S2 est associée la méta-donnée que pour cet attribut la valeur est « Economy » (quelles que soient les lignes). De plus il a été donné pour S2 que l'attribut Flight détermine l'attribut Company en dépendance fonctionnelle (FD). Les données19 de départ sont les suivantes :
Sl (partie visible seule)
Figure imgf000013_0001
17 On va utiliser une série de scénarios spécifiques, tout en décrivant pour chacun le procédé dans sa généralité.
18 « Flight » veut dire « Vol », « Dep » veut dire « ville de Départ », « Arr » veut dire « ville d'Arrivée », « Class » veut dire « Classe » (ses valeurs pouvant être : « First » voulant dire « Première classe », « Business » « Classe affaire » et « Economy » « Classe économique »), « Price » veut dire « Prix du Vol », « Company » veux dire « Compagnie ». A noter que dans certaines lignes, la valeur dans la colonne Price représente un prix minimum et les valeurs que peut prendre cet attribut est représenté par une contrainte « > ... » (signifiant "supérieur à").
19 Bien sûr ces données sont complètement fictives.
20 Marque de la compagnie Air France
Figure imgf000014_0001
Dans cet exemple, le but initial de l'utilisateur est d'obtenir des offres alternatives pour des villes de départ (Dep) et d'arrivée (AIT) présentées dans la partie visible de Sl et ce sont donc ces attributs qui constituent le filtre (F) appliqué à S2.
Pour chaque ligne L 22 de la partie visible d'une source de départ Sl, le procédé que l'on va maintenant décrire va tout d'abord tenter de combiner des ligne R 23 de S2 sur la base d'au moins un attribut filtre F, en l'occurrence Dep et Arr (pour S2). Comme on le voit dans la colonne Price, dans les colonnes il peut y avoir des valeurs précises ou des domaines (ensemble de valeurs possibles).
Sélection
Pour enrichir la partie visible d'une source de départ Sl par une source secondaire S2 , au moins un attribut clé (ou filtre) F étant donné pour S2 (ou pour la ligne R considérée de S2) et l'attribut map(F) de Sl correspondant à F par mappage, une ligne R de S2 est sélectionnée pour enrichir une ligne L de Sl, si pour le (ou les) attribut clé F, le (ou les) attribut map(F) de Sl -après transformation le cas échéant associée au mappage- implique F de S2, c'est-à-dire que toute valeur que peut prendre map(F) peut aussi être prise par F.24
Alternatif
Un attribut A d'une ligne R de S2 sélectionnée est alternatif si
1. dans L, l'attribut map(A) correspondant à A, est présent (c'est-à-dire que cet attribut peut avoir une valeur non nulle ou peut prendre une valeur parmi un ensemble de valeurs possibles, par opposition aux attributs non présents dans Sl et qui ont donc forcément la valeur implicite NULL25) et
2. map(A) est potentiellement26 différent de A (et de préférence27 il n'existe pas dans Sl de ligne L' (autre que L) où la valeur de map(A) est égale28 à celle de A).
Le procédé d'enrichissement
Pour chaque ligne (L) de Sl, lorsqu'appliquer le filtre29 sur S2 résulte en la sélection d'une ou plusieurs lignes (R) de S2 qui comportent au moins un attribut alternatif, ces lignes sont mises -dans le résultat (SIr)- en relation avec la ligne L en question de Sl, avec éventuellement en plus l'information de leur provenance (Source - S2). Ainsi l'utilisateur peut notamment visualiser l'union avec L des lignes R qui l'enrichissent, présentée par exemple comme dans le tableau SIr suivant où pour chaque ligne R (ayant
21 Marque de la compagnie Air India
22 (L comme Left)
23 (R comme Right)
24 (et si les conditions supplémentaires de filtre le cas échéant données sont aussi vérifiées)
25 (signifiant « on ne connaît pas la valeur pour cet attribut »)
C'est-à-dire que map(A) a -ou peut prendre- une valeur différente de celle qu'a -ou peut prendre- A. Cette nuance est nécessaire puisque les attributs peuvent avoir ensembles de valeurs possibles plutôt que des valeurs instanciées.
27 Cette dernière condition peut être enlevée dans le cas de recherche de valeurs alternatives dans Sl par rapport à S2, puisque l'utilisateur n'accède pas à S2 directement mais via la pop-up widget qui lui est présentée (voir la description plus loin).
28 (ou plutôt n'est pas potentiellement différente)
29 II s'agit ici de filtrer S2 selon Dep(L) et Arr(L), L étant la ligne courante de Sl considérée. Source = S2) la colonne « Ref » indique l'identifiant (ID) de la ligne L avec laquelle est ainsi mise en relation :
SIr
Figure imgf000015_0001
Ceci permet de déterminer les lignes de S2 à présenter à l'utilisateur (par exemple dans une pop-up widget, dans le style des figures 1 à 3 au moyen du synthétiseur déjà décrit) en fonction de l'attribut qu'il sélectionne dans une ligne (de la partie visible) de Sl: seules les lignes contenant une valeur alternative pour l'attribut sélectionné lui sont présentées. Ainsi, comme le montre schématiquement la figure 14, lorsque l'utilisateur positionne30 la souris sur la représentation d'un attribut de L (en l'occurrence l'attribut Price) correspondant à un attribut alternatif dans une ou plusieurs lignes R (de S2 filtré selon le filtre associé à S2 mais ayant les valeurs correspondantes à ce filtre dans L, en l'occurrence Dep=CDG et Arr=DEL), cette ou ces dernières lui sont présentées spontanément, avec éventuellement en plus l'indication de leur provenance (Source = S2).
En parallèle, dans le cas où des dépendances fonctionnelles (FD) et/ou multivaluées (MVD) ont été définies pour S2, elles permettent d'enrichir les lignes de la partie visible de Sl et réciproquement les dépendances fonctionnelles (FD) et/ou multivaluées (MVD) définies pour Sl permettent d'enrichir les lignes ajoutées de S231. Dans cet exemple, comme il a été défini pour S2 que l'attribut Flight détermine l'attribut Company en FD, cet attribut est ajouté dans L (c'est-à-dire la valeur NULL de la première ligne de SIr est remplacée par « Air France ») :
SIr
Figure imgf000015_0002
Ce dernier enrichissement peut être présenté de manière distincte32, comme dans la figure 15 présentant le procédé de manière schématique (alors qu'en réalité l'information peut être présentée au moyen du synthétiseur déjà décrit).
Le même procédé peut se poursuivre en sens inverse (c'est-à-dire de S2 vers Sl). On suppose que Sl fournit en plus les lignes ci-dessous (hors de sa partie visible) pour les vols AF12 et AF13 :
30 (ou montre son intérêt pour un attribut par un moyen quelconque qui lui est offert à cet effet, ceci pouvant se faire directement au niveau de la page d'origine comme illustré aux figures 1 à 3)
31 Les lignes qui enrichissent sont sélectionnées selon la définition (« Sélection ») donnée à la page précédente, ici la clé « F » n'étant pas le filtre mais la clé (respectivement des dépendances fonctionnelles et multivaluées) donnée.
32 L'information de provenance (Source) nécessite d'avoir dans SIr une colonne supplémentaire pour chaque attribut fourni comme enrichissement par dépendance fonctionnelle ou multivaluée, ce qui n'est pas montré ici dans les tableaux SIr (pour éviter de les surcharger). Sl (hors partie visible)
Figure imgf000016_0001
Rappelons qu'ici le filtre appliqué à Sl est la colonne Flight (c'est le filtre qui a été spécifié pour cette source) avec les valeurs de S2 pour l'attribut correspondant à ce dernier. Le procédé se poursuit ainsi :
• Si pour l'une ou l'autre desdites lignes de S2 figurant dans SIr, il y a dans Sl au moins une autre** ligne correspondante (L') 34 comportant au moins une valeur alternative35, ladite ligne L' est mise en relation avec les lignes en question de S2, avec éventuellement en plus l'information de leur provenance (Source = Sl). L'utilisateur peut ainsi visualiser une union élargie comprenant les lignes en question de Sl et S2, présentée comme dans le tableau suivant (les lignes L' sont ici légèrement grisées pour les distinguer) où, pour chaque ligne L' (ayant Source = Sl) ajoutée, la colonne Ref donne l'identifiant (ID) de la ligne R avec laquelle elle est en relation ;
• Les dépendances FD et/ou MVD déclarées permettent d'enrichir les sources de part et d'autre. En l'occurrence, la FD de S2 permet d'enrichir les nouvelles lignes (de Sl) ajoutées dans SIr en fournissant l'attribut manquant Company.
SIr
Figure imgf000016_0002
Ceci permet de déterminer les lignes de Sl à présenter à l'utilisateur en fonction de l'attribut sélectionné dans (directement comme dans la figure 14, mais optionnellement toujours via le synthétiseur) dans la pop-up widget qui présente les lignes de S2: seules les lignes36 de Sl contenant une valeur alternative lui sont présentées. Ainsi, comme le montre schématiquement la figure 16, lorsque l'utilisateur vise au moyen d'un dispositif de pointage (telle que la souris) la représentation d'un attribut de R (dans la figure 16, c'est l'attribut Price) présentée comme dans la figure 14, correspondant (pour Flight=AF13) à un attribut alternatif dans (un ou) des lignes L de Sl, ces dernières lui sont présentées spontanément, avec éventuellement en plus l'indication de leur provenance (Source = Sl).
Comme le montre la figure 17, la dépendance fonctionnelle de S2 selon laquelle l'attribut clé Flight détermine l'attribut Company, permet d'enrichir la ligne (parmi les dernières lignes de Sl ajoutées dans SIr) visée au moyen d'un dispositif de pointage.
33 (autre qu'une ligne L déjà présente dans la partie visible)
34 Sl retourne L' en réponse à une requête utilisant le filtre Flight, ce dernier prenant la valeur de l'attribut (Flight) correspondant de la ligne en question de S2.
35 (ici par exemple Price(L') est alternatif)
36 (parmi celles filtrés selon le filtre associé à Sl mais avec la valeur correspondante à ce filtre dans R) Enrichissement d'un résultat d'enrichissement
Un résultat d'enrichissement peut lui-même être enrichi.37 Ainsi, dans le cas où par exemple une troisième source (S3) dont un mappage avec Sl ou S2 est disponible (et se trouve dans le contexte), le procédé se poursuit. Les sources ont maintenant les attributs suivants :
Sl : Flight _Dep Arr Class Price
S2 : Flight Dep Arr Company (Class=Economy) Price
S3 : Flight Class Legroom Airplane Meal
Airplane dépend de Flight en FD ; Legroom dépend de Flight et Class en FD ; Meal dépend de Flight et Class en MVD.
Dans la mesure où les valeurs de l'attribut Class de S3 sont les mêmes que celles données dans Sl et S2 (pour l'attribut Class correspondant), et du fait que les trois autres attributs (Legroom, Airplane et Meal) manquent dans Sl et S2, aucune ligne alternative ne peut être trouvée dans S3 par rapport aux lignes du résultat d'enrichissement (SIr) obtenu jusqu'ici.
Si on ne considérait que les attributs Airplane et Legroom (si on ignorait Meal), on obtiendrait les enrichissements suivants :
SIr
Figure imgf000017_0001
Mais comme l'attribut Meal est multivalué (Flight et Class déterminent Meal en MVD ; en effet à chaque vol correspondent plusieurs plats, tels que « Veg » et « Non-veg », et ceci en fonction des classes), une ligne doit être ajoutée pour chaque valeur supplémentaire de Meal :
SIr
Figure imgf000017_0002
37 Enrichir (par S2) un résultat d'enrichissement résultant de Sl,sr,Sl", etc. (Sl' étant le résultat d'enrichissement de Sl, Sl" le résultat d'enrichissement de Sl', et ainsi de suite) tire potentiellement parti de la pluralité des ensembles de filtres candidats et/ou clés de dépendances associés à l'ensemble des différentes sources en jeu.
Figure imgf000018_0001
Ces derniers enrichissements peuvent être présentés de manière distincte, comme à la figure 1838:
Comme déjà mentionné, le contenu des pop-up widgets présentées schématiquement dans les figures 14 à 18 peut être généré par un synthétiseur (décrit plus haut) pour tirer parti des présentations d'origine des sources respectives (comme montré dans les figures 1 à 3). Les deux enrichissements (respectivement par S3 et S2) présentées schématiquement à la figure 18 peuvent être présentés dans deux onglets distincts d'un même pop-up widget, chaque onglet ayant comme étiquette la source (S2 ou S3) en question et présentant son contenu comme dans la source d'origine (comme dans le style graphique des figures 1 et 2).
Ajout de lignes ayant une référence à une ligne d'enrichissement
Chaque ligne de S2 (resp. Sl), qui a au moins un attribut ayant au moins une référence directe ou indirecte à au moins une ligne de S2 (resp. Sl) qui a été ajoutée dans SIr, y est ajoutée (dans SIr) à son tour. Elle n'y est cependant pas ajoutée en cas d'inconsistance de l'ensemble des contraintes en jeu. Le fait de l'ajouter entraîne la poursuite du procédé décrit jusqu'ici, comme on le décrit maintenant en étendant le scénario vu jusqu'ici.
Reprenons donc le même exemple avec Sl et S2, et ajoutons les attributs heure de départ (DepT) et heure d'arrivée (ArrT), qui sont en dépendance fonctionnelle de Flight,
51 : Flight Dep Arr DepT ArrT Class Price
52 : Flight Dep Arr DepT ArrT Company (Class=Economy) Price ainsi que deux lignes dans S2 :
• un vol AF14 qui attende à DEL l'arrivée du vol AF12, son départ pour Singapour (SIN) étant prévu Ih après l'arrivée du vol AF12 et son arrivée à SIN étant prévu 3 heures plus tard ;
• et un vol AF15 qui attende à DEL le départ du vol AF14, son départ pour SIN étant prévu 2h après le départ du vol AF14 et l'arrivée à SIN étant prévu 3 heures plus tard.
Les données sont maintenant les suivantes : Sl (partie visible seule)
Figure imgf000018_0002
38 Comme signalé plus haut, l'information de provenance (Source) nécessite d'avoir dans SIr une colonne supplémentaire pour chaque attribut fourni comme enrichissement par dépendance... S2 (supposons qu'il n'y ait que ces 6 lignes dans S2)
Figure imgf000019_0001
Les cellules de S2 ont chacun un identifiant composé de la lettre de la colonne et du numéro de ligne, comme dans un tableur. On voit que par exemple la cellule D3 contient une formule « =E1+1 », comme dans un tableur, qui est ici une contrainte d'égalité (D3=E1+1).
On suppose dans cet exemple que les lignes 3 et 4 de S2 ne peuvent être enrichies (par dépendance fonctionnelle) par aucune ligne de Sl (Sl ne fournissant aucune ligne avec Flight AF14 ou AF15).
L'enrichissement de Sl par S2 va résulter en un tableau SIr comme ci-dessous, les lignes en grisés étant les lignes alternatives de Sl (comme dans l'exemple précédent), et les septième et huitième lignes (correspondant aux lignes 3 et 4 de S2) étant maintenant ajoutées du fait qu'elles ont (directement ou indirectement) une référence à la deuxième ligne de SIr (correspondant à la ligne 1 de S2) :
SIr
Figure imgf000019_0002
En effet, bien que ne correspondant pas aux filtres Dep=CDG et Arr=DEL, les lignes 3 et 4 de S2 font partie de l'ensemble de lignes pertinentes pour l'utilisateur car elles ont une référence à au moins une ligne (de S2) enrichissant Sl. A noter que si dans Sl il y a des lignes ayant une référence à des lignes ajoutées dans SIr dont la Source est Sl, elles sont également ajoutées dans SIr, et ensuite de nouvelles lignes de S2 (alternatives par rapport à elles) sont ajoutées à leur tour (dans la mesure où elles ne sont pas invalidées par des dépendances fonctionnelles de Sl), et ainsi de suite...39
Toutefois, si plus tard dans ce même scénario, Sl fournit en plus la ligne ci-dessous Sl (hors partie visible)
Figure imgf000019_0003
39 La profondeur max de cette boucle peut être donnée en paramètre. alors, à cause du fait que l'attribut Flight détermine l'attribut DepT en FD, la ligne 8 de SIr est invalidée (la ligne 4 de S2 ne peuvent plus enrichir Sl), car l'ensemble courant de contraintes (D3=E1+1, D4=D3+2, etc. ) qui résulte en D4=2 est inconsistant avec D4=l, et la ligne 4 de S2 dépend de cet ensemble de contraintes du fait qu'elle a une référence à la ligne 3 (D4=D3+2). SIr ne contiendrait alors que les lignes suivantes .«.
SIr
Figure imgf000020_0001
Bien évidemment, si une autre ligne encore avait une référence à la ligne 8 qui a été invalidée, elle est aussi retirée de SIr.
M éta-attributs temporels
On peut mémoriser différents enrichissements effectués dans le temps et les comparer, grâce à deux méta-attributs temporels: BS (Belief Start, ou « Valide depuis ») et BE (Belief End, ou « Valide jusqu'à »).
Supposons que les premiers enrichissements ci-dessus (avant la fourniture du vol AF15 par Sl) aient eu lieu au temps 1 et que le dernier enrichissement à la suite de l'ajout dans Sl du vol AF15 ait eu lieu au temps 3. SIr est alors comme suit41. On y voit que les lignes 7 et 8 ne sont plus valides, vu que leur méta- attribut BE est à la valeur 3:
SIr
Figure imgf000020_0002
Bien évidemment, ces méta-attributs peuvent ne pas être montrés à l'utilisateur, à condition de cacher aussi les lignes qui ne sont pas valides à la date considérée (ici appelée « wall-clock time »). Cette
Cette nouvelle ligne de Sl va néanmoins être ajoutée en tant qu'alternative à la ligne 4 de S2. Ceci n'est pas montré afin d'alléger la description. Un tel cas de figure est montré plus loin.
41
Si l'on ne tient pas compte de la ligne alternative ajoutée en tant qu'alternative à la ligne 4 de S2, comme déjà mentionné. approche permet de se positionner à une date wall-clock time du passé et de voir les données d'enrichissement (SIr) valides à cette date. Par exemple, lorsque l'utilisateur se positionne à la date wall- clock time = 2, il revoit le tableau suivant (qui était montré plus haut):
SIr
Figure imgf000021_0002
alors que lorsque l'utilisateur se positionne au temps présent Wall-clock time = NOW (supérieur à 3) les lignes 7 et 8 y sont retirées. Il suffit pour cela de ne prendre de SIr que les lignes dont le Wall-clock time est compris entre BS et BE.
Plusieurs enrichissements peuvent ainsi être visualisés (et comparées) en faisant varier la variable Wall- clock time (par exemple au moyen d'un curseur temporel). On va maintenant voir un autre scénario où différentes lignes peuvent être regroupées selon un critère donné, et certains attributs agrégés, et dans lequel cette possibilité de comparer plusieurs jeux d'enrichissements peut être mise à profit.
Exemple
Les sources que l'on va utiliser ont les attributs suivants :
Date Price
Figure imgf000021_0001
Date Price Scénario
Chaque ligne de ces sources concerne disons une action, d'un groupe (Group) donné, effectuée dans un pays (Country) donné, à une certaine Date pour un certain prix (Price).
L'attribut Date de S2 est spécifié comme ayant le type « Temps Réel », ce qui signifie que cet attribut représente la date d'occurrence réelle de la donnée à enrichir, ce qui permet d'avoir la contrainte Date > NOW lorsqu'elle est (tentativement) ajoutée dans le résultat du fait d'une référence de (ou vers) une autre ligne ajoutée dans le résultat, tant qu'elle n'est pas combinée avec l'autre source qui lui donne alors sa date réelle d'occurrence.
Enfin, Group et Country déterminent les attributs Date et Price en FD tant dans Sl que dans S2. Les données sont les suivantes : Sl (partie visible seule)
Figure imgf000021_0003
S2 (supposons qu'il n'y ait que ces 6 lignes dans S2)
Figure imgf000022_0001
S2 est ici utilisé pour spécifier des scénarios ; chaque scénario étant un modèle de prédiction dans le temps pour un groupe (Group) d'actions donné. Ainsi on voit, dans l'attribut Date des lignes de S2, des contraintes de séquence (telle que C2>C1, C2<C3) entre lignes, avec des durées maximum entre elles (telle que C2≤C1+12), ainsi que des données par défaut (telles que default:Cl+12) à présenter à l'utilisateur dans le résultat, lorsque la date en question n'est pas instanciée. La colonne Price contient également des contraintes et des valeurs par défaut.
Comme les attributs Group et Country déterminent les attributs Date et Price en FD, la première ligne de S2 peut ici s'unifier avec celle de Sl 42 et amène avec elle les autres lignes de S2 qui en ont une référence directe ou indirecte :
SIr
Figure imgf000022_0002
Les contraintes « > NOW » ont été ajoutés pour l'attribut Date du fait que cet attribut est de type « Temps Réel » et que ces lignes ne sont pas encore enrichies par une ligne de Sl.
Plus tard, supposons que Sl fournisse en plus la ligne ci-dessous Sl (hors partie visible)
Figure imgf000022_0003
Par « Comme les attributs Group et Country déterminent...» on entend : Pour déterminer si la dépendance fonctionnelle spécifiée pour S2 (« Group et Country déterminent les attributs Date et Price en FD ») peut être exploitée, le procédé vérifie si les attributs dans Sl correspondant à Group et Country de S2 impliquent ces derniers, c'est-à-dire que pour toutes leurs valeurs potentielles dans la ligne considérée de Sl, ces attributs prennent aussi ces valeurs dans la ligne considérée de S2. En l'occurrence, le deuxième a été donné de manière instanciée (et non pas sous forme de domaine), et cette vérification revient donc à un simple test d'égalité, et tout implique NULL. Par « ... déterminent les attributs Date et Price en FD, la première ligne de S2 s'unifie avec celle de Sl... » on entend : Les contraintes données respectivement sur ces attributs dans la première ligne de S2 sont'ajoutées à l'ensemble de contraintes pour les attributs correspondants respectifs de la ligne en question de Sl. Ceci permet alors d'inférer (par FD 43) que la date des lignes EP est 02/2009 ". Or le temps courant (NOW) étant maintenant forcément supérieur à 02/2009 (puisque l'attribut Date de la ligne EP correspond à l'insertion de cette ligne en « temps réel ») et la Date de la deuxième ligne de SIr devant être supérieure à NOW (selon la contrainte « >N0W »), elle doit être supérieure à 02/2009, et par conséquent la deuxième ligne vient après la troisième (dont la Date est égale à 02/2009), ce qui contredit la contrainte C2<C3 donnée dans la colonne Date de la deuxième ligne. Par conséquent les deuxième et troisième lignes sont invalidées et dans SIr il ne reste plus que la première, la quatrième et la cinquième ligne. La quatrième ligne est par ailleurs enrichie en FD pour préciser ses valeurs Date et Price (déterminées en FD). En plus, la nouvelle ligne de Sl est ajoutée (ID=6 dans le tableau) en tant que donnée alternative45 à la ligne 4 de S2.
SIr
Figure imgf000023_0001
Enfin, le procédé peut comprendre une dernière étape qui (optionnellement) unifie les lignes de SIr qui peuvent l'être (c'est-à-dire lorsque le fait de combiner leurs contraintes respectives ne mène pas à une inconsistance), en l'occurrence les lignes 4 et 6:
SIr
Figure imgf000023_0002
II est aisé de calculer le total des prix (Price) comme illustré dans la dernière ligne du tableau ci-dessus.
Si les méta-attributs BS et BE sont utilisés, en supposant que les premières données aient été insérées au temps 1 et que les nouvelles données aient été insérées au temps 3 (Sl ayant fourni une ligne « EP » au temps 3, comme ci-dessous),
Sl (hors partie visible)
Group Country Date Price BS BE
A EP 02/2009 155 3
on a le tableau SIr suivant : SIr
Figure imgf000023_0003
II s'agit ici d'enrichir S2 par Sl, du fait de la FD selon laquelle Group et Country déterminent Date et Price.
(en combinant les contraintes des colonnes Date respectives de Sl (nouvelle ligne) et S2 (3e et 4e lignes))
45 Elle aurait directement été enrichie par la ligne 4 si cette dernière était dans la partie visible de Sl.
Figure imgf000024_0001
Ainsi, si on place le Wall-clock time au temps 2 et on souhaite voir la prédiction faite à ce temps la, on voit le tableau SIr suivant (où la ligne 6 n'existait pas encore). Il suffit pour cela de filtrer sur les lignes ayant le temps 2 compris entre BS et BE (puisque pour la ligne 6, le BS était égal à 3) :
SIr
Figure imgf000024_0002
La présentation des résultats peut permettre le regroupement/déploiement sélectif de lignes de Sl (resp. S2) et les lignes de SIr sont alors regroupées/déployées en conséquence. Lorsque les lignes de Sl (resp. S2) regroupent une pluralité de lignes et agrègent leurs valeurs, SIr agrège les lignes enrichies de la même manière.
Ajout de lignes auxquelles des lignes d'enrichissement ont une référence
Le cas des lignes d'enrichissement ayant une référence à d'autres lignes qui sont des conditions est décrit à travers l'exemple suivant :
Les sources que l'on va utiliser ont les attributs suivants :
51 : Person Parent
52 : Person Sibling Parent
Les attributs sont une personne (Person), son frère (Sibling), son parent (Parent).
Dans S2, Person détermine Sibling et Parent en MVD.
Les données sont les suivantes :
Sl (les personnes a et b ont tous deux c comme parent)
Figure imgf000024_0003
S2 (deux personnes qui ont le même parent sont frères).
Figure imgf000024_0004
Figure imgf000025_0001
On introduit ici un nouveau concept, celui des lignes « Conditions ». Ce sont les lignes ayant « Condition » en dernière colonne (grisées dans le tableau ci-dessus).
Les lignes Conditions ont le rôle de clé élargi, en ce sens que toutes leurs colonnes doivent être impliquées par des lignes de l'autre source, pour permettre aux lignes y faisant référence d'être éligibles à enrichir l'autre source.
Lors du procédé d'ajout dans SIr d'une ligne alternative de S2 (resp. Sl), ou d'enrichissement en FD ou MVD par une ligne de S2 (resp. Sl), les lignes Condition de S2 (resp. Sl) sont tout d'abord ignorées, puis celles dont ladite ligne de S2 (resp. Sl) fait référence sont prises en compte (et ainsi de suite, par « chaînage arrière »), mais à condition que tous leurs attributs soient impliqués par les attributs des lignes correspondantes dans Sl (resp. S2) et que bien sûr l'ensemble de contraintes soit consistant.
Ainsi, dans le présent exemple, la ligne 3 de S2, qui permet d'enrichir en MVD chaque ligne de Sl, amène avec elle tous les cas de combinaison de lignes Conditions impliquées par des lignes correspondantes dans Sl. Ceci donne le tableau SIr suivant :
SIr
Figure imgf000025_0002
Enfin, le même procédé d'unification de lignes de SIr présenté avec l'exemple précédent permet d'unifier les lignes 3 et 5 avec la ligne 1, ainsi que les lignes 2 et 6 avec la ligne 4 :
SIr
Figure imgf000025_0003
Ainsi, l'enrichissement par S2 permet d'ajouter dans Sl les valeurs manquantes pour l'attribut Sibling (respectivement b et a) de Person (respectivement a et b).
On va maintenant décrire la mise en œuvre globale du procédé, sachant que les cas vus dans les exemples ci-avant peuvent être mixés, par exemple des lignes peuvent avoir des références vers des lignes qui servent à enrichir (comme dans l'exemple des vols et aussi dans l'exemple de la planification d'actions), tout en ayant des références sur des lignes Conditions. Mise en œuvre de la résolution des contraintes
Le non-déterminisme (la combinatoire des jeux possibles de lignes à ajouter à SIr) inhérent au procédé d'enrichissement en présence de contraintes ayant des références interligne, peut être traité par l'approche récursive décrite ci-dessous. Toutes les lignes de la partie visible SIv et toutes les lignes alternatives candidates de S2 (puis de Sl), ainsi que leurs contraintes (classiquement par des instructions « solvertell »46), étant déjà introduites dans SIr dans la mesure où leurs contraintes n'engendrent pas d'inconsistance, l'enrichissement des lignes respectives de Sl (resp. S2)47 aura l'allure suivante : foreach L in SIv rows or in alternative Sl rows... foreach R in S2 en ignorant les lignes Condition foreach FD (FD: KeysS2- >cois) (et même approche pour les MVD et les lignes alternatives) sol ver: push mark if soiver : (Map (κeys2 (L) ) =>8 κeyS2 (R) ) pour tout KeyS2 dans KeysS2 solver: tell ' s (Map(KeyS2 (L) ) = KeyS2 (R) ) pOUrtOUt KβyS2 if (do solver: tell' s to merge in L the FD Cols of F? Détermine ReferredRows by transitive closure CheckReferredRows (ReferrecRows, { } ,L,R) soiver : undo(i.e. défaire les solvertell depuis le dernier "soiver : push mark")
Les lignes R de S2, susceptibles d'enrichir par FD 49 les lignes L de Sl, étant ainsi trouvées (ci-dessus), il faut vérifier pour chaque R que ses lignes Conditions (dans S2), le cas échéant, ont des correspondants dans Sl, il faut ensuite ajouter les autres lignes le cas échant auxquelles R fait référence, ainsi que les lignes ayant une référence à R, et les utiliser pour enrichir des lignes L par leurs FD, MVD et lignes alternatives :
CheckReferredRows (ReferredRows, AccumulatedRows, L, R) { if (ReferredRows is empty) add L to sir (if L is not NULL) (L est déjà enrichie des colonnes en FD) foreach X in AccumulatedRows add X to SIr foreach R' = row referring X (if X is from S2 and L is not NULL) checkRef errin^ow (R' ) (éviter si R' a déjà servi) foreach MVD (MVD: KeysS2->Cols) solver : push mark if soiver : (Map (κeyS2 (L) ) => κeyS2 (R)) pour tout KeyS2 dans KeysS2 create L1 from L with ail cols of L except MVD Cols whichare taken from R (L' est construite avec des soiver : tel 1) add L 1 to SIr
46 (consistant à ajouter/propager la contrainte en question dans l'ensemble des contraintes)
47 De manière symétrique, exécuter le même algorithme pour enrichir les lignes de S2 ajoutées dans SIr, etc.
48 Ce test peut être omis si les attributs Map(KeyS2(L)) et KeyS2(R) sont instanciés, puisque le test solveπtell (Map(KeyS2(L)) = KeyS2(R)) est ajouté juste après (puisque si le premier échoue, le second échoue aussi). Un test Xl Op Exprl => X2 Op Expr2 revient à détecter Store U { Xl Op Exprl } |= Xl Op Expr2 (le Store est l'ensemble de contraintes courant). Ceci est équivalent à Store U { Xl Op Exprl } U { Xl -Op Expr2 } est inconsistant.
49 En plus, prendre les lignes R impliquées par L sur la clé MVD, ainsi que les lignes R impliquées sur le Filtre. Solver : undo foreach R' = row referring R checkRef errin^ow (R' ) (éviter si R1 a déjà servi) else let R' be the lst row of ReferredRows if R' is a condition row (toutes les colonnes sont clé) foreach L1 in Sl solver: push mark if solver : (Map (Col (L' ) ) => CoI (R' ) ) POUr tOUtβS IθS COloπnβS solver : tell ' s (Map(Col (L ' ) ) = CoI (R' ) ) pour tOUtβS IθS COlonnβS if (do solver : tell ' s to merge in L' the FD Cols of R') then
CheckReferredRows (Ref errecKows - {R 1 } , AccumulatedRows + (L' } , L, R) solver : undo eise (R' n'est pas une Condition) found = false foreach L1 in Sl solver: push mark if solver: (Map (κeyS2 (L' ) ) => κeyS2 (R' ) ) pour tout KeyS2 de FD:KeysS2 (et found = true poursuivre l'approche pour les MVD et les lignes alternatives) solver: tell 's (Map(KeyS2 (L' ) ) = KeyS2 (R') ) pour tOUt KeyS2 if (do solver : tell' s to merge in L' the FD Cols of R') then
CheckReferredRows (ReferredRows - (R1 }, AccumulatedRows + (L' }, L, R) solver : undo if (found = false) solver: push mark if (solver: tell constraints of R1) foreach col X that has type "real-time" solver:tell X > now
CheckReferredRows (ReferretKows - (R' }, AccumulatedRows + (R' }, L, R) solver :undo
La fonction suivante sert essentiellement à ajouter dans SIr chaque ligne Ref erringRow qui aurait une référence à une ligne trouvée jusque là (après avoir vérifié la consistance de ses contraintes):
CheckReferringRow (R' ) { found = false foreach L1 in Sl solver: push mark if solver: (Map(κeyS2 (L' ) ) => κeyS2 (R' ) ) pourtout KeyS2de FD:KeysS2 (et found = true poursuivre l'approche pour les MVD et les lignes alternatives) solver : tell ' s (Map(KeyS2 (L ' ) ) = KeyS2 (R') ) pour tout KβyS2 if (do solver : tell ' s to merge in L' the FD Cols of R') then
Détermine ReferredRows by transitive closure(éviter œUX qui Ont déjà Sβrvi) CheckRef erredRows CRef erredRows , { } , L' , R' ) solver : undo if (found = false) solver : push mark if ( solver : tell constraints of R 1) foreach col X that has type "real-time" solver :tell X > NOW
Détermine ReferredRows by transitive closure(év'lter ceUX qui Ont déjà Servi) CheckRef erredRows (ReferredRows , { R' } , NULL1 R' ) solver :undo
L'algorithme ci-dessus donne la méthode pour cumuler les contraintes et ne garder que les jeux de lignes consistants entre eux. Il peut aisément être étendu pour déceler les lignes alternatives et les enrichir comme décrit en détail plus avant. L'homme du métier (connaissant l'art des solveurs de contraintes) a maintenant tous les éléments pour mettre en œuvre le procédé d'enrichissements et d'unifications décrit jusqu'ici et d'y intégrer des solveurs de contraintes (tels que sur les réels, les entiers, les booléens, les chaînes de caractères (strings), les listes, etc.) de l'état de l'art.
Contexte
Le contexte est l'ensemble des sources S2 à prendre en compte pour enrichir Sl dans la mesure où un mappage avec Sl est disponible. Le procédé prévoit que le mode de constitution du contexte soit paramétrable par l'utilisateur et puisse notamment inclure les pages figurant dans la même instance du navigateur et/ou les pages accédées les plus récemment, éventuellement triées selon leurs contenus et/ou leurs méta-données.
La sélection des sources du contexte pour enrichir une source courante accédée peut tenir compte des informations de « contexte local » telles que de géolocalisation, qui seront utilisées comme critères pour sélectionner des sources S2 en fonction de leurs méta-données ou de leur contenu.
La dite sélection tient bien entendu aussi compte du contenu des sources composant le contexte de l'utilisateur lui-même ou de ses « proches », ladite proximité incluant des critères de proximité géographique, des relations explicitement données et/ou des comptages d'utilisation effective de mappages comme décrit à la page suivante.
On va maintenant décrire certains principes de calcul sous-jacents à la sélection de mappages à suggérer à l'utilisateur.
Stockage local : quand un utilisateur crée un mappage entre deux extracteurs, on va le lui proposer en premier. Quand un utilisateur a utilisé un mappage, on veut la lui reproposer quand l'occasion se présente. Chaque utilisateur doit ainsi stocker tous les mappages qu'il a (récemment) utilisés.
Comptage d'utilisations : Quand beaucoup d'utilisateurs ont utilisé un mappage on va le proposer à tous les utilisateurs. On donne comme « score » à un mappage possible le nombre de fois qu'il a été appliqué, puis, au moment de donner des suggestions, on ne propose que les mappages ayant le score le plus haut. Le serveur stocke ainsi une table contenant le nombre d'utilisations pour chaque mappage.
Comptage de « refus » : Quand beaucoup d'utilisateurs ne donnent pas suite à cette suggestion on va cesser de le proposer automatiquement.
Le score d'un mappage peut maintenant être calculé selon une expression telle que s(U,R,S)=Min(U- R,K*U/S) (U nombre d'utilisations, R nombre de refus et S nombre de suggestions ; K constante). Le serveur stocke ainsi une table contenant ces trois nombres pour chaque mappage.
Prise en compte des valeurs : Une utilisation de mappage compte plus si une ou plusieurs des colonnes mises en correspondance ont la même valeur que dans le cas courant. Stocker côté serveur une table (page source, identifiant de mappage, identifiant de colonne Filtre ou Clé, valeurs source, nombres de mappages, nombre de suggestions). Lorsqu'il n'y a qu'une colonne de Filtre, on incrémente le compteur pour la ligne correspondante. Lorsqu'il y a plusieurs colonnes de Filtre, chaque paire colonne-valeur a son propre compteur et tous sont incrémentés indépendamment. Afin d'éviter que cette table ne devienne trop grande, les lignes ayant les plus petites fréquences d'utilisation sont supprimées (la fréquence étant le rapport du compteur d'utilisation sur le temps d'existence de la ligne dans la table)
Pour tenir compte de cette information, on effectue l'addition sv(U...,R...,S...)=s(U,R,S) + max(0,s(U',R',S'))+max(0,s(U",R",S"))+..., avec un terme pour chaque colonne de Filtre et un terme indépendamment des valeurs (U', R' et S' etc sont définis comme U, R et S, mais ne comptant que les fois où la valeur a correspondu).
Tenir compte des proximités des autres utilisateurs : si deux utilisateurs sont proches on suppose qu'ils vont vouloir établir les mêmes mappages, et donc on peut pondérer leurs comptages d'utilisation, création et refus par les proximités à l'utilisateur courant. La proximité entre deux utilisateurs peut notamment être calculée en comparant les différences entre les ensembles de mappages qu'ils ont utilisées. On conserve donc dans le serveur une liste complète des mappages effectués par un certain nombre d'utilisateurs « représentatifs ». Lorsque le nombre d'utilisateurs est réduit, ils sont tous considérés représentatifs. Lorsqu'il augmente, on cherche une paire d'utilisateurs très proches l'un de l'autre et retire l'un des deux de l'ensemble des représentatifs. On stocke pour tous les utilisateurs leurs proximités à tous les utilisateurs représentatifs. Un utilisateur est considéré proche d'un autre si leurs vecteurs de proximité aux utilisateurs représentatifs sont proches (la proximité p(t,u) de deux utilisateurs t et u est l/∑(ti-ui)2, où ti est la proximité de t à l'utilisateur représentatif i. Cette dernière est obtenue par le rapport entre le nombre de mappages utilisés en commun (intersection) sur le nombre de mappage total utilisé par les deux utilisateurs (union)). Ceci étant connu, la partie client d'un utilisateur peut se connecter directement aux autres utilisateurs proches, et calculer pour chacun le score des différents mappages en ne tenant compte que des utilisations, suggestions et refus concernant cet utilisateur, puis effectuer une moyenne pondérée par la proximité de cet utilisateur : st=sv(U...,R...,S...)+ pl*sv(Ul...,Rl...,Sl...)+ p2*sv(U2...,R2...,S2...)+..., où pi, .... pN sont des nombres positifs ayant pour somme 1 et correspondant aux proximités des utilisateurs proches, « Ui... » représente Ui,Ui',Ui",... et représente les nombres d'utilisation U, U', U", ... etc, concernant l'utilisateur i, et similairement pour R et S.) Afin de décharger le serveur (et limiter la quantité de données fournies au serveur par les utilisateurs) on peut, lorsqu'un nombre suffisant d'utilisateurs proches sont connus pour un utilisateur donné, ignorer le terme global sv(U...,R...,S...).
Chaque utilisateur stocke ainsi l'ensemble de ses utilisateurs proches, qu'il redemande au serveur à intervalles réguliers (en effet, cet ensemble peut changer au cours du temps. Par exemple lorsqu'un utilisateur n'a pas été vu en ligne pendant trop longtemps on peut le retirer de tous les ensembles d'utilisateurs proches, et il faut alors trouver des nouveaux utilisateurs pour le « remplacer »).
Pour préserver l'anonymat des utilisateurs, plusieurs solutions sont possibles :
• Les utilisateurs ne se connectent pas directement à leurs proches mais font transiter tout le trafic par le serveur.
• La méthode précédente permet au serveur de connaître toutes les données. On peut remédier à cela en chiffrant toutes les données (tous les utilisateurs auraient ainsi une clé privée inconnue du serveur, et une clé publique accessible à tous les utilisateurs à partir de l'identifiant de l'utilisateur correspondant).
• Comme cette solution peut imposer une charge élevée au serveur, le protocole suivant peut être utilisé : A veut contacter B. A envoie l'identifiant de B au serveur. Le serveur choisit un utilisateur I différent de A (idéalement un utilisateur connu pour avoir une bonne bande passante et qui n'est pas déjà engagé dans ce protocole avec d'autres utilisateurs). Le serveur fournit à I les adresses IP de A et B avec un numéro de connexion, l'informant ainsi qu'il a été choisi comme intermédiaire. Le serveur envoie à A l'adresse de I et l'identifiant de connexion. La machine A envoie les données à I, qui peut alors les relayer à B sans que A ne connaisse l'adresse de B, et sans que I sache l'identifiant d'utilisateur de B (il ne connaît que son adresse ip).
A noter que, quelle que soit la stratégie utilisée, un utilisateur proche n'étant pas en ligne au moment de l'exécution de l'algorithme ne pourra pas être consulté. Il est donc nécessaire de tenir à jour un ensemble suffisamment grand d'utilisateurs proches afin qu'à tout instant, un nombre suffisant soit disponible.
Transitivité (exécuté côté client) : quand on propose un mappage A-B et B proposerait un mappage B-C, on peut vouloir proposer A-C directement. Le score d'une telle chaîne d'e mappages est obtenu en multipliant les scores des éléments de la chaîne et en divisant par MΛ(n-l), où M est le plus grand score sv rencontré (parmi tous les mappages considérés) et n est le nombre de éléments dans la chaîne. Ceci est équivalent à calculer si * s2/M * s3/M *..., où chaque facteur sauf le premier est plus petit ou égal à 1 (M étant le maximum des scores rencontrés), et l'ensemble des « si » parcourt l'ensemble des scores des éléments de la chaîne. Le score est donc plus petit ou égal au score de tous les éléments de la chaîne, et le score d'une chaîne de longueur 1 est précisément le score de l'unique élément qu'elle contient. Deux chaînes ayant les mêmes extrémités et dont la combinaison des mappages de colonnes fournissent le même résultat sont considérées équivalentes, et dans ce cas une seule chaîne est proposée, celle dont le score est le plus élevé.
Exemples
Ainsi de nouvelles sources de données peuvent être combinées automatiquement par défaut, pourvu qu'elles aient déjà été (mappés et) combinées précédemment. Par exemple, un utilisateur crée lui-même une source de données "Vendeur2" (par exemple à partir d'une source déjà existante, en l'occurrence à partir de "Vendeur!.") et présente l'offre de vente d'un livre "Auteurl" "Titrel" (par exemple un livre d'occasion qu'il voudrait revendre). Un autre utilisateur qui accède à "Vendeurl" prend connaissance de l'offre de "Vendeur2" par le simple fait qu'un nombre relativement grand d'autres utilisateurs ont déjà combiné "Vendeur2" avec "Vendeurl" et mis leurs colonnes respectives en correspondance.
Un critère de sélection peut être le méta-attribut BS (« Valide depuis ») déjà décrit, représentant le temps de première apparition de la ligne. Si l'offre de "Vendeur2" est la plus récente, ledit autre utilisateur verra l'offre de "Vendeur2" au lieu des offres des autres vendeurs ; sinon, il pourra la voir en se déplaçant dans le passé (en déplaçant un curseur temporel « Wall-clock time »). Dans cette approche de combinaisons par défaut, un moyen graphique sera offert à l'utilisateur pour faire disparaître de l'affichage des valeurs provenant d'une source combinée, c'est-à-dire pour refuser la combinaison en question, ou défaire une mise en correspondance de colonnes effectuée par défaut, et ces refus sont comptabilisés dans les comptages, comme décrit plus haut, pour influencer la détermination des suggestions ultérieures.
De manière plus fine, les données présentées elles-mêmes peuvent être prises en compte dans les comptages. Reprenons l'exemple ci-dessus avec "Vendeur2" et précisons-le. L'utilisateur qui accède à "Vendeurl" va prendre connaissance de l'offre de "Vendeur2" non pas dans tous les cas, mais seulement dans le cas où "Auteurl" "Titrel" lui est présenté (dans la présentation de "Vendeurl"), car c'est précisément lorsque "Auteurl" "Titrel" leur était présenté qu'un nombre relativement grand d'autres utilisateurs avaient combiné "Vendeur2" avec "Vendeurl" (et non pas lorsqu'ils visualisaient des données sur n'importe quels autres livres). Ainsi, lesdits comptages peuvent en plus prendre en compte les données visualisées par l'utilisateur lors des combinaisons.
Voici un exemple plus complet : Un extracteur fournit une source de données "Yamazuki" à partir du site Web du grand constructeur de motos Yamazuki qui présente toutes les motos de cette marque, avec toutes leurs caractéristiques.
Yamazuki
Type de moto Caratéristiques... Valide depuis Valide jusqu'à
RS750 ... 20 mars 2007 10:00 NuII
Un particulier publie une source "Je vends" contenant une ligne présentant le type de moto (comme valeur clé), les détails, le prix et le lieu de vente d'une moto Yamazuki récente qu'il met en vente.
Je vends
Type de moto Détails... Prix Lieu Valide depuis Valide jusqu'à
RS750 ... 5000 Fontainebleau 23 mars 2007 17:00 null
Ensuite, lui-même et/ou d'autre(s) utilisateur(s) combinent cette source "Je vends" avec la source "Yamazuki", en mettant en correspondance (mappage) la colonne qui identifie le type exact de la moto mis en vente.
Yamazuki + Je vends
Caratéristiques- Détails... Prix Lieu Valide depuis
Figure imgf000031_0001
5000 Fontainebleau 23 mars 2007
Figure imgf000031_0002
17:00
Lorsqu'un utilisateur final va visiter le site de Yamazuki, et qu'il visualise les données sur le type de moto qui se trouve être celui de la moto que le particulier a mis en vente, l'offre de ce dernier va lui être spontanément présentée seulement si où le nombre de fois que "Je vends" a été combinée avec "Yamazuki" est relativement important. Dans le cas contraire, c'est-à-dire même s'il y a trop de sources à combiner avec la source Yamazuki pour ce type de moto, en concurrence avec la source "Je vends", l'offre du particulier pourra être présenté par défaut si l'utilisateur final s'intéresse dans la même session au lieu "Fontainebleau" qui se trouve être le lieu de vente de cette moto. En effet la concurrence de données à combiner avec la source Yamazuki (pour la moto RS750) sera alors réduite.
Le scénario est le suivant : L'utilisateur final accède dans la même session non seulement au site "Yamazuki" mais aussi à un site "Châteaux" dans lequel l'utilisateur sélectionne la ligne Fontainebleau. Dans ce cas, dans la mesure où la source "Je vends" est automatiquement combiné par défaut à ces deux sites, l'offre de la moto du particulier est présentée :
Yamazuki + Châteaux + Je vends
Type de moto Caratéristiques... Lieu Détails... Prix Valide depuis Valide jusqu'à
RS750 ... Fontainebleau ... 5000 23 mars 2007 null
17:00
De manière encore plus fine, le contenu même des données présentées peut être pris en compte dans les comptages. Considérons l'exemple simple suivant où les valeurs d'une colonne particulière sont prises en compte dans les comptages. Un utilisateur accède sur le Web à un moteur de recherche et lui fournit un mot-clé "mouche" représentant son domaine d'intérêt particulier. Un extracteur (comme déjà décrit) présente, sous forme de tableau, le résultat retourné par le moteur de recherche50 comme suit :
Moteur de recherche
Mot-clé URL Domaine Valide depuis Valide jusqu'à mouche ... Pêche à la mouche 23 mars 2007 17:00 null
On suppose ici que le moteur de recherche fournit, dans une colonne « Domaine », le domaine (en l'occurrence " Pêche à la mouche") correspondant au mot-clé ("mouche") donné. Dans le cas où un nombre relativement grand d'utilisateurs avaient, en visualisant précisément la valeur " Pêche à la mouche", combiné avec ce site "Moteur de recherche" la source "Vendeurl" (on suppose ici que "Vendeurl" est un vendeur de livre spécialisé dans le domaine "Pêche à la mouche"), cette dernière y sera automatiquement combiné :
Moteur de recherche + Vendeurl
Mot-clé URL Domaine Auteur Titre Vendeur Prix Valide depuis Valide principal jusqu'à mouche ... Pêche à la Auteurl Titrel Vendeurl 25 23 mars 2007 17:00 null mouche
A chaque source de données51 est associé le degré de finesse des informations à prendre en compte lors des comptages.
On va maintenant voir un autre exemple et introduire un procédé de suggestion qui ne reflète pas seulement un cas précédent de mise en correspondance, mais un enchaînement implicite de plusieurs cas précédents de mises en correspondance.
50 (qui devient ainsi une source de données au sens de la présente invention)
51 (ou chaque extracteur) Dans le tableau "Mes articles" ci-dessous, un utilisateur associe un article ("TitrelO", "AuteurlO") à un livre ("Auteurl","Titrel") qu'il considère comme étant très « populaire » dans le domaine de l'article.
Mes articles
Article Article Revue URL Date Livre Livre Valide Valide
Titre Premier parution Auteur Titre depuis jusqu'à Auteur principal TitrelO AuteurlO Revue] iirim Juin 2006 Auteurl Titrel 23 mars null
2007 16:00
II met ensuite en correspondance les colonnes « Livre Auteur Principal » et « Livre Titre » (qui identifient ledit livre très populaire dans "Mes articles") avec les colonnes « Auteur Principal » et « Titre » de la source de données "Vendeurl".52
Vendeurl + Mes articles
Auteur principal Titre Article Article Revue URL Date Valide Valide
(Liyre Auteur (Liyre Titre Premier parution depuis jusqu'à principal) Titre) Auteur
Auteurl Titrel TitrelO AuteurlO RevuelO UrIlO Juin 2006 23 mars
2007 16:00
Ainsi, comme déjà décrit, lorsque plus tard l'utilisateur accède à la source "Vendeurl" et s'intéresse à ce même livre, sa combinaison avec "Mes articles" lui est rappelée automatiquement et l'article "TitrelO"
"AuteurlO" lui est présenté.
Mais même lorsque l'utilisateur accède à une autre source (disons "Vendeur2") pour laquelle la combinaison avec "Vendeurl" aurait été automatiquement suggérée, sa source "Mes articles" peut53 lui être suggérée.
En effet, ceci est justifié par le fait que "Mes articles" lui aurait de toutes façons été suggérée pour être combinée indirectement via54 "Vendeurl" (et l'utilisateur aurait pu simplement faire disparaître les lignes et minimiser ("hide") toutes les colonnes provenant de "Vendeurl" pour se retrouver exactement dans le même cas).
Ainsi, une « chaîne de correspondances » existant entre "Vendeur2" et "Mes articles", et la correspondance de "Vendeurl" à "Mes articles" étant privilégiée (de poids fort) car établie par l'utilisateur lui-même, cette dernière source sera automatiquement combinée par défaut. La source "Mes articles" est ainsi rappelée à l'utilisateur même s'il ne se rappelle plus ni de son nom, ni même du nom de la source "Vendeurl" à laquelle il l'avait associé (combiné).
Bien évidemment, en fonction des règles de prépondérance utilisées, la combinaison de "Mes articles" avec "Vendeurl" ou "Vendeur2" sera aussi suggérée aux autres utilisateurs, dans la mesure où les sources en question leurs sont accessibles.55
52 A noter que l'on suppose ici que l'utilisateur a en plus « minimisé » (hide) les colonnes « Vendeur » et « Prix ».
53 (en fonction des règles de prépondérence)
54 Une chaîne d'indirection plus longue est ainsi aussi possible.
55 En outre, on n'a pas considéré dans ce dernier exemple des degrés de finesses différents comme on l'avait fait dans les exemples précédents, ce qu'on aurait bien sûr pu faire.

Claims

REVENDICATIONS
1. Procédé mis en œuvre dans un environnement informatique pour identifier des informations d'enrichissement par rapport à des informations de départ, caractérisé en ce qu'il comprend les étapes suivantes :
(a) accéder par réseau à une première source d'informations en vue d'en recueillir des premières informations en réponse à une première requête ;
(b) convertir lesdites premières informations en un premier jeu de données structurées selon une pluralité de premiers attributs ;
(c) appliquer à une source de mappage des informations de contexte en vue d'identifier au moins une deuxième source d'informations susceptible de délivrer des informations capables d'enrichir les premières informations ;
(d) accéder par réseau à la deuxième source d'informations en vue d'en recueillir des deuxièmes informations en réponse à une deuxième requête contenant un ou plusieurs critères contenus dans la première requête et/ou une ou plusieurs valeurs d'attributs du premier jeu de données structurées ;
(e) convertir lesdites deuxièmes informations en un deuxième jeu de données structurées selon une pluralité de deuxièmes attributs dont au moins certains sont liés à des premiers attributs par des informations de mappage entre attributs fournis par la source de mappage, et
(f) présenter des données comprenant des données du premier jeu de données et des données du deuxième jeu de données, combinées en fonction desdites informations de mappage.
2. Procédé mis en œuvre dans un environnement informatique pour identifier des informations d'enrichissement par rapport à des informations de départ, caractérisé en ce qu'il comprend les étapes suivantes :
(a) accéder par réseau à une première source de données en vue d'en recueillir un premier jeu de données structurées selon une pluralité de premiers attributs en réponse à une première requête ;
(b) appliquer à une source de mappage des informations de contexte en vue d'identifier au moins une deuxième source de données susceptible de délivrer des données capables d'enrichir les premières données ;
(c) accéder par réseau à la deuxième source de données en vue d'en recueillir un deuxième jeu de données structurées selon une pluralité de deuxièmes attributs en réponse à une deuxième requête contenant un ou plusieurs critères contenus dans la première requête etfou une ou plusieurs valeurs d'attributs du premier jeu de données structurées, les deuxièmes attributs étant liés à des premiers attributs par des informations de mappage fournies par la source de mappage ; et
(d) présenter des données comprenant des données du premier jeu de données et des données du deuxième jeu de données, combinées en fonction d'attributs clés prédéterminés parmi les deuxièmes attributs.
3. Procédé mis en œuvre dans un environnement informatique pour identifier des informations d'enrichissement par rapport à des informations de départ, caractérisé en ce qu'il comprend les étapes suivantes :
(a) accéder par réseau à une première source de données en vue d'en recueillir un premier jeu de données structurées selon une pluralité de premiers attributs en réponse à une première requête ;
(b) appliquer à une source de mappage des informations de contexte en vue d'identifier au moins une deuxième source de données susceptible de délivrer des données capables d'enrichir les premières données ;
(c) accéder par réseau à la deuxième source de données en vue d'en recueillir un deuxième jeu de données structurées selon une pluralité de deuxièmes attributs en réponse à une deuxième requête contenant un ou plusieurs critères contenus dans la première requête et/ou une ou plusieurs valeurs d'attributs du premier jeu de données structurées, les deuxièmes attributs étant liés à des premiers attributs par des informations de mappage fournies par la source de mappage ; et
(d) présenter des données comprenant des données du premier jeu de données et des données du deuxième jeu de données, combinées en réponse à l'existence de valeurs alternatives, dans le deuxième jeu de données, de deuxièmes attributs mappés sur des premiers attributs.
4. Procédé selon la revendication 3, dans lequel lesdites valeurs alternatives sont sélectivement affichées en fonction de la position d'un dispositif pointeur sur une valeur du premier jeu de données, les valeurs alternatives selon l'attribut correspondant à la valeur sur laquelle pointe le dispositif pointeur étant affichées.
5. Procédé mis en œuvre dans un environnement informatique pour enrichir automatiquement des données organisées en une multiplicité d'attributs (multidimensionnelles) fournies par une source de données telle qu'un site web, caractérisé en ce qu'il comprend les étapes suivantes :
(a) accéder à une première source de données pour obtenir des premières données ;
(b) obtenir automatiquement des données alternatives aux premières données, comparables avec elles, à partir d'au moins une deuxième source de données ;
(c) obtenir automatiquement des données complémentaires des premières données, à partir d'une troisième source de données ; et
(d) combiner lesdites données alternatives et lesdites données complémentaires aux premières données, de manière à sélectivement présenter lesdites premières données, les données alternatives et les données complémentaires.
6. Procédé selon la revendication 5, dans lequel ladite troisième source de données fournissant des données complémentaires à la première source de données est la deuxième source de données elle-même.
7. Procédé selon l'une des revendications 5 ou 6, dans lequel l'étape (c) consiste en plus à obtenir à partir de la première ou la troisième source, des données complémentaires desdites données alternatives obtenues de la deuxième source.
8. Procédé selon l'une des revendications 5 à 8, dans lequel l'étape (b) consiste en plus à obtenir automatiquement, à partir de la première source, des données alternatives aux données alternatives obtenues à partir de la deuxième source, comparables avec elles, ces dernières données alternatives obtenues étant également enrichies à l'étape (c).
9. Procédé selon la revendication 8, dans lequel les données alternatives correspondent à des attributs de type alternatif, dont les valeurs dépendent de la source, dans 'lequel lesdites premières données comprennent des données selon des attributs dont les valeurs sont indépendantes de la source, dans lequel l'étape (c) comprend une sous-étape de détection de l'existence d'attributs de type alternatif dans la première ou la deuxième source de données.
10. Procédé selon la revendication 9, comprenant en outre une étape de conversion des données issues des sources de données en des jeux de données structurées selon une pluralité d'attributs.
11. Procédé selon la revendication 10, comprenant en outre une étape de traitement graphique de la présentation des premières données fournies par la première source pour y inclure les données alternatives et les données complémentaires.
12. Procédé selon la revendication 11, dans lequel les données alternatives et les données complémentaires sont présentées sélectivement en fonction des attributs de valeurs présentées sélectionnées par l'utilisateur à l'aide d'un dispositif pointeur au niveau de la présentation d'origine des premières données.
13. Procédé selon l'une des revendications 5 à 12, dans lequel l'étape (d) comprend une mise en correspondance ou mappage d'attributs pour chaque paire de sources dont les données sont à combiner.
14. Procédé selon la revendication 13, dans lequel l'étape (d) comprend un filtrage sur un ou plusieurs attributs.
15. Procédé selon l'une des revendications 13 et 14, dans lequel l'étape (d) comprend la prise en compte de méta-données de dépendance entre attributs.
16. Procédé selon l'une des revendications 5 à 15, comprenant en outre une étape consistant à obtenir automatiquement des données complémentaires des données alternatives.
17. Procédé selon l'une des revendications 5 à 16, comprenant en outre une étape consistant à obtenir automatiquement des données alternatives aux données complémentaires.
18. Procédé selon l'une des revendications 5 à 17, comprenant en outre une étape consistant à obtenir automatiquement des données complémentaires des données complémentaires.
19. Procédé selon l'une des revendications 5 à 18, comprenant en outre une étape consistant à obtenir automatiquement des données alternatives aux données alternatives.
20. Procédé selon l'une des revendications 5 à 19, dans lequel les sources de données sont choisies parmi les sources de données multidimensionnelles classiques, et les sources de données dont des valeurs selon des attributs peuvent être représentés par des domaines de valeurs ou des contraintes sur valeurs.
21. Procédé selon la revendication 20, dans lequel lesdites contraintes dépendent de variables représentant des références à des valeurs d'attributs pour le même jeu de données multidimensionnelles (ligne) ou pour un autre jeu de données.
22. Procédé selon la revendication 21, dans lequel, lorsqu'un attribut d'un jeu de données (R) qui enrichit une première source comprend une référence à un attribut d'un autre jeu de données (R'), ou réciproquement lorsqu'un attribut d'un autre jeu de données (R') comprend une référence à un attribut d'un jeu de données (R) qui enrichit un jeu de données de la première source, ledit autre jeu de données (R') est ajouté dans les données combinées (SIr), même lorsqu' aucun jeu de données de la première source n'y correspond.
23. Procédé selon la revendication 22, dans lequel ledit autre jeu de données n'est inclus dans l'étape (d) qu'en présence d'un ensemble de contraintes cohérent.
24. Procédé selon l'une des revendications 22 et 23, dans lequel il existe des attributs de type « Temps Réel » et sur ces attributs des contraintes de validité/péremption, et dans lequel l'étape (d) est mis en œuvre en tenant compte des contraintes sur attributs de type « Temps Réel » pour permettre une gestion des enrichissements par données alternatives et données complémentaires prenant en compte le temps.
25. Procédé selon la revendication 21, dans lequel l'étape (d) comprend le recours à des solveurs de contraintes.
26. Procédé selon l'une des revendications 5 à 25, dans lequel les sources de données à partir desquelles les données de la première source de données sont susceptibles d'être enrichies comprennent des ressources appartenant à un contexte d'utilisateur paramétrable.
27. Procédé selon la revendication 26, dans lequel le contexte d'utilisateur comprend des pages Web actives dans d'autres onglets d'un navigateur Web, ledit navigateur constituant le moyen d'accès aux sources de données.
28. Procédé selon la revendication 26 ou 27, dans lequel le contexte d'utilisateur comprend des pages Web appartenant à un historique de navigation récent dans un navigateur Web constituant le moyen d'accès aux sources de données.
29. Procédé selon l'une des revendications 26 à 28, dans lequel le contexte d'utilisateur comprend des pages Web appartenant au contexte d'utilisateur d'un autre utilisateur ayant un lien de proximité avec l'utilisateur en cause.
30. Procédé selon l'une des revendications 26 à 29, dans lequel le contexte d'utilisateur est déterminé en tenant compte d'informations de géolocalisation de l'utilisateur.
31. Procédé la revendication 26, dans lequel le contexte d'utilisateur est déterminé à partir du contenu de sources de données précédemment accédées par l'utilisateur.
32. Procédé selon l'une des revendications 5 à 31, dans lequel l'étape (d) comprend un regroupement/déploiement sélectif de jeux de données provenant de la première source de données et des sources de données d'enrichissement.
33. Procédé selon la revendication 32, dans lequel, lorsque lesdites premières données regroupent une pluralité de jeux de données de ladite première source et agrègent leurs valeurs, alors l'étape (d) agrège de la même manière des jeux de données d'enrichissement des premières données.
34. Procédé pour effectuer un mappage entre attributs de deux sources de données multidimensionnelles, à des fins de mise en œuvre du procédé selon l'une des revendications 1 à 33, chaque source de données étant susceptible de donner lieu à un affichage de résultats en réponse à une requête, caractérisé en ce qu'il comprend les étapes suivantes :
(a) afficher des résultats de deux requêtes similaires appliquées aux deux sources de données dans deux zones d'affichage respectives,
(b) par actions à l'aide d'un dispositif pointeur, établir des correspondances entre données affichées provenant de Ia première source et données affichées provenant de la deuxième source, et
(c) mettre en correspondance les attributs des données de la première source et de la deuxième source pour lesquelles des correspondances ont été établies.
PCT/FR2009/000204 2007-02-23 2009-02-25 Procede d'enrichissement de sources de donnees WO2009115695A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/919,375 US20110106791A1 (en) 2007-02-23 2009-02-25 Method for enriching data sources

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EPPCT/EP2008/052274 2008-02-25
PCT/EP2008/052274 WO2008107338A1 (fr) 2007-02-23 2008-02-25 Procedes d'extraction, de combinaison, de synthese et de visualisation de donnees multidimensionnelles provenant de differentes sources

Publications (1)

Publication Number Publication Date
WO2009115695A1 true WO2009115695A1 (fr) 2009-09-24

Family

ID=40886873

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/000204 WO2009115695A1 (fr) 2007-02-23 2009-02-25 Procede d'enrichissement de sources de donnees

Country Status (1)

Country Link
WO (1) WO2009115695A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3099674A1 (fr) 2019-08-03 2021-02-05 Synchronized Procede et appareil d’enrichissement de contenu multimedia par des meta-informations

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002013098A1 (fr) * 2000-08-04 2002-02-14 Infopia, Inc. Procede et systeme de gestion de commerce en ligne

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002013098A1 (fr) * 2000-08-04 2002-02-14 Infopia, Inc. Procede et systeme de gestion de commerce en ligne

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
ALLEN G. TAYLOR: "SQL For Dummies", 14 August 2006, JOHN WILEY & SONS, ISBN: 0-470-04652-X, XP002486106 *
ALLEN G. TAYLOR: "SQL For Dummies", 14 August 2006, JOHN WILEY & SONS, ISBN: 0-470-04652-X, XP002539446 *
ANONYMOUS: "Beginner SQL Tutorial. SQL Joins.", January 2008 (2008-01-01), XP002539921, Retrieved from the Internet <URL:http://web.archive.org/web/20080101023418/http://beginner-sql-tutorial.com/sql-joins.htm> [retrieved on 20090728] *
ELWIN CHAI, RICK JONES: "Automated Price Comparison Shopping Search Engine: PriceHunter", 2005, SENIOR DESIGN PROJECT 2004-2005, DEPARTMENT OF COMPUTER AND INFORMATION SCIENCE, UNIVERSITY OF PENNSYLVANIA, USA, XP002539445 *
ENRIC PEIG, JAIME DELGADO, ISMAEL PÉREZ: "Metadata Interoperability and Meta-search on the Web", 2001, PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON DUBLIN CORE AND METADATA APPLICATIONS, XP002540609 *
JÜRGEN DORN, TABBASUM NAZ: "Integration of Job portals by Meta-search", 2007, PROCEEDINGS OF 3RD INTERNATIONAL CONFERENCE ON INTEROPERABILITY FOR ENTERPRISE SOFTWARE AND APPLICATIONS, FUNCHAL, PORTUGAL, XP002540608 *
LUKAS FAULSTICH: "The HyperView Approach to the Integration of Semistructured Data", 15 February 2000, DISSERTATION AM FACHBEREICH MATHEMATIK UND INFORMATIK DER FREIEN UNIVERSITÄT BERLIN, GERMANY, XP002539922 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3099674A1 (fr) 2019-08-03 2021-02-05 Synchronized Procede et appareil d’enrichissement de contenu multimedia par des meta-informations
WO2021023397A1 (fr) 2019-08-03 2021-02-11 Synchronized Procede et appareil d'enrichissement de contenu multimedia par des meta-informations

Similar Documents

Publication Publication Date Title
EP2181402A1 (fr) Procedes d&#39;extraction, de combinaison, de synthese et de visualisation de donnees multidimensionnelles provenant de differentes sources
WO2005045698A2 (fr) Procede mis en oeuvre dans un environnement informatique pour engendrer une vue courante a partir d’au moins un objet d’information source susceptible de varier
US10467265B2 (en) Method for extracting entries from a database
TW200529009A (en) Systems and methods for search processing using superunits
TW201108007A (en) Semantic trading floor
FR2888018A1 (fr) Procede et systeme de realisation d&#39;une base de donnees virtuelle a partir de sources de donnees presentant des schemas heterogenes
US20150006472A1 (en) Listing tune-up system
CN103390044B (zh) 一种连锁类兴趣点数据识别方法及装置
FR3043816B1 (fr) Procede de suggestion de contenus extraits d’un ensemble de sources d’information
EP2188744A1 (fr) Installation de gestion d&#39;une base de données
WO2009044086A1 (fr) Procédé d&#39;interrogation d&#39;une base de données et dispositif d&#39;interrogation
EP1895410A1 (fr) Procédé et système d&#39;extraction d&#39;un tableau croisé d&#39;une base de données, et produit programme d&#39;ordinateur correspondant
WO2016198635A1 (fr) Gestion de noms de domaine du reseau internet
WO2009115695A1 (fr) Procede d&#39;enrichissement de sources de donnees
Tedeschi et al. A cloud-based tool for brand monitoring in social networks
FR2986882A1 (fr) Procede d&#39;identification d&#39;un ensemble de phrases d&#39;un document numerique, procede de generation d&#39;un document numerique, dispositif associe
Dönz et al. Extracting Data from the Deep Web with Global-as-View Mediators Using Rule-Enriched Semantic Annotations.
FR2975553A1 (fr) Aide a la recherche de contenus videos sur un reseau de communication
WO2018015515A1 (fr) Procedes de partage d&#39;opinion, equipements et programmes d&#39;ordinateur pour la mise en oeuvre des procedes
WO2001095146A2 (fr) Systeme et procede permettant l&#39;importation semi-automatique de fragments de ressources d&#39;informations
Solich Analysis of the social network amongst artists on Wikipedia
Englund et al. A web crawler to effectively find web shops built with a specific e-commerce plug-in
FR3037421A1 (fr) Gestion de noms de domaine du reseau internet
FR3080930A1 (fr) Systeme informatique de base de donnees
FR3102594A1 (fr) Ensemble de génération d’application, méthode et programme associés

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09722014

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 12919375

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09722014

Country of ref document: EP

Kind code of ref document: A1