Metadata inheritance for data assets

Abstract

Embodiments of the invention relate to managing data using network computers. A hierarchical model including edges representing dependencies between fields can be generated. In response to a query for determining values of metadata associated with an anchor field, further actions including traversing the hierarchical model upward from the anchor field based on the query, and in response to visiting a field node in the hierarchical model, collecting values of metadata corresponding to the visited field node, and terminating the traversal based on a type of the query; in response to visiting a compute node, terminating the traversal of the hierarchical model associated with the visited compute node; and in response to visiting a flow node that depends on two or more other nodes, terminating the traversal of the hierarchical model can be performed. The collected metadata can be provided in response to the query.

Description

[0001] Cross-reference to related applications

[0002] This application is based on a previously filed U.S. Provisional Patent Application No. 63 / 195,568, filed on June 1, 2021, which claims the date of filing of the U.S. Provisional Patent Application under 35 USC §119(e), the entire contents of which are further incorporated herein by reference. Technical Field

[0003] This invention relates generally to data visualization, and more specifically, but not exclusively, to managing data associated with objects included in the visualization. Background Technology

[0004] Organizations are generating and collecting ever-growing volumes of data. This data can be correlated with different parts of the organization, such as consumer activities, manufacturing activities, customer service, server logs, etc. For various reasons, it may be inconvenient for such organizations to efficiently utilize their massive datasets. In some cases, the sheer volume of data can make it difficult to efficiently leverage the collected data to improve business practices. Therefore, in some situations, organizations may employ various applications or tools to generate visualizations based on some or all of their data. Using visualizations to represent data allows organizations to improve their understanding of business operations, sales, customer information, employee information, key performance indicators, etc. In some cases, complex visualizations may incorporate or otherwise depend on data from various sources within the organization, including different databases. In some cases, there may be many different visualizations, which may depend on these varying or different data sources. Typically, data defined across different data sources can include metadata, including descriptions, tags, labels, etc. The authors / designers of the data sources can associate metadata with various data to convey information that the visualization author or visualization user may be interested in. However, the data objects accessed by the visualization author or visualization user may be logically distant from the data in the data source. Therefore, determining when or whether metadata can be disseminated to data objects used by visualization authors or visualization users can be difficult. This invention addresses these and other considerations. Attached Figure Description

[0005] The following figures illustrate a non-limiting and non-exhaustive embodiment of the invention. In the figures, similar reference numerals denote similar parts unless otherwise stated. For a better understanding of the described invention, reference will be made to the following detailed description, which will be read in conjunction with the figures, wherein:

[0006] Figure 1The system environment in which various implementation schemes can be implemented is shown;

[0007] Figure 2 A schematic implementation scheme for the client computer is shown;

[0008] Figure 3 A schematic implementation of a network computer is shown;

[0009] Figure 4 The logical architecture of a system for metadata inheritance for data assets is shown according to one or more of various implementation schemes;

[0010] Figure 5 A logical representation of a portion of a system for metadata inheritance for data assets, according to one or more of various implementation schemes, is shown;

[0011] Figure 6 A logical diagram illustrating a portion of a system dependent on a data model, according to one or more of various implementation schemes;

[0012] Figure 7 A logical diagram of a portion of a dependency hierarchy structure according to one or more of various implementation schemes is shown, illustrating at least a portion of the logical nodes in the dependency hierarchy structure;

[0013] Figure 8 A logical diagram of a data object including metadata information is shown according to one or more of various implementation schemes;

[0014] Figure 9 An overview flowchart of the process for metadata inheritance for data assets according to one or more of various implementation schemes is shown;

[0015] Figure 10 A flowchart is shown illustrating the process of metadata inheritance for data assets according to one or more of various implementation schemes;

[0016] Figure 11 A flowchart is shown illustrating the process for metadata inheritance for data assets according to one or more of various implementation schemes;

[0017] Figure 12 A flowchart is shown illustrating the process for metadata inheritance for data assets according to one or more of various implementation schemes;

[0018] Figure 13 A flowchart is shown illustrating a process for information security associated with metadata inheritance of data assets, according to one or more of various implementation schemes.

[0019] Figure 14 The logical representation of a query for metadata inheritance for data assets is shown according to one or more of the various implementation schemes;

[0020] Figure 15 The logical representation of a query for metadata inheritance for data assets is shown according to one or more of the various implementation schemes;

[0021] Figure 16 The logical representation of metadata query results for metadata inheritance is shown according to one or more of the various implementation schemes. Detailed Implementation

[0022] Various embodiments will now be described more fully below with reference to the accompanying drawings, which form part of the invention and illustrate specific exemplary embodiments in which the invention may be practiced. However, embodiments may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that the disclosure will be thorough and complete, and will fully convey the scope of the embodiments to those skilled in the art. Among other things, the various embodiments can be methods, systems, media, or devices. Thus, the various embodiments can take the form of entirely hardware implementations, entirely software implementations, or implementations combining software and hardware aspects. Therefore, the following detailed description should not be construed as limiting.

[0023] Throughout the specification and claims, the following terms take on the meaning explicitly associated with this document unless the context clearly specifies otherwise. The phrase "in one embodiment" as used herein does not necessarily refer to the same embodiment, although it may refer to the same embodiment. Similarly, the phrase "in another embodiment" as used herein does not necessarily refer to different embodiments, although it may refer to different embodiments. Therefore, as described below, various embodiments can be readily combined without departing from the scope or spirit of the invention.

[0024] Additionally, as used herein, the term “or” is an inclusive “or” operator and is equivalent to the term “and / or”, unless the context clearly specifies otherwise. The term “based on” is not exclusive and allows for basing on additional factors not described, unless the context clearly specifies otherwise. Furthermore, throughout the specification, the meanings of “a,” “an,” and “the” include plural references. The meaning of “in” includes both “in” and “on”.

[0025] For exemplary implementations, the following terms are also used herein according to their corresponding meanings, unless the context clearly specifies otherwise.

[0026] As used herein, the term "engine" refers to logic implemented with hardware or software instructions, which can be written in programming languages ​​such as C, C++, Objective-C, COBOL, Java™, Kotlin, PHP, Perl, JavaScript, Ruby, VBScript, or in Microsoft .NET™ languages ​​such as C#. Engines can be compiled into executable programs or written in interpreted programming languages. Software engines can be invoked from other engines or from themselves. The engine described herein refers to one or more logical modules that can be combined with other engines or applications or can be divided into sub-engines. Engines can be stored on non-transitory computer-readable media or computer storage devices and can be stored on and executed by one or more general-purpose computers, thereby creating a dedicated computer configured to provide the engine. Furthermore, in some implementations, one or more parts of the engine can be hardware devices, ASICs, FPGAs, etc., that perform one or more actions to support the engine or are part of the engine.

[0027] As used herein, the term "data model" refers to one or more data structures that represent one or more entities associated with data collected or maintained by an organization. Data models are typically arranged to model the various operations or activities associated with the organization. In some cases, data models are arranged to provide or facilitate actions in various datasets, such as efficient storage, querying, indexing, searching, updating, etc. Often, data models may be arranged to provide features related to data manipulation or data management, rather than providing an easily understandable representation or visualization of the data.

[0028] As used in this article, the term "data object" refers to one or more entities or data structures that comprise a data model. In some cases, a data object can be considered part of a data model. Data objects can represent classes or kinds of items, such as databases, data sources, tables, workbooks, visualizations, workflows, etc.

[0029] As used herein, the term “data object class” or “object class” refers to one or more entities or data structures that represent a class, kind, or type of data object.

[0030] As used herein, the term "display model" refers to one or more data structures representing one or more representations of a data model that can be adapted for use in visualizations displayed on one or more hardware displays. The display model can define style or user interface features available to non-authoring users.

[0031] As used herein, the term "dependency hierarchy" refers to one or more data structures that represent a dedicated model used to represent the inheritance information of a corresponding data model. A dependency hierarchy typically includes field nodes for storing / representing the values ​​of data object attributes, computation nodes representing applied data transformations that can change the semantic meaning of the data, or flow nodes representing data transformations that do not substantially change the semantic meaning of the transformed data. Edges between nodes indicate that data or information from higher nodes in the dependency hierarchy can be propagated to lower nodes in the dependency hierarchy. Dependency hierarchies can be used to track data dependencies between data objects in a data model.

[0032] As used herein, the term "metadata query" refers to a query that represents a request for metadata information about one or more data objects. In some cases, a dependency hierarchy corresponding to the data model can be used to resolve metadata queries.

[0033] As used herein, the term "display object" refers to one or more data structures that comprise a display model. In some cases, a display object can be considered a part of the display model. A display object can represent an individual instance of an item that can be displayed in a visualization or an entire class or category of items. In some implementations, a display object can be considered a view or referred to as a view because it provides a view of a portion of the data model.

[0034] As used in this article, the term "anchor field" refers to a field node in a dependency hierarchy that has been selected as the starting point for determining metadata inheritance. Metadata queries can be qualified with anchor fields, which are often the focus of the metadata query.

[0035] As used herein, the term "panel" refers to an area within a graphical user interface (GUI) that has a defined geometry (e.g., x, y, z order) within the GUI. Panels can be arranged to display information to a user or to host one or more interactive controls. Configuration information, including dynamic rules, can be used to define the geometry or style associated with a panel. Furthermore, in some cases, users can be enabled to perform actions on one or more panels, such as moving, showing, hiding, resizing, reordering, etc.

[0036] As used herein, the term "configuration information" refers to information that may include rule-based policies, pattern matching, scripts (e.g., computer-readable instructions), etc., and that can be provided from a variety of sources, including configuration files, databases, user input, built-in defaults, etc., or combinations thereof.

[0037] The following is a brief description of embodiments of the invention to provide a basic understanding of some aspects of the invention. This brief description is not intended as a broad overview. It is not intended to identify key or important elements, nor is it intended to depict or otherwise narrow the scope. Its purpose is merely to present some concepts in a simplified form as an introduction to the more detailed description that follows.

[0038] In short, the various implementation schemes involve using networked computers to manage data. In one or more of these schemes, a hierarchical structure model can be generated, comprising one or more edges representing dependencies between one or more field nodes, one or more compute nodes, or one or more flow nodes.

[0039] In one or more of the various implementation schemes, in response to a query for determining one or more values ​​of metadata associated with an anchor field that is a field node in the hierarchical structure model, further actions are performed including: traversing the hierarchical structure model upwards from the anchor field based on the query and the hierarchical structure model, and performing further actions including: collecting one or more values ​​of metadata corresponding to the accessed field node in response to accessing one or more field nodes in the hierarchical structure model, wherein the traversal is terminated based on the type of the query; terminating the traversal of the hierarchical structure model associated with the accessed compute node in response to accessing the compute node; and terminating the traversal of the hierarchical structure model associated with the accessed flow node in response to accessing a flow node that depends on two or more other nodes in the hierarchical structure model.

[0040] In one or more of the various implementation schemes, a response to the query may be provided, which includes one or more collected values ​​of metadata that can be inherited from the anchor field.

[0041] In one or more of the various implementations, terminating traversal based on the query type may include: terminating traversal of the hierarchical model in response to the query being a first query type, in response to accessing a first ancestor field node that can be associated with the value of metadata for the anchor field, such that the value of the metadata collected from the first ancestor field node can be provided as metadata for the anchor field.

[0042] In one or more of the various implementation schemes, terminating traversal based on query type may further include: in response to the query being a second query type, performing further actions including: accessing each field node in the hierarchical structure model that is an ancestor of the anchor field, such that accessing intermediate compute nodes or intermediate multi-input stream nodes terminates the traversal of the hierarchical structure model; and collecting one or more values ​​of metadata for each accessed field node that is an ancestor of the anchor field, such that one or more values ​​of the metadata can be sorted based on one or more dependencies in the hierarchical structure model that correspond to the anchor field and one or more accessed ancestor field nodes.

[0043] In one or more of the various implementations, traversing the hierarchical structure model may include: determining one or more security policies associated with the hierarchical structure model based on the query and the client providing the query; comparing one or more accessed field nodes and the client with one or more security policies; determining one or more constrained field nodes in the hierarchical structure model based on the comparison, such that one or more security policies prevent the client from accessing information associated with one or more constrained field nodes; and excluding one or more values ​​of metadata that can be associated with one or more constrained field nodes from the response to the query, such that one or more of the identifiers or data types associated with one or more constrained field nodes can be included in the response to the query.

[0044] In one or more of the various implementations, one or more timeout values ​​or node access limit values ​​may be determined based on the query type or one or more of the query. In some implementations, in response to the timeout value being exceeded, traversal of the hierarchical model is terminated and a partial response, including one or more collected values ​​of metadata, is provided for the query. Alternatively, in response to the number of nodes accessed in the hierarchical model exceeding the node access limit value, traversal of the hierarchical model is terminated and a partial response, including one or more collected values ​​of metadata, is provided.

[0045] In one or more of the various implementations, the type of query can be determined based on information provided along with the query. In some implementations, one or more conditions for terminating traversal can be determined based on the type of query. In some implementations, response information to be included in the response to the query can be determined based on the type of query, such that the response information may include one or more of the following: one or more values ​​of metadata, one or more aggregated values ​​based on one or more values ​​of metadata, or the execution of one or more other actions defined by the type of query.

[0046] In one or more of the various implementations, in response to the anchor field being associated with a metadata value, the metadata value associated with the anchor field may be included in the response to the query. Furthermore, in some implementations, in response to the absence of a metadata value in the anchor field, the metadata value associated with the ancestor field node closest to the anchor field in the hierarchical structure model is provided in the response to the query.

[0047] Operating environment shown

[0048] Figure 1 The diagram illustrates components of one embodiment of an environment in which embodiments of the invention can be practiced. Not all components are essential for practicing the invention, and changes in the arrangement and type of components may be made without departing from the spirit or scope of the invention. As shown in the figure, Figure 1 System 100 includes a local area network (LAN) / wide area network (WAN) 110, a wireless network 108, client computers 102 to 105, a visualization server computer 116, etc.

[0049] The following is combined Figure 2 At least one embodiment of client computers 102 to 105 is described in more detail. In one embodiment, at least some of the client computers 102 to 105 can operate on one or more wired or wireless networks (such as network 108 or 110). Typically, client computers 102 to 105 can include virtually any computer capable of communicating over a network to send and receive information, perform various online activities, offline actions, etc. In one embodiment, one or more client computers 102 to 105 can be configured to operate within an enterprise or other entity to perform various services for the enterprise or other entity. For example, client computers 102 to 105 can be configured to operate as a web server, firewall, client application, media player, mobile phone, game console, desktop computer, etc. However, client computers 102 to 105 are not limited to these services, and in other embodiments, they can also be used, for example, for end-user computing. It should be recognized that more or fewer client computers (such as those described herein) can be included within a system such as those described herein. Figure 1 (as shown), and therefore the implementation is not limited by the number or type of client computers used.

[0050] Computers that can operate as client computers 102 may include computers typically connected via wired or wireless communication media, such as personal computers, multiprocessor systems, microprocessor-based or programmable electronic devices, network PCs, etc. In some embodiments, client computers 102 to 105 may include virtually any portable computer capable of connecting to another computer and receiving information, such as laptop computers 103, mobile computers 104, tablet computers 105, etc. However, portable computers are not limited to these and may also include other portable computers, such as cellular phones, display pagers, radio frequency (RF) devices, infrared (IR) devices, personal digital assistants (PDAs), handheld computers, wearable computers, integrated devices combining one or more of the aforementioned computers, etc. Therefore, client computers 102 to 105 are generally broad in terms of capabilities and features. Furthermore, client computers 102 to 105 can access various computing applications, including browsers or other web-based applications.

[0051] Web-enabled client computers may include browser applications configured to send requests and receive responses via the web. Browser applications can be configured to receive and display graphics, text, multimedia, etc., in virtually any web-based language. In one implementation, the browser application is enabled to display and send messages using JavaScript, Hypertext Markup Language (HTML), Extensible Markup Language (XML), JavaScript Object Notation (JSON), Cascading Style Sheets (CSS), and combinations thereof. In one implementation, a user of the client computer can use the browser application to perform various activities over the network (online). However, another application can also be used to perform various online activities.

[0052] Client computers 102 to 105 may also include at least one other client application configured to receive or send content with another computer. The client application may include the ability to send or receive content, etc. The client application may also provide information identifying itself, including type, capabilities, name, etc. In one embodiment, client computers 102 to 105 may uniquely identify themselves through any of a variety of mechanisms, including Internet Protocol (IP) addresses, telephone numbers, mobile identification numbers (MINs), electronic serial numbers (ESNs), client certificates, or other device identifiers. This information may be provided in one or more network packets, etc., and sent between other client computers, visualization server computer 116, or other computers.

[0053] Client computers 102 to 105 can be further configured to include client applications that enable end users to log in to end-user accounts that can be managed by another computer (such as visualization server computer 116). In a non-limiting example, such end-user accounts can be configured to enable end users to manage one or more online activities, including project management, software development, system administration, configuration management, search activities, social networking activities, browsing various websites, and communicating with other users. Furthermore, client computers can be arranged to allow users to display reports, interactive user interfaces, or results provided by visualization server computer 116.

[0054] Wireless network 108 is configured to connect client computers 103 to 105 and their components to network 110. Wireless network 108 may include any subnetwork from a variety of wireless subnetworks (which may also cover independent self-organizing networks, etc.) to provide infrastructure-oriented connectivity for client computers 103 to 105. Such subnetworks may include mesh networks, wireless LAN (WLAN) networks, cellular networks, etc. In one embodiment, the system may include more than one wireless network.

[0055] The wireless network 108 may also include autonomous systems such as terminals, gateways, and routers connected via radio links. These connectors can be configured to move freely and randomly and organize themselves arbitrarily, allowing the topology of the wireless network 108 to change rapidly.

[0056] Wireless network 108 can also employ a variety of access technologies, including 2G, 3G, 4G, and 5G radio access for cellular systems, WLANs, wireless router (WR) mesh networks, etc. Access technologies (such as 2G, 3G, 4G, 5G) and future access networks can achieve wide-area coverage for mobile computers (such as client computers 103 to 105) with varying degrees of mobility. In a non-limiting example, wireless network 108 can achieve radio connectivity via radio network access, such as for Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Downlink Packet Access (HSDPA), Long Term Evolution (LTE), etc. Essentially, wireless network 108 can include virtually any wireless communication mechanism through which information can travel between client computers 103 to 105 and another computer, network, cloud-based network, cloud instance, etc.

[0057] Network 110 is configured to connect network computers to other computers via wireless network 108, including visualization server computer 116, client computer 102, and client computers 103 to 105. Network 110 is enabled to use any form of computer-readable medium for transmitting information from one electronic device to another. Furthermore, in addition to local area networks (LANs), wide area networks (WANs), direct connections (such as via a universal serial bus (USB) port, an Ethernet port, other forms of computer-readable media, or any combination thereof), network 110 may also include the Internet. On the interconnection set of LANs (including those based on different architectures and protocols), routers act as links between LANs, enabling messages to be sent from one LAN to another. Additionally, communication links within a LAN typically include twisted-pair or coaxial cable, while communication links between networks may utilize analog telephone lines, including all or part of dedicated digital lines such as T1, T2, T3, and T4, or other carrier mechanisms including, for example, E-carrier, Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), wireless links including satellite links, or other communication links known to those skilled in the art. Furthermore, the communication link can employ any digital signaling technology from a variety of digital signaling technologies, including but not limited to DS-0, DS-1, DS-2, DS-3, DS-4, OC-3, OC-12, OC-48, etc. Additionally, remote computers and other related electronic devices can be remotely connected to the LAN or WAN via modems and temporary telephone links. In one implementation, network 110 can be configured to transmit Internet Protocol (IP) information.

[0058] Furthermore, communication media typically implement computer-readable instructions, data structures, program modules, or other transmission mechanisms, and include any medium for non-transitory or transient information delivery. By way of example, communication media include wired media such as twisted-pair cables, coaxial cables, optical fibers, waveguides, and other wired media, as well as wireless media such as acoustic, RF, infrared, and other wireless media.

[0059] In addition, the following combination Figure 3 A more detailed description of one implementation of the visualization server computer 116. Although Figure 1The visualization server computer 116 is shown as a single computer, but the innovation or implementation is not limited to this. For example, one or more functions of the visualization server computer 116, etc., may be distributed across one or more different network computers. Furthermore, in one or more implementations, the visualization server computer 116 may be implemented using multiple network computers. Additionally, in one or more of the various implementations, the visualization server computer 116, etc., may be implemented using one or more cloud instances in one or more cloud networks. Therefore, these innovations and implementations should not be construed as being limited to a single environment, and other configurations and architectures are also contemplated.

[0060] Exemplary client computer

[0061] Figure 2 An embodiment of a client computer 200 is shown, which may include a number of components, more or fewer than those shown. The client computer 200 may represent, for example... Figure 1 One or more embodiments of the mobile computer or client computer shown herein.

[0062] Client computer 200 may include processor 202 communicating with memory 204 via bus 228. Client computer 200 may also include power supply 230, network interface 232, audio interface 256, display 250, keypad 252, illuminator 254, video interface 242, input / output interface 238, haptic interface 264, GPS transceiver 258, air gesture interface 260, temperature interface 262, camera 240, projector 246, pointing device interface 266, processor-readable fixed storage device 234, and processor-readable removable storage device 236. Client computer 200 may optionally communicate with a base station (not shown) or directly with another computer. Furthermore, in one embodiment, although not shown, a gyroscope may be employed within client computer 200 to measure or maintain the orientation of client computer 200.

[0063] Power supply 230 can provide power to client computer 200. Power can be provided using rechargeable or non-rechargeable batteries. Power can also be provided by an external power source, such as an AC adapter or power docking station to replenish or charge batteries.

[0064] Network interface 232 includes circuitry for connecting client computer 200 to one or more networks and is configured to be used with one or more communication protocols and technologies, including but not limited to protocols and technologies that implement any part of any protocol for mobile communications (GSM), such as OSI model, CDMA, Time Division Multiple Access (TDMA), UDP, TCP / IP, SMS, MMS, GPRS, WAP, UWB, WiMax, SIP / RTP, GPRS, EDGE, WCDMA, LTE, UMTS, OFDM, CDMA2000, EV-DO, HSDPA, or various other wireless communication protocols. Network interface 232 is sometimes referred to as a transceiver, transceiver device, or network interface card (NIC).

[0065] Audio interface 256 can be configured to generate and receive audio signals, such as human speech. For example, audio interface 256 can be coupled to a speaker and microphone (not shown) to enable communication with others or to generate audio confirmation for a particular action. The microphone in audio interface 256 can also be used for input or control of client computer 200, for example, using voice recognition, sound-based touch detection, etc.

[0066] Display 250 may be a liquid crystal display (LCD), gas plasma, electronic ink, light-emitting diode (LED), organic LED (OLED), or any other type of light-reflecting or light-transmitting display that can be used with a computer. Display 250 may also include a touch interface 244 arranged to receive input from an object such as a stylus or a finger from a human hand, and may use resistive, capacitive, surface acoustic wave (SAW), infrared, radar, or other technologies to sense touch or gestures.

[0067] Projector 246 may be a remote handheld projector or an integrated projector capable of projecting images onto a remote wall or any other reflective object, such as a remote screen.

[0068] Video interface 242 can be configured to capture video images, such as still photos, video clips, infrared video, etc. For example, video interface 242 can be connected to a digital camera, web camera, etc. Video interface 242 may include lenses, image sensors, and other electronic components. The image sensor may include a complementary metal-oxide-semiconductor (CMOS) integrated circuit, a charge-connected device (CCD), or any other integrated circuit for sensing light.

[0069] Keypad 252 may include any input device arranged to receive input from a user. For example, keypad 252 may include a push-button numeric dial or a keyboard. Keypad 252 may also include command buttons associated with selecting and sending images.

[0070] The illuminator 254 can provide status indication or provide light. The illuminator 254 can remain active for a specific period of time or in response to an event message. For example, when the illuminator 254 is active, it can illuminate the buttons on the keypad 252 from behind and remain on when the client computer is powered. Furthermore, when performing specific actions, such as dialing another client computer, the illuminator 254 can illuminate these buttons from behind in various modes. The illuminator 254 can also cause a light source located within the transparent or translucent casing of the client computer to illuminate in response to the action.

[0071] In addition, the client computer 200 may also include a Hardware Security Module (HSM) 268, which provides additional tamper-proof protection for generating, storing, or using security / cryptographic information, such as keys, digital certificates, passwords, two-factor authentication information, etc. In some implementations, the hardware security module may be used to support one or more standard public key infrastructures (PKIs) and may be used to generate, manage, or store key pairs, etc. In some implementations, the HSM 268 may be a standalone computer; in other cases, the HSM 268 may be arranged as a hardware card that can be added to the client computer.

[0072] The client computer 200 may also include an input / output interface 238 for communicating with external peripheral devices or other computers, such as other client computers and network computers. Peripheral devices may include audio headsets, virtual reality headsets, display glasses, remote speaker systems, remote speaker and microphone systems, etc. The input / output interface 238 may utilize one or more technologies, such as Universal Serial Bus (USB), infrared, WiFi, WiMax, Bluetooth™, etc.

[0073] The input / output interface 238 may also include one or more sensors for determining geographic location information (e.g., GPS), monitoring power conditions (e.g., voltage sensors, current sensors, frequency sensors, etc.), monitoring weather (e.g., thermostats, barometers, anemometers, humidity detectors, precipitation meters, etc.). The sensors may be one or more hardware sensors that collect or measure data external to the client computer 200.

[0074] Haptic interface 264 can be configured to provide haptic feedback to a user of the client computer. For example, haptic interface 264 can be used to vibrate client computer 200 in a specific manner when another computer user is making a call. Temperature interface 262 can be used to provide a temperature measurement input or a temperature change output to a user of client computer 200. Air gesture interface 260 can sense the physical gestures of the user of client computer 200, for example, by using a single or stereo camera, radar, a gyroscope sensor within the computer held or worn by the user. Camera 240 can be used to track the physical eye movements of the user of client computer 200.

[0075] GPS transceiver 258 can determine the physical coordinates of client computer 200 on the Earth's surface, typically outputting the location as latitude and longitude values. GPS transceiver 258 can also employ other geolocation mechanisms to further determine the physical location of client computer 200 on the Earth's surface, including but not limited to triangulation, assisted GPS (AGPS), enhanced time difference of observation (E-OTD), cell identifier (CI), service area identifier (SAI), enhanced timing advance (ETA), base station subsystem (BSS), etc. It should be understood that GPS transceiver 258 can determine the physical location of client computer 200 under different conditions. However, in one or more embodiments, client computer 200 may provide other information that can be used to determine the physical location of the client computer through other components, including, for example, media access control (MAC) address, IP address, etc.

[0076] In at least one of the various implementation schemes, applications such as operating system 206, client display engine 222, other client applications 224, web browser 226, etc., may be arranged to use geolocation information to select one or more localization features, such as time zone, language, currency, calendar format, etc. Localization features can be used for documents, visualizations, display objects, display models, action objects, user interfaces, reports, and internal processes or databases. In at least one of the various implementation schemes, the geolocation information used to select localization information may be provided by GPS transceiver 258. Furthermore, in some implementation schemes, the geolocation information may include information provided using one or more geolocation protocols on a network (such as wireless network 108 or network 111).

[0077] The human-machine interface (HMI) component can be a peripheral device physically separate from the client computer 200, thereby allowing remote input or output to the client computer 200. For example, information routed here via an HMI component (such as display 250 or keyboard 252) can alternatively be routed via network interface 232 to a remotely located appropriate HMI component. Examples of remotely located HMI peripheral components include, but are not limited to, audio devices, pointing devices, keypads, displays, cameras, projectors, etc. These peripheral components can communicate via piconetworks such as Bluetooth™, Zigbee™, etc. A non-limiting example of a client computer with such a peripheral HMI component is a wearable computer, which may include a remote picoprojector and one or more cameras that communicate remotely with a separately located client computer to sense gestures of the user toward portions of an image projected by the picoprojector onto a reflective surface (such as a wall or the user's hand).

[0078] The client computer may include a web browser application 226 configured to receive and send web pages, web-based messages, graphics, text, multimedia, etc. The browser application on the client computer can use virtually any programming language, including Wireless Application Protocol (WAP) messages. In one or more implementations, the browser application is enabled to use Handheld Device Markup Language (HDML), Wireless Markup Language (WML), WMLScript, JavaScript, Standard Generalized Markup Language (SGML), Hypertext Markup Language (HTML), Extensible Markup Language (XML), HTML5, etc.

[0079] Memory 204 may include RAM, ROM, or other types of memory. Memory 204 illustrates an example of a computer-readable storage medium (device) for storing information such as computer-readable instructions, data structures, program modules, or other data. Memory 204 may store a BIOS 208 for controlling the low-level operations of client computer 200. Memory may also store an operating system 206 for controlling the operation of client computer 200. It should be understood that components may include a general-purpose operating system such as a version of UNIX or Linux™, or a dedicated client computer communication operating system such as Windows Phone™, Android™, or iOS. The operating system may include or interact with a Java Virtual Machine module, which enables control of hardware components or operating system operation via Java applications.

[0080] Memory 204 may also include one or more data stores 210, which may be used by client computer 200 to store application 220 or other data. For example, data store 210 may also be used to store information describing various capabilities of client computer 200. The information may then be provided to another device or computer based on any of a variety of methods, including sending it as part of a header during communication, sending it upon request, etc. Data store 210 may also be used to store social network information, including address books, friend lists, aliases, user profile information, etc. Data store 210 may also include program code, data, algorithms, etc., for a processor (such as processor 202) to implement and execute actions. In one embodiment, at least some of the data stores 210 may also be stored on another component of client computer 200, including but not limited to non-transitory processor-readable removable storage device 236, processor-readable fixed storage device 234, or even stored outside the client computer.

[0081] Application 220 may include computer-executable instructions that, when executed by client computer 200, transmit, receive, or otherwise process instructions and data. Application 220 may include, for example, a client display engine 222, other client applications 224, a web browser 226, etc. Client computers may be configured to exchange communications with visualization server computers, such as queries, searches, messages, notification messages, event messages, alerts, performance metrics, log data, API calls, etc., or combinations thereof.

[0082] Other examples of applications include calendars, search programs, email client applications, IM applications, SMS applications, Voice over Internet Protocol (VoIP) applications, contact managers, task managers, code converters, database programs, word processors, security applications, spreadsheet programs, games, search programs, and more.

[0083] Additionally, in one or more embodiments (not shown in the figures), the client computer 200 may include embedded logic hardware devices instead of a CPU, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable array logic (PALs), or combinations thereof. The embedded logic hardware devices can directly execute their embedded logic to perform actions. Furthermore, in one or more embodiments (not shown in the figures), the client computer 200 may include one or more hardware microcontrollers instead of a CPU. In one or more embodiments, the one or more microcontrollers can directly execute their own embedded logic to perform actions and access their own internal memory and their own external input and output interfaces (e.g., hardware pins or wireless transceivers) to perform actions, such as a system-on-a-chip (SoC).

[0084] Exemplary Network Computer

[0085] Figure 3 An embodiment of a network computer 300 is shown, which may be included in a system implementing one or more of the various embodiments. The network computer 300 may include, but is not limited to, a network computer 300. Figure 3 The diagram shows many components, with more or fewer. However, the components shown are sufficient to disclose exemplary embodiments for practicing these innovations. The network computer 300 can represent, for example... Figure 1 One implementation of one or more visualization server computers 116.

[0086] A network computer (such as network computer 300) may include a processor 302 that can communicate with memory 304 via bus 328. In some embodiments, processor 302 may include one or more hardware processors, or one or more processor cores. In some cases, one or more of the processors may be dedicated processors designed to perform one or more dedicated actions, such as those described herein. Network computer 300 also includes a power supply 330, a network interface 332, an audio interface 356, a display 350, a keyboard 352, an input / output interface 338, a processor-readable fixed storage device 334, and a processor-readable removable storage device 336. Power supply 330 provides power to network computer 300.

[0087] Network interface 332 includes circuitry for connecting network computer 300 to one or more networks and is configured to be used with one or more communication protocols and technologies, including but not limited to protocols and technologies that implement any part of any protocol from the Open Systems Interconnection (OSI) model, Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), User Datagram Protocol (UDP), Transmission Control Protocol / Internet Protocol (TCP / IP), Short Message Service (SMS), Multimedia Messaging Service (MMS), General Packet Radio Service (GPRS), WAP, Ultra Wideband (UWB), IEEE 802.16 Global Microwave Access Interoperability (WiMax), Session Initiation Protocol / Real-Time Transport Protocol (SIP / RTP), or various other wired and wireless communication protocols. Network interface 332 is sometimes referred to as a transceiver, transceiver device, or network interface card (NIC). Network computer 300 may optionally communicate with a base station (not shown) or directly with another computer.

[0088] Audio interface 356 is configured to generate and receive audio signals, such as human speech. For example, audio interface 356 may be coupled to a speaker and microphone (not shown) to enable communication with others or to generate audio confirmation for a particular action. The microphone in audio interface 356 may also be used for input or control of network computer 300, for example, using speech recognition.

[0089] Display 350 may be a liquid crystal display (LCD), gas plasma, electronic ink, light-emitting diode (LED), organic LED (OLED), or any other type of light-reflecting or light-transmitting display that can be used with a computer. In some embodiments, display 350 may be a handheld projector or micro projector capable of projecting images onto a wall or other object.

[0090] Network computer 300 may also include components for communication with... Figure 3 Input / output interface 338 for communication with external devices or computers (not shown). Input / output interface 338 may utilize one or more wired or wireless communication technologies, such as USB™, Firewire™, WiFi, WiMax, Thunderbolt™, infrared, Bluetooth™, Zigbee™, serial port, parallel port, etc.

[0091] In addition, the input / output interface 338 may also include one or more sensors for determining geographic location information (e.g., GPS), monitoring power conditions (e.g., voltage sensors, current sensors, frequency sensors, etc.), monitoring weather (e.g., thermostats, barometers, anemometers, humidity detectors, precipitation meters, etc.), etc. The sensors may be one or more hardware sensors that collect or measure data external to the network computer 300. The human-machine interface components may be physically separate from the network computer 300, thereby allowing remote input or output to the network computer 300. For example, information routed via a human-machine interface component (such as display 350 or keyboard 352) as described herein may alternatively be routed via network interface 332 to an appropriate human-machine interface component located elsewhere on the network. Human-machine interface components include any components that allow the computer to receive input from or send output to a human user of the computer. Therefore, pointing devices (such as mice, styluses, trackballs, etc.) can communicate via pointing device interface 358 to receive user input.

[0092] GPS transceiver 340 can determine the physical coordinates of network computer 300 on the Earth's surface, typically outputting the location as latitude and longitude values. GPS transceiver 340 can also employ other geolocation mechanisms to further determine the physical location of network computer 300 on the Earth's surface, including but not limited to triangulation, assisted GPS (AGPS), enhanced time difference of observation (E-OTD), cell identifier (CI), service area identifier (SAI), enhanced timing advance (ETA), base station subsystem (BSS), etc. It should be understood that GPS transceiver 340 can determine the physical location of network computer 300 under different conditions. However, in one or more embodiments, network computer 300 may provide additional information that can be used to determine the physical location of client computers through other components, including, for example, media access control (MAC) addresses, IP addresses, etc.

[0093] In at least one of the various implementation schemes, applications such as operating system 306, data management engine 322, display engine 324, inheritance engine 326, and web service 329 may be configured to use geolocation information to select one or more localization features, such as time zone, language, currency format, calendar format, etc. Localization features can be used in documents, file systems, user interfaces, reports, display objects, display models, visualizations, and internal processes or databases. In at least one of the various implementation schemes, the geolocation information used to select localization information may be provided by GPS 340. Furthermore, in some implementation schemes, the geolocation information may include information provided using one or more geolocation protocols on a network (such as wireless network 108 or network 111).

[0094] Memory 304 may include random access memory (RAM), read-only memory (ROM), or other types of memory. Memory 304 illustrates an example of a computer-readable storage medium (device) for storing information such as computer-readable instructions, data structures, program modules, or other data. Memory 304 stores a basic input / output system (BIOS) 308 for controlling the low-level operation of the network computer 300. Memory also stores an operating system 306 for controlling the operation of the network computer 300. It should be understood that components may include a general-purpose operating system such as a version of UNIX or Linux®, or a proprietary operating system such as Microsoft's Windows® operating system or Apple's OSX® operating system. The operating system may include or interact with one or more virtual machine modules, such as a Java Virtual Machine module, which enables control of hardware components or operating system operation via Java applications. Similarly, other runtime environments may be included.

[0095] Memory 304 may also include one or more data storage devices 310, which may be used by network computer 300 to store application 320 or other data. For example, data storage device 310 may also be used to store information describing various capabilities of network computer 300. The information may then be provided to another device or computer based on any of the various methods, including being sent as part of a header during communication, being sent upon request, etc. Data storage device 310 may also be used to store social network information, including address books, friend lists, aliases, user profile information, etc. Data storage device 310 may also include program code, data, algorithms, etc., for a processor (such as processor 302) to implement and execute actions, such as those described below. In one embodiment, at least some of the data storage devices 310 may also be stored on another component of network computer 300, including but not limited to non-transitory media within processor-readable removable storage device 336, processor-readable fixed storage device 334, or any other computer-readable storage device within network computer 300, or even stored outside network computer 300. Data storage device 310 may include, for example, data model 314, display model 316, source data 318, etc. Data model 314 can store files, documents, versions, properties, metadata, data structures, etc., representing one or more parts of one or more data models. Display model 316 can store display models. Source data 318 can represent storage for databases or other data sources that contribute data as the basis for data models, display models, etc.

[0096] Application 320 may include computer-implementable instructions that, when executed by network computer 300, transmit, receive, or otherwise process messages (e.g., SMS, Multimedia Messaging Service (MMS), Instant Messaging (IM), email, or other messages), audio, video, and enable communication with another user on another mobile computer. Other examples of applications include calendars, search programs, email client applications, IM applications, SMS applications, Voice over Internet Protocol (VoIP) applications, contact managers, task managers, code converters, database programs, word processing programs, security applications, spreadsheet programs, games, search programs, etc. Application 320 may include a data management engine 322, a display engine 324, a legacy engine 326, a web service 329, etc., which can be arranged to perform actions for the implementations described below. In one or more of the various implementations, one or more applications may be implemented as modules or components of another application. Furthermore, in one or more of the various implementations, applications may be implemented as operating system extensions, modules, plug-ins, etc.

[0097] Furthermore, in one or more of the various implementation schemes, the data management engine 322, display engine 324, inheritance engine 326, web service 329, etc., can operate in a cloud-based computing environment. In one or more of the various implementation schemes, these applications, including the management platform, and other applications can execute within virtual machines or virtual servers managed in the cloud-based computing environment. In one or more of the various implementation schemes, in this context, applications can migrate from one physical network computer within the cloud-based environment to another based on performance and scaling considerations automatically managed by the cloud computing environment. Similarly, in one or more of the various implementation schemes, virtual machines or virtual servers dedicated to the data management engine 322, display engine 324, web service 329, etc., can be automatically provisioned and decommissioned.

[0098] Furthermore, in one or more of the various implementation schemes, the data management engine 322, display engine 324, inheritance engine 326, web service 329, etc., may reside in a virtual server running in a cloud-based computing environment, rather than being bound to one or more specific physical network computers.

[0099] In addition, the network computer 300 may also include a Hardware Security Module (HSM) 360, which provides additional tamper-proof protection for generating, storing, or using security / cryptographic information such as keys, digital certificates, passwords, two-factor authentication information, etc. In some implementations, the hardware security module may be used to support one or more standard public key infrastructures (PKIs) and may be used to generate, manage, or store key pairs, etc. In some implementations, the HSM 360 may be a standalone network computer; in other cases, the HSM 360 may be arranged as a hardware card that can be installed within the network computer.

[0100] Additionally, in one or more embodiments (not shown in the figures), the network computer 300 may include embedded logic hardware devices instead of a CPU, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable array logic (PALs), or combinations thereof. The embedded logic hardware devices can directly execute their embedded logic to perform actions. Furthermore, in one or more embodiments (not shown in the figures), the network computer may include one or more hardware microcontrollers instead of a CPU. In one or more embodiments, the one or more microcontrollers can directly execute their own embedded logic to perform actions and access their own internal memory and their own external input and output interfaces (e.g., hardware pins or wireless transceivers) to perform actions, such as a system-on-a-chip (SoC).

[0101] Indicative logical system architecture

[0102] Figure 4 The logical architecture of a system 400 for metadata inheritance of data assets, according to one or more of various implementation schemes, is illustrated. In one or more of the various implementation schemes, system 400 may include various components, such as a data model 402, which may include a range of data objects ranging from one or more database objects to one or more visualizations. In the example, data model 402 includes database 404, database 406, table 408, table 410, table 412, workflow object 414, data source 416, data source 418, workbook object 420, form object 422, and form object 424.

[0103] In one or more of the various implementations, a visualization server computer (such as visualization server computer 116) may be arranged to employ a data model (such as data model 402) to represent information that can be used to generate visualizations. Furthermore, in some implementations, the data model may be used to manage other actors in the visualization system, including users, authors, etc.

[0104] In the example, data model 402 may have one or more root-level data objects, such as database 404 and database 406. Database 404 and database 406 represent databases that can be sources of information driving the data model. For example, database 404 may represent an SQL RDBMS associated with a part of an organization, while database 406 may represent an API gateway to another information provider or other databases.

[0105] In one or more of the various implementations, Tables 408, 410, 412, etc., represent tables or table-like objects that can be provided by one or more databases. At this level of the data model, a data object can be considered as wrapping an entity provided from a database or otherwise modeling it closely. Thus, in some implementations, the properties or attributes of a table or database object can closely reflect its native representation, including attribute names, data types, table names, column names, etc. For example, a data administrator may be able to "import" a database or table into the data model such that the imported object retains some or all of the features or attributes available in its native form. In some cases, in some implementations, one or more imported data objects may include metadata information that can also be imported.

[0106] In one or more of the various implementation schemes, the data administrator may have to perform or implement one or more actions to prepare the information for visualization or visualization authors to consume before the imported table objects can be used for visualization. In the example, Extract-Transform-Load (ETL) object 414 represents an ETL process that performs some processing on the information in tables 410 and 412 before it can be made available for visualization.

[0107] In one or more of the various implementations, a data source object (such as data source 416 or data source 418) represents a data object that a visualization author can use to incorporate into a visualization or other display model. In some implementations, the data source object may provide a data administrator with control over managing or otherwise shaping information from a database (e.g., database 404 or database 406) that can be used by the visualization or visualization author. For example, one or more tables in database 404 may include sensitive information that an organization wishes to exclude from the visualization. Therefore, in some implementations, by selecting mapping attributes from table objects to data source objects, a data administrator can control how data is presented from the underlying database. In some implementations, a data administrator may be enabled to select specific columns or attributes from a table object to include in the data source. Furthermore, in some implementations, attribute names (e.g., column names) in a table object may be mapped to different names in the data source. For example, a table column in a table object named "Customer_Identifier" may be mapped to an attribute in the data source named "Account". Additionally, in some implementations, other mapping transformations, such as data type conversion, aggregation, filtering, combination, etc., may be performed. In some implementations, extensive or complex transformations can be encapsulated in ETL objects, while simpler or more common transformations can be enabled without using separate ETL objects.

[0108] In one or more of the various implementations, edge 448 represents a mapping from a table object to a data source. In the example, edge 448 may represent mapping one or more attributes (e.g., columns) of table 408 to one or more data structures of data source 416. Thus, in some implementations, edge 448 provides or is associated with one or more mapping rules or instructions that define which information from table 408 is available in data source 416 and how the information from table 408 can be presented to visualization authors.

[0109] In one or more of the various implementations, workbook object 420 represents a data object that can be associated with one or more user-level data objects, such as form object 422 or form object 424. In some implementations, the visualization author may be enabled to design a workbook (such as workbook object 420) based on information provided by one or more data sources, such as data source 416 or data source 418. In some implementations, the visualization author may design a workbook that includes one or more forms (e.g., form object 422 or form object 424). In some implementations, the form object may include one or more visualizations, etc.

[0110] In one or more of the various implementation schemes, form object 422 or form object 424 may represent some or all of the information that can be provided to a visualization engine, etc., to provide one or more interactive visualization applications or reports that can be adopted by a user. In the examples, form object 422 or form object 424 may be considered to include or reference one or more of the following: data, metadata, data structures, etc., that can be used to render one or more visualizations of information that can be provided by one or more databases. In some implementation schemes, forms may be arranged to include one or more display models, style information, text descriptions, narrative information, styled graphics, links to other forms, etc.

[0111] Therefore, in some implementations, users (such as user 426 or user 428) may be made able to access forms. The content or visualizations in a form may depend on its design and the information it is based on (e.g., information from database 404 or database 406). Typically, a form or its included visualizations may depend on one or more attributes, columns, etc., from one or more databases. Similarly, in some implementations, dependencies that can be associated with a database can propagate through other data objects (such as tables, data sources, workbooks, etc.). In some cases, other data objects interposed between the form and its underlying database can introduce additional dependencies that can propagate to the form or visualization.

[0112] In one or more of the various implementations, it can be advantageous to propagate relevant or eligible metadata that can be associated with a data object to one or more dependent data objects. However, in some cases, intermediate data objects or data transformations may render the metadata associated with an ancestor object meaningless or obscure relative to one or more descendant / dependent data objects or data object attributes. Therefore, in some implementations, the inheritance engine may be configured to employ various strategies (in the form of query types) to determine whether metadata is eligible to be propagated to dependent objects.

[0113] Figure 5 This illustration shows a logical representation of a portion of a system 500 for metadata inheritance of data assets, according to one or more implementations of various schemes. In the example, for some implementations, data model 502 may be considered similar to data model 402 described above. However, the example illustrates how portions of data objects in the data model can be related or dependent.

[0114] In the example, data object 506 represents a data object that can be associated with metadata information. Therefore, in this example, some or all of the metadata associated with data object 506 may qualify to propagate to various dependent data objects, such as data object 508, data object 510, data object 512, data object 514, etc. Furthermore, in this example, user 516 or user 518 may be a user who depends on or owns data object 512 or data object 514.

[0115] Figure 6 A logical schematic diagram of a portion of system 600, illustrating dependencies in a data model, is shown according to one or more embodiments of various implementations. In the example, system 600 includes data object 602, data object 604, data object 606, data object 608, etc.

[0116] As described above, in one or more of the various implementation schemes, data objects in the data model may depend on other data objects in the same data model. In the example, data objects 604, 606, and 608 depend on data object 602. Therefore, in the example, data object 608 depends on data object 606, and so on. It should be noted that although all data objects in the example are part of the same dependency tree with data object 602 as its root, other data objects with different or separate dependencies may exist in the same data model.

[0117] In one or more of the various implementation schemes, data objects in the data model may depend on one or more other data objects because they depend on one or more attributes of those other data objects. Figure 6In this example, lines connecting columns in one data object to columns in another data object represent dependencies between data objects at the attribute level. Therefore, in the example, data object 602 has five columns, which can be considered five attributes. In the example, the line connecting data object 602 to data object 604 indicates that data object 604 depends on four attributes of data object 602. Similarly, in the example, data object 606 directly depends on three attributes of data object 604 and indirectly depends on three attributes of data object 602. Furthermore, similarly, in the example, data object 608 directly depends on one attribute from data object 606 and indirectly depends on one attribute from data objects 606, 604, and 602. Therefore, in the example, all data objects depend on one or more attributes from their parent objects; however, dependencies between data objects can be based on fewer than all attributes. For example, line 618 indicates that data object 608 depends on one attribute of data object 606.

[0118] In some implementations, dependencies between attributes or data objects can typically depend on one or more functions, filters, transformations, etc., that can be applied to attribute values ​​as they are passed down to descendant data objects. For example, a table data object might include a timestamp attribute stored as a Unix epoch timestamp. However, in this example, the dependent data source could have an attribute tagged as a date that expects a traditional date representation rather than a Unix epoch timestamp. Therefore, in this example, the date attribute of the dependent data source could be associated with a transformation action that converts a Unix epoch timestamp value provided by the parent table into a traditional date value that meets the data source's requirements.

[0119] Figure 7 A logical schematic diagram of a portion of a dependency hierarchy 700 according to one or more implementations of various schemes is shown, illustrating at least a portion of the logical nodes in the dependency hierarchy. As described above, the dependencies of data objects in a data model can be represented as a dependency hierarchy based on the attributes of the involved data objects that contribute to the dependency relationship. Therefore, the attributes of data objects represented in the dependency hierarchy can be called fields to distinguish them from general attributes. In some implementations, the dependency hierarchy may include one or more nodes, such as field nodes, flow nodes, compute nodes, etc.

[0120] In one or more of the various implementations, a field node (e.g., a field) may represent the value of an attribute of a data object. For example, in some implementations, a field corresponding to an attribute (such as a column from a table in the source / originating database) may provide the original value of the field. A dependency field node may be considered to hold values ​​that can propagate from one or more nodes higher in the dependency hierarchy.

[0121] Furthermore, in some implementations, one or more nodes in the dependency hierarchy can represent computations that can be applied to a field value before it can be propagated to descendant fields (e.g., computed nodes). In some cases, for some implementations, computed nodes can generate values ​​from one or more field values ​​that may have new or different semantic meanings than the input fields. For example, in some implementations, a computed node configured to compute the difference between two other field values ​​to produce a new value for another field can be considered a computed node. Therefore, in some implementations, computed nodes can be configured by the user or visualization author to perform arbitrary operations on values ​​from one or more input fields to generate values ​​that can be propagated to other fields.

[0122] Furthermore, in some implementations, a stream node can represent a transformation operation that can be applied to a field value before the field value can be propagated to other fields. In one or more of the various implementations, a stream node can be used to declare a transformation operation that can be performed on a field value without changing the semantic meaning of the field value. For example, a stream node corresponding to an operation (such as text formatting, date formatting, truncation / rounding of numbers, etc.) can be considered a stream node. Additionally, although not shown here, a stream node can be configured to receive input values ​​from more than one field node.

[0123] In the example, for some implementations, the dependency hierarchy 700 includes field nodes 702, 704, 706, 708, 710, 712, 714, 716, 718, and 720. Furthermore, in the example, the dependency hierarchy 700 includes compute node 714 and stream node 720.

[0124] Therefore, in some embodiments, the tracing engine can be arranged to propagate the value of field node 702 to field nodes 706, 708, 710, and 712 without modifying the value. In contrast, in this example, the tracing engine can be arranged to provide values ​​from field nodes 702 and 704 as input to computation node 714. Therefore, in this example, for some embodiments, computation node 714 can propagate new or modified values ​​to field node 716. In some embodiments, a particular operation performed by computation node 714 can be considered a valid operation or transformation that may deviate from the semantic meaning of field node 704 or field node 702. Furthermore, in this example, the value of field node 716 can be propagated to field node 718. Additionally, in this example, for some embodiments, the value from field node 704 can be provided to stream node 720. Therefore, in some embodiments, stream node 720 can be configured to perform one or more transformations on the value from field node 704. As described above, the transformations performed by the stream node can be considered to preserve the semantic meaning of the value of field node 704. Finally, in the example, the value generated by stream node 720 can be propagated to field node 722.

[0125] In one or more of the various implementation schemes, the data management engine or inheritance engine can be configured to automatically enforce rules or configurations defined in the data model or dependency model. Therefore, in some implementations, users or other clients can employ one or more fields in a data object or visualization.

[0126] It should be noted that those skilled in the art will understand that a production dependency hierarchy may include many more field nodes, compute nodes, flow nodes, etc., than are shown herein. However, those skilled in the art will understand that the dependency hierarchy 700 is sufficient to disclose at least the innovations included herein.

[0127] In addition, in some cases, for the sake of brevity or clarity, field nodes, compute nodes, stream nodes, etc., may be referred to as fields, computes, or streams in the context of a hierarchical structure.

[0128] Furthermore, in some implementations, the dependency hierarchy can be an inherent part of the data model. For example, in some implementations, the inheritance engine can be configured to generate a data model that includes dependency hierarchy information, rather than generating separate data structures for the data model and the dependency hierarchy. However, for the sake of brevity or clarity, the dependency hierarchy can be described herein as separate from its corresponding data model.

[0129] Figure 8A logical diagram of a data object including metadata information is shown according to one or more embodiments of various implementations. As described herein, in some embodiments, the data model may be configured to include or represent various data objects. In some embodiments, one or more data objects may be based on one or more original data sources, such as databases, spreadsheets, documents, archives, etc. Furthermore, in some embodiments, data objects may include one or more composite objects, which include data objects or data attributes from other data objects. For example, in some embodiments, data sources, workbooks, work forms, etc., may be data objects that may include one or more attributes from other data objects. As mentioned above, data objects or data object attributes may be associated with metadata. For example, a database may be configured to provide database objects, such as tables with one or more columns, where each table is named and each column is named. Thus, in the example, table names and column names can typically be used as data object names and data object attribute names in the data model. However, in some cases, for some implementations, database objects may be associated with metadata that can provide insights into the meaning, context, or purpose of the database object rather than representing the values ​​of data object attributes.

[0130] In the examples, for some implementations, data object attribute 800 can be considered to represent one or more data structures, which can be arranged to represent data object attributes in a data model. In the examples, data object attribute 800 can include one or more inherent features represented herein by feature 802. In the examples, for some implementations, the feature representing attribute 800 can represent various characteristics that are necessary or preferred for the attribute, such as identity / label, value, data type, etc. Those skilled in the art will understand that attributes can include more or fewer inherent features, depending on the kind of data object or the type of attribute. However, those skilled in the art will understand that feature 802 is intended to logically represent information that may be necessary to represent the value of a data object attribute. In the examples, labels, values, and types represent inherent characteristics of the data object. Therefore, labels, values, and types can be considered as necessary features that enable the attribute to be used in visualizations, reports, user interfaces, etc.

[0131] In contrast, in the example, metadata 804 represents metadata associated with data object attribute 800. In the example, descriptive metadata is presented as providing a more detailed description of the purpose of data object attribute 800. Furthermore, in the example, metadata annotations include a description of the application / pattern version introduced into the data object attribute. Clearly, in the example, feature 802 enables display engines, etc., to efficiently display the values ​​associated with the data object attribute. However, metadata 804 allows users or visualization authors to gain a better understanding of the context, purpose, or meaning of the purpose of the data object attribute. Therefore, in the example, the display engine can enable users or visualization authors to view metadata information to aid in the design of visualizations, reports, user interfaces, etc., that may include data object attribute 800.

[0132] In some implementations, metadata may include one or more of the following: tags, data quality warnings, personally identifiable information (PII) detection (e.g., fields containing sensitive information), data freshness, hierarchical structure hints / information (e.g., distances between various field nodes and computation nodes), proof / verification information (e.g., is the field trustworthy?), etc.

[0133] Furthermore, those skilled in the art will understand that data objects or data object attributes can support various types of metadata depending on the data type, data source, etc. Therefore, in some implementations, the inheritance engine can be configured to process or identify different types of metadata using rules, instructions, libraries, etc., provided via configuration information. Thus, in some implementations, since new metadata types can be introduced for various data objects or data object attributes, the inheritance engine can use configuration information to account for new metadata types or other local requirements or local conditions.

[0134] General Operations

[0135] Figures 9 to 13 This refers to a generalized operation for metadata inheritance of data assets, based on one or more of the various implementation schemes. In one or more of the various implementation schemes, combined with... Figures 9 to 13 The described processes 900, 1000, 1100, 1200, and 1300 can be performed by a single networked computer (such as...) Figure 3 The processes or portions thereof may be implemented or executed by one or more processors on a network computer (300). In other embodiments, these processes or portions thereof may be implemented or executed by multiple network computers (such as...). Figure 3The network computer 300 is used to implement or execute these processes. In other embodiments, these processes, or portions thereof, may be implemented or executed by one or more virtualized computers (such as those in a cloud-based environment). However, the implementation is not limited to this and various combinations of network computers, client computers, etc., can be utilized. Furthermore, in one or more of the various implementations, the combination of... Figures 9 to 13 The described process can be used to implement various schemes or architectures (such as combining) Figures 4 to 8 The metadata of data assets in at least one of the described implementation schemes or architectures is inherited. Furthermore, in one or more of the various implementation schemes, some or all of the actions performed by processes 900, 1000, 1100, 1200, and 1300 may be partially performed by a data management engine 322, a display engine 324, or a legacy engine 326 running on one or more processors of one or more network computers.

[0136] Figure 9 A flowchart outlining a process 900 for metadata inheritance of data assets, according to one or more of various implementation schemes, is shown. Following the start box, at start box 902, in one or more of the various implementation schemes, a data model can be provided to the inheritance engine. As described above, the data management engine, display engine, etc., can be arranged to generate a data model that can be used by visualization authors or data administrators to create data objects that can be associated with various data model layers or data object types in the data model.

[0137] At decision box 904, in one or more of the various implementations, if a metadata query can be provided to the inheritance engine, control may flow to box 906; otherwise, control may loop back to decision box 904. In one or more of the various implementations, the inheritance engine may be arranged to integrate with various clients or client applications that can provide metadata queries. For example, if a client application (such as a visualization authoring system) attempts to display metadata of data objects to a visualization author, the client application may provide a metadata query to the inheritance engine to provide eligible metadata (if any).

[0138] Furthermore, in some implementations, the metadata query information can vary depending on the type of query. Additionally, in some implementations, the inheritance engine can be configured to support metadata queries, which can be provided using various well-known or custom query languages, such as SQL, GraphQL, JSON, XML, Javascript, regular expressions, or combinations thereof.

[0139] At box 906, in one or more of the various implementations, the tracing engine can be configured to determine the dependency hierarchy based on the data model. In one or more of the various implementations, the tracing engine can be configured to generate the dependency hierarchy of the data model on demand or in advance. For example, in some implementations, if the tracing engine can be activated or associated with the data model, it can be configured to automatically generate the dependency hierarchy corresponding to the data model. In some implementations, the dependency hierarchy may inherently be part of the data model. However, for the sake of brevity or clarity, the dependency hierarchy is described separately from its corresponding data model herein.

[0140] At box 908, in one or more of the various implementations, the traversal engine may be configured to traverse the dependency hierarchy based on a query. In one or more of the various implementations, the metadata query information may include information identifying one or more fields or portions of the dependency hierarchy that can be associated with the metadata query. For example, if the metadata query requests metadata for a field, the metadata query will identify that field as the anchor field for the metadata query.

[0141] At box 910, in one or more of the various implementations, the inheritance engine may be configured to determine metadata information based on traversal of the dependency hierarchy. In one or more of the various implementations, the metadata query type and the query itself may inform the inheritance engine how to determine the eligible metadata to answer the query. In some implementations, determining eligible metadata information (e.g., inheritable metadata) may include traversing or otherwise evaluating nodes in the dependency hierarchy. For brevity or clarity, the action associated with evaluating relationships or nodes represented by the dependency hierarchy may be referred to as traversing the dependency hierarchy.

[0142] At box 912, in one or more of the various implementations, the inheritance engine can be configured to provide metadata information in the query results. In one or more of the various implementations, different metadata queries or metadata query types can produce different types of results. Some metadata query types can provide metadata information based on the first qualified (e.g., query-qualified) metadata determined from the dependency hierarchy. In contrast, in some implementations, other metadata queries or metadata query types can provide metadata for more than one field. For example, queries on linked metadata can be provided.

[0143] Next, in one or more of the various implementation schemes, control can be returned to the calling procedure.

[0144] Figure 10A flowchart of a metadata inheritance process 1000 for data assets, according to one or more embodiments of various implementations, is shown. Following the start box, at start box 1002, in one or more embodiments of various implementations, a metadata query can be provided to the inheritance engine. In one or more embodiments of various implementations, the inheritance engine can be configured to provide one or more APIs that enable client applications to provide one or more metadata queries. In one or more embodiments of various implementations, the metadata query information can be provided as one or more parameters via one or more APIs. In some embodiments, the metadata query information can be provided as a JSON object that the inheritance engine can parse to determine the metadata query information.

[0145] In one or more of the various implementation schemes, one or more APIs may enable clients to declare query types, one or more anchor fields in a dependency hierarchy, etc. In some implementations, the inheritance engine may be configured to provide APIs that allow clients to provide additional parameters, such as filters, security / authorization credentials, etc.

[0146] At box 1004, in one or more of the various embodiments, the inheritance engine may be configured to parse metadata queries to determine the type of metadata query. In one or more of the various embodiments, the inheritance engine may be configured to support one or more metadata query types. Thus, in some embodiments, the metadata query information may include direct indicators (e.g., labels), hints, etc., that enable the inheritance engine to determine the query type.

[0147] In one or more of the various implementation schemes, the inheritance engine can be configured to identify different query types using instructions, rules, libraries, etc., provided via configuration information. Therefore, in some implementations, the inheritance engine can be configured to support the addition of new or different query types, such as those provided via configuration information.

[0148] At box 1006, in one or more of the various implementations, the inheritance engine may be configured to parse metadata queries to determine one or more anchor fields in the dependency hierarchy.

[0149] In one or more of the various implementations, the anchor field can be a field that a metadata query in a dependency hierarchy can involve. In one or more of the various implementations, the inheritance engine can be configured to initiate a search for the requested metadata at the anchor field. In some implementations, the inheritance engine can be configured to support metadata queries with one or more anchor fields. Therefore, in one or more of the various implementations, queries including more than one anchor field can execute a query on each anchor field included in the query.

[0150] In some implementations, the anchor field identifier can be passed to the inheritance engine via a query API that may be different from the query itself.

[0151] At box 1008, in one or more of the various implementation schemes, the traversal engine can be configured to traverse the dependency hierarchy based on the query type. As described above, the traversal engine can be configured to generate the dependency hierarchy based on the relationships between data objects in the data model.

[0152] In one or more of the various implementations, the inheritance engine can be configured to answer metadata queries for one or more anchor fields. Therefore, in some implementations, the inheritance engine can be configured to traverse the dependency hierarchy to identify inheritable metadata values. It should be noted that in some implementations, the anchor field may have its own version of the requested metadata. Therefore, in some cases, depending on the query type, the inheritance engine may omit traversing the dependency hierarchy because the requested metadata value may be associated with the anchor field. Conversely, if the anchor field is not associated with the requested metadata, the inheritance engine may traverse the dependency hierarchy to determine if there is an inheritable metadata value that can answer the query.

[0153] In one or more of the various implementation schemes, the tracing engine may be configured to perform one or more actions based on the query type. In one or more of the various implementation schemes, the tracing engine may be configured to determine one or more actions based on rules, instructions, libraries, etc., provided by configuration information to take into account local requirements or local circumstances.

[0154] For example, in some implementations, certain query types can be configured to provide a response that can be limited to a first metadata value that answers a question. Furthermore, in some implementations, other query types can involve more information, such as a report identifying each field in the dependency hierarchy that can be associated with an inheritable metadata value. For example, in some implementations, a query of type "first" can return the first valid value of the metadata as determined by traversing the dependency hierarchy. Similarly, in some implementations, a query of type "linked" can return the requested metadata value for the entire portion of the dependency hierarchy accessed during traversal.

[0155] At box 1010, in one or more of the various implementations, the inheritance engine can be configured to determine metadata information based on traversal of the dependency hierarchy and query type. As briefly described above, the type of information can vary depending on the query type and query information. Some queries may return metadata values ​​for a single field, while other metadata queries may return metadata values ​​for one or more fields. Similarly, in some implementations, some queries may return aggregate values, counts, true / false (e.g., exist), etc. Furthermore, in some implementations, the inheritance engine may be configured to report null values ​​or errors if the requested query cannot be resolved. In some cases, the inheritance engine may fail to obtain metadata values ​​for a field because the inheritance rules associated with the query may not provide a valid answer. For example, in some implementations, if a field depends on two fields, the inheritance engine may be prevented from automatically determining how to propagate metadata. Therefore, in the example, null values ​​may be reported. However, in the example, some query types may provide every alternative result instead of failing to provide one.

[0156] Furthermore, in some implementations, one or more data objects or corresponding fields in a dependency hierarchy may be associated with one or more permission or privilege designations. Therefore, in some implementations, the inheritance engine may be configured to verify that the user or client submitting the metadata query is authorized to view or access fields associated with the metadata or inheritable metadata. In some implementations, the inheritance engine may be configured to apply one or more information security policies based on the metadata query associated with the query results, the metadata query type, the data model / object, etc. In some implementations, the inheritance engine may be configured to use rules, instructions, etc., provided by configuration information to determine permission assessments or user authorizations related to the metadata query results.

[0157] Next, in one or more of the various implementation schemes, control can be returned to the calling procedure.

[0158] Figure 11A flowchart of a process 1100 for metadata inheritance for data assets, according to one or more embodiments of various implementations, is shown. Following the start box, at start box 1102, in one or more embodiments of various implementations, a metadata query for a first metadata value can be provided to the inheritance engine. As described above, in some embodiments, the inheritance engine can be configured to support various query types. In one or more embodiments of various implementations, the available / authorized query types, as well as the rules, instructions, syntax, etc., used to declare queries for a particular query type, can vary depending on the query type. For example, in some embodiments, the inheritance engine can be configured to enable client applications to provide a name or symbol indicating the query type. In other embodiments, the inheritance engine can be configured to infer the query type from query information. For example, if the metadata query can be provided using SQL or GraphQL, the inheritance engine can be configured to parse the SQL or GraphQL to determine the query type.

[0159] Therefore, in some implementations, the inheritance engine can be configured to determine whether a metadata query is a request for the inheritance engine to determine the first metadata value of one or more anchor fields. For example, in some implementations, the query information may include a value indicating that the client is requesting the first eligible metadata value (if any) for an anchor field, such as "first". In the example, the "first" query type can be configured to return the first eligible / valid value of the specified metadata. For example, if the query is a request for the value of the metadata "description" of an anchor field, the inheritance engine can execute a query to find the first value of the "description" of the anchor object based on the dependency hierarchy. Thus, if the anchor field has descriptive metadata associated with the anchor field, the descriptive information can satisfy the query. In contrast, if the anchor field does not have descriptive metadata, the inheritance engine can be configured to traverse the dependency hierarchy to determine whether there is inheritable metadata associated with other fields that can satisfy the query.

[0160] At box 1104, in one or more of the various implementations, the tracing engine can be configured to determine anchor fields based on the query. In one or more of the various implementations, the anchor field can be considered the main subject of the query. Therefore, in some implementations, the query information can explicitly qualify the anchor fields. In some implementations, if multiple anchor fields can be included in the query information of the "first" query type, the tracing engine can be configured to find the first eligible metadata value for each anchor field.

[0161] At box 1106, in one or more of the various implementations, the traversal engine may be configured to access each next higher node in the dependency hierarchy. In one or more of the various implementations, the traversal engine may be configured to traverse the dependency hierarchy upwards starting from the anchor field. In one or more of the various implementations, the traversal engine may be configured to continue traversing until the query has reached a result or an error has occurred.

[0162] In some implementations, the traversal engine can begin traversing the dependency hierarchy at one or more anchor fields declared in the metadata query.

[0163] At decision box 1108, in one or more of the various implementations, if the accessed node is a computation node, control may flow to box 1120; otherwise, control may flow to decision box 1110. As described above, in some cases, for some implementations, field nodes in the dependency hierarchy may depend on one or more computation nodes. As described above, a computation node may represent one or more operations (e.g., computations) that can be performed on one or more other field values ​​to produce new or modified values.

[0164] In some cases, actions performed on a compute node can produce values ​​with semantic meanings that may differ from the semantic meanings of the source / input fields. Therefore, in some implementations, the meaning or context of metadata associated with fields fed to a compute node may be irrelevant to the values ​​produced by the compute node. Consequently, in some implementations, propagating such metadata to lower fields / nodes in the dependency hierarchy can be disadvantageous, as the semantic meaning of the metadata may no longer be consistent with the field values.

[0165] Therefore, in some implementations, if a compute node is encountered during traversal of the dependency hierarchy before other eligible metadata can be discovered, a query for the first metadata value may not need to be answered.

[0166] At decision box 1110, in one or more of the various implementations, if the accessed node is a flow node, control may flow to decision box 1112; otherwise, control may flow to box 1120. As mentioned above, for some implementations, a flow node can resemble a computed node because it can represent a transformation of a field value that can be performed so that the value can be passed down to descendant fields. However, in contrast to computed nodes, it can be assumed that the transformation associated with a flow node preserves the semantic meaning of the transformed field. Therefore, in some implementations, accessing a flow node during traversal of the dependency hierarchy may not terminate the query as it would with a computed node.

[0167] At decision box 1112, in one or more of the various implementations, if the accessed stream node can have one input, control can flow to decision box 1114; otherwise, control can flow to box 1120. As mentioned above, in some implementations, a stream node can be configured to have more than one input node. In some implementations, if a stream node has more than one input node, the traversal engine can be prevented from determining which metadata is propagated down to the anchor field because the traversal engine cannot select from one or more fields. Therefore, in some implementations, accessing a stream node with more than one input node can terminate the traversal and execution of the query.

[0168] At decision box 1114, in one or more of the various implementations, if the accessed node has metadata information that matches the query, control can flow to box 1118; otherwise, control can flow to decision box 1116. For example, if the query requests the first "description" metadata of the anchor field, the query can be satisfied if the accessed field node has a "description" value. In contrast, for some implementations, if the accessed field does not have a value of the requested metadata, the dependency hierarchy can continue to be traversed upwards.

[0169] At decision box 1116, in one or more of the various implementations, if traversal of the dependency hierarchy can continue, control can loop back to box 1106; otherwise, control can flow to box 1120. In one or more of the various implementations, the traversal engine can be configured to continue traversing upwards through the dependency hierarchy until all ancestor nodes of the anchor field are accessible, unless the query terminates otherwise due to encountering qualified metadata, computed nodes, or multi-input stream nodes. Note that the traversal termination condition can vary depending on the metadata query or the metadata query type.

[0170] Furthermore, in some implementations, the traversal engine can be configured to employ various security / performance metrics to constrain the amount of time or resources consumed in executing a query. Therefore, in some implementations, the traversal engine can be configured to terminate a query if it takes too long. Thus, in some implementations, the traversal engine can be configured to determine a timeout value from configuration information or the query itself. Additionally, in some implementations, the traversal engine can be configured to limit the query by constraining the total number of nodes that can be accessed in the dependency hierarchy during the query. For example, in some implementations, the traversal engine can be configured to limit traversal of the dependency hierarchy by constraining the number of accessible nodes to 20,000 nodes, etc. It should be noted that in some implementations, the traversal engine can be configured to determine timeout values ​​or traversal / node count constraints based on configuration information to consider local requirements or local conditions. Furthermore, in some implementations, different types of queries can have different timeout or node access limits.

[0171] At box 1118, in one or more of the various implementations, the tracing engine can be arranged to determine the metadata information of the accessed node. In one or more of the various implementations, the metadata requested by the query can be determined from a first accessed field node that can be associated with the requested metadata information. In some implementations, this can be an anchor field if it has the requested metadata information. Otherwise, in some implementations, the metadata information can be determined from a field node in the dependency hierarchy that can be an ancestor of the anchor field. Note that for the “first” query type described herein, the metadata value can be obtained from a first field node that has a value for the metadata requested by the query.

[0172] At box 1120, in one or more of the various embodiments, the tracing engine may be configured to return query results. In one or more of the various embodiments, if the value of the requested metadata can be determined, the tracing engine may be configured to return result information including the value of the requested metadata. Otherwise, in some embodiments, a result indicating that the requested metadata could not be determined may be provided. In some embodiments, the result information may indicate why the value of the requested metadata was not determined. Thus, in some embodiments, the result information may indicate whether a compute node or a multi-input stream node was encountered. Furthermore, in some embodiments, the result information may indicate that none of the field nodes in the dependency hierarchy include the requested metadata.

[0173] Furthermore, as mentioned above and described in more detail below, the inheritance engine can be configured to modify metadata query results based on information security considerations such as field / data access constraints, user roles, client types, client sources, etc.

[0174] In one or more of the various implementations, the tracing engine can be configured to provide result information to the client providing the query synchronously or asynchronously. In some implementations, the result information may be returned as API parameters or return values. In some implementations, the result information may include one or more individual parameters from various data structures consistent with the API used. For example, in some cases, the result information may be provided as one or more JSON objects, XML files, HTTP responses, etc. In some implementations, the tracing engine can be configured to support more than one protocol or format for returning query result information to the client providing the query information.

[0175] Next, in one or more of the various implementation schemes, control can be returned to the calling procedure.

[0176] Figure 12 A flowchart of a metadata inheritance process 1200 for data assets, according to one or more of various implementations, is shown. Following the start box, at start box 1202, in one or more of the various implementations, a metadata query for the linked metadata information can be provided to the inheritance engine. In the example, the metadata query request anchor field for the linked metadata information can depend on metadata information of some or all of the ancestors. Otherwise, the query information provided for the linked metadata query can be considered similar to that described for box 1102.

[0177] Furthermore, in one or more of the various implementations, a query against the linked metadata can be considered a query type. Therefore, in some implementations, determining the eligible metadata or other results associated with a query can differ from other query types.

[0178] At box 1204, in one or more of the various implementations, the inheritance engine may be configured to determine the anchor field based on the query. See the description for box 1104.

[0179] At box 1206, in one or more of the various implementations, the tracing engine may be configured to access the next higher node in the dependency hierarchy. See the description for box 1106.

[0180] At decision box 1208, in one or more of the various implementation schemes, if the accessed node can be a computing node, control can flow to decision box 1218; otherwise, control can flow to decision box 1210. (This is in accordance with...) Figure 11For a similar reason as described in the "first" query type, encountering a compute node can terminate the upward traversal of the dependency hierarchy. However, in some implementations, linked metadata queries can traverse multiple branches in the dependency hierarchy. Therefore, in some cases, for some implementations, encountering a compute node while executing a linked metadata query may not terminate the query execution, as described above for the "first" metadata query.

[0181] At decision box 1210, in one or more of the various implementations, if the accessed node is a flow node, control can flow to decision box 1212; otherwise, control can flow to decision box 1214. Encountering a flow node during upward traversal of the dependency hierarchy can be considered as related to... Figure 11 The “first” query type shown is similar to the description.

[0182] At decision box 1212, in one or more of the various implementations, if the accessed flow node can have an input, control can flow to decision box 1114; otherwise, control can flow to decision box 1218. (This is in accordance with...) Figure 11 For similar reasons described in the "first" query type shown, the traversal engine can be configured to terminate upward traversal of the dependency hierarchy if multiple input stream nodes are encountered during traversal. However, in some implementations, linked metadata queries can traverse multiple branches in the dependency hierarchy. Therefore, in some cases, for some implementations, encountering multiple input stream nodes while executing a linked metadata query may not terminate the query execution, as described above for the "first" metadata query.

[0183] At decision box 1214, in one or more of the various implementations, if the accessed node has the requested metadata information, control may flow to box 1216; otherwise, control may flow to decision box 1218. Similarly, as described above with respect to process 1100, the tracing engine may be arranged to determine whether the metadata information associated with the accessed field includes metadata values ​​that can respond to a query.

[0184] At box 1216, in one or more of the various implementations, the traversal engine can be arranged to determine the metadata information of the accessed box. Similar to what has been described above for process 1100, the traversal engine can be arranged to collect metadata values ​​that can respond to a query from the accessed field nodes. However, in contrast to process 1100, the traversal engine can be arranged to collect metadata values ​​from each accessed field node, rather than terminating the query after finding the first field node that satisfies the query and is associated with the metadata. Thus, in some implementations, the traversal engine can be arranged to collect eligible metadata values ​​from more than one field node encountered during upward traversal of the dependency hierarchy.

[0185] At decision box 1218, in one or more of the various implementations, if traversal of the dependency hierarchy should continue, control may loop back to box 1206; otherwise, control may flow to box 1220. In one or more of the various implementations, the traversal engine may be arranged to continue traversing the dependency hierarchy upwards along more than one branch or path based on the configuration of the dependency hierarchy. Furthermore, similar to process 1100, the traversal engine may be arranged to implement one or more security / performance protections, such as timeouts or node count limits. See the description above for process 1100.

[0186] At box 1220, in one or more of the various implementations, the tracing engine may be configured to return query results. In one or more of the various implementations, the tracing engine may be configured to provide linked metadata information that may have been encountered during traversal of the dependency hierarchy. In some implementations, the results of a query against linked metadata may provide the client with information about anchor fields and some or all of their ancestors in the dependency hierarchy. Otherwise, in some implementations, providing query result information may be considered similar to that described above for box 1120, including modifying the metadata query results based on information security considerations such as field / data access constraints, user roles, client types, client sources, etc.

[0187] Next, in one or more of the various implementation schemes, control can be returned to the calling procedure.

[0188] Figure 13 A flowchart of a process 1300 for information security associated with metadata inheritance of data assets, according to one or more embodiments of various implementations, is shown. Following the start box, at start box 1302, in one or more embodiments of various implementations, as described above, the inheritance engine can be arranged to generate metadata query results based on the execution of metadata queries.

[0189] At box 1304, in one or more of the various implementations, the inheritance engine can be configured to determine the relevant security policies associated with the metadata query results.

[0190] In one or more of the various implementation schemes, one or more fields or corresponding data objects in the dependency hierarchy may be associated with permission or access rules enforced by the inheritance engine.

[0191] In one or more of the various implementation schemes, the inheritance engine can be configured to apply one or more security policies that can be associated with one or more users, clients, data sources, data objects, etc., to prevent unauthorized access to protected / sensitive information.

[0192] In some implementations, the inheritance engine can be configured to determine security policies associated with metadata queries or their results. In other implementations, the inheritance engine can be configured to determine security policies based on configuration information, enabling different organizations or data owners to establish global or local security policies tailored to local requirements or circumstances. For example, in some implementations, security policies can be configured differently based on various factors, including query type, data source, data object, client, client type, user, etc. Therefore, in some implementations, the inheritance engine can be configured to determine security policies based on rules, maps, instructions, etc., to select security policies based on configuration information that considers local circumstances or requirements.

[0193] In one or more of the various implementation schemes, the inheritance engine can be configured to execute / evaluate one or more rules, conditions, instructions, etc., that may be defined in the security policy.

[0194] At box 1306, in one or more of the various implementations, the inheritance engine may be configured to evaluate the metadata query results in light of the determined security policy.

[0195] At decision box 1308, in one or more of the various implementation schemes, if a security policy issue can be determined, control may flow to decision box 1310; otherwise, control may flow to box 1314.

[0196] At decision box 1310, in one or more of the various implementation schemes, if the metadata query should be aborted, control may return to the calling procedure; otherwise, control may flow to box 1312.

[0197] In some cases, for certain implementations, security policies may instruct that metadata queries should be immediately suspended or rejected, so that no information or metadata query results can be returned to the client that provided the query. For example, if a security breach is determined to be associated with a malicious actor, the security policy may act as if the request has been ignored, rather than responding with any result.

[0198] At box 1312, in one or more of the various implementations, the inheritance engine may be configured to modify the metadata query results according to a determined security policy. In some implementations, the inheritance engine may be configured to hide / mask one or more parts of the metadata query results, such as metadata values, field names, data sources, etc.

[0199] For example, in some implementations, the inheritance engine can be configured to remove results associated with constrained / protected fields, leaving accessible fields in the results. In some cases, non-sensitive information (such as data types, data sources, hierarchical structure information, etc.) can be included in metadata query results while constrained information is removed.

[0200] In one or more of the various implementation schemes, the specific filtering or obfuscation of the initial metadata query results may depend on the rules, conditions, instructions, etc., declared in the determined security policy being implemented.

[0201] At box 1314, in one or more of the various implementations, the inheritance engine can be configured to provide modified metadata query results to the client / user providing the metadata query.

[0202] Next, in one or more of the various implementation schemes, control can be returned to the calling procedure.

[0203] It should be understood that each block in each flowchart illustration and combinations of blocks in each flowchart illustration can be implemented by computer program instructions. These program instructions can be provided to a processor to generate a machine, such that the instructions executing on the processor create means for implementing the actions specified in each flowchart block or blocks. The computer program instructions can be executed by the processor to cause the processor to perform a series of operational steps to produce a computer-implemented process, such that the instructions executing on the processor provide steps for implementing the actions specified in each flowchart block or blocks. The computer program instructions can also cause at least some of the operational steps shown in each flowchart block to be executed in parallel. Furthermore, some of these steps can also be executed on more than one processor, such as in a multiprocessor computer system. Additionally, without departing from the scope or spirit of the invention, one or more blocks or combinations of blocks in each flowchart illustration can also be executed simultaneously with other blocks or combinations of blocks, or even in a different sequence than shown.

[0204] Therefore, each block in each flowchart illustration supports a combination of means for performing a specified action, a combination of steps for performing a specified action, and a program instruction means for performing a specified action. It should also be understood that each block in each flowchart illustration and the combination of blocks in each flowchart illustration can be implemented by a hardware-based dedicated system that performs the specified action or step, or a combination of dedicated hardware and computer instructions. The foregoing examples should not be construed as limiting or exhaustive, but rather as illustrative use cases to illustrate how at least one embodiment of the invention is implemented in various embodiments.

[0205] Furthermore, in one or more embodiments (not shown in the figures), embedded logic hardware devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable array logic (PALs), or combinations thereof, can be used instead of a CPU to execute the logic in the exemplary flowchart. The embedded logic hardware device can directly execute its embedded logic to perform actions. In one or more embodiments, a microcontroller can be arranged to directly execute its own embedded logic to perform actions and access its own internal memory and its own external input and output interfaces (e.g., hardware pins or wireless transceivers) to perform actions, such as a system-on-a-chip (SoC).

[0206] Illustrative use cases

[0207] Figure 14 A logical representation of a query 1400 for metadata inheritance of data assets, according to one or more of various implementation schemes, is shown. In the example, query 1400 includes metadata query 1402 and metadata query result 1404.

[0208] In the example, the query type is declared as "First" in metadata query 1402. In this example, this type of query can be considered as being configured to return the first inheritable metadata that matches the query. In this example, the metadata query requests the metadata attribute named "Description" for the anchor field "Field C".

[0209] Therefore, in the example, result 1404 indicates that the metadata description of field C can be inherited from field B. It shows that the metadata "description" directly associated with "field C" is empty (because there is no qualification for the "description" for the field). Therefore, in the example, the metadata is inherited from "field B" which has the value "BBBBBB".

[0210] Figure 15 A logical representation of a query 1500 for metadata inheritance of data assets, according to one or more of various implementation schemes, is shown. In the example, query 1500 includes metadata query 1502 and metadata query result 1504.

[0211] In the example, the query type is declared as "link" in metadata query 1402. In this example, this type of query can be considered as being arranged to return a portion (e.g., a subtree) of metadata for fields in the dependency hierarchy that can be ancestors of the anchor field "field C". Therefore, two metadata values ​​are returned, one for each field in the dependency hierarchy that can be identified as an ancestor of the anchor field (field C).

[0212] Figure 16 The diagram illustrates a logical representation of a metadata query result 1600 for metadata inheritance according to one or more implementations of various schemes. In the example, metadata query result 1600 represents a result in which inheritable metadata was indeed found. Therefore, in the example, the metadata attribute "description" is reported as empty (e.g., blank). In the example above (e.g., process 1100), an empty result, such as metadata query result 1600, could be produced if compute nodes or multi-input stream nodes might be encountered in the dependency hierarchy.

Claims

1. A method for managing data using one or more processors, said one or more processors being configured to execute instructions, wherein the execution of said instructions includes the following actions: Generate a hierarchical structure model including one or more edges, wherein the one or more edges represent the dependencies between one or more field nodes, one or more compute nodes, or one or more flow nodes, wherein the field nodes represent the attribute values ​​of data objects, the compute nodes represent transformations that change the semantic meaning of the attribute values ​​of the data objects, and the flow nodes represent transformations that do not substantially change the semantic meaning of the attribute values ​​of the data objects; In response to a query for determining one or more values ​​of metadata associated with an anchor field, wherein the anchor field represents a field node in the hierarchical model that has been selected as the starting point for determining metadata inheritance, the following further actions are performed: based on the query and the hierarchical model, traversing the hierarchical model upwards from the anchor field, and performing the following further actions: In response to accessing one or more field nodes in the hierarchical structure model, the one or more values ​​of the metadata corresponding to the accessed field node are collected, wherein the traversal terminates based on the type of the query, wherein the type of the query includes: A first query type, wherein the traversal of the hierarchical model is terminated in response to accessing the first ancestor field node of the anchor field, the first ancestor field node including the value of metadata associated with the metadata of the anchor field; and The second query type, wherein the traversal of the hierarchical structure model is terminated in response to accessing all ancestor field nodes of the anchor field; In response to accessing a compute node, terminate the traversal of the hierarchical model associated with the accessed compute node; and In response to accessing a flow node that depends on two or more other nodes in the hierarchical structure model, the traversal of the hierarchical structure model associated with the accessed flow node is terminated; and Provide a response to the query, the response including one or more collected values ​​of the metadata that can be inherited from the anchor field.

2. The method of claim 1, wherein terminating the traversal based on the type of the query further comprises: In response to the query being a first query type, the traversal of the hierarchical model is terminated in response to accessing the first ancestor field node associated with the value of the metadata of the anchor field, wherein the value of the metadata collected from the first ancestor field node is provided as the metadata for the anchor field.

3. The method according to claim 1, wherein terminating the traversal based on the type of the query further comprises: In response to the query being a second query type, perform further actions: Visit each field node in the hierarchical structure model that is an ancestor of the anchor field, wherein visiting an intermediate computation node or an intermediate multi-input stream node terminates the traversal of the hierarchical structure model; and Collect the one or more values ​​of the metadata for each visited field node that is an ancestor of the anchor field, wherein the one or more values ​​of the metadata are sorted based on the one or more dependencies corresponding to the anchor field and the one or more visited ancestor field nodes in the hierarchical structure model.

4. The method according to claim 1, wherein traversing the hierarchical structure model further comprises: Based on the query and the client providing the query, determine one or more security policies associated with the hierarchical structure model; Compare the one or more accessed field nodes and the client with the one or more security policies; Based on the comparison, one or more constrained field nodes are determined in the hierarchical structure model, wherein the one or more security policies prevent the client from accessing information associated with the one or more constrained field nodes; and Exclude one or more values ​​of the metadata associated with the one or more constrained field nodes from the response to the query, wherein one or more of the identifiers or data types associated with the one or more constrained field nodes are included in the response to the query.

5. The method according to claim 1, further comprising: Based on the query type or one or more of the query, determine one or more of the timeout value or node access restriction value; In response to the timeout value exceeding the timeout period for providing a response to the query, the traversal of the hierarchical structure model is terminated and a partial response including the one or more collected values ​​of the metadata is provided to the query. and In response to the number of nodes accessed in the hierarchical structure model exceeding the node access limit value, the traversal of the hierarchical structure model is terminated, and a partial response including the one or more collected values ​​of the metadata is provided.

6. The method according to claim 1, further comprising: The type of query is determined based on the information provided with the query. Based on the type of query, determine one or more conditions to terminate the traversal; Based on the type of query, determine the response information to be included in the response to the query, wherein the response information includes one or more of the following: one or more values ​​of the metadata, one or more aggregated values ​​based on the one or more values ​​of the metadata, or the execution of one or more other actions defined by the type of query.

7. The method according to claim 1, further comprising: In response to the anchor field being associated with a value of the metadata, the value of the metadata associated with the anchor field is included in the response to the query; and In response to the absence of the value of the metadata in the anchor field, the response to the query provides the value of the metadata associated with the ancestor field node closest to the anchor field in the hierarchical structure model.

8. A system for managing data, the system comprising: A network computer, the network computer comprising: Memory, which stores at least instructions; and One or more processors that implement instructions that perform actions including: Generate a hierarchical structure model including one or more edges, wherein the one or more edges represent the dependencies between one or more field nodes, one or more compute nodes, or one or more flow nodes, wherein the field nodes represent the attribute values ​​of data objects, the compute nodes represent transformations that change the semantic meaning of the attribute values ​​of the data objects, and the flow nodes represent transformations that do not substantially change the semantic meaning of the attribute values ​​of the data objects; In response to a query for determining one or more values ​​of metadata associated with an anchor field, wherein the anchor field represents a field node in the hierarchical model that has been selected as the starting point for determining metadata inheritance, further actions are performed, including: Based on the query and the hierarchical structure model, the hierarchical structure model is traversed upwards from the anchor field, and further actions including the following are performed: In response to accessing one or more field nodes in the hierarchical structure model, the one or more values ​​of the metadata corresponding to the accessed field node are collected, wherein the traversal terminates based on the type of the query, wherein the type of the query includes: A first query type, wherein the traversal of the hierarchical model is terminated in response to accessing the first ancestor field node of the anchor field, the first ancestor field node including the value of metadata associated with the metadata of the anchor field; and The second query type, wherein the traversal of the hierarchical structure model is terminated in response to accessing all ancestor field nodes of the anchor field; In response to accessing a compute node, terminate the traversal of the hierarchical model associated with the accessed compute node; and In response to accessing a flow node in the hierarchical structure model that depends on two or more other nodes, the traversal of the hierarchical structure model associated with the accessed flow node is terminated; and Provide a response to the query, the response including one or more collected values ​​of the metadata that can be inherited from the anchor field; and The client computer includes: Memory, which stores at least instructions; and One or more processors that implement instructions that perform actions, including providing the query.

9. The system of claim 8, wherein terminating the traversal based on the type of the query further comprises: In response to the query being a first query type, and in response to accessing the first ancestor field node associated with the value of the metadata of the anchor field, the traversal of the hierarchical structure model is terminated, wherein the value of the metadata collected from the first ancestor field node is provided as the metadata for the anchor field.

10. The system of claim 8, wherein terminating the traversal based on the type of the query further comprises: In response to the query being a second query type, perform further actions: Visit each field node in the hierarchical structure model that is an ancestor of the anchor field, wherein visiting an intermediate computation node or an intermediate multi-input stream node terminates the traversal of the hierarchical structure model; and Collect the one or more values ​​of the metadata for each visited field node that is an ancestor of the anchor field, wherein the one or more values ​​of the metadata are sorted based on the one or more dependencies corresponding to the anchor field and the one or more visited ancestor field nodes in the hierarchical structure model.

11. The system according to claim 8, wherein traversing the hierarchical structure model further comprises: Based on the query and the client providing the query, determine one or more security policies associated with the hierarchical structure model; Compare the one or more accessed field nodes and the client with the one or more security policies; Based on the comparison, one or more constrained field nodes are determined in the hierarchical structure model, wherein the one or more security policies prevent the client from accessing information associated with the one or more constrained field nodes; and Exclude one or more values ​​of the metadata associated with the one or more constrained field nodes from the response to the query, wherein one or more of the identifiers or data types associated with the one or more constrained field nodes are included in the response to the query.

12. The system of claim 8, wherein the one or more network computer processors implement instructions that perform actions including: Based on the query type or one or more of the query, determine one or more of the timeout value or node access restriction value; In response to the timeout value exceeding the timeout period for providing a response to the query, the traversal of the hierarchical model is terminated, and a partial response including the one or more collected values ​​of the metadata is provided to the query; and In response to the number of nodes accessed in the hierarchical structure model exceeding the node access limit value, the traversal of the hierarchical structure model is terminated, and a partial response including the one or more collected values ​​of the metadata is provided.

13. The system of claim 8, wherein the one or more network computer processors implement instructions that perform actions including: The type of query is determined based on the information provided with the query. Based on the type of query, determine one or more conditions to terminate the traversal; Based on the type of query, determine the response information to be included in the response to the query, wherein the response information includes one or more of the following: one or more values ​​of the metadata, one or more aggregated values ​​based on the one or more values ​​of the metadata, or the execution of one or more other actions defined by the type of query.

14. The system of claim 8, wherein the one or more network computer processors implement instructions that perform actions including: In response to the anchor field being associated with a value of the metadata, the value of the metadata associated with the anchor field is included in the response to the query; and In response to the absence of the value of the metadata in the anchor field, the response to the query provides the value of the metadata associated with the ancestor field node closest to the anchor field in the hierarchical structure model.

15. A processor-readable non-transitory storage medium including instructions for managing data, wherein the instructions are executed by one or more processors to perform actions including: Generate a hierarchical structure model including one or more edges, wherein the one or more edges represent the dependencies between one or more field nodes, one or more compute nodes, or one or more flow nodes, wherein the field nodes represent the attribute values ​​of data objects, the compute nodes represent transformations that change the semantic meaning of the attribute values ​​of the data objects, and the flow nodes represent transformations that do not substantially change the semantic meaning of the attribute values ​​of the data objects; In response to a query for determining one or more values ​​of metadata associated with an anchor field, wherein the anchor field represents a field node in the hierarchical model that has been selected as the starting point for determining metadata inheritance, the following further actions are performed: based on the query and the hierarchical model, traversing the hierarchical model upwards from the anchor field, and performing the following further actions: In response to accessing one or more field nodes in the hierarchical structure model, the one or more values ​​of the metadata corresponding to the accessed field node are collected, wherein the traversal terminates based on the type of the query, wherein the type of the query includes: A first query type, wherein the traversal of the hierarchical model is terminated in response to accessing the first ancestor field node of the anchor field, the first ancestor field node including the value of metadata associated with the metadata of the anchor field; and The second query type, wherein the traversal of the hierarchical structure model is terminated in response to accessing all ancestor field nodes of the anchor field; In response to accessing a compute node, terminate the traversal of the hierarchical model associated with the accessed compute node; and In response to accessing a flow node in the hierarchical structure model that depends on two or more other nodes, the traversal of the hierarchical structure model associated with the accessed flow node is terminated; and Provide a response to the query, the response including one or more collected values ​​of the metadata that can be inherited from the anchor field.

16. The medium of claim 15, wherein terminating the traversal based on the type of the query further comprises: In response to the query being a first query type, and in response to accessing the first ancestor field node associated with the value of the metadata of the anchor field, the traversal of the hierarchical structure model is terminated, wherein the value of the metadata collected from the first ancestor field node is provided as the metadata for the anchor field.

17. The medium of claim 15, wherein terminating the traversal based on the type of the query further comprises: In response to the query being a second query type, perform further actions: Visit each field node in the hierarchical structure model that is an ancestor of the anchor field, wherein visiting an intermediate computation node or an intermediate multi-input stream node terminates the traversal of the hierarchical structure model; and Collect the one or more values ​​of the metadata for each visited field node that is an ancestor of the anchor field, wherein the one or more values ​​of the metadata are sorted based on the one or more dependencies corresponding to the anchor field and the one or more visited ancestor field nodes in the hierarchical structure model.

18. The medium according to claim 15, wherein traversing the hierarchical structure model further comprises: Based on the query and the client providing the query, determine one or more security policies associated with the hierarchical structure model; Compare the one or more accessed field nodes and the client with the one or more security policies; Based on the comparison, one or more constrained field nodes are determined in the hierarchical structure model, wherein the one or more security policies prevent the client from accessing information associated with the one or more constrained field nodes; and Exclude one or more values ​​of the metadata associated with the one or more constrained field nodes from the response to the query, wherein one or more of the identifiers or data types associated with the one or more constrained field nodes are included in the response to the query.

19. The medium according to claim 15, further comprising: Based on the query type or one or more of the query, determine one or more of the timeout value or node access restriction value; In response to the timeout value exceeding the timeout period for providing a response to the query, the traversal of the hierarchical structure model is terminated, and a partial response including the one or more collected values ​​of the metadata is provided to the query; and In response to the number of nodes accessed in the hierarchical structure model exceeding the node access limit value, the traversal of the hierarchical structure model is terminated, and a partial response including the one or more collected values ​​of the metadata is provided.

20. The medium according to claim 15, further comprising: The type of query is determined based on the information provided along with the query. Based on the type of query, determine one or more conditions to terminate the traversal; Based on the type of query, determine the response information to be included in the response to the query, wherein the response information includes one or more of the following: one or more values ​​of the metadata, one or more aggregated values ​​based on the one or more values ​​of the metadata, or the execution of one or more other actions defined by the type of query.

Images