2021-000540

本願は、２０１５（平成２７年）９月２５日（パリ条約による優先権主張外国庁受理２０１４年９月２６日、２０１５年９月２４日、アメリカ合衆国）を国際出願日とする出願であって、その手続の経緯は以下のとおりである。

平成３０年 ８月 ６日 手続補正書の提出

令和 元年 ７月３０日 拒絶理由通知書（起案日）

令和 元年 ９月２７日 意見書、手続補正書の提出

令和 ２年 ２月１３日 拒絶理由（最後の拒絶理由）通知書（起案日）

令和 ２年 ３月１６日 意見書、手続補正書の提出

令和 ２年 ９月２８日 令和２年３月１６日提出の手続補正書について

の補正の却下の決定、拒絶査定（起案日）

令和 ３年 １月１４日 審判請求書、手続補正書の提出

令和 ４年 ４月 ４日 拒絶理由通知書（起案日）

令和 ４年 ６月２７日 意見書、手続補正書の提出

当審拒絶理由に引用した引用文献１には、以下のとおりの記載がある。当審訳における下線は、注目箇所である。

「[0001] This document generally relates to systems and methods for use with enterprise resource planning. More specifically, this document relates to a system and method for intelligent rule validation suggestion in based on content type profiling.」

（当審訳）

[0001] 本明細書は、一般に、エンタープライズリソースプランニングで使用するためのシステムおよび方法に関する。より具体的には、コンテンツタイププロファイリングに基づくインテリジェントなルール検証提案のためのシステムおよび方法に関するものである。

「[0004] Enterprise resource planning (ERP) systems allow for the integration of internal and external management information across an entire organization, including financial/accounting, manufacturing, sales and service, customer relationship management, and the like. The purpose of ERP is to facilitate the flow of information between business functions inside the organization and manage connections to outside entities. Data with ERP, however, may not always be valid. For example, for an employee record, there may be a number of fields, including social security number, address, and postal code. Through profiling, it may be discovered that some of these fields incomplete, inaccurate, incorrect, or invalid data, or at least are suspected to have incomplete, inaccurate, incorrect, or invalid data. In such cases, it is beneficial to clean up this bad data and prevent future records from having such bad values entered on them. Validation and cleansing rules can be used to do this, but currently validation and cleansing rules require a lot of manual effort.

[0005] A content type is a table “column” attribute which identifies the semantic or meaning of the data values stored in a column. Content Type identification uses core Data Cleanse parsing technology and Cleansing Packages (parsing dictionaries) along with some additional custom logic (e.g. field proximity) to identify the content of a field of data. It also uses context and metadata information along with the analysis of the data itself to be able to establish an understanding of the data.」

（当審訳）

[0004] ＥＲＰ（Enterprise Resource Planning）システムは、財務・会計、製造、販売・サービス、顧客関係管理など、組織全体にわたって内部および外部の経営情報を統合することができるシステムである。ＥＲＰの目的は、組織内部の業務機能間の情報の流れを円滑にし、外部の組織とのつながりを管理することである。しかし、ＥＲＰのデータは常に有効とは限らない。例えば、従業員の記録では、社会保障番号、住所、郵便番号など、多くのフィールドが存在する場合がある。プロファイリングにより、これらのフィールドの中に不完全、不正確、誤り、または無効なデータがあること、あるいは少なくとも不完全、不正確、誤り、または無効なデータがある疑いがあることが判明する場合がある。このような場合、この不正なデータをクリーンアップし、将来のレコードにこのような不正な値が入力されないようにすることが有効である。これを行うには、検証およびクレンジングルールを使用することができるが、現在、検証およびクレンジングルールは、多くの手作業を必要とする。

[0005] コンテンツタイプは、テーブルの「列」属性で、列に格納されたデータ値の意味や意義を特定するものである。コンテンツタイプの識別は、データのフィールドのコンテンツを識別するために、いくつかの追加カスタム・ロジック（例えば、フィールドの類似性）とともに、コア・データ・クレンジング解析技術とクレンジング・パッケージ（解析辞書）を使用する。また、データの理解を深めるために、データ自体の分析に加え、コンテキストとメタデータ情報を使用する。

「[0021] FIG. 2 is a diagram illustrating as system 200 capable of automatic rule generation, in accordance with another example embodiment. Here, data is extracted from a source system, such as an ERP system 202 and placed in a staging area 204 of a server 206. A content type identification profiler 208 then identifies content types within the data. In an example embodiment, this may include identifying a content type for each column of the data. The system then can refer to a rule knowledge base 210 containing a number of rules and mappings between rules and data content types. The system is able to correlate content types to rules and therefore indicate relevant rules available for given content types. The system is able to correlate table columns to rules and therefore indicate relevant rules available for given table columns. This may be performed by a rule suggestion engine 212. Rules may be suggested to the user via a user interface 214. The use can then accept or reject the proposed rule. As will be seen later, the acceptance or rejection of the proposed rules can then be saved in the rule knowledge base 210 and used to help make future rule suggestions by the rule suggestion engine 212.

[0022] The data itself can be stored in a target system, such as data warehouse 216. The ERP 202 can then also utilize the stored validation rules from the data warehouse 216 when receiving future data from data sources, using the rules to validate and possibly reject bad data (or even correct the incomplete, inaccurate, incorrect, or invalid data).

[0023] It should be noted that the suggested rules may be any type of rules. Examples include validation rules, which are used by a component to detect and monitor quality of incoming data (e.g., by filtering the data according to the rules) and cleansing rules, which are used by a component to fix data (e.g., by modifying the data according to the rules, either as it arrives or in storage).

[0024] FIG. 3 is a diagram illustrating a system, in accordance with an example embodiment, of rule suggestion. The system 300 includes a rule knowledge base 302. New content types 304 and new rules 306 can be added to the knowledge base manually by users or automatically by the system. Content types and rules may be stored in the rule knowledge base 302 in entity data structures. Each entity 308 may contain one or more content types 310. Rules 312 may then be associated with content types 310. As can be seen, some content types may not have rules (or may not have rules assigned yet), while others do. The content type identification profiler 314 may take data and identify content types 310 for each column of the data. This may produce a column content type data structure 316. In this example, the column content type data structure 316 is a table including, for each column of the original data, an indication of the structure of the column's data (depicted as “type” 318 in this example), as well as an indication of a content type 320. In this example, four columns have been identified in an “HR.Employee” table, including AddressLine1, City, Postal Code, and EmployeeID. AddressLine1, for example, is of data type nvarchar with as length of 60. The system here has identified a content type “address” as correlating to this column of the HR.Employee table. It should be noted that the system may not be able to correlate content types for each and every column of the original table. In this example, EmployeeID, a data type being an integer of size 14, does not have a content type that the content type identification profiler can derive.

続きを表示（全13行）

[0025] Once the content types for the data are identified, these content types may be used to identify relevant rules for the data. Here, for example, the content type “zip code” 320 is used to retrieve the rule “Zipcode_must_be_valid” 322, which is stored under the corresponding content type in the rule knowledge base 302. An indication 324 may then be provided to the user in a user interface, showing that a suggested rule exists for this column. Indeed, this indication 324 may indicate all of the columns of the data, as well as which columns have suggested rules for binding. A rule binding is an association between a rule and a column. If there are existing rules that can be applied to this column, an indicator 326 suggests a new rules and binds the new rule to the column. If there are no relevant rules applicable for this column, a button 328 suggests a new rule creation.

[0026] When one of the columns having a suggested rule is selected, a rule binding prompt 330 may be displayed to the user, allowing the user to bind the suggested rule, as well as add additional rules or modify rule parameters, allowing the user to bind the column to specific parameters of a rule. This binding decision may be stored in a user rule binding history log 332 as part of the rule knowledge base 302 for future use of auto rule suggestion.

[0027] FIG. 4 is a screen capture illustrating a user interface, in accordance with an example embodiment, allowing a user to perform content type profiling. Within the user interface 400, a content type definition window 402 allows a user to select a table 404 and then use check boxes 408 to select one or more columns 406 present in the table for content type profiling. It should be noted that this initial setting of the definition of a content type being performed by a user may be optional in some embodiments. Artificial intelligence can be used to initially define content types for particular tables rather than direct user intervention.

[0028] FIG. 5 is a screen capture illustrating another user interface, in accordance with an example embodiment, depicting content types identified in profiling results. Subsequent to the system performing profiling of incoming data tables, a workspace 500 may be presented to the user. This workspace may depict tables 502a, 502b in the incoming data. Within each table 502a, 502b, a listing of columns 504 may be presented. Based on content type profiling result, a content type 506 may be presented for as many columns 504 as possible. Additional information about each column may also be presented, including value statistics 508, such as minimum, maximum, average, and median values; string length statistics 510; completeness statistics 512; and distribution statistics 514. These statistics, 508, 510, 512, and 514, may be useful in the user's decision as to whether to create or bind a rule to the particular content type.

[0029] FIG. 6 is a screen capture illustrating another user interface, in accordance with an example embodiment, depicting the user creating a rule far content types. A rule editor window 600 is presented that allows the user to define parameters for the rule, associate a content type 604 with the rule parameter 602. Also presented is an expression area 604, where the user can view the actual rule definition that involves the parameters. As can be seen, a single rule can be bound to a plurality of columns and/or content types.

[0030] FIG. 7 is a screen capture illustrating another user interface, in accordance with an example embodiment, displaying suggestions of rules. Here, user interface 700 may present a “Suggest” button 702 that indicate that proposed rules exist far one or more columns of the table 704, so that user can click the button 702 to view and accept rule suggestions, as opposed to or in conjunction with the user creating his or her own rules as depicted in FIG. 6.

[0031] FIG. 8 is a screen capture illustrating another user interface, in accordance with an example embodiment, depicting automatically suggested rules. Here, the user interface 800 presents rule suggestions 802. The user can Click “Accept” button 804 to accept one or more of the proposed bindings. Notably, a reason 806 for the suggestion of the rule may be presented. Often, this reason for suggestion 806 may be the content type associated with the rule.

[0032] FIG. 9 is a flow diagram illustrating a process 900 for automatic rule suggestion, in accordance with an example embodiment. At 902, data is profiled to identify a content type for each of one or more columns in the data. This may involve traversing each of the columns and comparing various statistics and information about each column to a content type table that identifies content types based on statistics and information. For example, the content type table may indicate that if the column contains numerical information in the format XXX-XX-XXXX, then the content type for such a column is a social security number. Likewise, if the column contains numerical information with a length of five digits, the content type for such a column is a U.S. postal zip code. The profiling operation may therefore involve mapping the columns of the data to this content type, if possible.

[0033] At 904, a rule knowledge base is accessed to locate rules specified for identified content types. At 906, one or more of the located rules are presented as suggestions to a user for confirmation. At 908, the user accepts one or more of the suggested rules. At 910, data may be validated, rejected, or cleansed using the suggested rules. At 912, the acceptance of the one or more suggested rules is stored in the rule knowledge base, to be used in the future when locating rules based on identified content types.」

（当審訳）

[0021] 図２は、他の実施形態による、自動ルール生成可能なシステム200を説明する図である。ここで、データは、ＥＲＰシステム202のようなソースシステムから抽出され、サーバ206のステージング領域204に置かれる。次に、コンテンツタイプ識別プロファイラ208が、データ内のコンテンツタイプを識別する。一実施形態では、これは、データの各列のコンテンツタイプを識別することを含み得る。次に、システムは、多数のルール及びルールとデータ・コンテンツタイプとの間のマッピングを含むルール知識ベース210を参照することができる。システムは、コンテンツタイプとルールとを関連付けることができ、したがって、所定のコンテンツタイプに対して利用可能な関連ルールを示すことができる。システムは、テーブルの列をルールに関連付けることができ、したがって、与えられたテーブルの列について利用可能な関連するルールを示すことができる。これは、ルール提案エンジン212によって実行されてもよい。ルールは、ユーザインターフェイス214を介してユーザに提案されてもよい。次に、ユーザは提案されたルールを受諾するか拒否することができる。後述するように、提案されたルールの受諾又は拒否は、その後、ルール知識ベース210に保存され、ルール提案エンジン212によって将来のルール提案を行うのを助けるために使用されることができる。

[0022] データ自体は、データウェアハウス216のようなターゲットシステムに保存することができる。ＥＲＰ202は、データソースから将来のデータを受信するときに、データウェアハウス216から保存された検証ルールを利用することもでき、ルールを使用して、不良データを検証し、場合によっては拒否する（あるいは、不完全、不正確、誤り、または無効なデータを修正する）ことが可能である。

[0023] 提案されたルールは、任意のタイプのルールであってよいことに留意すべきである。例としては、受信するデータの品質を検出し監視するためにコンポーネントによって使用される（例えば、ルールに従ってデータをフィルタリングすることによる）検証ルールや、データを修正するためにコンポーネントによって使用される（例えば、到着時または保管中のいずれかのデータをルールに従って修正することによる）クレンジングルールが挙げられる。

[0024] 図３は、一実施形態による、ルール提案のシステムを示す図である。システム300は、ルール知識ベース302を含む。新しいコンテンツタイプ304および新しいルール306は、ユーザによる手動で、またはシステムによる自動で、知識ベースに追加することができる。コンテンツタイプ及びルールは、エンティティ・データ構造でルール知識ベース302に格納されてもよい。各エンティティ308は、１つまたは複数のコンテンツタイプ310を含むことができる。そして、ルール312は、コンテンツタイプ310と関連付けられてもよい。図から分かるように、いくつかのコンテンツタイプはルールを有していない（または、まだ、ルールが割り当てられていない）かもしれないが、他のコンテンツタイプはルールを有している。コンテンツタイプ識別プロファイラ314は、データを受け取り、そのデータの各列についてコンテンツタイプ310を識別してもよい。これは、列のコンテンツタイプデータ構造316を生成してもよい。この例では、列のコンテンツタイプデータ構造316は、元のデータの各列について、列のデータの構造の表示（この例では「タイプ」318として描かれている）、ならびにコンテンツタイプ320の表示を含む表である。この例では、「HR.Employee」テーブルにおいて、AddressLine1、City、Postal Code、およびEmployeeIDの４つの列が特定されている。AddressLine1は、例えば、データ型がnvarcharであり、長さが６０である。このシステムは、HR.Employeeテーブルのこの列に関連するものとして、コンテンツタイプ "address "を識別している。システムは、元のテーブルの各列とコンテンツタイプの関連付けを行うことができないことに注意する必要がある。この例では、サイズ１４の整数であるデータ型であるEmployeeIDは、コンテンツ識別プロファイラが導出できるコンテンツタイプを有していない。

[0025] データのコンテンツタイプが特定されると、これらのコンテンツタイプは、データに対する関連するルールを特定するために使用され得る。ここでは、例えば、コンテンツタイプ「郵便番号」320は、ルール知識ベース302の対応するコンテンツタイプの下に格納されているルール「Zipcode_must_be_valid」322を検索するために使用される。その後、この列に対して提案されたルールが存在することを示す表示324が、ユーザインターフェイスにおいてユーザに提供され得る。実際、この表示324は、データの全ての列を示すだけでなく、どの列がバインディングのための提案されたルールを有するかを示してもよい。ルールバインディングは、ルールと列との間の関連付けである。この列に適用できる既存のルールがある場合、表示326は新しいルールを提案し、その新しいルールを列にバインドする。この列に適用可能な関連ルールがない場合、ボタン328が新しいルールの作成を示唆する。

[0026] 提案されたルールを有する列の１つが選択されると、ルールバインディングプロンプト330がユーザに表示され、ユーザが提案されたルールをバインドすることができるとともに、追加のルールを追加したりルールパラメータを変更したりして、ユーザが列をルールの特定のパラメータにバインドすることができるようにすることができる。このバインド決定は、自動ルール提案の将来の使用のために、ルール知識ベース302の一部としてユーザルールバインディング履歴ログ332に格納されてもよい。

[0027] 図４は、一実施形態による、ユーザがコンテンツタイププロファイリングを実行することを可能にするユーザインターフェイスを示す画面キャプチャである。ユーザインターフェイス400内で、コンテンツタイプ定義ウィンドウ402は、ユーザがテーブル404を選択し、次にチェックボックス408を使用して、コンテンツタイププロファイリングのためにテーブル内に存在する１つまたは複数の列406を選択することを可能にする。ユーザによって実行されるコンテンツタイプの定義のこの初期設定は、いくつかの実施形態において任意であってよいことに留意すべきである。人工知能は、ユーザが直接介入するのではなく、特定のテーブルのためのコンテンツタイプを最初に定義するために使用することができる。

[0028] 図５は、一実施形態による、プロファイリング結果において識別されたコンテンツタイプを示す別のユーザインターフェイスを示す画面キャプチャである。システムが受信するデータテーブルのプロファイリングを実行するのに続いて、ワークスペース500がユーザに提示される場合がある。このワークスペースは、受信するデータ内のテーブル502a、502bを描写することができる。各テーブル502a、502b内には、列504のリストが提示される場合がある。コンテンツタイププロファイリングの結果に基づいて、できるだけ多くの列504についてコンテンツタイプ506が提示される場合がある。また、最小値、最大値、平均値、および中央値などの値統計508、文字列長統計510、完全性統計512、および分布統計514など、各列に関する追加の情報が提示されてもよい。これらの統計値508、510、512、および514は、特定のコンテンツタイプにルールを作成またはバインドするかどうかというユーザの判断に有用である場合がある。

[0029] 図６は、一実施形態による別のユーザインターフェイスを示す画面キャプチャであり、ユーザが、コンテンツタイプからルールを作成する様子を描写している。ユーザがルールのパラメータを定義し、コンテンツタイプ604をルールパラメータ602に関連付けることを可能にするルール編集ウィンドウ600が提示される。また、ユーザがパラメータを含む実際のルール定義を見ることができる表示領域604が提示される。図から分かるように、単一のルールは、複数の列及び／又はコンテンツタイプにバインドさせることができる。

[0030] 図７は、一実施形態による、ルールの提案を表示する別のユーザインターフェイスを示す画面キャプチャである。ここで、ユーザインターフェイス700は、図６に示されているように、ユーザが自身のルールを作成するのとは対照的に、またはそれと連動して、ユーザがボタン702をクリックしてルール提案を表示し受諾することができるように、提案されたルールがテーブル704の１つ以上の列から離れて存在することを示す「提案」ボタン702を提示し得る。

[0031] 図８は、一実施形態による、自動的に提案されたルールを示す別のユーザインターフェイスを示す画面キャプチャである。ここで、ユーザインターフェイス800は、ルール提案802を提示する。ユーザは、提案されたバインディングの１つ以上を受諾するために、「受諾」ボタン804をクリックすることができる。注目すべきは、ルールの提案の理由806が提示され得ることである。多くの場合、この提案の理由806は、ルールに関連するコンテンツタイプであってもよい。

[0032] 図９は、一実施形態による、自動ルール提案のためのプロセス900を示す流れ図である。902で、データは、データ内の１つ以上の列の各々についてコンテンツタイプを識別するためにプロファイリングされる。これは、列の各々を横断し、各列に関する様々な統計及び情報を、統計及び情報に基づいてコンテンツタイプを特定するコンテンツタイプテーブルと比較することを含み得る。例えば、コンテンツタイプテーブルは、列がXXX-XX-XXXXの形式の数値情報を含む場合、そのような列のコンテンツタイプは社会保障番号であると示すことができる。同様に、列が５桁の長さの数値情報を含む場合、そのような列のコンテンツタイプは、米国の郵便番号である。したがって、プロファイリング操作は、可能でれば、データの列をこのコンテンツタイプにマッピングすることを含むことができる。

［図：0001394331000001.jpg］

［図：0001394331000002.jpg］

［図：0001394331000003.jpg］

［図：0001394331000004.jpg］

［図：0001394331000005.jpg］

［図：0001394331000006.jpg］

［図：0001394331000007.jpg］

当審拒絶理由に引用した引用文献２には、以下のとおりの記載がある。当審訳における下線は、注目箇所である。

「[0001] The subject disclosure relates to analyzing data sets to infer semantic information and generating visualizations based thereon.」

（当審訳）

[0001] 本開示は、意味情報を推測するためにデータセットを分析し、それに基づいて可視化を生成することに関する。

「[0004] More specifically, currently, the way data is uploaded by different parties is such that a similar column of different data sets (e.g., both representing city), if even named at all, will have different names, which may or may not be similar. In either case, human intervention into the underlying data and verification is the conventional way to determine what columns should be named the same or similarly, or to otherwise determine what the relationship between the types or columns of data might be. In addition to being unscalable, such intervention in the underlying data may not be desirable to publishers who want to guarantee their data remains unaltered, as may be the case for a host of proprietary data sets that might be published to the cloud.

[0005] The above-described deficiencies of today's devices and data services are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with the state of the art and corresponding benefits of some of the various non-limiting embodiments may become further apparent upon review of the following detailed description.

SUMMARY

[0006] A simplified summary is provided herein to help enable a basic or general understanding of various aspects of exemplary, non-limiting embodiments that follow in the more detailed description and the accompanying drawings. This summary is not intended, however, as an extensive or exhaustive overview. Instead, the sole purpose of this summary is to present some concepts related to some exemplary non-limiting embodiments in a simplified form as a prelude to the more detailed description of the various embodiments that follow.

[0007] A variety of data sets can be stored in a larger repository, in a unified manner, to provide an information-as-a-service system. The variety of data sets can be respectively published by disparate publishers and, accordingly, the data sets can include overlapping fields or columns. The system can perform semantic analysis on the data sets to infer a semantic type or meaning of various fields or columns of the data sets. The information-as-a-service system can learn and self-describe data stored in the data sets in an evolving way as more and more semantics are discovered.

[0008] Additionally, with learned semantic information, the information-as-a-service system can discover relationships between data sets via the overlapping fields or columns. For instance, the information-as-a-service system can generate mash-ups, e.g., joins or links between data sets, which can expose previously unknown correlations among data in the data sets. The mash-ups can form the basis of rich visualizations of data relationships and/or user interfaces provided to users of the system.

[0009] Semantic information can be inferred via a series of complementary and/or supplementary actions. The actions can verify, override, or enhance tags applied to fields or columns of data sets via manual means, e.g., human input entered by hand. Field names can be checked against a list of potentially valid names with known semantic types. Matches can be employed to associate a semantic type with the field or column Near matches can be presented to a user for verification. In another analysis, a format of fields of the data set can be identified to facilitate determination of a semantic type. Based upon the format or other parameters, one or more reference data sets, e.g., with known semantic types, can be selected to check values of the fields or columns.」

（当審訳）

[0004] より具体的には、現在、異なる当事者によってデータがアップロードされる方法は、異なるデータセット（例えば、両方とも都市を表す）の同様の列が、名前が付けられたとしても、類似しているか否かを問わず、異なる名前を有するようになっている。いずれの場合も、どの列に同じ名前または類似の名前を付けるべきか、あるいはデータの種類または列の間の関係がどうであるかを判断するには、従来の方法では、基礎となるデータに人間が介入して検証していた。拡張性がないことに加えて、基礎となるデータに対するそのような介入は、クラウドに公開される固有のデータセットの持ち主の場合がそうであるように、データが変更されないままであることを保証したい公開者にとって望ましくない場合がある。

[0005] 今日のデバイス及びデータサービスの上述の欠陥は、単に、従来のシステムの問題のいくつかの概要を提供することを意図しており、網羅することを意図していない。従来の技術に関する他の問題、および様々な非限定的な実施形態の対応する利点は、以下の詳細な説明により、さらに明らかになる。

発明の概要

[0006] 後に続く詳細な説明及び添付の図面に例示的な非限定的実施形態の様々な態様の基本的又は一般的理解を可能にするために、簡略化した要約を本明細書において提供する。しかしながら、この要約は、広範なまたは網羅的な概要として意図されていない。むしろ、この要約の唯一の目的は、後に続く様々な実施形態のより詳細な説明の前段階として、いくつかの例示的な非限定的実施形態に関連するいくつかの概念を単純化した形で提示することである。

[0007] サービスとしての情報システムを提供するために、様々なデータセットを、統一された方法で、より大きなリポジトリに格納することができる。様々なデータセットは、それぞれ、異なる発行者によって公開されることがあり、それに応じて、データセットは、重複するフィールドまたは列を含むことがある。システムは、データセットに対して意味解析を行い、データセットの様々なフィールド又は列の意味的なタイプ又は意味を推論することができる。サービスとしての情報システムは、より多くのセマンティックが発見されるにつれて、進化する方法でデータセットに格納されたデータを学習し、自己記述することができる。

[0008] さらに、学習された意味情報を用いて、サービスとしての情報システムは、重複するフィールドまたは列を介してデータセット間の関係を発見することができる。例えば、サービスとしての情報システムは、データセット間のマッシュアップ、例えば、結合またはリンクを生成することができ、これにより、データセット内のデータ間の以前は知られていなかった相関関係を明らかにすることができる。マッシュアップは、データ関係の豊富な視覚化、及び／又はシステムのユーザに提供されるユーザインターフェイスの基礎を形成することができる。

[0009] 意味情報は、一連の補完的及び／又は補足的な動作によって推論することができる。アクションは、手動手段、例えば、手入力された人間の入力によってデータセットのフィールドまたは列に適用されたタグを検証し、上書きし、または強化することができる。フィールド名は、既知の意味タイプを持つ潜在的に有効な名前のリストと照合することができる。フィールドまたは列と意味タイプを関連付けるために、マッチングを採用することができる。きわどいマッチングは、検証のためにユーザに提示することができる。別の分析では、データセットのフィールドの形式を特定することで、意味タイプの決定を容易にすることができる。フォーマットまたは他のパラメータに基づいて、１つまたは複数の参照データセット（例えば、既知の意味タイプを有する）を選択して、フィールドまたは列の値をチェックすることができる。

「[0029] As discussed in the background, different content providers providing different data sets do not generally coordinate with respect to possible overlap of information or data types represented in their data sets since they generally have no knowledge of one another's data sets, or any particular incentive to do so. In an information-as-a-service system (also referred to herein as information provided as a service from any platform) where one of the guarantees by the storage entity is adherence to access restrictions requested by the publisher, currently, there is no way to learn or visualize unique correlations between different data sets on the develop or consumption side except through inside knowledge of specific contents of the data sets. In addition, in information-as-a-service systems, another guarantee provided by the storage entity is non-interference with the underlying data sets after publishing, so that the data published remains unaltered. In such cases, the unique correlations, if known, cannot currently be leveraged without development of custom applications.

[0030] For instance, content provider A may publish a table including columns for latitude, longitude, with corresponding crime rate, e.g., column names of lat, long and cri_rate. Content provider B may publish movie theatre information for cities, with x and y coordinates corresponding to latitude and longitude, except the column for city may instead be called “Name”, e.g., column names of _theatre, _Name, _x and _y. Accordingly, it is unknown by any conventional means on the consumption side that by joining the two sets, one could actually determine the movie theatres in cities having the lowest crime rate, since the semantic meaning of the disparate columns remains abstruse. Moreover, it is likewise unknown by conventional means on the storage side that the two sets can be joined without manual inspection and analysis by a human.

[0031] It is thus desirable to determine that _x and _y are lat and long, that _Name means city name and that _theatre refers to movie theatre names. That is, it is desirable to acquire semantic information regarding the columns, wherein the semantic information conveys at least a semantic type indicating the semantic meaning of the data contained in the column. With the semantic information, relationship information can be systematically derived that enables the two data sets to be joined to readily obtain useful data about crime rates near movie theatres?information that could not have been discerned without the semantic information. As mentioned previously, this work can conventionally be done by hand. However, where data sets include numerous entries, columns, or rows, e.g., thousands, millions, billions, etc., manual tagging becomes a burdensome and time consuming task. In addition, the opportunities for mislabeling also increase as the size of data grows.

[0032] Accordingly, in various non-limiting embodiments, semantic analysis can be performed on data sets retained in a repository such as, but not limited to, an information-as-a-service system. Through semantic analysis, inferences can be made about the data to augment data sets with semantic information to improve not only the potential for joins, e.g., mash-ups, by providing mapping(s) between columns formerly thought to represent different data/types, but also descriptions of the data and/or fields within the data. In this regard, in accordance with various embodiments, a repository of data sets, e.g., an information-as-a-service system, can systematically learn types of data and connections between data to increase value of the underlying data as well as discover previously unknown correlations.

続きを表示（全43行）

[0033] In one embodiment, a method is described herein that includes extracting a subset of data from a data set stored in a data repository, identifying a format corresponding to the subset of data, selecting at least one reference data set based upon the format, wherein the at least one reference data set is associated with a known semantic type, comparing values of the subset of data against the at least one reference data, and inferring semantic information of the data set based upon comparison results, wherein the semantic information specifies at least a semantic type of data in the data set. In an example, the method can also include providing the semantic information to a user for confirmation. In more examples, extracting the subset of data can include extracting an entirety of the data set, selecting, at random, values of the data set, or extracting a pre-determined number of values from at least one of a beginning of the data set, an end of the data set, or a middle of the data set.

[0034] In another example, the method can include validating the values of the subset of data against one or more domain rules, wherein the one or more data rules correspond to the semantic type of data in the data set and presenting invalid values to a user, wherein invalid values include values disallowed by the one or more domain rules. In a further example, the method can include extracting a field name from the data set and comparing the field name to a set of potential valid tags. Further to this example, the method can include identifying when the field name matches a tag in the set of potential valid tags, identifying a type associated with the tag when matched and associating the data set with the type as the semantic type of the data set.

[0035] In further examples, the method can include evaluating structures of the values of the subset of data against a plurality of pre-configured patterns, identifying when the structures of the values match a pre-configured pattern, selecting the at least one reference data set, wherein the known semantic type associated with the at least one reference data set corresponds to the pre-configured pattern, and adopting the known semantic type as the semantic type of data of the data set when a number of structures matching the pre-configured pattern exceeds a predetermined threshold.

[0036] According to an additional example, comparing the values of the subset of data can include selecting a value from the values, querying the at least one reference data set with the value, and counting a valid hit when a result of the query with the value is returned. The method, in another example, can include identifying a second data set including at least one field corresponding to the semantic type of data of the data set, and generating relationship information that associates the data set with the second data set, wherein the relationship information specifies a correlation between the data set and the second data set. In addition, the method can include obtaining relationship information correlating a plurality of data sets in the data repository, displaying a visualization of the relationship information as part of a graphical user interface, receiving input via the graphical user interface and updating the relationship information based upon the input.

[0037] In another embodiment, a semantic analysis system, as described herein, includes a semantic analysis component configured to infer semantic information regarding data of a data set stored by an information-as-a-service system. The semantic analysis component includes a format check component configured to identify a format of sample data extracted from the data set and to select one or more reference data sets based upon the format and a value check component configured to check values of the sample data against the one or more reference data sets to identify a semantic type of the sample data. Additionally, the semantic analysis component infers the semantic information based upon the semantic type identified.

[0038] The system, in an example, further includes a domain check component configured to determine whether values of the sample data satisfy a set of domain rules. The set of domain rules establish valid data values for a particular data type. In further examples, the system includes a linking component configured to correlate a plurality of disparate data sets stored by the information-as-a-service system based upon respective semantic information and a visualization component configured to generate a visualization of correlations between data sets stored by the information-as-a-service system. The visualization can comprise a graph display where nodes represent respective data sets and edges represent correlations between data sets.

[0039] In an additional embodiment, a computer-readable storage medium is described herein that includes computer-executed instruction that, when executed, cause a computing device to perform extracting a subset of data from a data set stored in a data repository; identifying a format corresponding to the subset of data; selecting at least one reference data set based upon the format, wherein the at least one reference data set is associated with a known semantic type; comparing values of the subset of data against the at least one reference data; and inferring semantic information of the data set based upon comparison results, wherein the semantic information specifies at least a semantic type of data in the data set.

[0040] Further details of these and other various exemplary, non-limiting embodiments and scenarios are provided below.

Determining and Visualizing Data Set Semantics in Connection with Information as a Service

[0041] As mentioned, in the context of information-as-a-service, there is a limit to what machines, without intelligence, can determined from data sets. For instance, such a machine can determine that a first column of a data set includes strings, a second column includes numbers, and a pair of other columns includes mixed data types, e.g., numbers and strings. In addition, while a human can be brought in to classify the data, for large amounts of data, such conventional human classification does not scale well, and if data is re-published by a publisher with different semantics, the human characterization may already be out of date. In addition, a human can incorrectly characterize a set of data as the data can appear as related to a particular domain but the human can lack sufficient domain knowledge to validate the set of data.

[0042] Accordingly, in various embodiments, a variety of mechanisms can be applied to data sets in a unified repository to systematically generate semantic information that characterizes types of information and/or meanings of data included in a data set. The semantic information can be employed to validate, replace, and supplement human characterizations. One mechanism involves inferring a data type or column name based on clues in the data or column name, or other column names, of a data set. For instance, column or field names can be checked against a set of potential valid tags. Semantic information, e.g., a semantic type, of a column can be inferred when a column name matches a valid tag in the set of potential valid tags. However, this mechanism alone can lead to errors or inaccuracies when a field name is misspelled or when data insides a field is invalid, e.g., outside a domain associated with the matched valid tag.

[0043] To address data unmatched by column name and/or to verify accuracy of a matched tag, additional processing can be performed on the data in a column. For instance, a sample of data in the column can be extracted to evaluate a format of the data by pattern matching with a set of known data patterns. In a non-limiting, example, data having the form xxx-xxx-xxxx or (xxx) xxx-xxxx, where the x's represent arbitrary numeric digits, can be recognized a telephone number. In some cases, format checking may not provide a definitive result. For instance, a column of city names can be pattern matched as strings, but further details can be difficult to obtain since city names do not possess common or inherent formatting restrictions. However, in such cases, format checking can facilitate further semantic analysis and/or identification of semantic type by eliminating possible semantic types which do not conform to the evaluated format. For instance, phone numbers, latitude, longitude, dates, ages, and other numeric types can be eliminated as possible semantic types when the format is evaluated to be strings. A user can be presented with a list of possible semantic types providing string data such as, but not limited to, city names, first names, country names, region names, business names, and the like. In addition, the list of possible semantic types can be employed to select data sets having known semantic types to be employed as reference data sets for value checking in accordance with another embodiment.

[0044] In value checking, a sample of a data in a column of a data set can be matched against a reference data set associated with a candidate semantic type. The reference data set can be queried to determine whether values of the sample are contained therein. One or more thresholds can be established to facilitate distinguishing between a definitive match, e.g., the column of the data set include data of the candidate semantic type, a definite mismatch, and a nebulous result. For example, a 100% validation, e.g., every value in the sample is in the reference data set can be classified as a definitive match. In another example, a nebulous result can be forwarded to a user for verification, correction, or override.

[0045] In another embodiment, semantic information associated with columns of data sets in the unified repository facilitates instant discovery of join points between data sets, which can be leveraged to generate interesting mash-ups of data sets. In an example, a first data set comprising crime statistics can include crime rates by city can be joined with a second data set comprising real estate information by city along the overlapping city field. As semantic information of more fields of data sets is generated as described above, the system can continuously learn new correlations between the data sets can be derived to increase value of the underlying data.

[0046] In addition, the correlations, and mash-up data itself, can be visualized and displayed in connection with a user interface. For instance, a graph display with nodes representing data sets in a repository can be presented to a user. When a user selects a node, e.g., data set, links can be drawn between the selected node and other nodes, e.g., data sets, where correlations have been derived. In another example, a user can select a link between data sets to obtain a visualization of the mash-up, e.g., a generated data set produced as a join of the two disparate data sets.

[0047] FIG. 1 is a flow diagram illustrating an exemplary non-limiting embodiment for determining semantic information associated with a data set. In a specific, non-limiting example, the data set can be included in a data repository managed and exposed by an information-as-a-service system. However, it will be appreciated that private data sets can utilize embodiments disclosed herein to generate semantic information and/or interesting mash-ups in an automatic manner with reduced human input.

[0048] At 100, one or more field names, e.g., column names, of fields or columns in a data set are compared with a list of potential valid tags. The potential valid tags include field names, column names, data labels, tags, or the like, which have a known semantic meaning or type. Semantic information of the one or more fields or columns in the data set can be inferred based upon a match to a valid tag in the list. However, further processing can be performed to refine or validate the semantic information generated from a field name check. For instance, at 110, a format of the one or more fields of the data set is identified. By way of example, phone numbers are a type numerical data that can be relatively identified as such, despite variations such as area code parentheses, dashes, etc. Accordingly, semantic information can be inferred from format checks for phone numbers, social security numbers, calendar dates, time stamps, etc. In other cases, while format checking may not definitively identify a meaning or type of data in the data set, it can reduce a number of potential candidates by eliminating data types not associated with the identified format. For instance, format checking can narrow a number of potential candidate semantic types which are tested by value checking.

[0049] At 120, actual values of the one or more fields of the data set are checked against at least one reference data set. Reference data sets include known semantic information, e.g., the data has a known semantic type or meaning, which can be queried to determine if values of the one or more fields correspond to the known semantic type. At 130, semantic types associated with the one or more fields of the data set are determined. The semantic types can be determined based upon the field name check, the format evaluation, and/or the value check. In addition, the semantic types can be reported to a user for confirmation, or as part of a visualization of the data set.

[0050] It is to be appreciated that the above described process can occur in an automated fashion without user interaction. However, in another embodiment, a user can be prompted, at various steps in the process, to confirm determined semantic information (or partial semantic information determined thus far), to request further processing, to address inconsistent formats or values, to override the process, or to alter guessed semantic information. For instance, in one example, the user can be prompted to verify close matches during the field name check, e.g., field name is “_fname” and the list of valid tags includes “_name” or “name.” In another example, the user can be prompted to accept or correct values not found within the at least one reference data set. For instance, the value is not found due to a typographical error in the data set, which would be recognized by a user. Accordingly, user input can be utilized to supplement and/or verify inferences.

[0051] FIG. 2 is a flow diagram illustrating an exemplary non-limiting embodiment for checking field names of a data set against potential tags with known semantic types. At 200, a data set from a repository of information, e.g., an information-as-a-service system, is received. At 210, one or more field names of the data set are extracted. At 220, a comparison, e.g., a string comparison is performed between the extracted field names and a set of potential valid tags. The set of potential valid tags include possible labels or names of data fields, wherein a semantic meaning of the tags or a semantic type of the data fields is known. The set of potential valid tags can be populated with field names encountered during previous semantic analyses on disparate data, field names commonly employed for data sets, tags supplied by a user, or the like. At 240, a determination can made if there is a match between the one more field names and a valid tag in the list. If there is not a match, semantic analysis can continue utilizing different mechanisms or a user can be prompted to intervene. If there is a match, then, at 240, a semantic type associated with the matched valid tag is identified and flagged as a possible semantic type for the one or more fields associated with the one or more field names.

[0052] FIG. 3 is a flow diagram illustrating an exemplary non-limiting embodiment for selecting a reference data set based upon a format of a sample information extracted from a data set. At 300, a sample of data from a data set corresponding to one or more fields, e.g., columns, of the data set. The sample of data can be extracted randomly, or a first N entries or rows of the data set, a last N entries, or a middle N entries can be extracted, where N is an integer greater than or equal to one. In another embodiment, the sample of data can include an entirety of the data set. At 310, a format of the sample of data is evaluated. In an example, each value of the sample of data can be matched against patterns to determine a data type, e.g., strings, numbers, mixed type, etc., and/or a possible semantic type, e.g., telephone numbers, dates, proper nouns, etc. For instance, values can be determined to be a mixed type confirming to at least one format such as MM/DD/YYYY, MM-DD-YYYY, or the like. Accordingly, it can be determined that the sample of data includes dates. In another example, it can be identified that the values includes strings beginning with capital letters, i.e., proper nouns.

[0053] At 320, at least one reference data set can be selected based upon the evaluated format. In some situations, an accurate semantic type can be inferred from the evaluated format. For instance, semantic types associated with distinct formats, e.g., dates, times, telephone numbers, etc., can be inferred directly from the evaluated format and additional verification, e.g., value checking, can be avoided. However, it will be appreciated that, even data with easily recognizable formats, can be associated with a variety of semantic types. For instance, social security numbers, employee identification numbers, employer identification number, or the like can exhibit similar representations in data sets. However, since such disparate data have different meanings and context, further refinement or verification. As such, reference data sets including employer identification numbers, employee identification numbers, etc. can be selected.

[0054] In another aspect, other formats, such as strings, can narrow a pool of possible semantic types, but not provide a definitive solution. Accordingly, a set of reference data sets corresponding to the narrowed pool of possible semantic types can be selected. For instance, if the evaluated format indicates the data set includes proper nouns, data sets of proper names, e.g., city names, country names, first names, last names, business names, etc., can be selected.

[0055] FIG. 4 is a flow diagram illustrating an exemplary non-limiting embodiment for checking values from a sample of data against a reference data set. The reference data set can be selected as a result of format checking as discussed above or selected by a user as part of an interactive semantic analysis process. At 400, a sample of data from a data set corresponding to one or more fields, e.g., columns, of the data set. The sample of data can be extracted randomly, or a first N entries or rows of the data set, a last N entries, or a middle N entries can be extracted, where N is an integer greater than or equal to one. In another embodiment, the sample of data can include an entirety of the data set. At 410, a value from the sample of data is selected. At 420, a reference data set is queried to ascertain whether the selected valued is included. At 430, a check is made as to whether a result of the query is returned. If yes, a count of valid hits is incremented at 440. If no, or after the incrementing at 440, a determination is made, at 450, whether or not additional values remain in the sample. If yes, another value is selected at 410 and steps 420-450 can be repeated.

[0056] At 460, a level of validation can be identified from the count of valid hits, for example, as a percentage of hits relative to a size of the sample. In addition, semantic information, e.g., a semantic type of the sample, can be inferred based upon the level of validation. In an embodiment, the semantic type of the reference data set can be adopted as a semantic type of the data set from which the sample is extracted when the level of validation reaches or exceeds a threshold. In a specific, non-limiting example, the threshold can be 100%, such that the semantic type is adopted only when all values are validated. In another example, when a level of validation is below 50%, the data set can automatically classified as unrelated to the semantic type of the reference data set. In yet another example, a user can be prompted to confirm a hypothesized semantic type for the data set when the level of validation exists between 50% and 100%. However, it is further appreciated that such user input can be sought for any level of validation, or any level of validation which is not 100%. For instance, a data set can indeed contain city names, but do to limitations of the reference data set, have a low level of validation, i.e., the reference data set does not contain the city names in the sample. The user can override and establish city names as the semantic type of the data set. Further, the system can supplement the reference data set with the new city names learned. In this manner, the system can continue to learn and expand its reference knowledge to provide better and better inferences in the future.

[0057] FIG. 5 illustrates a flow diagram illustrating of an exemplary non-limiting embodiment for performing a domain check on a set of values associated with a semantic type. At 500, a set of values, e.g., a sample of data set or an entirety of a data set, and a candidate semantic type inferred from the set of values is received. At 510, the set of values are validated against domain rules corresponding to the candidate semantic type. For example, consider a semantic type of Earth latitudes. A valid latitude can range from +90° or 90° N, e.g., the North Pole, to ?90° or 90° S, e.g., the South Pole, with 0° corresponding to the equator. A value of 137 exceeds the valid range and is flagged as invalid. At 520, invalid values are presented to a user for correction, acceptance, override, dismissal, etc.

[0058] FIG. 6 is a block diagram illustrating an exemplary non-limiting act of inferring semantic information from published data sets in an information-as-a-service system. As illustrated in FIG. 6, an information service 610, e.g., an information-as-a-service system or information provided as a service from any platform can include a data set 612, data sets 614, and a data set 616. In an embodiment, publishers, e.g., content providers, can publish the data sets to the information service 610, essentially, without restriction as to form. As such, semantic information, e.g., meanings and types of data, can be missing from the published data sets. In this regard, FIG. 6 shows a semantic analysis component 620 that acquires sample data 615 for at least one data set in the information service 610 to infer semantic information 625 based thereupon. While FIG. 6 depicts sample data 615 extracted from data set 612, it is to be appreciated that such depiction is merely illustrative and exemplary for purpose of explanation and that semantic analysis component 620 can extract sample data 615 from data sets 614 and/or data set 616.

[0059] In an embodiment, semantic analysis component 620 can include various components configured to implement a variety of inference mechanisms. For instance, semantic analysis component 620 can include a field name check component 622 configured to implement a comparison of field names in sample data 615 with a set of tags having known semantic information. Further, semantic analysis component 620 can include a format check component 624 configured to identify and evaluate a format associated with sample data 615. In one embodiment, the format can facilitate selection of reference data sets employed by a value check component 626 configured to validate values in sample data 615 against one or more reference data sets corresponding to known semantic types. In a further embodiment, semantic analysis component 620 can include a domain check component 628 configured to verify that values in sample data 615 conform to domain rules associated with a particular semantic type.

[0060] According to a further embodiment where mash-ups of information in various data sets can be systematically generated based upon semantic information, FIG. 7 is a flow diagram illustrating an exemplary non-limiting embodiment for utilizing semantic information to correlate disparate data sets. At 700, a semantic type of at least one field of a first data set is inferred. For instance, the mechanisms described above can be employed on the first data set to determine the semantic type of the at least one field. At 710, at least one field of a second data set is identified, wherein the at least one field is associated with the same semantic type. For instance, the first data set can include a field of city names and a field of the second data set can be identified that also includes city names. At 720, relationship information, e.g., a join, between the first and second data sets, around the semantic type, can be generated. The relationship information can be employed to correlate disparate data sets. In addition, the relationship information can be utilized to query the disparate data sets to obtain hybrid data from multiple data sets.

[0061] FIG. 8 is a block diagram illustrating an exemplary non-limiting act of generating relationship information between data sets provided in an information-as-a-service system. As shown in FIG. 8, an information service 810, e.g., an information-as-a-service system or information provided as a service from any platform can include a data set 812, data sets 814, and a data set 816. A semantic analysis component 820 can extract sample data 815 from one or more data sets, such as data set 812 and data set 816 in a non-limiting and illustrative example. The semantic analysis component 820 is configured to infer semantic information 825 from sample data 815 extracted from data set 812 and data set 816. Semantic information 825 can specify a semantic type or a semantic meaning of one or more fields in data set 812 and data set 816.

[0062] In an embodiment, a linking component 830 configured to identify, based upon semantic information 825, fields of disparate data sets having identical semantic types. For instance, as indicated by semantic information 825, data set 812 and data set 816 can respectively include fields of state names. Linking component 830 is configured to generate relationship information 835 that associates data set 812 and data set 816 by the respective fields of state names.

[0063] In accordance with another embodiment, where a visualization of correlations between data sets can be displayed, FIG. 9 is a flow diagram illustrating an exemplary non-limiting embodiment for visualizing relationships between data sets of an information-as-a-service system. At 900, relationship information, e.g., a mash-up, correlating a plurality of data sets is obtained. The relationship information can specify a field of the plurality of data sets at which the plurality of data sets can be joined. At 910, visualization can be generated based upon the relationship information. In a non-limiting embodiment, the visualization can be a graph with nodes representing data sets and edges representing links e.g., correlations or relationships, identified between the data sets. At 920, the visualization is displayed as part of a user interface. At 930, input is received, via the user interface. The input can relate to approval or disapproval of the relationship information conveyed by the visualization. At 940, the relationship information is updated based upon the received input.

[0064] FIG. 10 is a block diagram illustrating an exemplary non-limiting act of generating visualizations of data set relationships and mash-ups in connection with an embodiment of an information-as-a-service system. As shown in FIG. 10, a semantic analysis component 1020 can extract sample data 1015 from an information service 1010 that includes data set 1012, data sets 1014, and data set 1016. The semantic analysis component 1020 produces semantic information 1025, which can be employed by a linking component 1030 to infer relationship information 1035. In an embodiment, the relationship information 1035 can be provided to visualization component 1040 configured to generate a visualization 1045. In a further embodiment, visualization component 1040 can query information service 1010, based upon the relationship information 1035, to acquire joined data 1050 representing the correlation of a plurality of data sets. The joined data 1050, in an aspect, can be displayed separately or in connection with the visualization 1045 in a user interface.

[0065] FIG. 11 is an exemplary non-limiting illustration of a visualization of relationships between data sets in connection with an embodiment of an information-as-a-service system. The visualization can be incorporated into a user interface that accepts user input. In a first, non-limiting example, a user can select a data set in the visualization to generate a first screen 1100. As shown in the first screen 1100, a plurality of data sets is depicted as nodes. A user can select a credit risk node (data set) to generate a visualization of the mash-ups available. As shown in FIG. 11, the credit risk data set correlates with a consumer debt data set and a stock ticker data. In a second, non-limiting example, the user can select a real estate data set to generate a second screen 1102. As seen in second screen 1102, the real estate data set is correlated with an unemployment data data set, an images data set, a news data set, and another data set. In another embodiment, the user can select a link 1104 to cancel or delete the association.

Building Semantics and Access API(S) in Connection with Information as a Service

[0066] The following description contains an alternative, non-limiting embodiment to build semantic information in connection with information as a service. As mentioned, in the context of information as a service, there are a finite number of things that may be represented in data sets (phone numbers, city codes, address, city, state, zip code, etc.) which can be inferred either the name of the column, or by weighted matching algorithms on the data itself (e.g., the 1st thousand things). For important data, while a human can be brought in to classify the data, for large amounts of data, such conventional human classification does not scale well, and if data is re-published by a publisher with different semantics, the human characterization may already be out of date.

[0067] Accordingly, in various embodiments, random samples resulting from querying a data set are analyzed to determine if the type of data can be inferred. For instance, a content provider provides a set of poorly described data, e.g., according to a proprietary schema. Based on or in response to a data request received over the data, a set of samples can be extracted from the data set for application of a set of algorithms to infer semantic meaning of the data, e.g., inferring data type or column name based on clues in the data or column name, or other column names. Since the publisher generally will not want his or her data that is published altered, a set of augmented semantics, e.g., mappings, can be maintained by the system to describe the inferences made by the system, e.g., _x=latitude for the earlier example. In this regard, as a result, the next developer is given more information about querying that data set, in which case more joins, filters, etc. can be performed with other data sets having a longitude column, and in addition, the access APIs themselves which previously included “_x( . . . )” as part of the syntax can be updated to “latitude( . . . )” making the access APIs self-descriptive over time to further aid developers. In one example, the query APIs are implemented via URLs, e.g., OData, more information about which can be found below.

[0068] In one embodiment, weighted algorithms based on known distributions of data, such as the age spread of a given population, can be used to determine probabilistically what a given set of data or column name represents, e.g., determine that a set of floating point numbers represents age.

[0069] In this way, without making it more difficult to publish data as is, certain conventions such as phone numbers and addresses can be enforced on the content providers through indirection, e.g., maintenance of semantic mappings. This way, content providers are encouraged to publish, but consumers still benefit from a sense of uniformity over the data. For instance, phone numbers are an example of numerical data that can be relatively easily identified as such, though variations such as area code parentheses, dashes, etc. exist. Standardizing this representation through semantic mappings based on inferences makes consumption of this data by developers and subscribers easier, in addition to adapting the access APIs over time to be more and more self-descriptive, e.g., re-naming a column “PN” as “phone numbers” or something else more descriptive.」

（当審訳）

[0029] 背景で説明したように、異なるデータセットを提供する異なるコンテンツプロバイダは、一般に、互いのデータセットについて知識がなく、そうする特別な動機もないため、それらのデータセットで表される情報またはデータ型の可能な重複に関して、一般に調整しない。ストレージエンティティによる保証の１つが、発行者が要求したアクセス制限の順守である、サービスとしての情報システム（本明細書では、任意のプラットフォームからサービスとして提供される情報とも呼ばれる）において、現在、データセットの特定のコンテンツの内部知識を通じてでなければ、開発側または消費側の異なるデータセット間の固有の相関関係を学習または視覚化する方法はない。また、サービスとしての情報システムでは、ストレージ事業者が提供するもう一つの保証として、公開後の基礎データセットへの不干渉性があり、公開されたデータは変更されないままである。このような場合、固有の相関関係は、既知であっても、カスタムアプリケーションを開発しなければ、現在活用することができない。

[0030] 例えば、コンテンツプロバイダＡは、緯度、経度、および対応する犯罪率、例えば、lat、longおよびcri_rateの列名を含むテーブルを公開することができる。コンテンツプロバイダＢは、都市の映画館情報を公開してもよく、緯度および経度に対応するxおよびy座標を有するが、都市の列が代わりに「Name」と呼ばれてもよく、例えば、_theatre, _Name, _x and _yの列名で呼ばれてもよい。したがって、従来のいかなる手段でも、この２つのセットを結合すれば、犯罪率が最も低い都市の映画館を実際に決定できることは、異なる列の意味するところが不明なままであるため、消費側では不明であった。また、人間が手作業で検査・分析することなく２つのセットを結合できることも、同様に蓄積側の従来の手段では不明であった。

[0031] したがって、_xと_yが緯度と経度であること、_Nameが都市名を意味すること、_theatreが映画館名を指すことを決定することが望まれる。すなわち、列に関する意味情報を取得することが望ましく、意味情報は、列に含まれるデータの意味的な（セマンティックな）意味を示す意味タイプを少なくとも伝達する。意味情報があれば、２つのデータセットを結合して、映画館周辺の犯罪率に関する有用なデータ（意味情報がなければわからなかった情報）を容易に得ることができる関係情報を系統的に導出することができる。前述したように、この作業は従来、手作業で行うことができた。しかし、データセットに数千、数百万、数十億といった多数の項目、列、行が含まれる場合、手作業によるタグ付けは負担が大きく、時間のかかる作業となる。さらに、データのサイズが大きくなるにつれて、誤ラベリングの機会も増加する。

[0032] 従って、様々な非限定的な実施形態において、意味解析は、サービスとしての情報システムなどのリポジトリに保持されるデータセットに対して実行することができるが、これらに限定されるものではない。意味解析を通じて、以前は異なるデータ／型を表すと考えられていた列間のマッピング（複数可）を提供することによって、結合、例えば、マッシュアップの可能性だけでなく、データ及び／又はデータ内のフィールドの説明を改善するために、データセットを意味情報で補強するためにデータについて推論することが可能である。この点に関して、様々な実施形態に従って、データセットのリポジトリ、例えば、サービスとしての情報システムは、データ型及びデータ間の接続を系統的に学習して、基礎となるデータの価値を高めるとともに、従来知られていなかった相関関係を発見することができる。

[0033] 一実施形態では、データリポジトリに格納されたデータセットからデータのサブセットを抽出することと、データのサブセットに対応するフォーマットを識別することと、フォーマットに基づいて少なくとも１つの参照データセットを選択することであって、少なくとも１つの参照データセットが既知の意味タイプに関連付けられることと、データのサブセットの値を少なくとも１つの参照データと比較することと、比較結果に基づいてデータセットの意味情報を推測することであって、意味情報がデータセット内のデータの少なくとも意味タイプを特定することと、を備える方法を、本明細書で説明する。一例において、本方法は、確認のために意味情報をユーザに提供することも含むことができる。より多くの例では、データのサブセットを抽出することは、データセットの全体を抽出すること、データセットの値をランダムに選択すること、またはデータセットの開始、データセットの終了、またはデータセットの中間の少なくとも１つから予め決められた数の値を抽出することを含むことができる。

[0034] 別の例では、方法は、１つ以上のドメインルールに対してデータのサブセットの値を検証すること、ここで１つ以上のデータルールはデータセット内のデータの意味タイプに対応し、無効な値をユーザに提示すること、ここで無効な値は、１つ以上のドメインルールによって許可されない値を含む、ことを含むこともできる。さらなる例では、本方法は、データセットからフィールド名を抽出することと、フィールド名を潜在的な有効タグのセットと比較することとを含むことができる。さらなるこの例では、本方法は、フィールド名が潜在的な有効タグのセット内のタグと一致するときを識別することと、一致したときにタグに関連するタイプを識別することと、データセットの意味タイプとしてタイプを関連付けることとを含むことができる。

[0035] さらなる例では、本方法は、データのサブセットの値の構造を複数の事前構成パターンに対して評価することと、値の構造が事前構成パターンに一致するときを識別することと、少なくとも１つの参照データセットを選択し、少なくとも１つの参照データセットに関連付けられた既知の意味タイプが事前構成パターンに対応し、事前構成パターンに一致する構造の数が所定の閾値を超えるとデータセットのデータの意味タイプとして既知の意味タイプを採用することとを含むことが可能である。

[0036] 追加の実施例によれば、データのサブセットの値を比較することは、データセットの値から１つの値を選択することと、その値で少なくとも１つの参照データセットを照会することと、その値での照会の結果が返されたときに有効ヒットをカウントすることとを含むことができる。別の例では、方法は、データセットのデータの意味タイプに対応する少なくとも１つのフィールドを含む第２のデータセットを特定することと、データセットを第２のデータセットと関連付ける関係情報を生成することとを含むことができ、関係情報は、データセットと第２のデータセットとの間の相関関係を指定する。さらに、本方法は、データリポジトリ内の複数のデータセットを相関させる関係情報を取得することと、関係情報の視覚化をグラフィカルユーザインターフェイスの一部として表示することと、グラフィカルユーザインターフェイスを介して入力を受け取ることと、入力に基づいて関係情報を更新することとを含むことができる。

[0037] 別の実施形態では、本明細書に記載の意味解析システムは、サービスとしての情報システムによって格納されたデータセットのデータに関する意味情報を推論するように構成された意味解析コンポーネントを含む。意味解析コンポーネントは、データセットから抽出されたサンプルデータのフォーマットを識別し、フォーマットに基づいて１つ以上の参照データセットを選択するように構成されたフォーマットチェックコンポーネントと、サンプルデータの値を１つ以上の参照データセットに対してチェックし、サンプルデータの意味タイプを識別するように構成された値チェックコンポーネントと、を含む。さらに、意味解析コンポーネントは、特定された意味タイプに基づいて意味情報を推論する。

[0038] 一実施例において、システムは、サンプルデータの値がドメインルールのセットを満たすかどうかを決定するように構成されたドメインチェックコンポーネントをさらに含む。ドメインルールのセットは、特定のデータ型に対する有効なデータ値を確立する。さらなる例では、システムは、それぞれの意味情報に基づいて、情報サービスシステムによって記憶された複数の異種のデータセットを関連付けるように構成されたリンクコンポーネントと、情報サービスシステムによって記憶されたデータセット間の相関関係の視覚化を生成するように構成された視覚化コンポーネントと、を含む。可視化は、ノードがそれぞれのデータセットを表し、エッジがデータセット間の相関関係を表すグラフ表示で構成され得る。

[0039] 追加の実施形態では、実行されると、データリポジトリに格納されたデータセットからデータのサブセットを抽出すること、データのサブセットに対応するフォーマットを識別すること、フォーマットに基づいて少なくとも１つの参照データセットを選択し、ここで、少なくとも1つの参照データセットは既知の意味タイプに関連付けられること、データのサブセットの値を少なくとも１つの参照データと比較すること、比較結果に基づいてデータセットの意味情報を推論し、意味情報はデータセット内のデータの少なくとも１つの意味タイプを特定することを実行させることを、コンピューティングデバイスに実行させるコンピュータ実行命令を含むコンピュータ可読記憶媒体が、本明細書に記載される。

[0040] これら及び他の様々な例示的、非限定的な実施形態及びシナリオの更なる詳細は、以下に提供される。

サービスとしての情報に関連して、データセットの意味を決定し、可視化すること

[0041] 前述のように、サービスとしての情報の文脈では、知能を持たない機械がデータセットから判断できることには限界がある。例えば、そのような機械は、データセットの第１の列が文字列を含み、第２の列が数字を含み、他の列の組が混合データ型、例えば数字と文字列を含むことを決定することが可能である。さらに、データを分類するために人間を導入することができるが、大量のデータに対して、そのような従来の人間の分類はうまく大規模にはできないし、データが異なる意味論で発行者によって再公開される場合、人間の特徴付けは既に古くなっている可能性がある。さらに、データは特定のドメインに関連しているように見えるが、人間はデータのセットを検証するのに十分なドメイン知識がないことがあるため、人間はデータのセットを誤って特徴付けることがある。

[0042] したがって、様々な実施形態において、様々なメカニズムを統一リポジトリ内のデータセットに適用して、データセットに含まれる情報のタイプ及び／又はデータの意味を特徴付ける意味情報を体系的に生成することができる。意味情報は、人間の特徴付けを検証し、置き換え、および補足するために使用することができる。１つのメカニズムとして、データセットのデータまたは列名、あるいは他の列名における手がかりに基づいて、データ型または列名を推定することが挙げられる。例えば、列名やフィールド名は、有効なタグの候補と照合することができる。列の意味情報（例えば、意味的タイプ）は、列名が有効なタグの集合に含まれる有効なタグと一致する場合に推論されることが可能である。しかし、このメカニズムだけでは、フィールド名のスペルが間違っている場合、またはフィールド内のデータが無効である場合（例えば、一致した有効なタグに関連するドメイン外の場合）、エラーまたは不正確さが発生する可能性がある。

[0043] 列名によってマッチしないデータに対処するため、および／またはマッチしたタグの正確性を確認するために、列内のデータに対して追加の処理を実行することができる。例えば、列内のデータのサンプルを抽出し、既知のデータパターンのセットとパターンマッチングすることによって、データのフォーマットを評価することができる。非限定的な例として、xxx-xxx-xxxxまたは（xxx）xxx-xxxxというフォーマットを持つデータ（xは任意の数字を表す）は、電話番号と認識することができる。場合によっては、フォーマットチェックで確定的な結果が得られないことがある。たとえば、都市名の列は文字列としてパターンマッチされるが、都市名には一般的又は固有のフォーマット制約がないため、詳細な情報を得ることが困難な場合がある。しかし、このような場合、フォーマットチェックを行うことで、評価されたフォーマットに適合しない意味的な型の可能性を排除し、さらなる意味解析や意味的な型の特定を容易にすることができる。例えば、電話番号、緯度、経度、日付、年齢、および他の数値タイプは、フォーマットが文字列であると評価される場合、可能な意味タイプとして排除されることが可能である。ユーザは、都市名、名字、国名、地域名、企業名などの文字列データを提供する可能性のある意味タイプのリストを提示されることができるが、これらに限定されるわけではない。さらに、可能な意味タイプのリストは、別の実施形態に従って、値チェックのための参照データセットとして採用される既知の意味タイプを有するデータセットを選択するために採用され得る。

[0044] 値のチェックにおいて、データセットの列におけるデータのサンプルは、候補意味タイプに関連付けられた参照データセットと照合され得る。参照データセットは、サンプルの値がそこに含まれているかどうかを判断するために照会され得る。決定的な一致を区別しやすくするために、すなわち、データセットの列が候補意味タイプのデータを含むか、明確な不一致か、曖昧な結果かを区別することを容易にするために、１つまたは複数の閾値を設定することが可能である。例えば、100％検証、すなわち、サンプル内のすべての値が参照データセットにあることは、決定的な一致として分類され得る。別の例では、曖昧な結果は、検証、修正、または上書きするためにユーザに転送することができる。

[0045] 別の実施形態では、統一リポジトリ内のデータセットの列に関連付けられた意味情報は、データセット間の結合点の即時発見を容易にし、これを活用して、データセットの興味深いマッシュアップを生成することができる。一例として、犯罪統計からなる第１のデータセットは、都市別の犯罪率を含むことができ、重なる都市フィールドに沿って都市別の不動産情報からなる第２のデータセットと結合することができる。上記のようにデータセットのより多くのフィールドの意味情報が生成されると、システムは、データセット間の新しい相関関係を継続的に学習して、基礎となるデータの価値を向上させることができる。

[0046] さらに、相関関係、およびマッシュアップデータ自体を、ユーザインターフェイスに関連して可視化し、表示することができる。例えば、リポジトリ内のデータセットを表すノードを有するグラフ表示をユーザに提示することができる。ユーザがノード（データセットなど）を選択すると、選択したノードと、相関関係が導出された他のノード（データセットなど）との間にリンクが引かれるようにすることができる。別の例では、ユーザは、データセット間のリンクを選択して、マッシュアップの視覚化、例えば、２つの異種データセットの結合として生成された生成データセットを得ることができる。

[0047] 図1は、データセットに関連する意味情報を決定するための例示的な非限定的実施形態を示すフロー図である。特定の非限定的な例では、データセットは、サービスとしての情報システムによって管理および公開されるデータリポジトリに含まれることができる。しかしながら、プライベートデータセットは、本明細書に開示される実施形態を利用して、人間の入力を減らして自動的な方法で意味情報及び／又は興味深いマッシュアップを生成できることが理解されよう。

[0048] 100において、データセット内のフィールドまたは列の１つまたは複数のフィールド名、例えば、列名が、潜在的な有効なタグのリストと比較される。潜在的有効タグは、既知の意味またはタイプを有するフィールド名、列名、データラベル、タグ、またはそのようなものを含む。データセット内の１つ以上のフィールドまたは列の意味情報は、リスト内の有効なタグとの一致に基づいて推論することができる。しかしながら、フィールド名チェックから生成された意味情報を洗練または検証するために、さらなる処理を実行することができる。例えば、110において、データセットの１つ以上のフィールドのフォーマットが特定される。一例として、電話番号は、エリアコードの括弧、ダッシュなどのバリエーションにもかかわらず、比較的識別できるタイプの数値データである。したがって、電話番号、社会保障番号、カレンダーの日付、タイムスタンプなどのフォーマットチェックから意味情報を推論することができる。他の場合、フォーマットチェックは、データセット内のデータの意味やタイプを確定的に特定することはできないが、特定されたフォーマットに関連しないデータ型を排除することにより、候補の数を減らすことはできる。例えば、フォーマットチェックは、値チェックによってテストされる潜在的な意味タイプの候補の数を狭めることができる。

[0049] 120において、データセットの１つまたは複数のフィールドの実際の値は、少なくとも１つの参照データセットに対してチェックされる。参照データセットは、既知の意味情報、例えば、データが既知の意味タイプまたは意味を有し、１つまたは複数のフィールドの値が既知の意味タイプに対応するかどうかを決定するためにクエリされることができるものを含む。130において、データセットの１つまたは複数のフィールドに関連する意味タイプが決定される。意味タイプは、フィールド名チェック、フォーマット評価、および／または値チェックに基づいて決定されることができる。さらに、意味タイプは、確認のためにユーザに報告され、またはデータセットの視覚化の一部として報告され得る。

[0050] 上述したプロセスは、ユーザとの対話なしに自動化された様式で起こり得ることが理解されるであろう。しかしながら、別の実施形態では、ユーザは、プロセスの様々なステップにおいて、決定された意味情報（またはこれまでに決定された部分的な意味情報）の確認、さらなる処理の要求、矛盾したフォーマットまたは値への対処、プロセスの上書き、または推測された意味情報の変更を促されることが可能である。例えば、一例では、フィールド名チェック中に、フィールド名が"_fname "であり、有効なタグのリストが"_name "または "name "を含む場合、近い一致を確認するようにユーザに促すことができる。別の例では、ユーザは、少なくとも１つの参照データセット内で見つからない値を受け入れるか修正するように促され得る。例えば、データセット内の誤字のために値が見つからず、これはユーザによって認識されるであろう。従って、ユーザ入力は、推論を補足及び／又は検証するために利用することができる。

[0051] 図２は、データセットのフィールド名を、既知の意味タイプを有する潜在的なタグに対してチェックするための例示的な非限定的実施形態を示すフロー図である。200において、情報のリポジトリ、例えば、サービスとしての情報システムからのデータセットが受信される。210において、データセットの１つ又は複数のフィールド名が抽出される。220において、抽出されたフィールド名と有効なタグのセットとの間で比較、例えば、文字列比較が実行される。潜在的有効タグのセットは、データフィールドの可能性のあるラベル又は名前を含み、タグの意味又はデータフィールドの意味タイプが既知である。有効なタグのセットは、異種データの以前の意味解析中に検出されたフィールド名、データセットに一般的に採用されるフィールド名、ユーザによって提供されたタグ、または同様のもので入力され得る。240において、１つ以上のフィールド名とリスト内の有効なタグとの間に一致があるかどうかの判定が行われ得る。一致しない場合、意味解析は、異なるメカニズムを利用して継続することができ、または、ユーザが介入するように促すことができる。一致するものがある場合、次に、240において、一致した有効なタグに関連する意味タイプが識別され、１つまたは複数のフィールド名に関連する１つまたは複数のフィールドのための可能なセマンティックタイプとしてフラグを立てられる。

[0052] 図３は、データセットから抽出されたサンプル情報の形式に基づいて基準データセットを選択するための例示的な非限定的実施形態を示す流れ図である。300において、データセットの１つ以上のフィールド、例えば列、に対応するデータセットからデータのサンプルを抽出する。データのサンプルは、ランダムに抽出することができ、又はデータセットの最初のＮ個のエントリ若しくは行、最後のＮ個のエントリ、又は中間のＮ個のエントリを抽出することができ、ここで、Ｎは1以上の整数である。別の実施形態では、データのサンプルは、データセットの全体を含むことができる。310において、データのサンプルのフォーマットが評価される。一例では、データのサンプルの各値は、データ型、例えば、文字列、数値、混合型など、及び／又は可能な意味タイプ、例えば、電話番号、日付、固有名詞などを決定するためにパターンと照合することができる。例えば、値は、MM／DD／YYYY、MM-DD-YYYYなどの少なくとも1つの形式を確認する混合型であると決定することができる。したがって、データのサンプルは、日付を含むと判断することができる。別の例では、値が、大文字で始まる文字列、すなわち、固有名詞を含むと特定することができる。

[0053] 320において、少なくとも１つの基準データセットが、評価された形式に基づいて選択され得る。いくつかの状況において、正確な意味タイプは、評価されたフォーマットから推論され得る。例えば、明確なフォーマット、例えば、日付、時間、電話番号などに関連する意味タイプは、評価されたフォーマットから直接推測することができ、追加の検証、例えば、値のチェックを回避することができる。しかし、容易に認識できるフォーマットを持つデータであっても、様々な意味タイプに関連付けることができることが理解されよう。例えば、社会保障番号、従業員識別番号、雇用者識別番号などは、データセットにおいて同様の表現を示すことができる。しかし、このような異種データは異なる意味と文脈を持っているため、さらなる改良や検証が必要である。そのため、雇用者識別番号、従業員識別番号などを含む参照データセットが選択され得る。

[0054] 別の態様では、文字列などの他のフォーマットは、可能な意味タイプの群を狭めることができるが、決定的な解決策を提供するものではない。したがって、可能なセマンティックタイプの絞り込まれた群に対応する参照データセットのセットが選択され得る。たとえば、評価されたフォーマットが、データセットに固有名詞が含まれていることを示す場合、固有名詞、たとえば、都市名、国名、名字、ビジネス名などのデータセットが選択され得る。

[0055] 図４は、データのサンプルからの値を参照データセットに対してチェックするための例示的な非限定的実施形態を示すフロー図である。基準データセットは、上述したようにフォーマットチェックの結果として選択され得るか、又は対話的意味解析プロセスの一部としてユーザによって選択され得る。400において、データセットの１つ以上のフィールド、例えば列、に対応するデータセットからデータのサンプルを抽出する。データのサンプルは、ランダムに抽出され得るか、またはデータセットの最初のＮ個のエントリもしくは行、最後のＮ個のエントリ、または中間のＮ個のエントリが抽出され得、ここでＮは、１以上の整数である。別の実施形態では、データのサンプルは、データセットの全体を含むことができる。410で、データのサンプルからの値が選択される。420では、選択された値が含まれているかどうかを確認するために、参照データセットが照会される。430で、クエリの結果が返されるかどうかが確認される。ＹＥＳの場合、440で有効なヒットのカウントが増加される。ＮＯの場合、または440での増加の後、450でサンプルに追加の値が残っているかどうかが判断される。ＹＥＳであれば、410で別の値が選択され、ステップ420?450を繰り返すことができる。

[0056] 460で、有効なヒットのカウントから、例えばサンプルのサイズに対するヒットの割合として、検証レベルを識別することができる。さらに、検証レベルに基づいて、意味情報、例えば、サンプルの意味的なタイプを推測することができる。実施形態において、基準データセットの意味タイプは、検証レベルが閾値に達するか又はそれを超える場合に、サンプルが抽出されるデータセットの意味タイプとして採用され得る。特定の非限定的な例では、閾値は、すべての値が検証された場合にのみ意味タイプが採用されるように、100％とすることができる。別の例では、検証レベルが50％未満である場合、データセットは、参照データセットの意味タイプに無関係であると自動的に分類され得る。さらに別の例では、検証レベルが50％から100％の間に存在するとき、ユーザは、データセットの仮説的な意味タイプを確認するように促され得る。しかしながら、このようなユーザ入力は、任意の検証レベル、または100％でない任意の検証レベルに対して求めることができることがさらに理解される。例えば、データセットは確かに都市名を含むが、参照データセットの制限により、低い検証レベルを有する、すなわち、参照データセットがサンプル中の都市名を含まないことができる。ユーザは、都市名をデータセットの意味タイプとして上書きすることができる。さらに、システムは、学習した新しい都市名で参照データセットを補完することができる。このように、システムは学習と参照知識の拡張を続けることで、より良い推論を将来にわたって提供することができる。

[0057] 図５は、意味タイプに関連する値のセットに対してドメインチェックを実行するための例示的な非限定的実施形態を示すフロー図である。500において、値のセット、例えば、データセットのサンプルまたはデータセットの全体、および値のセットから推定される意味タイプの候補が受信される。510において、値の集合は、候補意味タイプに対応するドメインルールに対して検証される。例えば、地球の緯度の意味タイプについて考える。有効な緯度は、+90°または90°N（北極）から-90°または90°S（南極）の範囲で、0°は赤道に対応する。137の値は、有効範囲を超え、無効であるとしてフラグが立てられる。520において、無効な値は、修正、受諾、上書き、棄却などのためにユーザに提示される。

[0058] 図６は、サービスとしての情報システムにおいて公開されたデータセットから意味情報を推論する例示的な非限定的行為を示すブロック図である。図６に示されるように、情報サービス610、例えば、サービスとしての情報システムまたは任意のプラットフォームからサービスとして提供される情報は、データセット612、データセット614、およびデータセット616を含むことができる。実施形態では、発行者、例えば、コンテンツプロバイダは、基本的に、フォーマットに関する制限なしに、情報サービス610にデータセットを公開することができる。そのため、意味情報、例えば、データの意味及びタイプは、公開されたデータセットから欠落し得る。この点に関して、図６は、情報サービス610内の少なくとも１つのデータセットに関するサンプルデータ615を取得して、それに基づいて意味情報625を推論する意味解析コンポーネント620を示す。図６は、データセット612から抽出されたサンプルデータ615を描いているが、そのような描写は、単に説明のために例示的であり、意味解析コンポーネント620は、データセット614および／またはデータセット616からサンプルデータ615を抽出できることが理解されよう。

[0059] 実施形態において、意味解析コンポーネント620は、様々な推論機構を実装するように構成された様々なコンポーネントを含むことができる。例えば、意味解析コンポーネント620は、サンプルデータ615内のフィールド名の、既知の意味情報を有するタグのセットとの比較を実施するように構成されたフィールド名チェックコンポーネント622を含むことができる。さらに、意味解析コンポーネント620は、サンプルデータ615に関連するフォーマットを識別し評価するように構成されたフォーマットチェックコンポーネント624を含むことができる。一実施形態では、フォーマットは、既知の意味タイプに対応する１つ以上の基準データセットに対してサンプルデータ615内の値を検証するように構成された値チェックコンポーネント626によって採用される基準データセットの選択を容易にすることができる。さらなる実施形態では、意味解析コンポーネント620は、サンプルデータ615中の値が特定の意味タイプに関連するドメインルールに適合することを検証するように構成されたドメインチェックコンポーネント628を含むことができる。

[0060] 様々なデータセットにおける情報のマッシュアップが意味情報に基づいて体系的に生成され得るさらなる実施形態によれば、図７は、異種データセットを関連付けるために意味情報を利用するための例示的な非限定的実施形態を示す流れ図である。700において、第１のデータセットの少なくとも１つのフィールドの意味タイプが推論される。例えば、少なくとも１つのフィールドの意味タイプを決定するために、上述の機構を第１のデータセットに採用することができる。710において、第２のデータセットの少なくとも１つのフィールドが特定され、少なくとも１つのフィールドは、同じ意味タイプに関連付けられる。例えば、第１のデータセットは、都市名のフィールドを含むことができ、第２のデータセットのフィールドは、都市名も含むことが特定されることができる。720において、意味タイプを中心とした、第１及び第２のデータセット間の関係情報、例えば、結合を生成することができる。関係情報は、異種のデータセットを関連付けるために使用することができる。さらに、関係情報は、複数のデータセットからハイブリッドデータを得るために異種データセットを照会するために利用することができる。

[0061] 図８は、サービスとしての情報システムにおいて提供されるデータセット間の関係情報を生成する例示的な非限定的行為を示すブロック図である。図８に示すように、情報サービス810、例えば、サービスとしての情報システムまたは任意のプラットフォームからサービスとして提供される情報は、データセット812、データセット814、およびデータセット816を含むことができる。意味解析コンポーネント820は、非限定的かつ例示的な例では、データセット812およびデータセット816などの1つまたは複数のデータセットからサンプルデータ815を抽出することができる。意味解析コンポーネント820は、データセット812及びデータセット816から抽出されたサンプルデータ815から意味情報825を推論するように構成される。意味情報825は、データセット812およびデータセット816内の１つまたは複数のフィールドの意味的なタイプまたは意味的な（セマンティックな）意味を指定することができる。

[0062] 実施形態では、意味情報825に基づいて、同一の意味タイプを有する異種データセットのフィールドを識別するように構成されたリンクコンポーネント830が提供される。例えば、意味情報825によって示されるように、データセット812およびデータセット816は、それぞれ、状態名のフィールドを含むことができる。リンクコンポーネント830は、状態名のそれぞれのフィールドによってデータセット812およびデータセット816を関連付ける関係情報835を生成するように構成される。

[0063] データセット間の相関関係の視覚化が表示され得る別の実施形態に従って、図９は、サービスとしての情報システムのデータセット間の関係を視覚化するための例示的な非限定的実施形態を示す流れ図である。900において、複数のデータセットを相関させる関係情報、例えば、マッシュアップが取得される。関係情報は、複数のデータセットが結合され得る、複数のデータセットのフィールドを指定し得る。910において、関係情報に基づいて、可視化が生成され得る。非限定的な実施形態において、可視化は、データセットを表すノードと、データセット間で特定されるリンク、例えば相関又は関係を表すエッジとを有するグラフであり得る。920で、視覚化は、ユーザインターフェイスの一部として表示される。930で、ユーザインターフェイスを介して、入力が受信される。入力は、可視化によって伝達される関係情報の承認または不承認に関連することができる。940で、関係情報は、受信された入力に基づいて更新される。

[0064] 図１０は、サービスとしての情報システムの一実施形態に関連して、データセットの関係及びマッシュアップの視覚化を生成する例示的な非限定的行為を示すブロック図である。図１０に示すように、意味解析コンポーネント1020は、データセット1012、データセット1014、およびデータセット1016を含む情報サービス1010からサンプルデータ1015を抽出することができる。意味解析コンポーネント1020は、関係情報1035を推論するためにリンクコンポーネント1030によって採用することができる意味情報1025を生成する。実施形態では、関係情報1035は、可視化1045を生成するように構成された可視化コンポーネント1040に提供され得る。さらなる実施形態では、可視化コンポーネント1040は、関係情報1035に基づいて、情報サービス1010に照会して、複数のデータセットの相関関係を表す結合データ1050を取得することができる。結合データ1050は、一態様では、ユーザインターフェイスにおいて、別個に、または可視化1045に関連して表示され得る。

[0065] 図１１は、サービスとしての情報システムの実施形態に関連する、データセット間の関係の視覚化の例示的な非限定的図解である。この視覚化は、ユーザ入力を受け付けるユーザインターフェイスに組み込むことができる。第１の非限定的な例では、ユーザは、視覚化においてデータセットを選択して、第１の画面1100を生成することができる。第１の画面1100に示されるように、複数のデータセットがノードとして描かれる。ユーザは、信用リスクノード（データセット）を選択して、利用可能なマッシュアップの視覚化を生成することができる。図１１に示すように、信用リスクデータセットは、消費者負債データセット及び株式ティッカーデータと相関がある。第２の非限定的な例では、ユーザは、第２の画面1102を生成するために不動産データセットを選択することができる。第２の画面1102に見られるように、不動産データセットは、失業データデータセット、画像データセット、ニュースデータセット、および別のデータセットと相関している。別の実施形態では、ユーザは、リンク1104を選択して、関連付けを取り消すか、または削除することができる。

サービスとしての情報に関連するセマンティクスおよびアクセスＡＰＩ（S）の構築

[0066] 以下の説明は、サービスとしての情報に関連して意味情報を構築するための代替の非限定的な実施形態を含む。前述のように、サービスとしての情報の文脈では、データセット（電話番号、都市コード、住所、都市、州、郵便番号など）において表現され得るものの数は有限であり、列の名前、またはデータ自体（例えば、最初の１０００個）に対する重み付きマッチングアルゴリズムによって推論され得るものである。重要なデータについては、人間がデータを分類することができるが、大量のデータについては、そのような従来の人間の分類はうまく大規模化できないし、データが異なる意味を有する発行者によって再公開される場合、人間による特徴付けは既に古くなっている可能性がある。

[0067] 従って、様々な実施形態において、データセットをクエリした結果のランダムなサンプルが分析され、データのタイプを推測することができるかどうかが判断される。例えば、コンテンツプロバイダは、十分に記述されていない、例えば、独自のスキーマに従ってデータセットを提供する。データ上で受け取ったデータ要求に基づいて、またはそれに応答して、データの意味的な（セマンティックな）意味、例えば、データまたは列名、または他の列名における手掛かりに基づいてデータ型または列名を推測するためのアルゴリズムのセットを適用するために、データセットからサンプルのセットを抽出することができる。発行者は一般に、公開された自分のデータが変更されることを望まないので、システムによって行われる推論、例えば先の例では_x= latitude（緯度）を記述するために、一連の拡張セマンティクス、例えばマッピングをシステムによって維持することが可能である。この点、結果として、次の開発者は、そのデータセットのクエリに関するより多くの情報を与えられ、その場合、経度の列を有する他のデータセットとのより多くの結合、フィルタなどを実行することができ、さらに、以前は構文の一部として「_x（ ... ）」を含んでいたアクセスＡＰＩ自体を「latitude（ ... ）」に更新し、アクセスＡＰＩの自己記述性を時間の経過と共に高め、開発者をさらに支援することができる。一例では、クエリＡＰＩは、ＵＲＬ、例えば、ＯＤａｔａを介して実装され、これに関するより多くの情報は、以下に見出される。

[0068] 一実施形態では、所定の人口の年齢分布のようなデータの既知の分布に基づく重み付けアルゴリズムを使用して、所定のデータ集合または列名が表すものを確率的に決定することができ、例えば、浮動小数点数の集合が年齢を表すと決定することができる。

[0069] このようにして、データをそのまま公開することを難しくすることなく、電話番号や住所などの特定の規則を、意味的マッピングの維持など、間接的な方法でコンテンツプロバイダに強制することができる。こうすることで、コンテンツプロバイダは公開を奨励されるが、購読者はデータに対する統一感の恩恵を受けることができる。例えば、電話番号は、市外局番の括弧やダッシュなどのバリエーションはあるものの、比較的容易に識別できる数値データの一例である。推論に基づく意味的マッピングによってこの表現を標準化することで、開発者と購読者によるこのデータの利用が容易になる。さらに、アクセスＡＰＩを時間の経過とともに適応させ、より自己記述的なもの、例えば、列の名前を「PN」から「電話番号」または他のより記述的なものに変更することができる。

「[0112] FIG. 15 is a block diagram illustrating an exemplary end to end flow from data to consumers of the data in accordance with one or more embodiments of the general infrastructure for enabling information as a service. For instance, information as a service 1500 can include commercial data 1502 and free data 1504, which can be of interest to various for profit developers 1510, nonprofit developers 1512 with non-profit motives and other information workers 1514 who are interested in consuming the data generally for productive goals. These entities can use discovery services 1520 to determine what applications 1522, 1524, . . . , 1526 may be of interest to them, and to ultimately transmit the data to ILA consumers 1530 and DLA consumers 1532 alike.」

（当審訳）

[0112] 図１５は、サービスとしての情報を可能にするための一般的なインフラストラクチャの１つ以上の実施形態による、データからデータの消費者への例示的なエンドツーエンドフローを示すブロック図である。例えば、サービスとしての情報1500は、商業データ1502及び無料データ1504を含むことができ、これらは、様々な営利開発者1510、非営利の動機を有する非営利開発者1512、及び一般に生産的な目標のためにデータを消費することに関心がある他の情報労働者1514にとって関心があるものであり得る。これらのエンティティは、発見サービス1520を使用して、どのアプリケーション1522,1524,....,1526に興味を持つかもしれず、最終的にＩＬＡ消費者1530およびＤＬＡ消費者1532に同様にデータを送信することができる。