Methods to curate data and deliver recommendations

Abstract

Disclosed herein are methods and systems for providing individualized responses and recommendations based on a shared knowledge language. A method of receiving a user query for a personalized response associated with a profile; interpreting the query by executing a machine-learning model; generating a data query corresponding to the user query by executing the machine-learning model, the data query configured for execution in a computer model comprising one or more nodes having an identifier corresponding to a series of nouns and verbs generated in accordance with a schema associated with a shared knowledge language; receiving a first node of the computer model, wherein the first node is associated with the profile and generated based at least in part on an application accessed by the profile; presenting the personalized response, wherein the personalized response comprises an indication of the first node of the computer model.

Description

CMK0014-PCT-125056-0147 PATENT METHODS TO CURATE DATA AND DELIVER RECOMMENDATIONS CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 534,335, filed August 23, 2023, and also claims priority under 35 U.S.C. § 120 as a continuation-in-part of U.S. Application No. 18 / 303,890, filed April 20, 2023, which claims priority to U.S. Patent Applicant No. 18 / 088,485, filed December 23, 2022, which claims priority to U.S. Provisional Patent Application No. 63 / 308,305, filed February 9, 2022, U.S. Provisional Patent Application No. 63 / 293,600, filed December 23, 2021, U.S. Provisional Patent Application No. 63 / 351,690, filed June 13, 2022, U.S. Provisional Patent Application No. 63 / 354,563, filed June 22, 2022, and which is also a continuation-in-part of U.S. Patent application No. 17 / 707,888, filed March 29, 2022, which claims priority to U.S. Provisional Patent Application No.63 / 191,852, filed May 21, 2021 and 63 / 167,401, filed March 29, 2021, all of which are incorporated by reference herein for all purposes. TECHNICAL FIELD

[0002] This application relates generally to electronic data management and communication. BACKGROUND

[0003] Many engineering processes lack a universal standard for the accumulation, translation, and transformation of digital information across disparate end-user needs and work processes. An increase in connectivity among different computing device has led to large volume of data being created and relied upon across fragmented environments and domain areas. The more friction there is in connecting data and capabilities across and within any given set of software tools, the harder it is for data creators and for end users to draw value from the underlying information, and the easier it is for “middle-men” to monetize said data and data pipelines. As a result, entire secondary markets have emerged to try to connect data and capabilities across disparate software tools. This incompatibility of data fragments has led to many technical shortcomings. For instance, various computing infrastructure cannot efficiently communicate because they cannot freely exchange data.

[0004] Beyond the problems associated with the of incompatibility of data that is fragmented about disparate computing infrastructres, difficulties arise in presenting user- specific information to specific uses. With data about the user fragmented about disparate computing infrastructures, relevant contextual data about the user is inaccessible or difficult to Page 1 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT collate, leading to shortcomings in the ability to generate personalized responses to a user’s natural language query based on relevant user data, leading to generic or inaccurate responses that fail to meet user expectations.

[0005] Additionally, the fragemented nature of data has caused difficulties for entities to curate personal recommendations for users based on trusted sources. Rather, traditional approaches to data management and communication have resulted in providing generic recommendations from static databases and / or from untrusted sources of data.

[0006] Additionally, as the processing power of computers allow for greater computer functionality and the internet technology era allows for interconnectivity between computing systems, electronic content have become more ubiquitous. Content providers use various platforms, such as websites or other applications, to provide their content.

[0007] However, since the implementation of more sophisticated online tools, several shortcomings in these technologies have been identified and have created a new set of impediments. For example, electronic content for a given user or organization now tends to be highly fragmented across a variety of different tools and systems. The high level of fragmentation makes it more difficult to monitor the electronic content consumed by users, to extract knowledge from the content consumed by users, and to augment electronic content with other useful knowledge. SUMMARY

[0008] In contrast, ecosystems offer a more flexible framework that enhances coordination and leverages synergies among diverse components without sacrificing autonomy. This model fosters an integrated and adaptable approach, allowing teams to reinvent and vertically integrate components when necessary for innovation, while maintaining an interoperable framework throughout the ecosystem. Configuring themselves as ecosystems enables organizations to respond dynamically to changing market conditions, fostering an environment conducive to continuous innovation and growth. Additionaly or alternatively, the systems and methods described herein provide for a front end user interface for providing contextualized and personalized data (e.g., recommendations) from the interopable framework of the ecosystem.

[0009] For the aforementioned reasons, there is also a desire for an efficient system and method to identify, extract, and improve access to knowledge and capabilities across fragmented systems by analyzing electronic content that has been, is being, or will be Page 2 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT consumed by users (e.g., is presented to users). More specifically, there is a growing need for methods and systems that facilitate how users interact with computer systems in order to, for example, enable users to easily identify relevant actions for and perform relevant actions on any given piece of data across a variety of systems and interfaces, and facilitate users’ access to relevant knowledge for any given piece of data. Methods and systems described herein can monitor and help manage electronic content, actions, and relationships between and across data and actions.

[0010] In some aspects, the techniques described herein relate to a computer- implemented method including: receiving, by one or more processors, a user query for a personalized response associated with a profile; interpreting, by the one or more processors, the user query by executing a machine-learning model; generating, by the one or more processors, a data query corresponding to the user query by executing the machine-learning model, the data query configured for execution in a computer model including one or more nodes, each node of the one or more nodes having an identifier corresponding to a series of nouns and verbs generated in accordance with a schema associated with a shared knowledge language; receiving, by the one or more processors, a first node of the computer model, wherein the first node is associated with the profile and generated based at least in part on an application accessed by the profile; and presenting, by the one or more processors, the personalized response, wherein the personalized response includes an indication of the first node of the computer model.

[0011] In some aspects, the techniques described herein relate to a computer- implemented method, further including: receiving, by the one or more processors, a second indication indicative of a context displayed by a computing device associated with the profile; determining, by the one or more processors, a second node of the computer model, the second node associated with the context displayed by the computing device; generating, by the one or more processors, a personalized prompt based on the second node, wherein the personalized prompt is a second output of the machine-learning model; and presenting, by the one or more processors, the personalized prompt.

[0012] In some aspects, the techniques described herein relate to a computer- implemented method, wherein the computer model further includes a nodal data structure of a set of nodes where each node corresponds to data identified as associated with each application within a set of applications accessed and used by each computing device, each node having an identifier corresponding to a series of nouns and verbs generated in accordance with the schema Page 3 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT associated with the shared knowledge language, wherein the series of nouns define one or more types of data and the series of verbs define one or more software processes, the computer model transforming the data generated as a result of at least one computing device accessing and using one or more applications from the set of applications into a series of nouns and verbs using the schema.

[0013] In some aspects, the techniques described herein relate to a computer- implemented method, wherein the user query is provided in a natural language syntax.

[0014] In some aspects, the techniques described herein relate to a computer- implemented method, further including: executing, by the one or more processors, the machine- learning model to review one or more search results from the data query; and selecting, by the one or more processors, a search result from the one or more search results that satisfies a threshold.

[0015] In some aspects, the techniques described herein relate to a computer- implemented method, wherein generating the data query further includes: parsing, by the one or more processors, the user query into one or more search elements; and determining, by the one or more processors, one or more search parameters associated with the one or more search elements.

[0016] In some aspects, the techniques described herein relate to a computer- implemented method, further including: responsive to receiving a selection of the personalized response, generating, by the one or more processors, a second query based on the search result, wherein the second query is associated with the personalized response; querying, by the one or more processors, the computer model based at least on the second query; receiving, by the one or more processors, a second node linked to the first node of the computer model; and presenting, by the one or more processors, a second personalized response, the second personalized response corresponding to the second node.

[0017] In some aspects, the techniques described herein relate to a computer- implemented method, wherein at least one node of the one or more nodes represents contextual data associated with a previous response.

[0018] In some aspects, the techniques described herein relate to a system including: one or more processors; and a non-transitory computer-readable medium having a set of instructions that when executed, cause the one or more processors to: receive a user query for a personalized response associated with a profile; interpret the user query by executing a Page 4 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT machine-learning model; generate a data query corresponding to the user query by executing the machine-learning model, the data query configured for execution in a computer model including one or more nodes, each node of the one or more nodes having an identifier corresponding to a series of nouns and verbs generated in accordance with a schema associated with a shared knowledge language; receive a first node of the computer model, wherein the first node is associated with the profile and generated based at least in part on an application accessed by the profile; and present the personalized response, wherein the personalized response includes an indication of the first node of the computer model.

[0019] In some aspects, the techniques described herein relate to a system, wherein the set of instructions further cause the one or more processors to: receive a second indication indicative of a context displayed by a computing device associated with the profile; determine a second node of the computer model, the second node associated with the context displayed by the computing device; generate a personalized prompt based on the second node, wherein the personalized prompt is a second output of the machine-learning model; and present the personalized prompt.

[0020] In some aspects, the techniques described herein relate to a system, wherein the computer model further includes a nodal data structure of a set of nodes where each node corresponds to data identified as associated with each application within a set of applications accessed and used by each computing device, each node having an identifier corresponding to a series of nouns and verbs generated in accordance with a schema associated with a shared knowledge language, wherein the series of nouns define one or more types of data and the series of verbs define one or more software processes, the computer model transforming the data generated as a result of at least one computing device accessing and using one or more applications from the set of applications into a series of nouns and verbs using the schema.

[0021] In some aspects, the techniques described herein relate to a system, wherein the user query is provided in a natural language syntax.

[0022] In some aspects, the techniques described herein relate to a system, wherein the set of instructions further cause the one or more processors to: execute the machine-learning model to review one or more search results from the data query; and select a search result from the one or more search results that satisfies a threshold.

[0023] In some aspects, the techniques described herein relate to a system, wherein the set of instructions further cause the one or more processors to: parse the user query into one or Page 5 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT more search elements; and determine one or more search parameters associated with the one or more search elements.

[0024] In some aspects, the techniques described herein relate to a system, wherein the set of instructions further cause the one or more processors to: responsive to receiving a selection of the personalized response, generate a second query based on the search result, wherein the second query is associated with the personalized response; query the computer model based at least on the second query; receive a second node linked to the first node of the computer model; and present a second personalized response, the second personalized response corresponding to the second node.

[0025] In some aspects, the techniques described herein relate to a system including: one or more processors; and a non-transitory computer-readable medium having a set of instructions that when executed, cause the one or more processors to: receive a user query for a personalized response associated with a profile; interpret the user query by executing a machine-learning model; generate a data query corresponding to the user query by executing the machine-learning model, the data query configured for execution in a computer model including one or more nodes, each node of the one or more nodes having an identifier corresponding to a series of nouns and verbs generated in accordance with a schema associated with a shared knowledge language; receive a first node of the computer model, wherein the first node is associated with the profile and generated based at least in part on an application accessed by the profile; and present the personalized response, wherein the personalized response includes an indication of the first node of the computer model.

[0026] In some aspects, the techniques described herein relate to a system, wherein the set of instructions further cause the one or more processors to: receive a second indication indicative of a context displayed by a computing device associated with the profile; determine a second node of the computer model, the second node associated with the context displayed by the computing device; generate a personalized prompt based on the second node, wherein the personalized prompt is a second output of the machine-learning model; and present the personalized prompt.

[0027] In some aspects, the techniques described herein relate to a system, wherein the computer model further includes a nodal data structure of a set of nodes where each node corresponds to data identified as associated with each application within a set of applications accessed and used by each computing device, each node having an identifier corresponding to Page 6 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT a series of nouns and verbs generated in accordance with a schema associated with the shared knowledge language, wherein the series of nouns define one or more types of data and the series of verbs define one or more software processes, the computer model transforming the data generated as a result of at least one computing device accessing and using one or more applications from the set of applications into a series of nouns and verbs using the schema.

[0028] In some aspects, the techniques described herein relate to a system, wherein the set of instructions further cause the one or more processors to: execute the machine-learning model to review one or more search results from the data query; and select a search result from the one or more search results that satisfies a threshold.

[0029] In some aspects, the techniques described herein relate to a system, wherein the set of instructions further cause the one or more processors to: responsive to receiving a selection of the personalized response, generate a second query based on the search result, wherein the second query is associated with the personalized response; query the computer model based at least on the second query; receive a second node linked to the first node of the computer model; and present a second personalized response, the second personalized response corresponding to the second node. BRIEF DESCRIPTION OF FIGURES

[0030] Non-limiting embodiments of the present disclosure are described by way of example with reference to the accompanying figures, which are Schematic and are not intended to be drawn to scale. Unless indicated as representing the background art, the figures represent aspects of the disclosure.

[0031] FIG. 1A is a graphical representation of using the methods and system described herein to generate a unified memory bank, in accordance with an embodiment.

[0032] FIG. 1B is a graphical representation of two methods for integrating various applications together, in accordance with an embodiment.

[0033] FIG. 1C is a graphical representation of two methods for integrating various applications together, in accordance with an embodiment.

[0034] FIG. 2 is a visual representation of storing data in a unified memory bank, in accordance with an embodiment.

[0035] FIG. 3 is a visual representation of an abstraction of data to integrate with various applications, in accordance with an embodiment. Page 7 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0036] FIG.4 is a visual representation of using a unified standardization of data for various benefits, in accordance with an embodiment.

[0037] FIG. 5 is a visual representation of a developer’s method of integrating data between various APIs, in accordance with an embodiment.

[0038] FIG.6 is a visual representation of an application’s method of integrating data between various APIs, in accordance with an embodiment.

[0039] FIG. 7 is a visual representation of a developer’s method in using a Standard Knowledge Language, in accordance with an embodiment.

[0040] FIG.8 is a visual representation of an application’s method in using a Standard Knowledge Language to integrate data between various APIs, in accordance with an embodiment.

[0041] FIG. 9 is a visual representation of a Virtual Database with contents from various constituent databases, in accordance with an embodiment.

[0042] FIG. 10 is a visual representation of a Standard Knowledge Data Store following a Solid specification, including a Standard Syncer, in accordance with an embodiment.

[0043] FIG.11 illustrates an architectural diagram, in accordance with an embodiment.

[0044] FIG.12 illustrates an architectural diagram, in accordance with an embodiment.

[0045] FIG. 13 is a flow diagram of a process executed by a Standard SDK, in accordance with an embodiment.

[0046] FIG. 14 is a visual representation of an application that uses a Standard SDK together with Schemas to integrate with various different data sources, in accordance with an embodiment.

[0047] FIG.15 is a flow diagram of a representation of a Shared Knowledge Language process, in accordance with an embodiment.

[0048] FIG.16 is a illustrates a conceptual diagram of how a developer may leverage the concepts behind SKL to integrate with many different applications and / or accounts, in accordance with an embodiment.

[0049] FIG.17 is a flow diagram of a Shared Knowledge Language framework using a Standard SDK, in accordance with an embodiment. Page 8 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0050] FIG. 18 depicts exploring the data inside a document through a natural- language query, in accordance with an embodiment.

[0051] FIG. 19 is a visual representation of various components that make up a Standard Knowledge Language framework, in accordance with an embodiment.

[0052] FIG. 20 is a visual representation of two different applications using a single Standard Knowledge Framework to access a single data source, in accordance with an embodiment.

[0053] FIG.21 is a visual representation of three different applications using a single Standard Knowledge Framework to integrate with three distinct sources of data, in accordance with an embodiment.

[0054] FIG. 22 is a visual representation of Standard Syncer pulling data from three distinct data sources through the use of a single Standard SDK, in accordance with an embodiment.

[0055] FIG.23 is a visual representation of a Persistent Database with contents from various constituent databases, using a Standard Syncer, in accordance with an embodiment.

[0056] FIG.24 is a visual representation of several applications using a Standard SDK to access data from a data storage, in accordance with an embodiment.

[0057] FIG.25 is a graphical user interface displayed by a rules engine, in accordance with an embodiment.

[0058] FIG.26 is a graphical user interface displayed by a rules engine, in accordance with an embodiment.

[0059] FIG.27 is a graphical user interface displayed by a rules engine, in accordance with an embodiment.

[0060] FIG.28 is a graphical user interface displayed by a rules engine, in accordance with an embodiment.

[0061] FIG. 29 is a visual representation of a frontend application using a Standard SDK.

[0062] FIG.30 is a visual representation of how a noun may be mapped to a variety of Interface Components, in accordance with an embodiment. Page 9 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0063] FIG.31 is a visual representation of a graphical user interface using the methods of a Standard Knowledge Language, in accordance with an embodiment.

[0064] FIG. 32 illustrates a conceptual diagram of how the SKL Library may relate different SKL Attributes, in accordance with an embodiment.

[0065] FIG.33 illustrates an Integration’s profile on the Official Library, in accordance with an embodiment.

[0066] FIG. 34 illustrates a clustering of entities based on their properties and / or relationships to other Entities, in accordance with an embodiment.

[0067] FIG. 35 depicts a graphical user interface of an online word processor application, in accordance with an embodiment.

[0068] FIG.36 illustrates some of the Nouns that an analytics server may automatically identify within electronic content, in accordance with an embodiment.

[0069] FIG. 37 depicts the composition the Official Library and some of the various SKL Artifacts and SKL Libraries that can compose it, in accordance with an embodiment.

[0070] FIG.38 illustrates components of an electronic workflow management system, in accordance with an embodiment.

[0071] FIG. 39 illustrates a flow diagram of a process executed in an electronic workflow management system, in accordance with an embodiment.

[0072] FIG.40 represent a nodal structure created based on a set of identified files and related nodes connected via different edges, in accordance with an embodiment.

[0073] FIG.41 shows a series of graphical user interfaces where a SKApp may provide contextually useful information and capabilities to an end user based on electronic content and electronic context, in accordance with an embodiment.

[0074] FIG.42a illustrate the graphical user interface of a SKApp, in accordance with an embodiment.

[0075] FIG.42b illustrate the graphical user interface of a SKApp, in accordance with an embodiment.

[0076] FIG.42c illustrate the graphical user interface of a SKApp, in accordance with an embodiment. Page 10 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0077] FIG.43 illustrate the graphical user interface of a SKApp, in accordance with an embodiment.

[0078] FIG.44 illustrate the graphical user interface of a SKApp, in accordance with an embodiment.

[0079] FIG.45 is a graphical illustration of a system architecture, in accordance with an embodiment.

[0080] FIG.46 depicts a nodal data structure, in accordance with an embodiment.

[0081] FIG. 47 illustrates a diagram of two Entities sharing similar properties and relationships in a nodal data structure, in accordance with an embodiment.

[0082] FIG.48 illustrates a conceptual diagram of the Syncer SKApp, in accordance with an embodiment.

[0083] FIG.49 illustrates a graphical user interface for SKApp, in accordance with an embodiment.

[0084] FIG.50 illustrates a noun mapping system with a Syncer SKApp, in accordance with an embodiment, in accordance with an embodiment.

[0085] FIG.51 shows a graphical user interface where a user is interacting with a large language model that is able to retrieve data, in accordance with an embodiment.

[0086] FIGS.52-53 illustrate user interfaces displayed using the methods and systems discussed herein, in accordance with an embodiment.

[0087] FIG. 54 illustrates a series of steps that a SKApp may take in order to contextualize and then synthesize natural language summaries of notifications from various different data sources.

[0088] FIG. 55 illustrate user interface displayed using the methods and systems discussed herein, in accordance with an embodiment.

[0089] FIG. 56 shows a database including information about an activity, in accordance with an embodiment.

[0090] FIG.57 illustrates a user interface for providing personalized recommendations to a user based on a SKL Platform, in accordance with an embodiment. Page 11 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0091] FIG. 58 illustrates a connection between a user’s personal nodal data structure and an entity’s nodal data structure.

[0092] FIG.59A–67 illustrate user interfaces displayed using the methods and systems discussed herein, in accordance with an embodiment.

[0093] FIG. 68A–68D illustrate various entity interfaces displayed using the methods and systems discussed herein, in accordance with an embodiment.

[0094] FIG. 69 illustrates a flow diagram of a process executed in an electronic data management system, in accordance with an embodiment.

[0095] FIG. 70 illustrates a flow diagram of a process executed in an electronic data management system, in accordance with an embodiment.

[0096] FIG. 71 illustrates operational steps of a method for inferring content relationships, according to an embodiment.

[0097] FIGS. 72-74 illustrate various graphical user interfaces, according to various embodiments.

[0098] FIG. 75 illustrates operational steps of a method for inferring content relationships, according to an embodiment.

[0099] FIG. 76 illustrates a nodal data structure, according to an embodiment.

[0100] FIGS. 77-79 illustrate operational steps of methods for inferring content relationships, according to various embodiments.

[0101] FIG. 80 illustrates operational steps for an automated workflow between third- party productivity applications, according to an embodiment.

[0102] FIG. 81 illustrates a nodal data structure, according to an embodiment that corresponds with the automated workflow in FIG. 80.

[0103] FIG. 82 illustrates operational steps for two automated workflows between third-party productivity applications, according to an embodiment.

[0104] FIG. 83 illustrates a nodal data structure, according to an embodiment that corresponds with the automated workflow in FIG. 82.

[0105] FIG. 84 illustrates operational steps for an intelligently automated workflow over data regardless of source applications, according to an embodiment. Page 12 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0106] FIG.85 illustrates operational steps of a method for triggering automations and inferring content relationships, according to an embodiment.

[0107] FIG. 86 illustrates operational steps of a method for inferring content relationships, according to an embodiment. DETAILED DESCRIPTION OF FIGURES

[0108] Reference will now be made to the illustrative embodiments depicted in the drawings, and specific language will be used here to describe the same. It will nevertheless be understood that no limitation of the scope of the claims or this disclosure is thereby intended. Alterations and further modifications of the inventive features illustrated herein, and additional applications of the principles of the subject matter illustrated herein, which would occur to one skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the subject matter disclosed herein. Other embodiments may be used and / or other changes may be made without departing from the spirit or scope of the present disclosure. The method, systems, and illustrated architectures are non-limiting to the concepts discussed herein. The SKL discussed herein may be understood as a methodology rather than a taxonomy.

[0109] Turning now to FIG.1A, which illustrates two different models for comparing attributes of different objects and being able to exchange and / or translate those objects. The way people integrate software today generally requires translation from one proprietary format to another (e.g., integrate Salesforce® with QuickBooks®). These one-to-one connections and translations are a sub optimal way to translate data across multiple workflows and processes. This is like society trying to trade goods and services before the standard of money as is shown in diagram 100. Before money, goods and services were bartered one-to-one and wealth was always understood in terms of a particular good (e.g., number of chickens, number of chickens produced per week, etc.).

[0110] Storing data in proprietary formats is not conducive to the accumulation of knowledge. Doing so has a higher risk of loss of, misunderstanding of, and / or incomplete data. For example, a software provider may get bought, go out of business, change some aspect of the software without your approval, etc. This is like people trying to accumulate wealth before the standard of money. Before money, people had to accumulate wealth in goods that were harder to trade with and had more inherent risks than money (e.g., all the chickens die, grain can grow stale, society decides a particular good is taboo, etc.) as is shown in diagram 102. Page 13 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0111] Turning now to FIG.1B, two conceptual alternative embodiments for how a set of applications 111a-f (collectively applications 111) and applications 121a-f (collectively applications 121) may be integrated is illustrated. Applications 111 and 121 are to be considered the same applications, only represented as part of two different integrated networks of applications. The network of integrations 110 show an approach where each application 111 is directly integrated with every other application. In this embodiment, a developer creates, uses, and / or maintains custom software that translates the way data is represented between every pair of applications. Furthermore, the developer also creates, uses, and / or manages custom software that translates whatever capabilities (e.g., identity and access management) need to be programmatically accessed between any pair of software applications. In some embodiments, the developer of each application vendor tends to be responsible for connecting their application with as many other relevant applications as makes viable business sense.

[0112] Moreover, in some embodiments, these different connections and transformations between applications and systems tend to be created and managed in different programming languages, via different integration platforms using different technologies, and through other fragmented approaches. This makes it difficult for users, organizations, and developers to effectively manage rapidly changing ecosystems of integrated data sources, applications, digital solutions, and other integratable systems like artificial intelligence models, software, sensors, and technology products. FIG. 1C shows two conceptual alternative embodiments for how a set of databases 131a, software applications 131b, AI models 131c, processes 131d (e.g., analog or digital business processes), cloud services 131e, and other systems 131f (e.g., sensors, satelites, mainframes, etc.) (collectively applications 131) and applications and systems 141a-f (collectively applications 141) may be integrated. Applications 131 and 141 are to be considered the same applications, only represented as part of two different integrated networks of applications. The network of integrations 130 show an approach where each application 131 is directly integrated with every other application. In this embodiment, multiple different developers are likely responsible for each of the applications 131. These developers are likely to create, use, and / or maintain custom integrations and transformations between their application 131a-f and other relevant applications 131. This leads to fragmented ecosytems integrations, translations, and logic between applications 131 created using various technologies, systems, hardware, SDKs, and implementations strategies. These fragmented ecosystems are hard to manage, govern, understand, debug, improve, and generally work with. Page 14 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0113] FIG.2 illustrates two exemplary conceptual architectural diagrams for a set of software applications used by a given person or organization. Architecture diagram 210 is illustrative of a software architecture for applications where the software developer or vendor for each application bundles custom interfaces 221a–c, custom processing logic 222a–c, and custom data models 225a–c with the corresponding data storage (e.g., infrastructure, etc.) into their platform 220a–c. Integrating the various platforms 220a–c may be done according to the network of integration 110 of FIG. 1B. Each custom interface 221a–c may be built to only support the capabilities from its respective platform 220a–c, creating one-to-one integrations between each pair of platforms 220a–c.

[0114] Referring back to FIG.1B, a schema-driven semantic integration network 120 provides an alternative embodiment wherein rather than integrating each application 121 with every other application 121, each application 121 is only integrated once through a common data and capabilities model 125 (i.e., a sematic layer). In some embodiments, this semantic network of integration 120 may shift the integration paradigm away from trying to integrate each application with other applications, and towards integrating each application through a relevant ontology or ontologies (e.g., the common data and capabilities model 125) that represent the necessary data types and software capabilities. In this embodiment, each application 121 may still expose a programmatic interface (e.g., an API) that facilitates integration.

[0115] Further, a developer may choose to translate the data and capabilities from at least two applications 121 into or through a common—or “standard”—ontology rather than trying to build an integration that translates the custom logic and data exposed via the programmatic interface of a first application 121 with the custom logic and data from a second application 121. In one illustrative embodiment, the semantic network of integration 120 may not require the data be stored in a standard ontology, but rather that it is translated through that standard ontology. In another embodiment, the semantic network of integration 120 may store a portion of the data in a standard ontology and translate another portion through the standard ontology.

[0116] This non-limiting alternative semantic network of integration 120 embodiment may encourage application developers to offer integrations to ontologies, rather than integrations to other applications. This semantic network of integration 120 may be more scalable as an application only has to be integrated once with a given ontology (and through it, connect to many different applications) rather than being integrated multiple times for every Page 15 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT other relevant application. It encourages building, using, and maintaining integrations “to” use cases and domain areas (through the related ontologies) rather than simply trying to directly integrate every application within those use cases and domain areas. For example, developers of a healthcare application might offer a single integration to the FHIR ontology rather than trying to integrate directly with every other application. In industries, like productivity, where a standard ontology has been more historically elusive, developers could offer integrations to a variety of different ontologies in order to meet various the needs of their users.

[0117] In alternate embodiments where the likiness of a perfect unified abstraction that can suit all needs is low, FIG.1C shows a schema-driven semantic mesh 140 that facilitates standardized integration of connections between various applications 141 using schemas. In this embodiment, schemas are used to represent the data and capabilities of each application 141 in their native formats without forcing all communication through common data model or “unified” semantic layer. This semantic mesh 145 allows both the use of connections with native data formats and endpoints through schemas well as interaction through a common data model or unified semantic layer. The schema-driven semantic mesh 145 facilitates the representation of interaction with the various native components (e.g., API endpoints, user interfaces, keyboard shortcuts, etc.) that make up applications 141 is provided in standard ways (e.g., using the schemas) regardless of the underlying technologies, APIs, and hardware systems, etc. It also facilitates the schema-driven representation of business logic, data transformations, governance and compliance policies, and more such that developers, users, and organizations can have a holistic understanding of their ecosystems.

[0118] FIG.3 illustrates a non-limiting embodiment of a data integration method 300 showing four different applications 310a–c and 350 that are semantically integrated through a standardized data Schema 330. Each application 310a, 310b, 310c, or 350 may choose to store and represent data in custom ways (e.g., according to custom Schemas). For instance, the developer(s) of application 310a may choose to represent to a user in a different way than how application 310b or application 310c represent users. Similarly, the developer(s) of application 350 may also choose to store a user’s data according to a custom Schema or representation that is different from the other applications 310, and also different than the standardized data Schema 330. In other words, each application 310a–c or 350 may use unique representations of user data that follows custom Schemas with custom fields and properties.

[0119] In this embodiment, the standardized data Schema 330 establishes standardized fields or properties for the necessary data types, such as user data type. In this non-limiting Page 16 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT example, these standardized data Schema 330 may be mapped, translated, and / or transformed with Mappings 320a–c to the custom Schemas for the integrated applications 310a–c. The business logic and associated processing for this embodiment may be invoked through application 350, which means that application 350 may use an interface 340 to call on data according to its standardized data Schema 330. The developers of application 350 may then determine the appropriate action to take with the returned data.

[0120] Referring back to FIG.2, the software architecture 250 shows yet another non- limiting alternative embodiment wherein the software architecture allows the multiple applications 260a–c to access data in a standardized way, according to a standardized data model. This software architecture 250 may use the various data integration methods described through in FIG.1B and FIG.3. Regardless of whether the data from applications 260a–c are consolidated in a standardized way, each application 260 may be able to access the data in a standardized way. In this way, the applications 260a–c may collectively provide data through a single interface, which may be considered an authoritative source of truth (the “ASOT”). More than offering a standard interface for data access, alternate embodiments may also offer standard ways of accessing software capabilities, interfaces, infrastructure, AI-models, and more.

[0121] Turning now to FIG.4, according to some embodiments, a standard knowledge language (“SKL”) framework 400 illustrates an embodiment wherein data and capabilities may be unified and shared across software applications 411a–j (e.g., applications, platforms, tools, extensions, etc.). By way of example, using the methods described herein, a user or an organization may establish a standardized and / or unified interface 450 to access all the data, capabilities, and software components they rely on. Applications 411a-j, like those from a user’s or an organization’s existing software stack 410, may be semantically integrated so that any software may independently interact with the data and software capabilities from the one or more of the various applications through a unified data and standardized and unified interface 450. In this way, the SKL framework 400 may provide a flexible methodology to transform a user’s or an organization’s fragmented software experience into a unified and parametrically configurable one that exposes all the relevant data and software capabilities pertaining to that user or organization. This, in turn, may allow the user or organization to easily build and manage custom automations 461, custom workflows 462, custom applications 463, custom extensions 464, and more. In other words, establishing a unified and standardized Page 17 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT access point to software components such as data and software capabilities may significantly improve a user’s or organization’s capacity to innovate.

[0122] Developers may use software development kits (“SDK”) or other code packages to connect data and capabilities from each unique codebase with data and capabilities from other external software platforms. For example, a developer creating a new custom software application might use Apple’s iOS® SDKs or Google’s Android® SDKs to help the software exchange information with and leverage the capabilities of each third-party platform. Similarly a developer building an app that needs to interact with external file storage systems like Dropbox® and Box® might add the SDK for each platform into the app’s codebase in order to facilitate interactions between the app’s data and capabilities and those from Dropbox® and Box®. These SDKs may facilitate the communication between the app’s codebase and the APIs offered by each platform, for example by including tools that handle HTTP requests, errors, and more.

[0123] In some configurations, the SKL framework 400 uses the SDKs, which may be written in a variety programming languages. Like the aforementioned SDKs (e.g., proprietary SDKs), a Standard SDK is a packaged collection of software development tools that may help developers connect their codebases with one or more external databases, software, platforms, etc. In one embodiment, the SKL framework 400 uses a Standard SDK to allow the developer to use one SDK to establish connections with a theoretically infinite number of external platforms rather than having to use a different SDK for each platform that the developer is trying to connect with however. However, in some configurations, the SKL framework 400 may use multiple software development kits.

[0124] In this configuration, developers need not rely on multiple different proprietary SDKs to offer core tools (e.g. that help handle HTTP requests, rate limits, errors, etc.), because a Standard SDK offers these as shared tooling that may be used to interact with many different external databases, platforms, APIs, etc. The differences between and across various external platforms APIs and / or their respective SDKs are represented through easily manageable configurations according to the SKL framework 400, such as Mappings from various data representations to a standardized data model. This may remove a significant amount of complexity from a codebase as well as the need for a given codebase to use many different SDKs. Moreover, because the customization necessary for a Standard SDK to support different platforms and use-cases is largely stored as configurations (e.g., the flexible and dynamic Schemas mentioned herein), these customizations may be shared across different applications Page 18 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT and various Standard SDKs written in different programming languages (e.g., Standard SDK in JavaScript®, Standard SDK in Rust®, etc.).

[0125] The Schemas and configurations, for example, may be used to describe external databases, APIs, platform capabilities, etc. in a way that a Standard SDK may understand them. The Schemas and configurations may also be used to describe a codebase’s data model and capabilities, as well as Mappings and translations between external platforms’ data and capabilities models and those within the codebase using a Standard SDK.

[0126] Turning to FIG. 4, the SKL framework 400 is now described in various non- limiting embodiments herein to illustrate various alternative Schemas and configurations wherein a Standard SDK may be used.

[0127] A conceptual example aids in the understanding of the SKL framework: a developer 502 is building a workplace chat software application that brings teams together and empowers them deliver work more efficiently in an asynchronous way. The app does this by helping team members organize their communication into conversations with a dedicated purpose (e.g., a channel dedicated to a given project). Naturally, its users end up sharing and discussing relevant information, links to research, docs, presentations, and more with each other through the chat application.

[0128] Currently, when the users share a link to a file or a task with someone, the app has no way of knowing if the person the user sent the link to actually has access to the file or task. The sender of that link has no way of checking or controlling whether the receiver of the link may access its contents without leaving the app. The receiver often has to check their email for sharing notifications, which reduces the value of the app. Overall, this process may result in some back and forth between the sender and receiver trying to coordinate the shared element’s permissions, which leads to lost productivity for the app’s users, and which may ultimately hurt the app’s chances at success in the market. The developer decides that a better, more integrated solution, is one that automatically checks the permissions of the shared element when a user sends it. If the app identifies that the receiver does not have access to the shared element, then the application immediately prompts the sender about modifying the permissions accordingly within its interface. In this way the sender and the receiver save time in achieving the desired result, the application is appreciated for streamlining that process, and the value of consolidating all related work in a contextual conversation is achieved. Page 19 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0129] Solution Method 1—Solve the problem without the SKL framework 400 of FIG.4 (in conjunction with FIGS.5-6).

[0130] As the developer 502 plans for how to build this with their available resources, they likely need to decide which integrations are the most valuable and which to prioritize. They start to evaluate which tools are most prevalent amongst their users and identify Dropbox® 504 and Asana® 506 as the top two, so they decide to build those integrations first.

[0131] Their immediate next step is likely to look through the API documentation 514, 516 for each tool in order to understand if and how they support the functionality they want to offer. They find that Dropbox® 504 provides unique API endpoints with custom arguments to manage permissions and sharing, and that Asana® 506 similarly has its own custom API endpoints and formats. Ultimately, they confirm that the platforms both support the functionality they want, albeit in different ways.

[0132] As the developer 502 moves past research into planning and execution, they likely start to write out the logic 604, 606 for potential functions and processes in the app’s code that may call the respective endpoints for each of these APIs. They look for and install SDKs for Asana® and Dropbox® that match the programming language the app is written in and start building out some methods to test. They try to architect their system with maximum modularity, but ultimately end up having to create different functions that call the respective SDKs and / or APIs for each integration they want to support. Finally, they have to test that each of these functions works well and debug each until it performs as desired.

[0133] Developer 502 of FIG.5 then is ready to release their first two integrations, and the users enjoy the results. The users ask the developer to do the same type of integration for twenty other apps. The developer quickly realizes that their success has created a lot more work and they go back to thinking about how to build the next ones. Looking back, the developer recognizes how much more time integrating the first two took than they would have liked. In many cases, this process is measured in weeks or months (or even years in particular circumstances) from the start of research, through planning, execution, testing, and the final production-ready release. As the developer moves on to the next integrations they hope the process is faster and simpler than before, however, they still need to research each new tool’s API and find SDKs that exist in their programming language, create new functions that call the SDKs or APIs in order to achieve a desired result, test them, maintain them, and so on. Page 20 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0134] Solution Method 2—Solve the problem with the SKL framework 400 of FIG. 4 (in conjunction with FIGS.7-8).

[0135] Turning now to FIG. 7, the moment that the developer 702 decides they want their users to be able to share work elements from other tools within the app’s interface, they could instead decide to use the SKL framework 704 to integrate the various applications. Instead of choosing a few specific tools to build their first integrations with and researching each of their third-party APIs, now they simply have to install a Standard SDK and either find existing or create new Schemas that the Standard SDK may use to connect the codebase with the various external platforms.

[0136] In this case, the developer 702 wants their users to be able to “share” work elements from other platforms within the app, so they either find Schema 706, either existing (e.g., publicly available) or create their own to represent the “sharing” capability they want their app to support. Similarly the developer will add other Schemas (e.g., OpenAPI and OpenRPC Schemas) to the codebase that represent the APIs of the various platforms they want to integrate as well as Mappings that relate the “sharing” Schema with the capabilities in the various platform APIs.

[0137] By using the SKL framework 704, the developer 702 is then able to reference the “share” capability directly within their code. This means that they do not have to write out any unique code or logic for each third-party integration. Furthermore, the app’s code does not need to have any custom code that deals with third party SDKs or APIs. Instead, the developer is now able to build all the application logic over the “share” capability represented through the Schema, which abstracts and standardizes the capabilities from a potentially infinite number of unique third-party “sharing” endpoints.

[0138] FIG.8 further illustrates the extended benefits of SKL framework 704 of FIG. 7. Now no custom logic has to be rewritten as code every time a developer wants build a new integration. All that remains to be done is find or create a Mapping between the Schema for “share” and the sharing endpoint for each desired external platform’s API. This enables the developer to now build each of their next twenty integrations in a matter of minutes or hours, rather than weeks or months. Moreover, because the “sharing” capability and the Mappings are represented as Schema and are therefore defined through configuration rather than some specific programming language, they are able to be shared across projects written in different programming languages (e.g., Python or JavaScript). Page 21 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT DESCRIPTIONS OF TERMS AND CONCEPTS

[0139] In some non-limiting embodiments, standard knowledge language (“SKL”) may define a protocol that empowers data sovereignty, software interoperability, and end- users’ capacity to create and innovate through software. It may facilitate the abstraction of software into components and create a standard for semantic connection between software components and data. Through these abstractions, SKL may empower developers and end users to more easily create combine, customize, and maintain software components in order to build solutions that are tailored to their unique needs. Moreover, SKL may provide a way for developers and end-users to have more control of their data by storing data locally, on a cloud, or on other infrastructure of their choice. More than data, applications may also be deployed in a decentralized way as SKL enables anyone to contribute components (e.g., ontologies, interfaces, data stores, etc.) to the ecosystem, as well as develop components for use in private ecosystems. SCHEMAS

[0140] According to some embodiments, the abstractions in an SKL framework that make up the components may be called Schemas. A “Schema” in a SKL framework may define the composition and configuration of a data type, software capability, interface component, Mapping, cron schedule, OpenAPI specification, and / or some other aspect of SKL-powered software function. SKL Schemas may be compatible with existing technologies such as the W3C Semantic Web technology stack (RDF / OWL / SPARQL) and existing libraries / dictionaries like Schema.org and FHIR that represent rich and complex knowledge about things, groups of things, and relations between things. Schemas in SKL may inherit from other Schemas. Schemas may be stored in a variety of ways such as, but not limited to, one or more files in a codebase, a set of triples in a graph database, one or more rows in a relational database, and data in decentralized blockchains or other networks. Schemas may similarly be accessed and / or referenced in a variety of different ways, including REST APIs, GraphQL APIs, SQL queries, SPARQL queries, and more. ENTITIES

[0141] According to some embodiments, an “Entity” may be an instance of data conforming to a Schema, often corresponding to a thing or capability in the real world. Like Schemas, Entities may be stored in a multitude of ways, including one or more rows in a relational database, in multiple triples in a single RDF store, in multiple triples across multiple databases, and so on. Page 22 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT UNIQUE IDS

[0142] According to some embodiments, a SKL may support the demarcation of certain properties on an Entity as identifiers, including but not limited to uniform resource identifiers (“URIs”), contextually unique entity identifiers (“CueID”), universally unique entity identifiers (“Unique IDs” or “UIDs”), or universally unique identifiers (“UUIDs”). SKL Schemas may use these various identifiers extensively to access and / or compare Entities. Identifiers like CueIDs and UIDs may be used to de-duplicate Entities.

[0143] A CueID may be used to identify the uniqueness of a given Entity within a certain context. For example, if a given database contains two different Entities that represent the same thing and a user manually confirms that the two Entities are instances of same thing, then the two Entities may be given the same CueID (e.g., the URI of an Entity of type DEDUPLICATED ENTITY). In some embodiments, CueIDs may be automatically generated (e.g., through the creation of Relevance Scores). SKL may allow for a certain tolerance of uncertainty in determining the uniqueness of an Entity in order to create or use a corresponding CueIDs.

[0144] In some embodiments, a UID may be used to identify the uniqueness of a given Entity across all contexts. For example, take two entities that represent the same thing yet exist on two independent systems. If those entities are processed by a third system using SKL to generate UIDs, then they may each be given the same UID and subsequently identified as duplicates. Certain software processes may be used to generate UIDs for given Entities so that they may be compared across all contexts in which an Entity might exist (e.g., a SHA-3 hash for file contents, feature vectors built with the data within and / or related to an Entity, etc.). In an alternative embodiment, certain properties on a given Entity may be used to establish a UID (e.g., a social security number for Entities of type PERSON).

[0145] SKL Schemas may be used to indicate which fields may be used as UIDs with given types of data. Using the methods described elsewhere herein, the configuration necessary to do so may vbe recorded in any number of ways. For example, a PERSON data type could have a property that lists what fields are UIDs for PERSON Entities. In a separate example, a PROPERTYIDENTIFIER data type could be established. The Schema for the PROPERTYINDETIFIERdata type could specify that it is composed of the following properties: a URI, a SchemaEntity, aproperty, and an IDENTIFIERTYPE. An Entity of type PROPERTYIDENTIFIER could be instantiatedas follows: URI = HTTPS: / / EXAMPLE.COM / PERSONSOCIALISPROPERTYUID Page 23 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT SCHEMAENTITY = PERSON PROPERTY = SOCIALSECURITYNUMBER IDENTIFIERTYPE = UID.

[0146] This https: / / example.com / personSocialIsPropertyUID Entity could then be used by a software process (e.g., “Verb” as defined below) that looks for UIDs associated with given types of data (e.g., “Nouns” as defined below) in order to deduplicate the Entities of those types.

[0147] Schemas and Entities in the SKL may have URIs, including Nouns, Verbs, Integrations, SKDSs, Events, Code Packages, and the like (these terms are defined below). This increases the ability of SKL’s linked data structure to semantically track provenance of data and the activity of users. Moreover, Interfaces may query and display any information associated with a given URI. For example, an Interface displaying the profile of a PATIENTEntity (according to FHIR ontology), may also display other information associated with thatpatient Entity’s URI, including activity Events, related DOCTORS, MEDICATIONS, and so on.Similarly, provenance and activity may be queried and used by a software process to generate insights about data, deduplicate data from different Data Sources, or alert users of abnormal data or behaviors by their collaborators. RELEVANCE SCORES

[0148] According to some embodiments, a SKL may use “Relevance Scores” to establish likeliness of relatedness between any two Entities. Relevance Scores (sometimes referred to herein as confidence scores) may be used to de-duplicate data and Entities, to establish a likelihood that a given classification may be added to data, capabilities, and / or relationships between Entities, and for other reasons. There are many methods that may be used to establish Relevance Scores and that may be used for a variety of different use cases. Any pair of Entities may have one or more Relevance Scores that may be calculated in any number and / or combination of ways.

[0149] Non-limiting embodiments of methods to calculate Relevance Scores are described briefly here. Unique feature vectors of n-dimensions may be created for each Entity and the underlying data, properties, and relationships in order to compare them by, for example, calculating the L2 distance (Euclidean distance), cosine similarity, and inner product (dot product). Jaccard similarity coefficients may also be calculated to measure the similarity between two Entities and compare their underlying data, properties, and relationships. Pearson correlation coefficients may also be calculated in order to measure the linear correlation Page 24 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT between two Entities and compare their underlying data, properties, and relationships. Machine-learning, computer vision, and / or natural language processing algorithms may also be used to train models that may establish one or more Relevance Scores between two Entities.

[0150] These and other various embodiments may use the data associated with an Entity to create CueIDs and / or UIDs, including but not limited to the Entities’ properties, contents, related Entities, related activity and interaction data, related provenance data, etc. NOUNS

[0151] According to some embodiments, Nouns may define the Metadata fields and properties which Entities that follow that Noun’s Schema may include. These properties may include Primitives and relationships to other Nouns. “Primitives” include the standard primitives in most programming languages: NUMBER, BOOLEAN, STRING, ARRAY, etc. Relationships may be of any cardinality (one-to-one, one-to-many, or many-to-many), though they will likely be labeled (making cardinality obsolete) because implementations of persistence in SKL software may often be built using a graph model.

[0152] In yet another embodiment, a Noun may provide a “standardized” representation of a type of data structure used by one or more software tools (e.g., FILE, PERSON, TASK, PATIENT, etc.). Nouns may allow for those data types to be used by a Standard SDK. Many software tools use data structures with the same name but with slight differences. The data source Facebook® has a variety of different data types (e.g., PERSON, EVENT, PRODUCT, VIDEO, IMAGE, MESSAGE). Other versions of these data types may also be found in other data sources. Some version of the PERSON data type also exists in Gmail®, Dropbox®, LinkedIn®, Salesforce®, etc., as contacts, sender, user, social profiles, and more. Nouns may be used to represent the unique data representations from each data source, as well as to establish standardized data representations that facilitate the data access and manipulation across software tools.

[0153] In one non-limiting embodiment, Google Drive® and Dropbox® each use their own data structure FILE to represent files. Two copies of the exact same file that are stored in each service are likely to be stored, represented, and accessed differently across the two services. While Nouns may be used to represent the unique ways that FILE data types are represented in both tools, they also enable the creation of a standardized representation of a FILE data type which acts as a sort of shared middle ground that developers may write code to interact with. In other words, a standardized FILE Noun may be used by a developer along with Page 25 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT Mappings to each software tool’s unique data structures, and / or the interfaces that expose them, so that the developer may not have to integrate with and build custom logic for different representations of files provided by the two data sources. A standardized Noun may have fields that are not supported by every tool. For example, a FILE on a hard drive might not have sharing permissions, whereas a FILE on OneDrive® might. Both may be mapped to a standardized FILE Noun.

[0154] According to some embodiments, Nouns may be extendable and customizable, allowing developers to add or change data types and fields according to their unique needs. For example, a developer might start using the FHIR ontology and the representation of PATIENT it offers when building a custom application. This developer might realize that their custom application may need additional fields that FHIR does not offer. Using SKL, the developer may create a “fork” of the FHIR PATIENT Noun, in order to make whichever changes or add whichever fields they need for their use case. SKL’s Schema manager may automatically create and manage the Mapping of fields between the Schema for FHIR PATIENT and the developer’s custom PATIENT Schema. In this way, the developer may customize and extend Schemas without losing interoperability with other components that have been mapped to FHIR PATIENT.

[0155] As mentioned herein, in some embodiments, Nouns may have relationships with other Nouns. For example, one Noun may be a sub-type of another Noun, causing it to inherit properties and other attributes from their parent Noun or Nouns. Any particular Entity (e.g., an image of George Washington with a mountain in the background) may be associated multiple types of Nouns (e.g., FILE, PNG, embedded PERSON, and embedded MOUNTAIN). This means that the image Entity may contain or access properties and attributes from the various Nouns that are associated with it according the Schemas available. In this example, SKL may provide a way for the image Entity to add properties from the various associated Nouns, as well as make it easy to access actions and / or software processes (a.k.a. “Verbs” as defined below) associated with various related Nouns. For instance, the IMAGE Noun could help software applications automatically provide the image Entity with related capabilities such as COPY, RENAME, IMAGEOBJECTRECOGNITION, etc., and the PERSON Noun could help provide capabilities such as RUNFACIALRECOGNTION, CALL, etc.

[0156] Because a PERSON Noun may have been identified in the image Entity, SKL is able to help the application easily configure a process that automatically uses the RUNFACIALRECOGNITION capability on the image, thereby creating a Unique ID or CueID in Page 26 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT order to link the image with a corresponding person Entity (e.g., an Entity of type PERSON for George Washington). In turn, linking the image with the George Washington Entity may establish connections to the data and capabilities that the George Washington Entity has associated with it. This means that the application could provide capabilities such as CALL or MESSAGE George Washington. Similarly, if the there is a process that may be used to identify a location based on the image of the mountain in the background, then the application may offer capabilities such as GETDIRECTIONS, GETWEATHER, and the like. VERBS

[0157] According to some embodiments, the types of Schemas that define extensible, and often standardized, abstractions of software capabilities in SKL may be called “Verbs.” In other words, a “Verb” may provide a “standardized” representation of a certain software process or capability offered by one or more software tools (e.g., SHARE, SEND, DOWNLOAD, LIKE, SUMMARIZETEXT, GENERATEIMAGE, etc.). Verbs may allow for those capabilities to be used by a Standard SDK. Like their unique data structures, many software tools expose similar capabilities that vary slightly in their inputs, outputs, and execution methods, even though they may have the same meaning or eventual effect.

[0158] A task management platform such as Asana® is likely to offer capabilities such as create task, assign task, and share project. Other software tools may also offer similar functionality, and expose those capabilities in very different ways. For example, the SHARE capability also exists in Egnyte®, Medium®, Polymail®, etc. However, the sharing that each of these tools offers may correspond to different data types, have different options for controlling permissions, and more. Verbs may be used to represent each software’s unique capabilities, as well as to establish standardized representations for capabilities that may be used in conjunction with other Schema and configurations, such as Mappings, to be able to access capabilities across software tools.

[0159] In some embodiments, Verbs may use, act on, and process data (e.g., provided as Nouns or primitives), their relationships, and provenance in standardized ways. They may create a simplified way through which developers may use the capabilities of multiple software tools and services without having to know the distinct requirements of each. Verbs may be configured to be run at a specific time, upon a specific schedule, or in response to specific events, for example in response to an event from a webhook registered with the API of an Integration. Verbs may be composed together to form larger processes or other Verbs. Page 27 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0160] The Schema for a particular Noun may include configuration that specifies relevant Verbs for Entities of that data type. In some embodiments, certain Verbs may be listed under a DEFAULTACTIONS property for Entities of a given Noun. In this scenario the Schema for that type of Noun would define DEFAULTACTIONS.

[0161] For example, the Schema for a person Noun might define:

[0162] DEFAULTACTIONS = HTTPS: / / STANDARDKNOWLEDGE.COM / VERBS / CALL, HTTPS: / / STANDARDKNOWLEDGE.COM / VERBS / MESSAGE.

[0163] An application which uses that PERSON Noun may therefore easily provide the capabilities that correspond to the default Verbs listed on the Schema of that Noun. An application may also provide other capabilities that are not listed as DEFAULTACTIONS for in the Schema of that Noun. For example, the developer of the application could create custom functions that could be mapped to Verbs. The developer might choose do so in order to increase composability, and to facilitate the reuse of software functions across applications and use cases. In this way, that developer could upload their Verbs to a library and be able to semantically and contextually find them, and use them, at a future point in time.

[0164] In yet other embodiments, the Verbs available to an application using a Standard SDK (defined below), or to an end user of such an application, may be defined via Schemas. Each Verb Schema may define Metadata about the Verb such as its name and description, as well as its standard inputs and outputs. In addition to a Verb Schema, a Mapping (defined below) Schema may determine what will happen when a Verb is called, how the Verb’s standard inputs will be translated into the inputs of the specific implementation referenced by the Mapping, and how that implementation’s output will be translated into the standard outputs of the Verb.

[0165] Non-limiting examples of what may happen when a Verb is called include: one or more web requests are sent to an external server in the form of: (i) HTTP requests to an API such as a REST API or GraphQL API, or (ii) a Remote Procedure Call (RPC) such as JSON RPC; the execution of one or more functions or methods from a code package either: (i) included in the server, container, or other accessible infrastructure of the Standard SDK in any way, including as one or more files, as a variable stored in memory of a running software program which Standard SDK has access to, etc., (ii) downloaded from a remote address; or Page 28 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT one or more queries are sent to a database for example using a JDBC Driver, ODBC driver, or other connection manager or protocol which a database communicates with.

[0166] In an embodiment represented herein, Verbs may trigger processes that run on a different server, or a different network address, than the server, container, or infrastructure running Standard SDK. For example, there may be a process running on a server separate from the application that invoked a Verb which is built to run background jobs to parse the contents of files. In such a case, a Mapping may be used to specify how to translate the Verb and its inputs into the IP address, endpoints, and parameters to send in the form of a web request to the external service. The Mapping also may specify how to translate the response of the web request into the expected standard output of the Verb. In some embodiments, to perform these translations, SKL defines Integrations as an abstraction of tools, services, or data sources running externally to the application that invokes a Verb, such as the integrations discussed herein.

[0167] In an embodiment represented herein, Verbs may trigger the execution of code that is run within the same application, server, container, infrastructure, or environment as the application that invokes the Verb. This code may be run in either the same or a separate process or thread than the one which invoked the Verb. For example, a Mapping associated with a Verb may specify a translation in the RDF Mapping Language (see RML) which includes one or more functions to execute and as well as their parameters, identified via URIs. When the Verb is called, a Standard SDK may use an RML Mapping Engine, implemented in a specific programming language, to execute the RML Mapping.

[0168] The application or program running the Standard SDK may either supply the implementations of the functions identified via URI to the RML Mapping Engine, or they may be pre-packaged with the RML Mapping Engine. In another example, an SKL Mapping associated with a Verb being invoked, may specify one or more functions or methods exposed by a package of code to execute. In some embodiments, SKL may define an abstraction called a Code Package to represent these packages of code and the functions and methods they expose in a standard way (see Code Package). Code Packages may specify their required environments and dependencies and may only be used by an application, server, container, or other infrastructure running a Standard SDK if it adheres to those requirements.

[0169] In an embodiment represented herein, and illustrated in FIG. 9, Verbs may trigger one or more queries to be sent to one or more databases. In one such embodiment, there Page 29 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT may be an SKL Schema which serves as an abstraction of queries to the database. For example, the abstraction might include an operation called “getUsers.” This operation could be mapped to a hard-coded query to a database to select a subset of fields from all records in the “users” table of the database. This abstracted operation could be listed along with any expected parameters and / or return values. Alternatively, there may be an SKL Schema which serves as an abstraction on the structure of the database(s) so that queries may be submitted to the database(s) in a domain model more familiar with a developer. To do so, a Standard SDK might use a Virtual Database 902 technology which, when queried, federates requests to multiple databases and / or multiple tables of those databases to construct a complete response in the format of the domain model. Such a Virtual Database 902 may be used not only to federate queries to multiple databases but also to one or more web APIs 704a–c (e.g., REST, GraphQL, etc.), or files (e.g., JSON, CSV, etc.).

[0170] Verbs may also use as input a collection of Entities of one or more types of Nouns. For example, the Verb to send a file may require an Entity of type file to be sent, along with a list of one or more Entities of type person. Instead of using the full object representation of a piece of data, the Action could use an identifier or unique identifier to match the input with an existing node / record in the Data Store (e.g., a person’s name, email, phone number, etc.

[0171] Verbs may also be configured to be contextually aware of the execution environments they work in and do not work in. For example, when working with cloud-based file storage tools, a download button may appear viewing a file. However, if a user of SKL uses a SKApp running locally on their computer, they may interact with local APIs like their computer’s local file system API. Thus, the DOWNLOAD Verb may not be relevant and may not be displayed by an Interface querying for data with that local SKApp. AI PROCESSOR

[0172] According to some embodiments, Verbs may have a Mapping to an Integration or Code Package that runs some algorithm over input data to produce new or updates to data stored as Nouns or to relationships between data. Non limiting examples include: 1. an image recognition algorithm which accepts raw images and data of the Noun Person as input, processes them, identifies that there are people in the image, runs facial recognition to identify who the people are, and returns relationships between the images and the respective Person Noun entities; and Page 30 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT 2. a named entity recognition algorithm that may locate and classify named entities mentioned in unstructured text through identifiers for Nouns such as person names, organizations, locations, medical codes, ISBN numbers, etc. Primitives and other data could also be identified and returned to be used to query and SKDS for relationships, such as time expressions, quantities, monetary values, percentages, etc. DATA ENCRYPTION

[0173] According to some embodiments, Verbs may have a Mapping to an Integration or Code Package, which runs an encryption algorithm over input data to encrypt or decrypt data. INTEGRATIONS

[0174] According to some embodiments, an “Integration” may be a type of Schema, and more specifically, a type of Noun that may represent the data, capabilities, and other aspects of an external software tool, application, platform, database, and the like. Integrations may represent software tools which may have data and capabilities accessible via an interface (e.g., REST, GraphQL, JSON RPC, OData, SQL, ODBC, etc.) that a Standard SDK may communicate with to query for, mutate, receive messages about, or otherwise access or perform actions over data.

[0175] In some embodiments, Integrations may provide data and events through an interface which may be accessed via a program or code in any code execution environment, not just the standard format of JSON APIs exposed by many popular web applications. The Schema that defines an Integration may, for example, detail the following: 1. Metadata about the Integration such as Name, domain, keyboard shortcuts, etc.; 2. descriptions of methods and their parameters which may be used to read raw data from the Integration; 3. descriptions of methods and their parameters which may be used to write data to the Integration; and 4. descriptions of methods which emit Events that an application may subscribe to.

[0176] According to some embodiments, the Schema for an Integration may reference, or is referenced by, a Schema that contains an abstraction of the API of the Integration. This Page 31 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT may make it easier and more concise for Mappings to reference the capabilities the Integration exposed and their inputs, outputs, required credentials, etc. Examples of these abstractions of the capabilities offered by an Integration’s API include OpenAPI specifications for REST APIs, OpenRPC specifications for JSON RPC APIs, and AsyncAPI specifications for event- driven APIs. If the integration offers other types of interfaces (e.g., SQL), similar abstractions of their data and capabilities may be represented through Schemas. A Mapping between a service such as Google Drive®, and the Verb download, may reference the operationID of the operation listed in an OpenAPI specification for Google Drive’s® REST API which represents the endpoint to download a file. Subsequently, Standard SDK may execute the Mappings for the parameters of the Verb and may properly use them to construct a web request that will be sent to the Google Drive® API according to the OpenAPI specification.

[0177] Non-limiting examples of types of Integrations are described herein.

[0178] First, web applications such as Google Drive®, Slack®, Gmail®, or Evernote®. These web applications commonly expose a JSON REST API with methods to read and write raw data from and to the application. Many also consist of web pages (e.g., drive.google.com) which contain data that may be scraped by a Data Processor using CSS selectors or Javascript code (e.g., Schema.org information, email addresses on the page, etc.). Google Drive® is a file storage tool which has a REST API exposing capabilities to upload, delete, edit sharing permissions, and manage versions of files and folders. MedFusion is a healthcare IT company which has REST APIs built according to the FHIR standards exposing patients’ medical data from John Hopkins Medicine;

[0179] Second, the scripts loaded by a browser extension or browser add-on. These scripts, particularly the background script or service worker, may access the Javascript Extension API. A browser extension could also use JavaScript to scrape data from websites a user visits.

[0180] Third, a computing device’s operating system such as macOS, iOS, Microsoft Windows, Linux, or Android. An operating system typically exposes APIs in order to allow programs running on the operating system to interact with the input devices, sensors, and storage and memory systems, on the device on behalf of the user / owner of the device (e.g., File system API, video and image processing APIs, etc.). There are many packages which developers may develop or use to interact with these APIs in a simplified or more abstracted way. The term computing device does not only mean smart phones, laptops, and desktop Page 32 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT personal computers, it may also be used to describe embedded systems or wearable computing devices such as virtual reality headsets, smart watches, or brain smayning devices. These other types of computing devices typically will gather some kind of biometric and / or environmental data and have an API for accessing that data through software on device or web requests. Sensors or trackers that provide access to a repository of data and recorded events (e.g., such as a digital camera with internal storage, or a heart monitor with internal storage)

[0181] Fourth, a program running on a computing device which has its own storage and / or processing and which exposes an API. Examples: (1) an application which records a user’s computer screen, stores the video, runs processing to label key moments in the video, indexes it, and provides an API to search and access those key moments; (2) A program which tracks and stores a log of web requests originating from the computing device and exposes and API for querying or accessing those logs; and (3) An application installed on a smart fridge that track’s the inventory of food within the fridge and exposes API to access the inventory data (via web request, Bluetooth, etc.).

[0182] Fifth, databases and data stores such as: Wikidata, World Bank Open Data, WHO (World Health Organization) — Open data repository, and European Union Open Data Portal.

[0183] Sixth, a blockchain such as the Ethereum blockchain. Data may be stored within Smart Contracts on a blockchain and read or written to using transactions. The data in a blockchain could also be indexed outside of the chain by systems like The Graph (https: / / thegraph.com / ), which expose APIs to query data. For example, Go Ethereum is an open-source execution client for the Ethereum Protocol which has a JSON-RPC API exposing capabilities to get information about blocks, send transactions, and much more. CODE PACKAGE

[0184] According to some embodiments, a Code Package may be a Schema that represent a package of code. Each Code Package Schema, like all other Schemas in SKL, may have a unique identifier in the form of a URI which allows it to be referenced in SKL. A Code Package Schema may serve as an abstraction of the interface that the Code Package exposes, similar to how an Integration has a Schema which abstracts its API so that its capabilities may be accessed and performed in a standard way using Verbs and Mappings. A Code Package may not be hosted or otherwise made available to SKL via some external interface. Instead, Code Packages may be run on the same server, container, or infrastructure that SKL is being used in. Page 33 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT The SKL engine or application running an SKL engine may either have the Code Package included in its environment as one or more files or as a variable stored in memory, or may download it from an external source during runtime. In the same way that a VERBINTEGRATIONMAPPING (further defined below) relates a Verb to an Integration, a VERBCODEMAPPING (further defined below) relates a Verb to a Code Package. Thus, a user of SKL may have the option to execute a certain Verb using either an Integration or a Code Package.

[0185] Non-limiting examples of types of Code Package Schema are described herein.

[0186] First, the execution environments that the Code Package may be run in. Non- limiting examples include: (1) an operating system running on a personal computing device, (2) a Virtual Machine such as the Java Virtual Machine or a JavaScript Engine, and (3) container running a specific image such as a Docker Image.

[0187] Second, the dependencies of the Code Package.

[0188] Third, specifications of the functions, methods, or variables which the Code Package exposes and the data types and formats of the inputs and outputs of those methods and functions. INTERFACES

[0189] According to some embodiments, an “Interface,” or “Interface Component” in SKL may be a type of Schema, and more specifically a type of Noun that represents a discrete component displayed on a webpage or other application with a graphical user interface, according to an embodiment. Interface Components may be to display, select, or edit particular types of Nouns to end users. Interface Components may be combined into sets, networks, or hierarchies to form a larger or more domain specific component (e.g., a Card component that includes a Table component specifically built to render previews of Excel spreadsheets).

[0190] Non-limiting examples of types of Interfaces are described herein.

[0191] First, an Interface may be the Schema representing a GUI and / or code of an application or program running on the operating system of a personal computing device.

[0192] Second, an Interface may be the Schema representing a GUI and / or code of a web application running in a web browser.

[0193] Third, an Interface may be the Schema representing a voice assistant software agent which may interpret human speech and run code in response to prompts or on a schedule. Page 34 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0194] Fourth, an Interface may be biometric tracking devices, which may be preprogrammed to respond to changes or events in their wearer’s biometric signals.

[0195] Fifth, an Interface may be software running in an augmented or virtual reality environment. For example, a HAT Entity in a VR environment could be associated with the Nouns 3DMODEL, OBJFILE, CLOTHING, and HAT. Its associations to those Nouns could make at least some of the Entity’s data accessible within, or at least translatable to different applications outside of the virtual reality environment, such as a spreadsheet, a file browser, a “clothing browser” (e.g., software that lets you browse and “try on” clothes with AR or mixed reality), etc. Similarly, the HAT could be understood as having certain distinguishing characteristics that could be described in a way that different virtual reality environments interpret and render differently.

[0196] The geometry could also be described via a mathematical representation that is not human readable / understandable (e.g., in a way similar to how an AI-based object recognition model represent HAT objects in order to recognize HATS in images), and it could use that representation to translate between different three-dimensional environments by first comparing other items in each environment and creating a mathematical model to represent the types of geometries that are acceptable in each environment. INTERFACE COMPONENTS

[0197] According to some embodiments, an SKL Interface Component may be a type of SKL Noun. Its SKL Schema may define the Metadata about the component and may either (a) define its implementation through declarative rules, or (b) link to its implementation defined in a specific package or repository of code. These interface components may be used to display, interact with, and / or edit data in any format, as long as an SKL Mapping(s) exist to translate between the data and the component.

[0198] In various embodiments, the Schema for an SKL Interface Component may include the following:

[0199] ID - the URI of the component (as is required by any named node within an RDF graph).

[0200] NAME (or label) - a textual label by which to refer to component.

[0201] DESCRIPTION - a textual description of the component. Page 35 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0202] PARAMETERS - a specification of the parameters that the component accepts. Each parameter should specify constraints if it is required or not, its data type, and its allowed cardinality.

[0203] PARAMETERSCONTEXT - a JSON-LD context object defining a more human readable format which each parameter may be supplied in if desired by application developers.

[0204] SOURCEURL - The location of the component’s source code (likely stored on a CDN or other blob storage like AWS S3). May or may not be used in conjunction with the nodes field.

[0205] NODES - An ordered list of nodes that declaratively configure a tree of UI building blocks to render, each with a type, styling, a tree of sub nodes, and an optional properties Mapping (More on this below). May or may not be used in conjunction with the sourceUrl field.

[0206] In some embodiments of the SKL Interface Components, the Schema for a component may need to specify information about the author, organization, and / or version of the component as additional fields. This information may also be incorporated within the URI that makes up the component’s id field.

[0207] Interface Components may be used to build interfaces using composable blocks without having to know exactly how those blocks work or what their contents are. An Interface Component may be nothing more than a representation and description of a component implemented in code using a language such as HTML or JavaScript®. Examples of JavaScript® components include those built using frameworks like React®, Vue®, Svelte®, etc. In such embodiments, the Schema for these components may a sourceUrl field to point to the location of an implementation of the described component. This location may be remote, meaning the component is hosted on a server, or local to the running application.

[0208] In addition to serving as a wrapper around components implemented in a specific programming language, Interface components which do not require complex logic defined through code may have their entire content specified through their Schema. SKL Interface Components Schemas may have a set of declarative configuration detailing the implementation of the component.

[0209] In some embodiments, this is done through the nodes field. The nodes field can contain an ordered list of nodes that declaratively configure a tree of UI building blocks to render, each with a type, styling, a tree of sub nodes, Examples of the UI building blocks this Page 36 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT field would use are line, box, text, and image. Many UI frameworks include a set of built in herein “primitives.” For example, HTML has a set of standard tags which are expected to be implemented in the same way by any HTML rendering engine such asherein”div,”herein”p,”herein”h1,” “h2,” etc. Likewise, SKL expects Interface Engines or applications doing their own interface rendering to implement a standard set of primitive interface components including but not limited to:

[0210] CONTAINER –defines a section which can contain a sub tree of other components herein.

[0211] TEXT - defines a block which contains a text which may be styled.

[0212] IMAGE - defines a block which displays an image through a source URL.

[0213] According to an embodiment, these primitive components can be composed as a tree of RDF nodes in RDF serialization. A non-limiting example may include the following code in JSON-LD (context omitted for brevity): { ... “https: / / skl.standard.storage / properties / nodes”: [ { “@type”: “https: / / skl.standard.storage / interface / Container”, “https: / / skl.standard.storage / properties / styling”: { ... }, “https: / / skl.standard.storage / properties / nodes”: [ { “@type”: “https: / / skl.standard.storage / interface / Text”, “https: / / skl.standard.storage / properties / styling”: { ... }, “https: / / skl.standard.storage / properties / propertiesMapping”: { “@type”: “rr:TriplesMap”, “rml:logicalSource”: { ... }, “rr:subjectMap”: { ... }, “rr:predicateObjectMap”: [ ... ] Page 37 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT }}... }

[0214] As shown herein, in addition to a tree of sub-nodes, a Node may include properties specifying styling, and a property Mapping. In this way, Interface Components can be an abstraction on certain structures and content which can be rendered by any (or most) application using that application’s framework of choice.

[0215] In some embodiments, the Schemas for Interface Components can define the types of data they expect as inputs, properties, or available variables or values. This makes it so that an end-user can easily choose an entity of any Noun and be able see data from that entity without having to have preexisting Mappings. For instance, if a Card component has two fields, specified to accept data of type image and string respectively, then the first occurrence of each of those types of data in the Schema of the Noun of the Entity passed to the Interface Engine can be automatically loaded into the Card Interface Component. Alternatively and / or additionally, an end-user may be able to choose and / or change the fields of the entity that are used by the Card Interface Component from a list of compatible fields from the Noun Schema of the Entity. INTERFACE ENGINE

[0216] According to some embodiments, interface components defined through configuration makes it so that the interfaces of applications may be controlled, configured, and customized without changing code. To enable this, a developer may use an SKL Interface Engine.

[0217] In some configurations, an SKL Interface Engine is a set of code, which takes as input (1) an SKL Interface Component Schema; (2) a set of data adhering to a specific SKL Noun to be rendered by that component; and, optionally, (3) the chosen theme styling to apply to the component. The Engine may then find and perform the Mappings necessary to translate the data, according to its Schema, into correctly formatted parameters for the component and Page 38 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT renders the component. In some embodiments, the Engine may update in real time if any changes are made to (1) the input data, (2) the chosen component, or (3) the supplied theme (among various other alternatives). Additionally, the Engine may have the ability to perform such real-time updates by re-rendering the applicable section of an HTML DOM tree after a component’s properties are changed.

[0218] In addition to supplying data to components, an SKL Interface Engine may need to supply callbacks, or bind event handlers to components in order to respond to user interaction with the components. According to some embodiments, there may be a general callback or bound event listener which may be used by any Interface Component rendered by an Engine. When a component calls the callback, or sends an event, the payload may include an identifier about the meaning of the event. Using this identifier, and the name of the component that executed the event or callback, the Engine may either find and perform a Mapping to translate the payload of the event or callback into a data format used by the application, or simply pass the payload as is to the application.

[0219] In yet another embodiment, there could be a pre-defined set of operations or “event types” which the SKL Interface Components may execute as callbacks or events to the Engine and / or embedding application. For example, this predefined set of operations may encompass all possible CRUD (Create, Read, Update, Destroy) operations on an individual, or collection, of SKL Entities or Schemas. As such, the components may offer the ability for users of applications to modify the entities in their SKDS through SKL Interface Components. This would also allow Interface Components to query for SKL entity data themselves.

[0220] In an alternate embodiment, the set of possible operations could include all the SKL Verbs a user or application has defined in its set of Schemas. This may allow SKL Interface Components to execute callbacks or send events with a payload containing the name of the Verb to be executed as well as the specified parameters for that Verb.

[0221] In an alternate embodiment, Engines or applications may define multiple “services,” “sets,” or “domains” of operations allowed. For example, such a scenario may allow Interface Components to use an “Entity” service to execute callbacks or events about CRUD operations on entities, and a “Verb” service to execute callbacks or events Mapping to SKL Verbs defined in a user or application’s Schemas. Page 39 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT MAPPINGS

[0222] According to some embodiments, the types of Schemas that define how a program may translate data, capabilities, and more between SKL components may be called “Mappings.” Mappings specify, for example, how a Noun may be translated to or from a unique data format specific to an Integration or an Interface, or how a Verb may be translated to or from a unique capability of a software tool.

[0223] In some embodiments, each Schema representing a Noun, Verb, Integration, Code Package, Interface, and / or SKDS may have embedded within it the logic and translations for how it relates to, uses, or produces every other artifact. Alternatively, Mappings defined separately from the Schemas, configurations, or code of Nouns, Verbs, Integrations, Code Packages, or Interfaces, users or developers may compose components of the system together. This setup makes it so that the internal implementation of each component may be edited and updated independently. For example, the developer of an Interface Component could change the structure of the HTML code, and any Nouns and Verbs that have been Mapped to that Interface Component are able to continue working seamlessly. No other developer would have to alter their code or configuration as long as their data is mapped to the standard PERSON Noun, which has one or more Mappings to the Interface Component’s inputs.

[0224] Mappings may be used to allow SKLs to interoperate. Each Mapping may consist of configurations specifying the name and type of the Mapping, and sets of declarative rules, code, or other logic that define how a data structure or API capability is transformed into another. In one embodiment, Mappings may scale across as many different programming languages and environments as possible. When written as code, either the Mappings may have to be manually translated into each programming language or infrastructure would have to be built to automatically compile them to each programming language (e.g., Javascript, Java, Python, etc.). Alternatively, Mappings may be written as declarative rules within JSON files, or other data-interchange formats or RDF serializations that may easily be translated to JSON (e.g., YAML, Terse RDF Triple Language (Turtle)). JSON is a data-interchange format that many programming languages may parse and generate. In this way, according to a non-limiting embodiment, people and systems may easily find related components and join them together. Mapping^Language^^

[0225] According to some embodiments, SKL may use the RDF Mapping Language (RML) serialized in the JSON-LD format to encode the logic of Mappings as declarative rules. Using RML, a Mapping may: (1) reference any field within an input dataset (including nested Page 40 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT data and iterations over lists); (2) use constant values such as strings, integers, booleans, etc.; and (3) use other ontologies including: (i) the Hydra Core Vocabulary (HYDRA) to load data from remote web APIs; (ii) D2RQ to access data in a remote database; and (iii) the Function Ontology (FNO) to execute control logic, conditional logic, and any other arbitrary function.

[0226] For example, in one non-limiting embodiment, when using or displaying files in their applications, many developers may want to know the mime type of the file, thus the Schema for a file Noun may include mimeType as a field. However, the Dropbox® API does not provide a mimeType field in its response when getting Metadata about a file stored in Dropbox®. Using an SKL Mapping which defines declarative rules and logic using RML and FNO, the Dropbox® representation of the file may be translated to be compliant with the file Noun’s Schema. The Mapping may get the file’s extension by referencing the Dropbox® file’s filename field within the input data and uses it as input to a getMIMEType function executed by an RML execution library written in Java. TYPES OF MAPPINGS

[0227] According to some embodiments, the SKL Library may include multiple types of Mappings for translating between different types of artifacts. Non-limiting examples of these include:

[0228] 1. NounDataMapping:

[0229] According to some embodiments, a NOUNDATAMAPPING may translates an Entity conforming to the Schema of a Noun into a unique data structure to be used as the input of an Integration capability, an Interface Component, or a Code Package, or it may translates a unique data structure output from an Integration capability, Interface Component, or Code Package, into the Schema of a Noun. NOUNDATAMAPPINGS may be used by VERBINTEGRATIONMAPPINGS by reference to avoid duplication of Mappings.

[0230] 2. OntologyMapping:

[0231] According to some embodiments, an ONTOLOGYMAPPING is type of NOUNDATAMAPPING that may describe how to map the Schema and structure of a different Linked Data ontology to an SKL conformant Schema (e.g., Noun or Verb).

[0232] 3. NounInterfaceMapping:

[0233] According to some embodiments, a NOUNINTERFACEMAPPING may translate an Entity conforming to the Schema of a Noun into a unique data structure to be used as the input Page 41 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT of an Interface Component. It may reference one or more NOUNDATAMAPPINGS. This type of Mapping may be executed using an Interface Engine and the response is used to render the component.

[0234] 4. VerbIntegrationMapping:

[0235] According to some embodiments, a VERBINTEGRATIONMAPPING may translate the inputs of a Verb to the unique inputs and correct capability (API endpoint, SDK function call, etc.) of an Integration to execute and perform the intent of the Verb using the Integration. The Mapping may also include a conversion of the outputs of the executed capability to the standard outputs of the Verb. It may reference one or more NOUNDATAMAPPINGS.

[0236] 5. VerbCodeMapping:

[0237] According to some embodiments, a VERBCODEMAPPING may translate the inputs of a Standard Verb to the unique inputs and execution format of a Code Package to execute and perform the intent of the Verb using the Code Package. The Mapping may also include a conversion of the outputs of the executed code to the standard outputs of the Verb. It may reference one or more NOUNDATAMAPPINGS.

[0238] 6. VerbNounMapping:

[0239] According to some embodiments, a VERBNOUNMAPPING may translate from one Verb into another Verb based on a Noun parameter supplied to the original verb called. For example, suppose a developer has created a Standard Knowledge Application which may sync data from any Integration a user has added to their SKL Schema. This syncer application may need to sync many types of Nouns such as FILES, MESSAGES, TASKS, etc. In some embodiments, the developer may have to write code to call specific Verbs to fetch each type of Noun in an Integration (e.g., GETFILESINFOLDER, GETMESSAGESININBOX, GETTASKS). In order to make their code more scalable, the developer may create a SYNC Verb which, when called with a noun parameter, uses a VERBNOUNMAPPING to determine a “noun-specific” Verb to execute. Thus, the developer writes one line of code through which many different types of data may be synced.

[0240] 7. VerbQueryLanguageMapping:

[0241] According to some embodiments, a VERBQUERYLANGUAGEMAPPING may translate the inputs of a Verb into a query in a database language and the outputs of the query Page 42 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT back to the standard outputs of the Verb. It may also reference one or more NOUNDATAMAPPINGS. SOLID

[0242] According to an embodiment, SKL’s decentralized ecosystem may adhere to the principles and interfaces defined in the Solid Protocol (https: / / solidproject.org / ). Solid is a specification that lets people store their data securely in decentralized data stores called “Solid Pods.”

[0243] The Solid specification defines how applications may access and manage data from user’s personal data stores, as summarized below:

[0244] First, Linked Data Solid supports storing Linked Data so that different applications may more easily work with the same data. Specifically, it uses the Linked Data Platform for accessing, updating, creating and deleting Linked Data resources.

[0245] Second, Solid-OIDC Authentication defines how the servers hosting personal data stores verify the identity of users and applications based on the authentication performed by an OpenID provider.

[0246] Third, Web Access Control Authorization is a decentralized cross-domain access control system providing a way for Linked Data systems to set authorization conditions on resources using access control lists.

[0247] Certain components of the SKL ecosystem may conform to Solid. According to an embodiment, Standard Knowledge Data Stores (“SKDS,” as defined below) are required to be compliant with Solid’s concept of personal data stores called “Solid Pods.” As such, implementations of SKDSs may implement Solid-OIDC, Web Access Control, and the Linked Data Platform. In this embodiment, Standard Knowledge Applications (“SKApp,” as defined below) are also compliant with Solid’s concept of “Solid Apps.” This means that any SKApp may expect to communicate with SKDSs using the Linked Data Platform and authenticate users using Solid-OIDC.

[0248] According to one non-limiting embodiment, the SKL specification may recommend that each user’s SKDS store its own Schemas. In this way, end users may customize and extend SKL as they see fit. When using SKL Verbs, a SKApp may use a Standard SDK and set the Standard SDK’s Schema source to the user’s SKDS. In one non- limiting embodiment, SKApps may use a Standard SDK to query an SKDS. As described elsewhere herein, a Standard SDK may use a variety of methods to interact with data (e.g., Page 43 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT create, read, update, and destroy) within an SKDS. The mediums for interaction with data in an SKDS may include the SKDS’s native query language such as SPARQL or GraphQL, as well as the Standard Knowledge Query Language (“SKQL” as defined below) which is in effect an Object-Relational Mapping tool. STANDARD KNOWLEDGE DATA STORES

[0249] According to some embodiments, a standard knowledge data store (“SKDS”) may be a nodal that is accessible to one or more users on one or more computing devices that may be manifested in any number of ways. For example, the nodal data structure may be represented as files on a user’s local computer, data on a blockchain, data in one or more relational databases, data in a graph database, data in a distributed database system, etc. In some embodiments, an SKDS may follow the specification for a Solid Pod. Accordingly, an SKDS may be more than a Solid Pod. It could have other manifestations, similar to the nodal data structure described herein.

[0250] A Standard Knowledge Data Store or “SKDS” may be a type of Integration that stores Entities, and in some embodiments, also stores the Schemas that make up the Nouns, Verbs, and Mappings and / or other SKL components on behalf of a developer, end-user, and / or system. SKDSs may be referred to herein as standard data stores, data stores, Standard Storage, knowledge pods, and nodal data structures.

[0251] In order to use SKL according to some embodiments, a developer must first decide where they will store the desired SKL Schemas, Mappings, and the code their application will work with as well their end users’ data, or how such artifacts will otherwise be accessed. One of the first decisions to make will be whether to use an SKL-compliant Standard Knowledge Data Store (SKDS), to store or reference the artifacts and configuration directly from other sources (e.g., schema.org, the SKL Dictionary as defined below, etc.), or to use their own method (hard-coding schemas into their code).

[0252] Any kind of information may be stored in an SKDS. Non-limiting examples of a data store that could serve as an SKDS include: (1) a server connected to the internet running a relational or graph database or a key-value store, (2) a web browser’s IndexedDB store, (3) a database running on a personal computing device, (4) and a decentralized blockchain or decentralized file storage system like IPFS. Depending on the type of data storage available, the method or mechanism an SKDS uses to store data can be manifested in a number of ways including, but not limited to, as files on a computer, server, or container, as data on a Page 44 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT blockchain, as data in one or more relational databases, graph databases, or key-value stores, as data stored by one or more machines in a distributed system, as data stored in memory by a program etc.

[0253] In some embodiments, an SKDS is similar to a secure personal web server for a user’s SKL nodal data structure. In this scenario, users control access to the data in their SKDS. Users may decide what data to share and with whom to share it (be it individuals, organizations, or applications). Access may be revoked at any time. To store and access data in an SKDS, applications use standard, open, and interoperable data formats and protocols. In one embodiment, the data creator may be in full control of their data as shown in FIG.2.

[0254] In some embodiments, a developer will have a predetermined set of SKL artifacts that they know their application will need. In such embodiments, the developer may download and bundle them along with their application’s code or download the artifacts via the SKL Library API at runtime, as their use case necessitates. This situation may not need an SKDS, though it may still use one for the application itself. In other embodiments, a developer may choose to let the decision be made by end users. An application could choose to store SKL artifacts on behalf of end users in any format they choose. For example, the developer may store all SKL artifacts in a MongoDB® database with a key specifying which end user they are used for.

[0255] In one non-limiting exemplary embodiment, several criteria of an SKDS may be defined to do the following: (1) be compatible with the world of Linked Data by exposing APIs that accept formats such as Resource Description Framework (RDF) as input, (2) allow end users to choose from a market of database providers for storage of their data, (3) have robust authorization over data such as access control lists on each resource (each end user may be able to share and revoke third-party access to their data), (4) be able to verify the identity of agents (users or applications) accessing or modifying data, and (5) allow for the validation of any data written to the SKDS according to SKL Schemas.

[0256] One embodiment of a system which fulfills these criteria may be built using the Solid Protocol. Solid is a secure, robust, and highly configurable decentralized storage system. Solid uses Solid OIDC, an authentication protocol built on top of OpenID Connect 1.0, which allows for secure authentication between storage providers, identity providers, and applications. It uses Web Access Control to implement authorization via access control lists. It also utilizes Linked Data and mandates usage of the Linked Data Platform as a standard Page 45 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT interface for reading and writing resources. Many implementations of the Solid Protocol are open source and architected in a way that makes it easy for developers to build off of, for example to add custom SKL Schema validation. Solid may also be seen as accessible to many developers because it does not specify constraints on the type of persistent storage used to store resources, developers may choose whatever works best for them. While Solid Protocol is used in this embodiment, it should be noted that the SKDS may be built using a variety of different methods.

[0257] In some embodiments, the specification of an SKDS need not to be compatible with Linked Data, and thus would not use Solid. Its REST APIs may be built to accept request bodies that are not a serialization of RDF such as JSON. In such embodiments, the embodiment may specify a distributed storage system—that uses the Oauth2.0 protocol, for example—for authorization between identity providers, storage providers, and applications.

[0258] In other embodiments, an SKDS may be a nodal data structure stored in a graph database hosted on a private cloud controlled by a private company. In this case, the SKDS would not necessarily implement the Solid specification but instead implement a proprietary interface unique to the company. According to the embodiment, any application, SKApp or not, would need to implement a data persistence strategy in accordance with the company’s SKDS specifications. In addition, the specificities of the company’s interfaces and security might make them unable to leverage open source Standard SDK and / or SKQL libraries.

[0259] In an alternate embodiment, an SKDS could be implemented using blockchain technologies. For example, there are several layer one chains that support smart contracts and that may be programmed such that only certain people are able to access and un-encrypt certain data stored on chain. This may, in a similar way to Solid, provide individuals with the ability to have more complete control over their data. In this scenario the SKDS could store its database on a chain in an encrypted way such that only a given user (or wallet) is able to control the data that is assigned to that wallet. The “owner” of such data could then choose to share any subset of their data with other users or wallets as desired. Furthermore, certain restrictions could be placed on data via a smart contract. For example, the data on chain could specify that it may only be accessed by components that meet certain qualifications, beyond simply other users, as described further herein in the operating environments section. Also similar to the Solid Protocol, a blockchain based system would also separate the user’s identity from the data and from the applications which access said data. Page 46 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0260] In yet other embodiments, a mixture of the examples described herein could be used, ranging from semantic blockchains, to a Solid-based system that uses a blockchain-based wallet for authentication, to an SKDS that stores assets using a distributed peer-to-peer storage solution like IPFS, and more.

[0261] In some configurations, an end user may not be able to use the developer’s application until they have installed or downloaded a specific SKL package or set of Schemas, Mappings and / or code. At least one embodiment includes an easy-to-use package for application developers to query and check against the user’s SKDS whether the user has all necessary SKL artifacts installed.

[0262] An SKDS may have column, property names, or relationship names which differ slightly from the popular ontologies such as FHIR and Schema.org. For these cases, SKL may include Mappings between the popular ontologies and their altered representations in the Schema of the data store.

[0263] Developers of SKApps may be able to switch persistent storage types without altering (or at least with minimal alterations) functionality, support for features, or data structures.

[0264] A Data Store (which in some embodiments may be called the nodal data structure) may be a location where standardized Data Types and their relationships are persisted. Non-limiting example of a system architecture and nodal data structures are illustrated in FIG.38, FIG.40, FIG.45, and FIG.46. SKDS enable developers of applications will be able to switch persistent storage types without altering, or at least with minimal alterations to functionality, support for features, or data structures.

[0265] According to a non-limiting embodiment, an SKDS can be comprised of multiple databases such as a vector database, a graph database, and / or a relational database. For example, an SKDS may include a first database for Entities related productivity data, a second database for Entities related to health data, and a third database for information related to activity by the SKDS’ user(s). In this case, the third database could include information about activity as shown in FIG. 56. The activity in this third database could follow Schemas related to activity (e.g., activityschema.com), could support activity spans (e.g., OpenTracing) to better track electronic content and electronic context, could track notifications sent from other sources, and more. In this way a single SKDS can be configured and optimized for a Page 47 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT variety of criteria ranging from security needs, performance needs, ease of analysis, to support privacy-conscious personalization and advertising capabilities, and more. STANDARD KNOWLEDGE QUERY LANGUAGE

[0266] According to some embodiments, Standard Knowledge Query Language (“SKQL”) may be an abstraction that standardizes the interaction with different types of databases by providing a single interface for operations that may be performed using various database query languages. It may be designed to facilitate object-oriented interactions, as this is a common requirement of most application developers who use persistent databases. It may be described as either an Object Relational Mapping (ORM) or Object Graph Mapping (OGM), depending on if it is being used to query a relational database or a graph database. However, it may not go so far as “Active Record” style ORMs in that it may not tie the database implementation to models or classes and their business logic. Instead, it may works with the data structures provided in Schemas. SKQL may expose methods for basic operations such as create, read, update, destroy (CRUD) on data according to the Schema or ontology that a user is using.

[0267] Instead of manually constructing and sending web requests to an SKDS to query or modify Schemas or user data, a developer may set the SKDS as the source of SKQL and specify valid authentication credentials for SKQL to use and it may automatically send requests to the SKDS when needed. For example, if a developer’s code needs to save a new blog post a user just submitted using a Standard Knowledge Application for blogging, the application code may call SKQL.save(blogPost) or blogPost.save(). Subsequently, SKQL may communicate with the user’s SKDS to save the blog post. If the user’s SKDS is a Solid Pod, SKQL may send a web request compliant with the Linked Data Platform with the body being an RDF representation of all the blog post’s attributes.

[0268] Given that SKQL may work with SKL Schemas, it may be extended by developers, systems, and / or end-users. For example, a Verb to move a file from one folder to another may use a specialized query to modify the file’s relationship to its old and new parent folder in a single request instead of using the standard operation to delete the old relationship and create the new one. Likewise, an application attempting to uncover insights from a data store may need to perform a complex path traversal query using the native query language of a graph database (e.g., Cypher, SPARQL, etc.) which could be preconfigured with Schema. SKQL may also expose special methods to write queries in the native query language of databases which users have chosen to use. Page 48 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0269] In some embodiments, SKL Schemas may be used by an Integrated Development Environment (IDE) while a developer is programming to perform type checking of fields, variables, functions, and methods accessed and used. SKQL could have its own programming language which may be compiled either as a developer programs or at build time to a more well supported target programming language such as Python, Java, or JavaScript— similar to how TypeScript is typically type checked by an IDE as a developer writes code and is compiled into JavaScript when they build and / or package their application.

[0270] While this would result in less composable and less interoperable components, in other embodiments, SKL Schemas could be represented as classes in a programming language like Ruby® or Java®, type interfaces and / or classes in JavaScript® or Typescript®, etc.

[0271] SKQL may allow for high composability of databases and SKDSs to the point where an end-user, system, or developer may “swap out” a database or SKDS of one type for another type. This also enables seamless replication of databases in any format and enables applications to easily offer multiple database options to users. Mappings may include translations from SKQL queries into various native query languages and / or web requests or other API requests to third-party tools according to the Schema of the target data source.

[0272] In addition to the basic translation of operations to database query languages, SKQL may also include a suite to manage a connection pool with each database.

[0273] Different database types may have differing levels of support for SKQL features. For example, users would only be able to add custom properties / relationships to their Schemas if their database supports that. A relational database may require a database migration to be able to support the additional properties or relationships, while a graph database or other NoSQL database could theoretically support any arbitrary property or relationship.

[0274] According to some embodiments, SKQL may be used to allow developers or users to “program,” or define, logic in near-natural language. This natural language may be parsed into one or more search elements and compiled into a series of commands to run against databases and / or data sources. In an alternate embodiment, SKQL could be used to automatically generate migrations for relational databases based on changes to SKL Schemas. In an alternate embodiment, SKQL could be used to automatically generate Mappings between SKL Schemas and the Schemas of the databases that store Entities. In an alternate embodiment, SKQL may expose the ability for developers to supply a raw query or web request and any Page 49 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT necessary connection details or credentials. In this case, SKQL would not do any transformation and would simply send the query or web request to a database. For example, SKQL could expose a sendSqlQuery function which, when supplied with a SQL query, database IP address, and credentials, will make the connection to the database, perform the query, and return the result. Similarly, SKQL could expose a function such as sendWebRequest, or fetch which would send a web request to a REST API based on a supplied endpoint / URL, required parameters or data, and necessary credentials. SKQL could then expose a function such as executeOpenApiOperation which takes as input an OpenApi operationID and the operation’s required and / or optional parameters and credentials. These SKQL functions would allow developers to access functionality and perform queries which fall outside the boundaries of the standard CRUD operations.

[0275] FIG.11 illustrates a system architectural diagram (computer infrastructure) of how an application 1110 can use SKQL to query (or otherwise interact with) an SKDS 1150, according to an embodiment. In this example, the application 1110 uses an SKQL Client Library 1111, which may be included as part of a Standard SDK, as an ORM and / or OGM that the application’s codebase 1112 can use to interact with the SKDS 1150.

[0276] The SKDS in this example could follow the Solid specification and send web requests according to the Linked Data Protocol 1152 to an SKDS 1150. In doing so, it would communicate about resources using the Resource Description Framework (RDF) 1120b. In this example, multiple and alternate means for the SKQL Client Library 1111 to communicate with the SKDS 1150 are presented. These mean Redis Commands 1120a, SPARQL 1120c, DQL or GraphQL 1120d. In each case, if any of these alternate communication formats are used, the SKDS 1150 may be required to implement an interface other than Linked Data Platform 1153. Regardless of communication format, the SKDS 1150 may perform authorization 1151 of the application making the request. In the case where the SKDS is conformant to the Solid specification, this authorization must be conformant to the Web Access Control specification. In some embodiments, the authorization step 1151 may require re- writing or re-building a query to include authorization information. This would likely happen if Redis Commands 1120a, SPARQL 1120c, DQL or GraphQL 1120d were used.

[0277] After re-writing a query to include authorization, the SKDS 1150 may translate the query into a format acceptable by its type or types of persistent storage. This example shows two examples of persistent storage used by the SKDS 1150, which may be used alone or in combination, a Redis key-value store 1190, and a Dgraph graph database 1180. In either case, Page 50 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT the chosen communication format in 1120 may be translated and sent to the persistent storage 1160. Examples of the translations that may be required include but are not limited to, from RDF to commands executed using a Redis Client Library 1160a to send to a Redis key-value store 1190, from RDF to DQL or GraphQL queries 1160b to send to a Dgraph database 1180, from SPARQL to DQL or GraphQL queries 1160b to send to a Dgraph database 1180, and from DQL to GraphQL or kept as DQL1160d to send to a Dgraph database 1180. Once the persistent store performs the request, any response may be translated back 1160 and returned to the Application’s code 1112 via the SKQL Client Library 1111. STANDARD KNOWLEDGE APPLICATIONS

[0278] According to some embodiments, a “Standard Knowledge Application” (also referred to herein as a “Knowledge App” or “SKApp”) is a software application, program, or any other set of code which downloads, bundles, or otherwise accesses SKL Schemas, configurations, and / or code and uses them to interact with Integrations, Code Packages, and / or Interface Components through a Standard SDK (e.g., Mapping the unique data structures and capabilities of those Integrations, Code Packages or Interfaces in and out of Noun and Verb Schemas according to the SKL protocol).

[0279] In some embodiments, a SKApp may be code which uses any aspect of the SKL framework to achieve a goal. The SKApp may be different from an Integration or Code Package because by not directly using any aspect of SKL internally; but is rather represented by SKL Schemas. In some embodiments, a SKApp may be represented by an SKL Schema, but it may also use SKL Schemas, Standard SDK, Standard UI, Standard API, etc. to perform its function.

[0280] Non-limiting examples of Standard Knowledge Applications include the following: (1) an application which integrates with other software using Standard SDK and / or SKL Schemas, (2) a script which uses Standard SDK and SKL Schemas to scrape data from websites, or (3) a mobile application which uses Schemas and an Interface Engine according to Standard UI to run it’s user facing GUI.

[0281] In some embodiments, a SKApp may store and access data in SKDSs using the SKL protocol and the Solid specification. In this way, instead of every application using a separate data silo that it independently controls, different SKApps may interact with the same data stored in a given user’s SKDSs. In other words, a user may give multiple SKApps access to read and / or write Schemas and data to / from a single SKDS. Page 51 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0282] In another embodiment, a SKApp may store and access data independently in its own database. In yet another embodiment, a SKApp may interact with data in multiple data stores, both public and private. In some embodiments the SKApp may be Solid compliant.

[0283] A data syncing application could be a non-limiting embodiment of a SKApp. This SKApp may periodically check for updates to, or subscribe to events about data in a data source, extract the new or updated data, standardize it according to the Schemas and then write those updates to a data store. Other non-limiting examples include the following: (1) an application that uses one or more servers to poll the Google Drive® API for changes to files and writes updates to a data store or (2) a Chrome extension that subscribes to web navigation events, classifies the corresponding website as a particular Noun, and writes data associated with that Noun to a data store.

[0284] A data-duplication application could also be an example of a SKApp. This SKApp may use data (e.g., Metadata, interaction data, etc.) from a data source in order to identify two or more Entities which represent the same data. For example, a data-duplication application may run code which calculates a unique hash with the contents of every file in a data source, in order to identify any duplicates. According to an embodiment, SKDSs could come pre-packaged with a data deduplication SKApp to help keep the data clean.

[0285] FIG.47 illustrates a conceptual diagram where two Entities 4701a and 4702b share similar properties and relationships 4701b and 4702b in the nodal data structure 4600, according to a non-limiting embodiment. In this case, one or more of the methods described above could be used to establish a relevance score 4705 between both Entities in order to automatically deduplicate them or otherwise establish a recommendation for deduplication. COORDINATOR

[0286] In some embodiments, certain types of SKApps may be referred to as Coordinators. A Coordinator is a SKApp, which executes the settings of a developer or end- user. These settings and configurations may include, for instance, which Nouns, Verbs, Integrations, SKDSs, SKApps, etc. a given user is using. The data a Coordinator uses may be stored in an SKDS, and could include configuration of Verbs that specify the times or the frequency at which they are meant to be run, as well as any events from external systems that the Coordinator should subscribe to and pass along to a Verb, such as an Integration’s webhook. Coordinators may be responsible for adhering to configurations that trigger Verbs to run at certain times. Coordinators may also responsible for maintaining connections to SKDSs which Page 52 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT may need to be read from or written to by a Verb or to fulfill a request from an Interface Component. In some embodiments, the Coordinator is included on the same server as an SKDSs. In other embodiments the Coordinator may exist as a Standard Knowledge Application or in part between one or more SKDSs and / or Standard Knowledge Applications.

[0287] FIG. 12 illustrates an architectural diagram of the ecosystem in which a User 1220 separately interacts with one or more Integrations 1200 and Standard Knowledge Applications 1210 and 1260 while a Coordinator 1240 executes code processes 1230 in the background on their behalf. The user 1220 can use the interface 1250 of one of their SKApps 1210 in order to set settings for the processes 1230 they want to be run over their data in any Integration 1200. These settings get stored in their SKDS 1270. Non-limiting examples of processes a SKApp include AI Processing to generate text or images from data 1230a, workflow automation to move or update information in one Integration from another 1230b, data syncing to create a knowledge base in their SKDS 1230c, and data deduplication across Integrations 1230d. In some embodiments, these processes may be controlled by a Coordinator 1240. The Coordinator 1240, reads the Schema, settings and other configuration chosen by the User 1220 from their SKDS 1270, then periodically upon a schedule, or upon certain events, or at a certain time, runs any applicable code process 1230 to fulfil the User’s 1220 settings. The user may also interact with other SKApps 1260 which do not have a Coordinator to run code processes in the background and only read or write data to or from one or more of a user’s SKDSs 1271 or 1270. Importantly, each piece in the architecture can communicate with others via SKL Nouns and Verbs using Standard SDK. For example, the data syncer code process 1230c can use Standard SDK to send queries for data to an Integration 1200. Likewise, the Coordinator 1240 or a code process 1230, can use SKQL to read or write Nouns or Schemas to or from an SKDS 1270. ANALYTICS SERVER

[0288] In some embodiments, an Analytics Server represents one or more computing devices which runs some aspect of the SKL ecosystem. As such, an Analytics Server may be made up of one or more computing devices such as a mobile phone, personal computer, virtual reality headset, server, blockchain infrastructure, browser, etc. Any of these pieces of hardware or environments may perform one or more operations that SKL defines including—but not limited to—the following: (1) running a SKApp that uses a Standard SDK to access data from an SKDS, (2) running an application that uses a Standard SDK to interact with an Integration, and (3) running an application that uses a Standard UI Engine to present and interface to a user, Page 53 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT be it graphical, auditory, haptic, etc. An example of a system architecture is provided in FIG. 37 that includes an analytics server. AUTHENTICATION SERVER

[0289] According to some embodiments, in SKL’s decentralized embodiment, it may provide end users with control over their data, and in other embodiments, separate entity and Schema storage from authentication. As such, an Authentication Server is a service, program, server, or other interface which a user designates as the authority for their identity. An Authorization Server is responsible for allowing a user to sign up and create, or have automatically generated for them, a unique identifier such as a WebID, email address, username, a cryptographically signed key, etc. The Authorization Server may pair a unique identifier with a method of authentication and provide whatever interfaces are necessary for the user to authenticate themselves. Examples of these authentication methods include, but are in no way limited to, OpenID Connect (OIDC), Solid OpenID Connect (Solid OIDC), Oauth2.0, Public Key authentication such as RSA and DSA, username and password, LDAP, Kerberos, SAML or RADIUS.

[0290] In the embodiment wherein SKApps and SKDSs are conformant to the Solid specification, any request to an SKDS from a SKApp may either respond with a link to the user’s Authorization Server if the request is unauthenticated or will verify the identity of the SKApp and / or end user based on the authentication performed by an Authorization Server. As such, an Authorization Server may be conformant to an OpenID Provider.

[0291] In order to authenticate users and provide an authorization code to a Solid Application, A Solid OpenID Provider may be required to have a web page wherein a user authenticates themselves. In such an embodiment, although a user is identified via a WebID and a WebID Profile document, the implementation of authentication of the user as that WebID may be up to the OpenID Provider. As such, the OpenID Provider could use, among other techniques, a username and password, public key authentication, Oauth2.0, etc. In this way, Solid OIDC and its WebIDs may serve as an Authorization wrapper for resources controlled by any Authentication method.

[0292] In other embodiments, an Authorization Server may consist of, or leverage third party or proprietary authentication services such as Okta® or Aikon.com to facilitate access to Data Sources. Page 54 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0293] In another embodiment, A Coordinator or SKDS running locally on a user’s computer may not need authentication for interactions between locally running SKApps since it is running on a machine that the user owns and which the SKApp is also running on. However, some users may require their SKDS to be encrypted and access to it to be password or key protected. According to some embodiments, local SKDS APIs will not need any authentication if operating on a system with proper user permissions. STANDARD SDK

[0294] According to some embodiments, a Standard SDK may be a code package that may simplify the developer experience when building an application. It may execute Verbs by using Mappings to translate between Nouns and Verbs and the APIs of Integrations (e.g., REST, SQL, etc.) or the functions and methods of Code Packages. Standard SDKs are sometimes referred to herein as “SKL Engines.”

[0295] According to one decentralized embodiment of SKL, wherein an application does not need to have preexisting knowledge of what Schemas (e.g., Noun, Verb, and Mappings) a user has installed, Standard SDKs may dynamically respond to a developer’s execution of a standard Verb. To do so, a Standard SDK may query for and read SKL Schemas from, for example, an SDKS. A Standard SDK may use SKQL as a convenient way to query for Schemas from a user’s SKDS using its simplified ORM style interface. Alternatively, a Standard SDK may not use SKQL and instead submit queries in the native query language of the user’s SKDS.

[0296] FIG. 13 is a conceptual diagram illustrating how an application may use a Standard SDK to interact with an Integration API, according to an embodiment. In this embodiment, an application 1310 needs to interact with an Integration API 1320 (e.g., to share a file, or otherwise change the permissions on a file hosted by the Integration). As described herein, the developer of application 1310 could choose to write custom code and logic to help interact with the custom functions provided by a proprietary SDK. Alternatively, as illustrated by SKL framework 1300, the developer may use a Standard SDK 1350, which has a standardized set of functions that facilitate interactions with a variety of Integration APIs and then use certain Schemas to determine exactly how to interact with a given Integration API 1320 in order to perform a certain operation, as represented by Verb 1301. The Standard SDK then uses the Verb 1301 and the corresponding Mapping or Mappings 1351 as configuration on its standardized functions in order to interact 1302 with the Integration API 1320. The Integration API 1320 then responds 1303 with data that may use a Mapping to transform 1352 Page 55 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT according to the Schemas provided and thereby return the data 1304 to the application 1310 according to the Schemas and configuration provided.

[0297] FIG.14 illustrates a non-limiting embodiment of a composition of a software application 1400 that uses a Standard SDK 1404 together with a set of Schemas and configurations to integrate three different data sources 1406a–c. In this example, the software application 1400 aggregates data from multiple sources and includes hard-coded logic 1414 to allow users to interact with and manipulate the consolidated data, as well as to create new data. As described herein, rather than using multiple SDKs to connect to the three data sources 1406a–c, the application’s codebase may only interact with the one Standard SDK 1404. The one Standard SDK then uses a set of Schemas 1418 included in the application’s codebase 1416 to facilitate interactions between the application’s logic 1414 and the data sources 1406a– c.

[0298] In this embodiment, the Schemas 1418 included in the application’s codebase 1416 may represent data and capabilities 1412 according to the application’s needs (e.g., the application might need a data type for a person, and it may therefore define the Schema for a person and include whatever fields are needed, or it could use a copy of a commonly used data model for a person such as FOAF:person). In a similar way, the Schemas 1418 may also describe the data and capabilities of the data sources 1406a–c (e.g., using OpenAPI or OpenRPC). In this example, the last set of Schemas 1410a–c then establish relationships or Mappings between the data source Schemas 1408a–c and the application’s Schema 1418.

[0299] In other embodiments, the application may reference a Schema from a data source external to the codebase 1416, including but not limited to a database, another application, a website, a Solid Pod, etc. In this example, the application’s Schema 1418 could reference an ontology managed and hosted by third parties such as FHIR or Schema.org. Similarly, the application’s codebase could reference an externally hosted Schema representing Data Source 11406a, such as an OpenAPI Schema stored on a public website or an external repository of Schemas compatible with SKL (e.g., an SKL library). As mentioned, in the event that one or more Schemas are not included in the application’s codebase 1416, they could be requested for use by the Standard SDK at a specific point in time, such as when a certain process requires them.

[0300] In some embodiments, the same schemas 1418 can be used by different Standard SDKs 1404 written in different programming languages and running in different Page 56 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT runtime environments. In other words, a mobile application written in SWIFT, a webapp written in Ruby, and a windows application written in C or C# can all use the same schemas 1418 interact with integrations. This results in the schemas being treated as a type of cross- language type system that can be modified, “installed,” and used at runtime.

[0301] According to an embodiment, the procedure for Standard SDK 1350 to execute a Verb 1301 of FIG.13 may proceed in the following manner:

[0302] First, the Standard SDK finds the configuration for the Verb called by its name from the currently set Schema source. The Schema source may, for example, be the SKL Library REST API, an object in memory of the application code being executed, or a remote SKDS. The Schemas may be accessed using SKQL or a custom method, for example by submitting queries in the native query language of the SKDS.

[0303] Second, the Standard SDK may assert the validity of the input arguments supplied according to the Verb’s configuration. The Verb’s configuration may specify for each parameter (1) what its name is, (2) if it is required or not, (3) if it is allowed to be null, and (4) its data type. Its data type may, for example, be either a scalar data type (e.g., String, Boolean, Integer, etc.), or a reference to a Noun. The Standard SDK may also return an error if the inputs are invalid.

[0304] Third, the Standard SDK may perform the Mapping(s) defined in the configuration of the Verb to obtain the inputs and operation to perform the Verb.

[0305] Fourth, the Standard SDK may perform the Verb’s operation. Different types of Verbs and their associated Mappings may result in different types of operations. For example, a VerbIntegrationMapping may specify that the Verb should use an OpenApi description for the Integration’s REST API endpoints to send an HTTP request and obtain the response. A VerbQueryLanguageMapping may specify that the Verb should execute a SQL request with inputted username and password credentials via an HTTP request to a specific server running PostgreSQL. A VerbCodeMapping may specify that the Verb should execute a certain function or method of a code package and obtain the response. In another embodiment, Standard SDK may perform operations via other methods such as a Remote Procedure Call (RPC) according to an OpenRPC specification.

[0306] Fifth, the Standard SDK may support one or more types of operations by the Standard SDK Code Package. Page 57 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0307] Sixth, the Standard SD may obtain the response from performing the Verb’s operation.

[0308] Seventh, the Standard SDK may perform the Mapping defined in the configuration of the Verb to obtain the standardized output of the Verb.

[0309] Eighth, the Standard SDK may assert the validity of the outputs according to the Verb’s configuration. Throw an error if the outputs are invalid.

[0310] Ninth, the Standard SDK may return the outputs of the Verb.

[0311] The foregoing process is provided merely as illustrative examples and is not intended to require or imply that the steps must be performed in the order presented. The steps in the foregoing embodiment may be performed in any order.

[0312] A conceptual example helps illustrate the Standard SDK procedure. A developer of a file management application needs to get the contents of a folder stored on Google Drive®. They may use the GETFILESINFOLDER Verb to do so, as long as the user has it installed. When calling STANDARDSDK.GETFILESINFOLDER(ARGUMENTS), a Standard SDK may first use SKQL to check the source SKDS if a Verb with such a name is “installed.” If not, an error may be returned to the developer, which may be presented to the end user telling them to install the necessary Verbs and / or Mappings. In some embodiments, the StandardSDK might automatically look for the Verb elsewhere (e.g., the SKL Library) and ask the user or developer if they want to use that Verb. If the Verb is installed, Standard SDK may search for the appropriate Mapping to translate the inputs of the standard GETFILESINFOLDER Verb to the specific inputs and URL of the Google Drive® API endpoint to obtain the contents of a folder. The Standard SDK code package may handle parsing Schemas and Mappings and the translation of the inputs and outputs of the Verb. In this way, a developer only interacts with the standards specified in their SKL Schemas.

[0313] In some embodiments, a Verb may be called as a function on the root Standard SDK object, or as an instance method on any instance of an SKL Noun. In other words a developer may call STANDARDSDK.SAVE(FILE) where StandardSDK is the “root StandardSDK object” or they may call FILE.SAVE() when FILE is an instance of an SKL Noun.

[0314] In other embodiments, the module or library could be called anything (e.g., SKQL.DO.SAVE(FILE) rather than STANDARDSDK.SAVE(FILE)) and Verbs can be called via any means, such as a top-level method or function, a nested method or function, as an argument to another method or function, etc. Page 58 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0315] In some embodiments, a Verb may be mapped to multiple operations and / or functions of one or more Integrations or Code Packages which may be executed in series or parallel. The responses of one or more of these operations or functions may be translated to the standard output of the Verb.

[0316] FIG.16 illustrates a conceptual diagram 1600 of how the developer of the file management application above can leverage the concepts behind SKL to easily integrate with many different applications and / or accounts 1611a-j using the same GETFILESINFOLDER Verb 1610. In this example conceptual example, the developer above wrote custom logic 1650 in order to recursively call the GETFILESINFOLDER Verb 1610 over every nested FOLDER returned by GETFILESINFOLDER Verb 1610 the so that users of the file management application can sync all the FILES and FOLDERS they may have on a given Google Drive® account 1611j. In this case, the GETFILESINFOLDER Verb 1610 may accept a FOLDER and Google Drive® account 1611j as the arguments that the StandardSDK can use to query the data source API with. The StandardSDK using the GETFILESINFOLDER Verb 1610 automatically transforms the data according to the Schemas and provided to the application according to the FILE and FOLDER Nouns in the Schemas. This means that the custom logic described in the applications code base, only needs to interact with these Schemas and therefore no (or almost no) additional custom logic is needed to integrate with the other applications 1611a-i. All that the developer needs is to provide is the additional Schemas that correspond to each Integrations and the Mappings and the StandardSDK will be able to return the data according to the Schemas of FILE and FOLDER Nouns. Any additional capabilities provided by the developer as part of the application (e.g., card interface 1641 and table interface 1642) can be built to only interact with the Schemas of FILE and FOLDER Nouns, and can thereby also automatically work once the developer (or the users) provides the application with the necessary Schemas.

[0317] FIG.15 illustrates a flow diagram of a representation of a Shared Knowledge Language process 1500, in accordance with an embodiment. At step 1501 an application uses a Standard SDK to call a SHARE Verb with shareable Entity (e.g., a task) and a PERSON Entity (or an ACCOUNT Entity if a person has more than one ACCOUNT). At step 1502 the Standard SDK find the Schemas and relevant Mappings for that correspond with the PERSON, the shareable Entity, and the Integration(s) associated with the PERSON and the shareable Entity (e.g., from the codebase, from an SKL Library, etc.). At step 1503 the Standard SDK uses the Schemas and Mappings to translate the arguments provided to the SHARE Verb (e.g., the PERSON Entity and the shareable Entity) into the formats expected by the Integration API. At Page 59 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT step 1504 the Standard SDK uses its standard functions, such as EXECUTEOPENAPIOPERATION(), to send a request to the corresponding Integration’s API endpoint according to the API’s specification (e.g., as defined through its OpenAPI spec). At step 1505 the Integration’s API returns the data to the Standard SDK. At step 1506 the Standard SDK uses the Schemas and Mappings to transform the Integration API’s response to the expected outputs of the SHARE Verb. At step 1507 the Standard SDK returns the standard response from the SHARE Verb to the application.

[0318] Turning now to FIG.17, the flow of data in the SKL framework 1700 is shown. A Universal File Browser application 1702 which displays to users all their files and folders from multiple Integrations (e.g., Dropbox®, Google Drive®, OneDrive®, etc.) is shown. The application 1702 may contain code which uses Verbs to recursively request and copy the Metadata of all files and folders within a user’s accounts regardless of what service they exist in so that it may display them to the user.

[0319] Instead of the developer storing the Metadata about files and folders in a siloed database they control, the developer may store the data in a user’s SKDS. The SKL framework 1700 includes Schema 1706 and special Verbs 1708 for querying and saving data to SKDS 1704.

[0320] In the future, the user may use another SKApp for signing documents. This application, once authorized by the user to read data from their SKDS, may query for Entities conforming to the standard FILE Noun in the SKDS which the user may need to sign. In this way, the two applications may interoperate on the same data because they have a common understanding of its Schema.

[0321] Referring back now to FIG. 1B and FIG. 3, a non-limiting embodiment of a Standard SDK framework is shown. Application 121a–f of FIG.1B may use a Standard SDK to integrate with all other applications 121a–f by only building one integration each. A first application 121a may be considered as application 350 of FIG. 3, and the other applications 121b–f that need to be integrated with the first application 121a may be thought of as applications 130 of FIG.1b.

[0322] Application 121b–c may use a Standard SDK together with the Schemas and Mappings to integrate with each other, without requiring a central server to act as a “unified API” by having all interactions route through it. In this embodiment, the various applications may communicate with each other in a one-to-one manner, similar to network of integrations Page 60 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT 110, but rather than translating information directly from the first application 121a to the other applications 121b–f, each application only needs to be integrated once with a given standardized ontology, and through that standardized ontology, they may be integrated with each other. This non-limiting embodiment demonstrates that a SKL framework may be a highly composable and customizable. Through the abstraction of software, and providing access through an ontology, SKL allows each independent software developer to reuse components such as Mappings for other integrations.

[0323] An SKL framework may enable the reuse of components across software applications, codebases, and more by providing composable Schemas to link components together. For example, in the process of creating an application, a developer may create Mappings between the FHIR ontology and twenty different healthcare platforms. Those twenty integrations may then be shared with other applications and developers (e.g., through the SKL Library). Over time, certain ontologies may emerge as “standards” in a given domain area and / or within a given industry. In this embodiment, developers and end users may remain in control of the Schemas and the Standard SDK so as to make changes to any standard according to a specific need.

[0324] FIG. 19 illustrates a conceptual diagram of various components that make up Standard Knowledge Language framework 1900, according to an embodiment. In this embodiment, SKL is a protocol that may be built to work with a wide variety of software, regardless of whether that software was built according to an SKL specification or not. As such, in this embodiment, there may be an abstraction / translation of software and components (e.g., proprietary APIs and their data) into a universal language of data, capabilities, interface components, storage solutions, and more. As described herein, the various components are represented abstractly through Schemas which include Nouns 1920, Verbs 1930, Integrations 1911, Interfaces 1950, and the like.

[0325] According to this embodiment, Standard Storage 1940 may be an SKDS provider that offers various different types of SKDSs. Similar to how Integrations 1911a-j may each be represented by Schema such as an OpenAPI specification that SKL tooling may use, each SKDSs offered by Standard Storage 1940 may be represented through an SKDS Schema.

[0326] Abstractions that represent data as Nouns 1920, capabilities as Verbs 1930, interfaces as Interfaces 1950, and data stores as SKDS Schemas may assist the SKL framework 1900 to understand each piece deterministically in a standard way. By centering all software Page 61 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT components around an ontology, and providing tooling to help build software semantically, each component may represent data based on what it is rather than where it comes from or how it is stored. Each component may access a capability in a standard way regardless of whether that capability is executed remotely or not. Each component may be able to access data from a data store regardless of whether they know the how that data store handles persistence, and so on. Furthermore, because these abstractions or Schema may be stored as a configuration, they may easily be shared across programming languages, execution environments, etc. In this way, these abstractions may be easily ported and / or shared between tools. Moreover, because SKL components may be connected through Mappings, and because their Schemas may specify their attributes as configuration, SKL systems may be able to evaluate which components are compatible with their needs in a standard way.

[0327] Due to the modular nature of the SKL ecosystem’s components, in some embodiments each type of component may be used independently. According to some embodiments, every component need not be used together. For example, a developer of an existing application (e.g., Gmail®) could choose to use a Standard SDK to build integrations with other tools. Similarly, a developer could choose to build a SKApp that communicates with SKDSs without using other components. In yet another non-limiting example, a developer could choose to use SKApp with Standard Interfaces that connects to an Integration without using an SKDS.

[0328] According to some embodiments, as more Schemas are created for a wider variety of components and needs, and as those component Schemas are mapped to more ontologies, it may become increasingly easy for developers and users to develop solutions with SKL. In other words, because SKL is highly composable and parametric, it may have the ability to offer value to its users because any component for a solution may be able to be reused and repurposed for a second solution with ease. As more applications, platforms, and data sources are mapped to a given ontology, the easier it may be to integrate novel software into that industry or domain area. For example, in some embodiments, developers may be able to integrate with a given ontology to connect to a theoretically infinite number of applications. In this way, SKL technologies and methods may replace any closed and proprietary “unified API” service that restricts application developers from extending capabilities such as which integrations the unified API supports, that requires the application using the unified API to route all data through their the unified API company’s servers, that charges high amounts per throughput, etc. Page 62 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0329] Turning now to FIG.20, two different applications 2002a–b using a Standard API 2004 (as described herein) are shown. In this embodiment, the standard API 2004 may use Schemas to expose endpoints corresponding to Nouns and Verbs.

[0330] FIG. 21 shows an embodiment wherein multiple applications 2102a–c use a Standard API 2110 (as described herein) that may use Schemas to expose endpoints corresponding to Nouns and Verbs in order to interact with multiple Integrations. In one embodiment, a Standard SDK 2104 may use a Virtual Database 2108 technology which, when queried through the Standard API 2110, federates requests to multiple databases, multiple tables of those databases, and / or multiple Integrations to construct a complete response in the format of the domain model. Such a Virtual Database 2108 could be used not only to federate queries to multiple databases but also to one or more web APIs 2106b (e.g., REST, GraphQL, etc.), or files 2106c (e.g., JSON, CSV, etc.).

[0331] In yet another embodiment, FIG.22 illustrates a single SKApp 2200 (in some embodiment called a “Standard Syncer”) which may be used to continuously sync information from multiple data sources, databases, and / or Integrations 2202a–c into a standard knowledge data storage (“SKDS”) 2204 that may be used by other applications (e.g., SKApps).

[0332] FIG. 23 illustrates how the Standard Syncer SKApp of FIG. 22 may be configured to “coordinate” syncing 2302 from the different data sources in custom ways (e.g., using a cron schedule). In this embodiment, the Standard Syncer SKApp 2300 may be considered a Coordinator. In this embodiment, the Standard Syncer SKApp may be used to consolidate data from multiple source into a unified data model which is described by Nouns. In this example, the unified data model (i.e., the ontology) includes FLIGHT 2306 and PASSENGER 2308 Nouns The Entities are stored on a persistent database or an SKDS 2310. AUTOMATIONS AND RULES ENGINES

[0333] Turning now to FIG.24. According to some embodiments, a process is shown in which applications 2402a–c may query an SKDS 2404 for data synced from multiple data sources 2406a–c using a Standard SDK 2408a. In this non-limiting embodiment, each SKApp 2402a-c may use a Standard SDK 2408b–d to access the SKDS’s 2404 Schema to feed data into interfaces, such as those for a rules-engine SKApp illustrated in FIGs.25-28. FIGS.25- 28 correspond various interfaces of the same rules-engine SKApp.

[0334] Considering the Standard Syncer SKApp of FIG. 23, the Standard Syncer SKApp 2410 may be used to consolidate data from multiple sources into a unified data model Page 63 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT which is described by Nouns. In this example, the unified data model (i.e., the ontology) includes FLIGHT and PASSENGER Nouns. The unified data model may then be used by SKApps (e.g., 2402a–c) to create a filtered and ordered list of PASSENGERS for any given FLIGHT that meet certain criteria according to the values on the fields of the PASSENGER and FLIGHT Entities as illustrated in FIG.25.

[0335] FIG. 25 show a non-limiting embodiment of the interface for a rules-engine SKApp 2500 that allows non-technical users to easily customize the parameters for how PASSENGERS are filtered on a given FLIGHT. In this example, interface component 2501 can be used by a non-technical user to determine variable numbers of PASSENGERS in each list of PASSENGERS according to certain parameters associated with a FLIGHT. As depicted, interface component 2501 can use the travel distance (e.g., the MILEAGE property) of a FLIGHT Entity in order to establish that: a list of 4 PASSENGERS should be generated for FLIGHTS with a travel distance of less than or equal to 250 miles; a list of 6 PASSENGERS should be generated for FLIGHTS with a travel distance greater than 250 and less than or equal to 500 miles; a list of 15 PASSENGERS should be generated for FLIGHTS with a travel distance greater than 500 and less than or equal to 900 miles; and a list of 20 PASSENGERS should be generated for FLIGHTS with a travel distance greater than 900. Interface component 2502 illustrates how non-technical users may create, modify, and use certain FLIGHT filters in order to facilitate the testing of a particular overall configuration for a program 2520 on the rules-engine 2500. Similarly, Interface component 2503 illustrates how non-technical users may create, modify, and use certain PASSENGER filters or qualifications that should be applied to all PASSENGERS that get added to any list generated by the program 2520.

[0336] Non-technical users are able to test the program 2520 by using running it according to the configuration set through interface components 2501, 2502, and 2503. The interface component 2510 provides a simple way for non-technical users to click a button that will automatically query the SKDS 2404 for Entities that match the criteria established through interface components 2501, 2502, and 2503. The resulting data after each step can be seen contextually on the SKApp’s interface 2500. Interface component 2511 shows that four FLIGHT Entities were identified in SKDS 2404 that match the configuration set through interface component 2502, and lists out certain fields associated with those flights as well as the ability to see more detail associated with the results. Interface component 2512 shows that at least three PASSENGER Entities were identified in SKDS 2404 that match the configuration set through interface component 2503. FIG. 27, described further below shows the continuation Page 64 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT of the interface 2500 and how there are 198 PASSENGERS that meet the criteria determined through interface component 2503.

[0337] FIG. 26 shows a non-limiting embodiment of how the Schemas for the PASSENGER and FLIGHT Nouns shown in FIG.23 may be used to populate information into the interfaces shown by the rules-engine SKApp 2600. According to this embodiment, exemplary fields include LAST_FLOWN 2602a, LOYALTY_NUM 2602b, and BIRTHDAY 2602c. The SKApp 2600 could use an Interface Component 2604 which accepts one or more Noun Schemas as inputs in order to provide filtering capabilities based on the properties associated with those Schema(s). Simple query logic, such as is EQUAL TO, is GREATER THAN, CONTAINS, etc. could then be used to evaluate whether a given Entity of that type of Noun in the SKDS matches the query provided. Interface Component 2605 could then provide a detailed list of Entities that match the filtering criteria provided in Interface Component 2604, similar to Interface Components 2511 and 2512. Additional capabilities, such as sorting may also be used as is shown on in Interface Components 2603a and 2603b. In this example, the PASSENGER Entities that match the filters 2602a-c should be sorted in ascending order by LAST_FLOWN (as shown in Interface Component 2603a) and any PASSENGERS with the same value on LAST_FLOWN should be consecutively sorted in descending order by the LAST_FLOWN parameter (as shown in Interface Component 2603b). The SKApp could then save these filters as a configuration (e.g., as an Entity of the RECOGNTIONCATEGORY Noun with a given name or ID shown as “Welcome Back” in Interface Component 2610) along with a related Entity of type MESSAGE as shown in Interface Component 2620.

[0338] FIG. 27 shows the configuration for a different Entity of the RECOGNTIONCATEGORY Noun (e.g., “Million Mile Threshold”) in the Interface Component 2700, which could expose more sophisticated filtering capabilities, such as using an equation 2702. The example below shows an Interface Component 2700 that may be used to build aquery 2704 (e.g., using SKQL, or SQL: SELECT PASSENGER FROM FLIGHT WHERE FLOOR(TOTAL_MILES / 1,000,000) <> FLOOR (TOTAL_MILES+MILES_TODAY / 1,000,000)) that may besaved and / or sent directly to the SKDS. The different Entities of type RECOGNTIONCATEGORY could be used to save different configurations and / or filters that can be used to create different lists of PASSENGERS that match different criteria.

[0339] Turning now to FIG.28, which shows the rest of the interface 2500, according to a non-limiting embodiment. Interface 2800 shows all the configuration and test results for steps of a the program 2520. In this example, a Verb GENERATERECOGNTIONS may be Page 65 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT configured to create recognitions for one or more Entities of type FLIGHT. For example, the four flights 2802a–d could each be taken through a series of consecutive steps as may be defined in the GENERATERECOGNITIONS Verb. These steps may be defined in several ways, including by creating other Verbs such as GENERATERECOGNITIONSFORCATEGORY which could require an Entity of type RECOGNITIONCATEGORY to specify the configurations for the filtering that would be specified by an Entity of RECOGNITIONCATEGORY (e.g., Corporate, MillionMileThreshold, LoyaltyMember). In this example, the four flights 2802a-d are each run through the program 2520 by first filtering the passengers on those flights by the criteria set at step 2804a, which returns 198 passengers, of which the first five of which are shown in Interface Components 2803a-e. The program 2520 then filters the 198 passengers on those flights by the Entities of RECOGNITIONCATEGORY shown in interfaces 2804b-d. According to this embodiment, the steps 2804b-d are run on each flight in order starting with 2804b, then 2804c, and finally ending with 2804d. A use could edit the configuration for the “Million Mile Threshold” RECOGNITIONCATEGORY 2804c by clicking “Edit” which would bring up interface 2700.

[0340] According to this embodiment, a user could easily create new and / or add existing Entities of RECOGNITIONCATEGORY (e.g., such as the “Welcome Back” Entity shown in FIG. 26) by clicking the interface component 2804e. A user may also click and drag to change the order of RECOGNITIONCATEGORIES 2804b-d. Each of these changes could be saved as configuration in a different Entity of type RULESENGINEPROGRAM, where the configuration of number of passengers per flight 2501, the flight filters for testing 2801, the overall passenger qualifications 2804a, and the various recognition categories and their order 2804b-d (which may be stored as references to the RECOGNITIONCATEGORIES Entities 2804b-d) could be the information stored by the Entity. In this example, the GENERATERECOGNTIONS Verb could accept a given FLIGHT Entity as well as a RULESENGINEPROGRAM Entity (e.g., program 2520) and take the flight through all the steps of program 2520 in order to output the resulting data, which in this case is a list of passengers that should be recognized on the flight Entity provided to the Verb. For the sake of testing, the interface 2800 can show the user the resulting lists of passengers that should be recognized on each flight as shown in interface components 2812a- c, as well as the corresponding RECOGNITIONCATEGORY that resulted in that passenger being recognized on that flight.

[0341] In another embodiment, the Verb that runs the workflow according to the configuration set may be made accessible or exposed via a Standard API endpoint or simply called by a Standard SDK of another SKApp that is interacting with the SKDS. These other Page 66 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT applications could trigger the workflow remotely through the GENERATERECOGNTIONS Verb for any given flight or set or flights.

[0342] According to another configuration, a different program of a rules-engine SKApp may use Verbs, which execute one or more other Verbs that include Triggers and Actions that may be connected together and run automatically. In one embodiment, a shared email account may receive an email. The receipt of this email may then trigger a Verb which finds named entities (e.g., FINDNAMEDENTITIES) in the email, followed by a second Verb to compare identified named entities to a predetermined list (e.g., project 1, client 2, deal 3). If there is a match, the Verb may then find the person that is associated as a lead on that project / deal / client / etc. in a data source. Once the person is found, the Verb may then (1) create a task that references the email, the project / deal / client / etc., (2) assign it to the lead, and (3) forward that person the email and include a reference to the task in the forwarded email.

[0343] In this way, SKL abstractions may make it easier to interact with data from multiple sources and Integrations. Tools such as IFTTT®, Zapier®, Tray.io®, and Mulesoft® offer workflow automation builders by offering connectors and easy drag / drop interfaces to workflows between specific Integrations. However, because of SKL, a SKApp which utilitizes rule engines of FIGS.25–28 may easily build automations and workflows by leveraging the full power and range of capabilities that Nouns and Verbs offer.

[0344] In another embodiment, a SKApp can use programs, business processes, automations, process workflows, etc. like these to establish links between nodes within a nodal data structure. For instance, when a user copies & pastes information from one place to another, the analytics server may automatically create a link between the Entity that corresponds to the copied data and the Entity corresponding to the pasted data and label that link between those Entities (e.g., managing the Metadata to that relationship) accordingly such as labeling that one Entity is a source for the other. In another example, automations like those done with popular automation tools may create links between content and may add Metadata to the edges / relationships. In another example, a user (or system) that navigates to a certain website or piece of information from a different piece of information may establish a relationship between both of those nodes and add the appropriate Metadata to the edge (e.g, a user accessing a website by clicking a link in a particular text message, and then navigating to another webpage may establish and / or alter the links, relationships, and metadata about and / or between the nodes). Specifically, the analytics server may also score a variety of aspects related to this system, such as: the potential relevance of relationships being established between nodes that Page 67 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT a user interacts with, the confidence on the potential labels and metadata established on and / or between nodes, etc. CONNECTING SKL TO INTERFACES

[0345] FIG. 29 illustrates a conceptual diagram of how an SKApp 2905 can use a Standard SDK 2902 to retrieve data from various data sources 2901a-d according to the Schemas of Nouns and then use a Standard UI Engine 2903 to provide the data to various different Interface Components 2904a-c, according to an embodiment. In this example, the SKApp 2905 can execute Standard SDK 2902 requests in order to feed data to or respond to events from Standard UI Engine 2903. In some embodiments, in order to do this the SKApp 2905 can have one or more top-level Interface Components 2904a-c or files which import or have access to both the Standard SDK 2902 and the Standard UI Engine 2903.

[0346] According to some embodiments, an SKL framework may provide a frontend engine (e.g., Standard UI Engine) that applies similar concepts as the Standard SDK, but to Interface Components. By using NOUNINTERFACEMAPPINGS, a developer may create a relationship between certain parameters of a Noun’s Schema and certain fields of an Interface’s Schema. The fields of an Interface’s Schema might in turn correspond to the props for a React component. For example, FIG.30 shows how a certain Noun may be mapped, according to an embodiment, to a variety of Interface Components. In other words, a Noun like SCHEMA.ORG:EVENT could be mapped to four different Interface Components: TABLE 3002a, CARD 3002b, MAP 3002c, and CALENDAR 3002d. The various properties of the SCHEMA.ORG:EVENT such as TITLE, DATE, etc. could then be mapped to the inputs of the various Interface Components.

[0347] In some embodiments, if relationships exist between different Noun Schemas— such as a CONCERT being (1) mapped to, (2) a subtype of, or otherwise (3) has a relationship to the SCHEMA.ORG:EVENT Noun—then CONCERT may automatically work with any Interface Component that is mapped to SCHEMA.ORG:EVENT.

[0348] FIG. 31 shows, according to some embodiments, how the methods of the various embodiments of SKL as described herein (including the abstraction of Integrations, the Mappings to standardized Nouns, and the Mappings to Interface Components) may be used to show data from multiple sources in a standard way on a map Interface. Because of how SKL works, the Interface could be swapped out at any time with relative ease. In some embodiments, Page 68 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT the Schemas for Interface Components may be used to represent components from different frameworks (e.g., React, Standard Interfaces, etc.).

[0349] FIG. 50 shows a conceptual diagram 5000 that combines the concepts from FIG.30 and FIG.31, according to an embodiment. In this example several Integrations 5001a- e are connected to a Syncing SKApp 5004a, that includes a deduplication process 5004b. As with other examples, the Syncing SKApp 5004a-b may use Schemas to represent each Integration 5001a-e, the standardized Nouns 5003 and Verbs that are used to interact with the various Integrations 5001a-e, and the Mappings 5002a-e that translate the various data formats and capabilities offered by each Integration 5001a-e into their standardized representation(s) 5003. Using the methods described herein, the Syncer SKApp also reads and writes Entities from and to the SKDS 5005 which a third-party website 5010 is able to query directly. In this example, the website may also use a Standard UI Engine 5006 to help various Interface Components 5007a-c access and interact with the standardized Nouns and Verbs that are stored in SKDS 5005.

[0350] FIGS.42-49 illustrate the graphical user interface of SKApp 5010 that lets end users easily and dynamically modify Schemas in order to customize almost any part of the SKApp, according to an embodiment. Referring first to FIG.42a, graphical user interface 4200 shows three main panes: a Schema navigator 4210 that lets users easily view and modify all the Schemas, as well as create new and / or load in other existing Schemas from other sources (e.g., the SKL Library) using interface component 4211; a Schema inspector and editor 4220 which may let users easily open SKL Schemas and modify any of the embedded and / or related configuration, and a section 4230a that uses the Standard UI Engine to render Entities of a given type according to a chosen Interface Component Schema. In this example, the user has chosen to add a Tickemaster® account 5001b, and then selected that account from the Schema navigator 4210. In this example, the purpose of the SKApp 5010 is to sync and deduplicate Events (e.g., sports matches, concerts, festivals, etc.) from various data sources and to show them in in a unified interace.

[0351] According to this embodiment, the configuration for a given Tickemaster® account 5001b is represented through two Schema files, one for the security credentials (e.g,. API token) and one for the configuration of syncing of data from that integration. The Schemas to represent the Ticketmaster® API (e.g., the Ticketmaster® OpenAPI spec), standardized Events, and the Verbs and Mappings necessary to get them are all within their own subsection in panel 4210. Page 69 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0352] This example provides a manual trigger for syncing 4222 and a couple syncing parameters that can be changed for the Ticketmaster® account such as the number of results to grab and a given city to get Events for 4221a. For the sake of simplicity this example has been limited to a couple editable parameters but other embodiments can allow users to edit other parameters, as well as to use automatic triggers and syncing schedules as described elsewhere herein. Given that the relevant “city” parameter 4221a in this example is set to New York, the EVENT Entities shown in panel 4230a are events that take place in in New York City. Referring now to FIG.42b, changing the “city” parameter 4221b to Atlanta and resyncing adds events that take place in the city of Atlanta as is shown in panel 4230b. In this way, SKL is able to abstract away a significant amount of complexity and make it accessible via parametric configuration files.

[0353] Referring back to FIG. 42a for a moment, interface component 4231 can be used to specify how what types of Entities returned by the syncer should be displayed in panel 4030a. Since the syncer is likely to return multiple types of Entities like LOCATIONS, PERFORMERS, and EVENTS from a data source like Ticketmaster®, a user may want to filter them down by a given type of Entity. Similarly, interface component 4232a can be used to specify how the EVENT Entities returned by the syncer should be displayed within panel 4030a. In this case, a user has specified that the EVENT Entities should be displayed in Interface Components of type CARD. Entities synced with the New York parameter 4221a and Entities synced with the Atlanta parameter 4221b both can be displayed in cards as shown in interface components 4233a and 4233b respectively. Referring now to FIG. 42c, because Interface Components in SKL may be easily mapped to Noun Schemas as explained herein, any Interface Component previously mapped to the standardized EVENT Noun (e.g., SCHEMA.ORG:EVENT Noun) may be loaded into this SKApp 5010 and used to display EVENT Entities. For instance, a user can choose to change the CARD component 4232a for a TABLE Interface Component 4232c that has been appropriately mapped in order to easily view the EVENT Entities according to their varied needs.

[0354] Referring now to FIGs.43-44, in a similar way to how users may change the syncing parameters for an Integration, they may also choose to parametrically edit Interface Components, their styling, spacing, and more. For instance, FIG.43 shows how a user might select to view the Schema 4310 for the CARD component and change certain parameters like the size of the image 4320 from 30px in FIGs.42a-c to 100px, according to an embodiment. Similarly, as described elsewhere herein, certain shared styles (e.g., design tokens, CSS classes, Page 70 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT etc.) could be applied to multiple Interface Components in order to facilitate the customization of multiple Interface Components simultaneously. FIG.44 shows how a particular theme 4410 has its own Schema that can be easily and parametrically modified to change the styles of any Interface Components whose properties reference the Style Schema’s parameters, according to an embodiment. In this example, the CARD component’s 4430 Schema says that some of the text in the CARD component should be colored according to a theme’s primary text color value 4420. In this way, changing the value of the primary text color 4420 in the theme’s Schema will result in a change to the color of some of the text in the CARD component 4430.

[0355] FIG. 49 illustrates a graphical user interface for SKApp 5010 that shows deduplicated Entities from multiple data sources for events and venues, according to an embodiment. In this example, a user chose to view Entities of type DEDUPLICATEDLOCATION (e.g., venues) through Interface Component 4910 and to view them with the DEDPLICATEDENTITYCARD through Interface Component 4920. The DEDPLICATEDENTITYCARD Interface Component 4950 shows how different fields from various data sources can be combined into one deduplicated Entity stored in an SKDS 5005. For instance, some fields like the NAME field 4951 of the DEDUPLICATEDLOCATION Entity shows how two data sources share the name “Atlanta Symphony Hall” and a third data source has a different name “Symphony Hall Atlanta”. This is in contrast to the ADDRESSLOCALITY field, for which all three data sources share the same value.

[0356] In some embodiments, if a deduplicated Entity has the same value from all sources but one, it could be used to suggest to the one outlier that the data is wrong. In other embodiments, certain data sources can be given a higher authority than other data sources. In these ways, deduplication of Entities can actually be used to clean up data across one or more sources. SKL LIBRARY

[0357] According to some embodiments, an “SKL Library” may document and allow for the discovery, creation, editing, and management of Schemas, configurations (e.g., ontologies, Nouns, Verbs, Interfaces, Mappings, Code Packages, AI models, etc.), SKApps, Authentication Servers, Standard SDKs, Standard UI Client Libraries, and / or any other SKL artifacts and SKL-compatible components (the “Artifacts”). Other types of Artifacts in the SKL Library may also include elements related to open-source contributions (e.g., notes, bugs, feature requests, pull request, sample data, etc.) and collaboration (e.g., messages, posts, Page 71 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT threads, tasks, etc.). An SKL Library may be sometimes referred to herein as “The Library,” “SKL Dictionary,” “The Dictionary,” and the like.

[0358] In some embodiments, any Artifact may be related to any other Artifact. As such, each Artifact (e.g., an Entity) may provide, for example, contextual access to other related Artifacts such as comment threads, version histories, bugs, change requests, and / or any other Artifacts. According to a non-limiting embodiment, the SKL Library may use Linked Data to allow each Artifact to reference other Artifacts. This may be similar to how a nodal data structure (e.g., an “SKDS”) might be used to record relationships between different Entities (e.g., files and messages) and to surface related Entities (e.g., through search, contextually through relationships in nodal data structure, through Relevance Scores, using other machine- learning techniques, using other natural language processing techniques, etc.). In some embodiments, given a Verb Schema, SKL Libraries may be used to access Noun Schemas which are related to that Verb as inputs or outputs. SKL Libraries may link and / or provide access to Entities through Mappings (e.g., any Mappings that specify relationships between Artifacts such as an Integration endpoint and a Verb, a Noun and a Verb, a Noun and an Interface, etc.), and / or other means such as edges between nodes, Relevance Scores, and more.

[0359] FIG.32 illustrates a conceptual diagram, according to one embodiment, of how the SKL Library may relate different SKL Attributes. The Noun 3202 in the SKL Library SKDS in this example represents a FILE Schema. Since this FILE Noun 3202 has been mapped to a variety of Verbs such as MOVE 3204a, SEND 3204b (or SENDINMESSAGE), SHARE 3204c, SCHEDULE 3204d, and more (e.g., GETFILESINFOLDER, GETATTACHMENTSINEMAIL, GETFILECONTENTSASSTRING, GETNAMEDENTITIESINFILE, etc. which could be used by a syncing SKApp), an SKL Library may present them as capabilities for files. Different embodiments or processes for a Verb that is meant to send a file may include a sending a file in a message, sending a file through Bluetooth®, sending a file through AirDrop®, and other means.

[0360] These various capabilities may be abstracted away through a single SEND Verb, that will use different Schemas like Mappings and Nouns and / or combinations of different Schemas, to parametrically and / or intelligently determine which specific process should be used. In other embodiments, an SKL Library may help a developer trying to use a FILE Noun 3202 together with a SEND Verb 3204b to automatically determine what Integrations 3206a–j may be used to send the file, what other Schemas may be needed (e.g., a PERSON Noun 3208 to send the file to, a MESSAGE Noun 3210 to send with the file, and more. These relationships Page 72 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT and various other Schemas could be accessed through a variety of methods, including but limited to, by browsing, searching, and interacting with a website, by referencing one of the Schemas in an Integrated Development Environment (an “IDE”) and seeing suggestions, by querying to an API, by interacting with a file inside a SKApp that helps a non-technical user centralize their health information, and more. As such, when a developer, or any other user of software that leverages SKL, interacts with any SKL Artifact (e.g., in the SKL Library, within a SKApp), they may easily access the documentation for that Artifact and they may easily view all related other Artifacts (e.g., organized by category, by relevance, etc.). In other embodiments, the developer may filter by some criteria like Operating Environment, pre- approved by an organization, etc.).

[0361] An SKL Library may hold this information in an SKDS, but in some embodiments the information may be stored in other ways, such as files in a codebase, on a blockchain, across multiple data stores and Integrations, etc. An SKL Library may have one or more corresponding SKApps, such as website, webapp, local application, dapp, etc. to help users create, find, interact with, or otherwise manage Artifacts. Users may also interface with an SKL Library in sever ways in order to interact with Artifacts (e.g., code, SKQL, web requests (e.g, to a REST API), etc.) DISPLAY & SEARCH

[0362] At least one embodiment of an SKL Library may be considered “Official SKL Library” (sometimes called the “Official Library,” “Official Dictionary,” and the like). The Official Library may serve as the main public distribution of Attributes. Other SKL Libraries may exist simultaneously, such as private SKL Libraries, or other domain-specific SKL Libraries which may be considered to be part of the Official Library. In some embodiments, an organization may also choose to have an Official SKL Library for their organization while keeping some Attributes private and publishing some Attributes to the public Official Library.

[0363] The Official Library may serve as the official public library / dictionary for a SKL to allow individuals and companies to learn about, discover, contribute, and use any aspect of it in a composable way. The Official Library may be organized by various methods such as relational data, indexing and search, and more. The Official Library may implement one or more SKDSs and SKApps to store and serve the data.

[0364] FIG. 37 depicts the composition the Official Library 3700, and some of the various SKL Artifacts and SKL Libraries that can compose it, according to an embodiment. In Page 73 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT this example, the Official Library includes all of the Schemas, configuration files, code, infrastructure templates, documentation and anything else necessary to: find, use, create, and modify SKApps; find, use, create, and modify Nouns; find, use, create, and modify Verbs; find, use, create, and modify Integrations; find, use, create, and modify Interfaces; find, use create, and modify any other configurations, code, or documentation a user or developer may need to interact with SKL; and so on. The Official Library may also include an index of all registered SKApps and their details; different Interfaces and Verbs that can be used to interact with the data inside SKL Libraries including all the users who choose to have a profile on the Official Dictionary and their contributions, discussions, etc.; information related to APIs and other interfaces (e.g., SKQL) that can be used to programmatically interact the data in the Official Dictionary, and so on. Certain components can require payment by users 3702–3706 and certain other components can be originally developed to follow other protocols and programming standards (e.g., that are not related SKL) but that are able to be abstracted and represented through SKL Schemas and thereby made interoperable and composable with the SKL ecosystem 3708–3714.

[0365] In some embodiments, a user of the Official Library may search for, view, interact, and create new SKL Artifacts, as well as relationships to other resources. In other words, Artifacts in the Official Library may be full-text searchable and filterable, for example via any of its Metadata, Schema, or relationships. Upon selection of an Artifact (e.g., an Integration, an SKDS, a Verb, a Noun, a SKApp, an Interface Component, a message, a task, etc.) the SKApp for the Official Library may generate and / or display a “profile” for that Artifact.

[0366] According to some embodiments, the profile for an Integration in an Official Library SKApp might include various information. For example, the profile might include the following: Metadata about the Integration (e.g., name, domain, developer, provider, execution environments, pricing, reviews, keyboard shortcuts, related API endpoints, URL structures, whether it may be used to train AI models or in conjunction with AI models, etc.); information related to how the Integration and data, capabilities, instances, Artifacts, etc. related to the Integration may be automatically identified by software; the Schemas which detail how a Verb may read and write data to and from the Integration and how data from the Integration may be converted to Nouns; any Nouns, Verbs, Interfaces, and SKApps which work with the Integration or which could potentially be easily configured to work with the Integration; information about Integration usage (e.g., any users that have used, interacted with, etc. the Page 74 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT Integration, according to the privacy settings of those users); any relationships to other Integrations, contributors, developers, etc.; the edit history, versions, etc. of the Integration; and the like.

[0367] In some embodiments, SKL Libraries can facilitate access to “dummy data” and / or public / non-confidential data that can be provided when the API endpoints of an Integration are queried with certain special parameters (e.g., queryAsTest). These example responses may be used within a code testing suite to mock the responses of endpoints and test other components of the system without sending real HTTP requests.

[0368] FIG.33 is a non-limiting example of how an Integration’s profile on the Official Library (and / or another SKL Library) may appear. This particular embodiment shows what the profile for Google Drive® Integration might look like, including: general information about the Integration, its developer and / or provider, pricing, privacy practices, performance, persistence type, terms & conditions, how to access it and / or use, reviews, etc.; different relevant UI components including icons, Interface Components which may work with the Integration; Schemas, documentation, and any other information representing or relevant to the API; relevant ontologies that have or could be integrated including Nouns and Verbs SKApps which work or could work with the Integration; a timeline of contributions, changes, edits, usage, etc.; issues, bug reports, feature requests, forks, pull requests, and other capabilities to help with the management of Schemas; and more.

[0369] According to a non-limiting embodiment, an SKDS’s profile on the Official Library (and / or another SKL Library) might include: general information and Metadata about the SKDS (e.g., developer and / or provider, pricing, security and privacy certifications and practices, performance, persistence type, terms and conditions, how to access it and / or use, reviews, execution environments, whether it may be used to train AI models or in conjunction with AI models, etc.); information related to how the SKDS and data, capabilities, instances, Artifacts, etc. related to the SKDS may be automatically identified by software; the Schemas which detail how data may be read and written to and from the SKDS; information related to which SKApps and Interfaces may work with the SKDS or which could potentially be easily configured to work with the SKDS; information about SKDS usage (e.g., usage and performance metrics, any users that have used, interacted with, etc. the SKDS, according to the privacy settings of those users); any relationships to other SKDSs, icons, images, contributors, developers, etc.; the edit history, versions, other Artifacts, etc. of the SKDS; and the like. Each SKDS may also include custom adapters that help map SKQL functionality (e.g., via the SKQL Page 75 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT ORM) to whatever the the language the database or databases offered by SKDSs natively offer (e.g., SQL, DQL, GraphQL, etc.).

[0370] According to a non-limiting embodiment, a Verb’s profile on the Official Library (and / or another SKL Library) might include: general information and Metadata about the Verb (e.g., developer and / or provider, pricing, security and privacy certifications and practices, performance, terms & conditions, how to access it and / or use, reviews, execution environments, whether it may be used to train AI models or in conjunction with AI models, etc.); information related to how the Verb and data, AI models, capabilities, instances, Artifacts, etc. related to the Verb that may be automatically identified by software; the Schemas which detail when the Verb may or should be run, what its inputs and outputs are including the Nouns and possible SKDSs and Integrations it works with; information related to which SKApps and Interfaces use the Verb or which could potentially be easily configured to work with the Verb; information about the Verb’s usage (e.g., usage and performance metrics, any users that have used, interacted with, etc. the Verb, according to the privacy settings of those users); any relationships to other Verbs, icons, images, contributors, developers, other Artifacts, etc.; the edit history, versions, etc. of the Verb; and the like.

[0371] In some embodiments, and in a similar fashion to Integrations (and sometimes in conjunction with the dummy data associated with an Integration), SKL Libraries may facilitate access to “dummy responses” for a given Verb, enabling developers, SKApps, users, etc. to more easily run tests and determine if a given SKApp is working properly (e.g., executing Verbs at the right time, with the right parameters, and correctly handling the responses and / or emitted events).

[0372] According to a non-limiting embodiment, a Noun’s profile on the Official Library (and / or another SKL Library) might include: general information and Metadata about the Noun (e.g., developer and / or provider, pricing, security and privacy certifications and practices, performance, terms and conditions, how to access it and / or use, reviews, execution environments, whether it may be used to train AI models or in conjunction with AI models, etc.); information related to how the Noun and data, AI models, capabilities, instances, Artifacts, etc. related to the Noun may be automatically identified by software; other criteria for identifying, deduplicating, and / or processing Entities of that type of Noun; the Schemas which detail the Noun’s larger ontology, properties, fields, actions, and possible Verbs, SKDSs, and Integrations (e.g., Integrations that emit events which may be translated into data of the Noun) it works with; information related to which SKApps and Interfaces use the Noun or Page 76 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT which could potentially be easily configured to work with the Noun; information about the Noun’s usage (e.g., usage and performance metrics, any users that have used, interacted with, etc. the Noun, according to the privacy settings of those users); any relationships to other Nouns, icons, images, contributors, developers, other Artifacts etc.; the edit history, versions, etc. of the Noun; and the like.

[0373] In some embodiments, and in a similar fashion to other types of Schemas (and sometimes in conjunction with the dummy data and responses from those other Schema Entities), SKL Libraries may facilitate access to “dummy data”, publicly accessible data, non- confidential data, etc. for a given Noun. In other words, each Noun can provide access to a large number of examples of Entities that correspond to that Noun from a variety of sources (e.g., from Integrations, from SKDSs, from the Library itself, automatically generated Entities, etc.) that can be used in a variety of different ways, ranging from testing software (e.g., running test suites), training AI models, and more. In other words, beyond helping with test data, certain machine-learning and artificial intelligence models (e.g., classification of data types) could be trained using the “dummy data” that is made accessible through a given Noun (e.g., CAT, IMAGE, FILE, MESSAGE, ARTICLE, LOGO, SPORTSEVENT, SVGICON,etc.). For example, as the Official Library grows, it could help provide the training data for a model that can classify types of Nouns as a variety of different data is encountered by users in SKApps (“in the wild” so to speak).

[0374] In some embodiments, multiple methods and criteria can be made available through SKL Libraries to help with the recognition, identification, and / or classification of certain types of Nouns. For instance a PDF may be identified by its mime type, a PERSON referenced in an online news article may be identified by the metadata in the websites header. (e.g., schema.org), a CAT (or a representation of a “CAT”) may be identified in a 3D model, a video, and / or an image by using computer vision techniques such as object recognition, etc.

[0375] According to a non-limiting embodiment, an Interface’s profile on the Official Library (and / or another SKL Library) might include: general information and Metadata about the Interface (e.g., developer and / or provider, pricing, security and privacy certifications and practices, performance, terms & conditions, how to access it and / or use, reviews, execution environments, whether it may be used to train AI, etc.); information related to how the Interface may be automatically identified by software; the Schemas which detail the Interfaces’ inputs and outputs are, including the Nouns, Verbs, and other SKL components it works with; information related to which SKApps and SKDSs use the Interface or which could potentially Page 77 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT be easily configured to work with the Interface; information about the Interface’s usage (e.g., usage and performance metrics, any users that have used, interacted with, etc. the Interface, according to the privacy settings of those users); any relationships to other Interfaces, contributors, developers, other Artifacts, etc.; the edit history, versions, etc. of the Verb; and the like.

[0376] According to a non-limiting embodiment, a SKApp’s profile on the Official Library (and / or another SKL Library) might include: general information and Metadata about the SKApp (e.g., developer and / or provider, pricing, security and privacy certifications and practices, performance, terms & conditions, how to access it and / or use, reviews, execution environments, whether it was generated with AI, etc.); information related to how the SKApp may be automatically identified by software; the Schemas which detail what Nouns, Verbs, Interfaces, SKDSs, etc. the SKApps works with, and which others it could be configured to work with; information related to other SKL components which use the SKApp or which could potentially be easily configured to work with the Interface; information about the SKApps’s usage (e.g., usage and performance metrics, any users that have used, interacted with, etc. the Interface, according to the privacy settings of those users); any relationships to other SKApps, contributors, developers, other Artifacts, etc.; the edit history, versions, etc. of the Verb; and the like.

[0377] According to some embodiments, in addition to the lists herein, each profile for a resource on the Official Library could include discussion about the resource, and contributions of developers to the configuration, code, or anything else about the resource.

[0378] According to a non-limiting embodiment, the Official Library may also include profiles for each user displaying the Integrations, Verbs, Nouns, SKApps, SKDSs, Interfaces, etc. they use (e.g., if they allow this information to be public) as well as their contributions, reviews, comments, discussions, etc. around each.

[0379] In some embodiments, the Official Library (and / or another SKL Library) Dictionary of Standard Knowledge (including private or branched instances of the dictionary) may incorporate sample data following the Schemas of Nouns that may be manually created or automatically generated. As the SKL Libraries grow, they may provide these data examples (e.g., through hosting the data and / or Mappings to trusted data sources with Entities of those types of Nouns) in order to test easily. This sample data may be used in test cases to test the Page 78 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT functionality of different parts for the SKApps (e.g., without having to hard code them into the SKApp). INTERFACE LIBRARIES

[0380] According to some embodiments, the SKL Library may include a registry of Interface Components which developers may use to build Interfaces for users (e.g., for graphical interfaces which use the React JavaScript® library). Interface Components may follow the Standard UI Framework or simply use Schemas to represent the Metadata, properties, design tokens, etc. that components written in other frameworks (e.g., React, VueJS, Angular, etc.). Moreover SKL Libraries may include Artifacts like colors, themes, design tokens, icons, and more which may each be related to—and used by—the various other relevant SKL components (e.g., Interfaces, SKApps, etc.). In addition, SKL UI Libraries may include utility Interface Components for keyboard navigable lists, forms, form inputs, buttons, dropdowns, search bars, views for Metadata, graphs, charts, maps, etc. In some embodiments, developers may “plug and play” these different interfaces in no-code (i.e., without having to write code) or low-code environments through the use of a GUI. This would empower the average person to be able to develop sophisticated software that meets their needs exactly, without sacrificing the interoperability or longevity of data.

[0381] The system also allows for interface libraries focused non-graphical Interfaces. For example, developers of voice assistant software agents could access components that help translate speech into usable commands. Similarly, other Interface Components could be used to represent brain interfaces, haptic controls, and other forms of human-computer interaction.

[0382] SKL Libraries may also include other types of Artifacts related to UI, such as scraping scripts or Verbs for certain Interfaces, Integrations, Nouns, and / or combinations thereof. For example, developers using SKL could share or publish a library of code for scraping the profile information on a social media site in order to enrich a user’s contacts. PACKAGES

[0383] According to some embodiments, artifacts within the Official Library may be exposed for use via an SKDS interface such as an API. A developer wanting to use certain SKL artifacts in a SKApp may specify that they want to work with certain Integrations, Nouns and Verbs and the Official Library may find or help the user create the necessary Mappings and Schemas in order to combine them into an easily installable package in the SKApp (e.g., similar to NPM modules). For example, a developer or user may specify that they want their Page 79 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT application to work with FILES, PEOPLE, TASKS, and MESSAGES and support Integrations like Google Drive®, Dropbox®, Gmail®, Slack®, and Asana®. The Dictionary could then provide them with a downloadable package that includes the necessary configurations between the specified and / or related Nouns, Verbs, Interfaces, Integrations, etc. Should the developer and / or user decide to support a new Interface or Integration (e.g., Sharepoint®) at some point in the future, they would be able to specify that and get the additional configurations added to their package.

[0384] In an alternate embodiment, the SKL Library may include common ontologies and their relationships to whichever other Artifacts a given user desires to “package” in order to facilitate the combination of Schemas. This may allow developers or end users to pick and choose certain functionality they wish to obtain from the SKL Libraries without having to download more than they need. For example, a developer wanting to integrate data from many file storage tools may choose the GENERAL FILE MANAGEMENT package which includes the Schema for FILE, FOLDER, PEOPLE, and FILEPERMISSION Nouns, the GETFILESINFOLDER, MOVE, COPY, and DOWNLOAD Verbs, and Mappings between those Nouns and Verbs to the most popular Integrations like Dropbox®, Google Drive®, and OneDrive®.

[0385] In an alternate configuration, developers could simply reference Artifacts and then SKApps could access individual Artifacts directly from the Official Library at runtime (e.g., via a REST API). In this way, developers may not have to download the configurations from the Library, but rather simply access the right version of each of configuration stored directly in the Official Library.

[0386] In yet another configuration, the Official Library may provide additional tooling to help developers download Artifacts in alternate ways that might make most sense for their specific needs. For example, the Official Library could help translate Noun Schemas into SQL in order to serve as the Schema relational databases, classes in a programming language like Ruby® or Java®, type interfaces and / or classes in JavaScript® or Typescript®, etc. SCHEMA MANAGER

[0387] According to some embodiments, SKL Libraries may include tooling to facilitate the installing, uninstalling, editing, and otherwise managing versions for SKL Schemas in a similar way to popular methods and tooling like Git push, Ruby Gems, npm install, etc. Different embodiments of SKL Libraries may help manage Schemas in other codebases, databases, SKDSs, through SKApps’ user interfaces, within the SKL Library itself, Page 80 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT etc. In other embodiments, SKL Libraries may also provide or integrate with graphical user interfaces that may facilitate Schema management. SKL Libraries may also include other interfaces like a command line interface and REST interface.

[0388] In a non-limiting, SKL Libraries may automatically different Schemas in a way similar to Git in order to help see changes between Schemas. In one embodiment, a user may work with an SKDS that uses a Noun called FILE version 1 and then they want to install a SKApp that uses expects FILE v2. When installing the SKApp on the SKDS, the SKApp may show the user a diff of what is different between both Schemas and ask the user if they want to migrate their Entities of FILE from v1 to v2. In another embodiment, the SKApp could show the user the diff of what is different between both Schema versions and ask the user to either install or create a Mapping to address those changes so that the user’s SKDS is able to work with SKApps that expect v1 and v2. In this way, if a given SKApp installs / uses a new Noun that is a synonym or a different version to / of another Noun already in use within an SKDS, then the Schema manager (which may be embedded in the SKDS, the SKL Library, the SKApp, etc.) could look for one or more Mapping between both (from one or more SKL Libraries) and install that Mapping(s) in the SKDS in order to enable the different Nouns to be translated. BRANCHING & VERSIONING

[0389] According to some embodiments, Artifacts and Schemas in SKL Libraries may each have a URI. Each of these Artifacts may also have version identifier that allows the collaborative editing and management of Schemas. This version identifier could for example be in the URI, in the Schema as its own field, in related Mappings.

[0390] According to an embodiment, the Official Library may simply need to index and reference the locations and versions for other ontologies’ Schemas. In another embodiment, the Schemas may be cloned to the Official Library. In yet another embodiment, the Schemas may be cloned to locally hosted SKL Libraries. Any changes to Schemas cloned from the Official Library may be proposed as changes back to the Schemas hosted by the Official Library. The Official Library may provide discussion and collaboration features in order for the person responsible for changing the ontology to explain and discuss the proposed changes. If the Schemas’ maintainers do not want to make the changes, or the Schemas in the SKL Library are references to ontologies managed elsewhere, their respective Schemas may be forked into a different ontology. Page 81 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0391] According to some embodiments, version and release management for each Schema may be done according to the Semantic Versioning specification.

[0392] An embodiment of a SKApp is one that may clone a local copy of Schemas for some of the most popular Integrations from the Official Library. In some embodiments, this SKApp may be termed KnowledgeOS. In order to support custom KnowledgeOS features, these Schemas may be unique customizations or extensions of the normal Schemas that the Official Library shares publicly and that other SKApps use for the same Integrations. For example, KnowledgeOS, or any other SKApp, might use the Schemas for an Integration which detail the Integration’s keyboard shortcuts to display as a reminder for users. The SKApp may also provide additional keyboard shortcuts whenever a user is looking at content from that Integration. To do so, it can modify, and thus use a custom version of, the Schema for each Integration to include the additional keyboard shortcuts

[0393] According to some embodiments, when using KnowledgeOS, if a user visits a website (e.g., an Integration) which is not represented in the Official Library, the SKApp may create an Integration from the Schema for the INTEGRATION data type and include as much information it may about the website (e.g., via the DOM, the Browser API, etc.) and upload this to the Official Library as a “suggested” Integration. The process until this point may be entirely automated. The maintainers of the Official Library may then choose to manually review, edit, accept, or reject the changes to the public repository. In some embodiments, the creation and / or the review and acceptance of changes may also be automated. For example, a heuristic or artificial intelligence could be used to automatically review, edit, accept, or reject the changes. Similarly, web scrapers, web crawlers, and other methods and processes could be employed to automate the generation of Integration profiles, including Schemas, Metadata, configs, etc. The same may be done for other aspects of SKL, such as the collection of data, creation, review, and approval of Schemas (e.g., Nouns, Verbs, Interfaces, etc.).

[0394] In a non-limiting embodiment, updates to Schemas are versioned using a standard versioning scheme (e.g., SemVer). SKApps and other components may have the ability to choose both which branch of the Artifacts they prefer to use (e.g., main vs. a custom branch vs. a branch with suggested changes), as well as the version they use if on the main branch. Page 82 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0395] In another non-limiting embodiment, SKApps and SKDSs also have the option of subscribing to a branch for a given Schema or set of Schemas in order to automatically receive notifications about changes to the resources as they are suggested or edited.

[0396] According to some embodiments, a SKApp or an SKDS may use and store alternate versions of any Artifacts, as this may enable non-standard or custom implementations. For example, an organization might use a custom, proprietary, and confidential data ontology, including custom Nouns, Verbs, etc. In this embodiment, the Schemas and Artifacts corresponding to this confidential ontology are in a locally hosted SKL Library that is not accessible to anyone outside the organization. The Schemas and Artifacts could even be totally disconnected from the Internet so that the Official SKL Library may not be aware of them. If the organization decides to make a Mapping from their proprietary Schemas to one or more popular and public ontologies with Mappings to other components in the Official Library, then that company’s proprietary Schemas, and the SKL components that work with the proprietary Schema, may now also be able to work with several of the components that previously only worked with the public ontology. REGISTRY

[0397] In yet another embodiment, Artifacts in the SKL Library are able to be viewed and downloaded publicly, in an open source way. However, attribution and control of changes and versioning may be given to individuals and organizations by listing certain Schemas, configurations, code or other Artifacts under the profile page of the individual or organization that first introduced said Artifact to the Library. Such individuals or organizations may maintain ownership over those Artifacts and control the approval of requested changes and versioning. They may also choose to give such permissions to other individuals or organizations to help manage and maintain the Artifacts, including but not limited to restricting the training of AI models and / or the use of the artifact by AI models in composing software. In this embodiment, the SKL Library forms a registry wherein developers upload contributions to be shared with the community.

[0398] In some embodiments, the record of such contributions by individuals and organizations to the Library of Artifacts and Mappings could be maintained using blockchain technologies. In the event that money flows through the SKL Library to pay for specific Verbs, Interfaces, and more, the SKL Library may distribute payments or micropayments for every transaction according to the contributions made by various individuals / organizations, which could be stored on a blockchain. Page 83 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0399] According to some embodiments, smart contracts could be considered types of Verbs that get executed when certain conditions are met, such as a payment for a SKApp or a Verb that uses certain other components contributed by other people. Using SKL in conjunction with smart contracts, those payments could automatically be distributed to the people that created or contributed to the one or more components that make up the Knowledge App receiving payment. In some embodiments, an app store provider takes a percentage of the payments that are made through the platform. In this embodiment, people may be properly incentivized to make components in exchange for payments, micropayments or otherwise pre- programmed value that would be distributed through the use of the components and Mappings they created. PRIVATE SKL LIBRARIES

[0400] According to some embodiments, the system may support the hosting and management of private SKL Libraries that may either be connected to the Official Library or hosted in isolation. In this way, organizations and / or individuals may choose to create private Schemas, configurations, code, etc. following the SKL protocol. According to at least one embodiment, these private Artifacts could be hosted privately on the Official Library, in a separate private library such as a private SKDS, or in some combination of the concepts discussed herein. In an embodiment, a bank may want to build applications that integrate with a proprietary database technology which they do not want external individuals or companies to discover. The bank may build Mappings in accordance with the SKL protocol which it uploads to the SKL Library (via the API or website interface) with a field marking them as private to their organization. Only developers that are members of that bank’s organization or applications with security keys authenticating them with the organization may be able to download and use the Mappings to the proprietary database technology.

[0401] Similarly, in yet another embodiment, an organization (e.g., the U.S. Navy) may want to create and manage a custom private ontology that may be represented via custom standard Nouns and / or Verbs that abstract away endpoints from a variety of Integrations. These custom Artifacts could exist in isolation such that they are only mapped to each other privately. Alternatively, they could be related to the Artifacts in the public Library such that they are able to make use of the total capabilities that are publicly available. In other words, the U.S. Navy could make a custom representation of a “Contractor” and only relate it to Nouns, Verbs, Interfaces, and other Artifacts within their private library. Alternatively, they could relate CONTRACTOR to the public representation of CONTRACTOR, if it exists, or ORGANIZATION and Page 84 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT thereby make many of the public Noun ORGANIZATION’S public capabilities and relationships also available via their private Noun CONTRACTOR. For example, the public Noun ORGANIZATION may have an associated Verb that may help keep track of public news mentions (e.g., TRACKNEWSMENTIONS). By relating the necessary fields of the private Noun CONTRACTOR to the public Noun ORGANIZATION, and further classifying it as a child of ORGANIZATION, the public Verb TRACKNEWSMENTIONS could automatically work with any instance of the private Noun contractor even though the public Verb and the private Noun were never directly mapped to each other.

[0402] In some embodiments, users may be able to create custom Verbs without having to upload them to any Dictionary; public or private. Since Verbs may follow a certain Schema, their configuration may be easily created, customized, or otherwise altered directly within an SKDS, the code for a given application, or wherever they are defined. In other words, since Verbs may be composed of a configuration that does not actually contain the processing logic within it, but rather what logic to call and when. This may enable the simple creation of Verbs that may call other Verbs according to specified configuration and triggers, such as a specific schedule or trigger(s). In this embodiment, users and developers may be able to use custom Verbs to create automations that may in turn be composed of, or otherwise reference, standard Nouns and Verbs. The benefit of this approach is that an automation may be easily made to run over all Messages regardless of which Integration that message is actually sent through. The user may be able to easily determine what to do with every Message, such as check for customers’ PII (personally identifiable information) or other sensitive information that should not be shared externally, regardless of the messaging service. OPERATING ENVIRONMENTS

[0403] According to some embodiments, SKL components may have Metadata to suggest which ecosystem and / or platforms they may run on. For example, certain components may only be able to work on a blockchain such as Ethereum®, while others may only be able to work on a device that runs iOS® (such as an iPhone®). In other embodiments, users may only want to connect components that meet certain security and / or privacy requirements for compliance (e.g., SOC 2, HIPAA, etc.). The configurations that determine the operating environment for a given set of connected SKL components may be automatically managed or manually specified. In various embodiments, these configurations may be held within the SKDS, as part of the Coordinator, and / or within Knowledge Apps. Page 85 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0404] In some embodiments, when configurations are held by an SKDS, that SKDS may restrict which Verbs, Interfaces, and Knowledge Apps are able to interact with data within that SKDS. For example, an organization might manually create a whitelist of acceptable components and / or Knowledge Apps that may be connected to their SKDS. Alternatively, they might simply specify that only HIPAA certified components and / or Knowledge Apps are able to be connected. In yet another embodiment, the SKDS may exist on a device that is not connected to the internet and is therefore only able to work with other components that may be run on device or otherwise within its network without having to connect to the internet. In another embodiment, an SKDS that only stores data in a decentralized way may specify that all data must be stored on IPFS (InterPlanetary File System) and that all processing must be documented via transactions stored on the Ethereum® blockchain (or for example, other layer 1 chains that might support smart contracts). Similarly, certain SKL Artifacts might only work in virtual or augmented environments.

[0405] In some embodiments, SKDSs may restrict which processors / interfaces / etc. are used together. This may, for example, be embedded into the SKDS configuration in the Library. This is a way for enterprise customers (e.g., the U.S. Navy) to ensure that only approved software components are used with their data. MANAGING LIBRARIES

[0406] According to a non-limiting embodiment, SKL Libraries may provide a variety of systems and methods that can deduplicate, correlate, interrelate, and provide recommendations of Entities. Since, according to the embodiment, an SKL Library is an SKDS that primarily hold the SKL Schemas in and of themselves (e.g., the Schema for a FILE Noun, a SHARE Verb, a CARD Interface, etc.), the SKL Library’s nodal data structure and the methods and processes used to build and maintain it can therefore applied to the Schemas and other Artifacts.

[0407] In other words, the Official Library can store or otherwise index or represent Entities in an SKDS that can be deduplicated, interlinked, and contextualized. For example, an SKL Library may establish that the Google Drive® API and Google Drive® website are both two different representations of a broader Google Drive® Integration Entity. This association can be made by, for example, automatically comparing metadata and establishing CueIDs and / or Unique IDs associated with each Entity, how that Entity is used, what common relationships any two given Entities may have, and more. Similarly, Entities can be clustered based on their properties and / or relationships to other Entities (e.g., both Google Drive® API Page 86 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT and Google Drive® website have relationships to a FILE Noun, a FOLDER Noun, etc.), as depicted in FIG.34. Machine-learning algorithms, such as k-means clustering, and / or some of the other methods described herein can also be used to find similar Entities within SKL Libraries. In another non-limiting example, semantic similarity between words can be established (e.g., Google Drive® API and Google Drive® website use many similar words). In yet another example, users can establish and classify links manually across Entities.

[0408] Several types of relationships between Entities and / or Artifacts can be established and managed automatically, semi-automatically, and / or manually. For example, any type of Schemas and Artifacts, not just Integrations, can be linked, classified, and / or otherwise have a relationship with one or more Entities in the nodal data structure change. This includes not just the deduplication of Nouns, Verbs, Interfaces, SKDSs, SKApps, and the data they represent, but also other types of relationship-building and relationship-management.

[0409] For example, SKL Libraries may let users upload OpenAPI® specifications for given Integrations in order to help facilitate the creation and management of Schemas and Mappings related to the Integration. The SKL Library may then automatically parse the contents of the OpenAPI® specification and compare the methods, inputs, outputs, and any other information provided or otherwise available (e.g., the Integration’s website, the Integration API’s website documenting the API, other third-party information such as Wikidata®, etc.) in order to gather information, automatically or semi-automatically build Schemas, create or modify CueIDs and / or UniqueIDs related to that Integration (e.g., for each API endpoint) such that they can be automatically compared to other existing Schemas that may each also have one or more CueIDs and / or UniqueIDs, and so on. In this way an SKL Library may use the methods described herein in order to automatically and / or semi- automatically help establish relationships and recommendations, such as deduplication, Noun, Verb, and Mapping recommendations, between related Entities (e.g., Schemas, components, Artifacts, etc.).

[0410] In an alternate embodiment, various Schemas (e.g., Nouns and Verbs) can be automatically created that are unique to each Integration. For instance, each Integration’s representation of Nouns and Verbs (such as PERSON, ORGANIZATION, SHARE, etc.) can be created as Schema and then deduplicated. In some embodiments, this may create redundancies between the Integration Schema and the Integration-specific Verbs and Nouns (e.g., because the Verbs may are already defined as Schema through OpenAPI®), however, doing so may be helpful with the automated and / or semi-automated management of various Schemas in SKL Page 87 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT Libraries by being able to more effectively compare specific Schemas in discrete ways. Similar results may be otherwise achieved through the use of natural language processing techniques such as tokenization. RECOMMENDATIONS OF SKL LIBRARY ARTIFACTS

[0411] According to a non-limiting embodiment, SKL Libraries can provide automatically, semi-automatically, and / or manually generated and / or recommended relationships and / or classifications between SKL Artifacts (e.g., and the data the Schemas represent) to users in a variety of ways. For instance, administrators of the SKL Libraries trying to manage Artifacts in an SKL Library may manually link two or more Noun nodes as being related (or manually create a Mapping between at least one Verb and a Noun, etc.). In the process of manually linking two Nouns (e.g., as synonyms, or some other type of relationship) the administrators may use a graphical user interface showing the profile of a Noun, similar to the Integration profile shown in FIG. 33, in order to access a button to “add a relationship” (not shown in FIG.33) between that Noun and some other Entity. This can reveal a list of other Artifacts (e.g., Nouns) that have been or are being suggested (e.g., automatically, by another user, etc.) as related to the current Noun. The administrators may choose to establish a link with any Artifact in that list, or they may alternatively search for a different Artifacts. In either case, the SKL Library may employ one or more different algorithms to rank the results presented (e.g., based on existing linkages, based on semantic similarity, based on CueIDs and / or UniqueIDs, etc.).

[0412] In another example, as a user or developer searches for, creates, modifies, and / or otherwise interacts with the Library of SKL Artifacts, the SKL Library may provide and / or recommend other related SKL Artifacts that may be relevant. In other words, a user or developer creating a new Noun called HUMAN can be presented with other existing Nouns which are synonyms or which may otherwise be relevant to his / her work such as PERSON, MAN, WOMAN, INDIVIDUAL, etc. The SKL Library might similarly provide other relevant SKL Artifacts including related Interfaces, Verbs, and more. This can help the user or developer avoid creating duplicate Nouns and take most advantage of the work that has already done within the Library. In this way, contextually relevant information can be identified and presented around any given SKL Artifact. Furthermore, these methods can also help avoid the duplication of Nouns, Verbs, and SKL Artifacts, and thereby help maintain a clean and usable SKL Library. Page 88 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0413] In some embodiments, SKL Libraries can suggest relationships as well as the classifications for those relationships between any given Entities, as described elsewhere herein.

[0414] Further described, each Noun within an SKL Library can dictate and / or reference a one or more methods for the identification of said data type / Noun. For example, while a user is interacting with a given website, the SKL Library might have the information necessary to identify what type of data that website represents. SKL configurations can automatically look through the website’s HTML for embedded information that might classify the page as a social profile or alternatively classify that the website is a social profile for a Person by matching the website’s URL structure to existing configurations in the SKL Library. Once a given piece of data is identified as being a particular Noun, or a particular Noun from a particular Integration, the SKL Library will be able to match a variety of other SKL components that can work with the data in its existing environment. For example, if a user is looking at someone’s LinkedIn® profile, the SKL Library can suggest a variety of existing Verbs (and / or other SKL Artifacts) that a user can easily use over that profile. For example, the user can elect to create a new, or enrich an existing, Contact in his / her SKDS with the data found on the LinkedIn page. The user can similarly choose to run a Verb that uses a separate Integration to find the email and other contact information for the person shown on the LinkedIn profile. In this way, relevant Verbs and other SKL Library Artifacts can be easily shown and / or recommended contextually as the user is working.

[0415] Some of these SKL Artifacts can be preinstalled or preconfigured to run automatically any time the user visits a person’s LinkedIn® profile, so that the user’s existing contacts are constantly being enriched and updated with data from their LinkedIn® profiles. Furthermore, as is described in more detail below, some of these SKL Artifacts, such as the LinkedIn® contact enriching Verb, can require payment from the user by the Verb creator.

[0416] In another embodiment, the analytics server might be able to identify the user’s intent based on more than just the identification of what he / she may have in focus on the screen. For example, the analytics server may be able to draw more information from a user’s SKDS such as his / her current role, project, and objective and start to recommend specific actions, Verbs, and other SKL Artifacts that may be useful to the user. For instance, if a user is reviewing a document that relates to a particular project and then opens a new spreadsheet while billing his time to the project. As a result, it can be assumed that the user’s interaction with the spreadsheet is related to the project. Page 89 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0417] Using the various methods described herein, an analytics server, in conjunction with an SKL Library, can identify a user’s electronic content and electronic context and then present potentially related and / or relevant Nouns, Verbs, Interfaces, Integrations, SKDS, etc. as shown in the figure below. Relevance can between SKL Artifacts and electronic content and / or electronic context can be established in a number of ways, including but not limited to graphical analyses, semantic analyses, activity analyses, and more. As described herein, relationships and recommendations can be synthesized, such as by analyses of text, images, videos, and more in order to establish semantic similarity, content similarity, activity similarity, etc.

[0418] For example, FIG. 35 depicts a graphical user interface of an online word processor application 3504, according to an embodiment. In this example, the analytics server establishes that certain SKL Artifacts 3502a–d are included in the electronic content and therefore is able to present other relevant Artifacts that may add value to end users of the online word processor. In this non-limiting example, FIG.36 illustrates some of the Nouns 3602 that the analytics server may automatically identify within electronic content include WEBSITE, DOCUMENT, TEXT, GOOGLE DRIVE, GOOGLE DOCS, and GOOGLE CHROME. Using an SKL Library, the analytics server is thereby able to identify related Verbs such as SHARE, SUMMARIZETEXT, GENERATECOUNTERARGUMENTS, and SEERELATEDKNOWLEDGE, as well as present other capabilities that the SKL Library can facilitate. Some of these related Verbs may be sponsored by a given provider (e.g., services like OpenAI®, Google Cloud Platform®, Azure®, Amazon Web Services®, etc. that may have been previously only accessible to developers and / or users with technical know-how) that wants to market certain capabilities to end-users directly based on the identified electronic content and / or electronic context. These capabilities may include exploring the data inside the document through a natural-language query such as the one shown on FIG.18 where the user can ask questions about a document (and / or related Entities) or access more information, a graph-like interface where the user can explore relationships and similarities to other Entities in one or more SKDSs (e.g., SKL Libraries, private nodal data structures with productivity data and / or personal health information, etc.).

[0419] FIG.51 shows a graphical user interface where a user is interacting with a large language model that is able to retrieve data (e.g., Entities, and information about and related to Entities) and execute capabilities defined through SKL (e.g., Verbs in a user’s SKDS, in an SKL Library, etc.) in a chat-like interface, according to an embodiment. In this example a user Page 90 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT is able to execute Verbs such as “run payroll” through natural language commands communicated conversationally. The user is further able to engage with the chat-like interface to ask for clarification, gather more information contextually, change parameters, and more. In some embodiments, the user is able to speak to the chat-like interface rather than type out questions, commands, responses, and the like.

[0420] In this way, SKL Libraries can be used to present contextually relevant data and capabilities to end-users. Some of these capabilities can be abstracted away from a variety of competing products such as text summarization services from Amazon Web Services®, Google Cloud Platform®, Azure®, etc. Certain providers may choose to pay the providers of certain analytics servers and / or SKL Libraries for a higher ranking on suggestions.

[0421] In some embodiments, a user is able to use other types of human-computer interaction interfaces such as haptic devices, brain interface, and the like to communicate with an SKL-powered system. For instance, a brain interface might be able to recognize certain intentions (e.g., language expressions, feelings, etc.) through monitoring brain signals and be able to find data and capabilities from SKDSs, Integrations, and / or SKL Libraries in order to contextually enable the user to access data and / or leverage MONETIZATION AND MANAGEMENT OF SKL

[0422] As discussed herein, certain SKL Artifacts may require payment. For example, a user reading a long article may wish to use a text summarization Verb to help him / her understand the gist of what he / she is reading in a short amount of time. According to an embodiment, user of a SKApp (e.g., a web browser, a browser extension, etc.) may choose ahereinSUMMARIZETEXThereinVerb while reading the long article and be able to specify whether he / she wants to use a given Integration to summarize said text, such as Google® Cloud Platform’s service, Amazon Web Services®’ service, OpenAI’s® service, and so on. Several of these services require payment which can be facilitated via the Official Library. The Official Library may charge a processing and / or platform fee over whatever payment is made through the Official Library.

[0423] Furthermore, the developers that contributed the Schemas (e.g., Integrations, Nouns, Verbs, and / or Mappings) to the Official Library may also request compensation on any payment that uses their Schemas and / or SKL Artifacts. In this case, the platform fee can be distributed in part or in whole to all the contributors that contribute to the Official Library. This creates an incentive for people to contribute components to the overall system, thereby Page 91 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT increasing the ability of any individual to build and customize software that solves an ever- increasing breadth of use cases.

[0424] In a non-limiting embodiment, all contributions to and usage of SKL Artifacts, including Nouns, Verbs, Mappings, Interfaces, and more may be tracked so that they can be properly attributed. The Official Library can distribute payments to contributors proportional to the amount of usage their Artifacts are receiving.

[0425] In another non-limiting embodiment, all contributions to SKL Artifacts can be maintained on a blockchain, and any payment logic can be embedded within smart contracts on said chain such that any payment related to and / or usage of SKL Artifacts can automatically distribute the payments to the corresponding contributors in a pre-established manner. In other words, the Official Library can establish a protocol to track and incentivize the contributions to, and development of, SKL. Furthermore, a decentralized autonomous organization (“DAO”) can be established to set the rules for how payments and incentives are distributed to stakeholders of the Official Library and ecosystem (e.g., the process to share revenue based on contributions, what the Official Library’s commission is, etc.).

[0426] In some embodiments, there may be incentive structures to encourage people to contribute to this community, for example by tokenizing contributions, requiring that contributions are staked by something of value, and / or using a logic for evaluating the value of contributions.

[0427] In yet another embodiment, the SKL Library may also provide advertising opportunities such as the prioritization in the placement of Google Cloud’s® text summarization service over Amazon’s® text summarization service in the example herein. Given that the Official Library can become the central access point for software components that either use or are represented with SKL methods or Schemas, the Official Library may be considered as the marketplace of software components, including Nouns, Verbs, Integrations, Interfaces, and more. The Official Library can offer one or more interfaces to be able to access all the Artifacts it contains. For example, the Official Library GUI can help users search and browse for components and the Official Library API can help users search or access information in other ways that enable contextual access while they are working normally.

[0428] According to some embodiments, the SKL Libraries may also offer to organizations various managed, private SKL Libraries along in exchange for a subscription fee (e.g., software as a service, platform as a service, etc.). In this way, and as described elsewhere Page 92 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT herein, an organization can accumulate private SKL Artifacts that can help them establish a competitive advantage over time by compounding their ability to reuse software components across needs, projects, and use cases. LOW-CODE AND NO-CODE COMPOSITION

[0429] In a non-limiting example, an airline has a variety of different systems and databases that each hold historical and operational records related to flights, passengers, tickets, loyalty program statuses, stewardesses, pilots, and more. The airline wants to be able to easily create portals, interfaces, and / or apps that can easily access data regardless of where that data resides. In other words, it wants to create unified APIs for all of its data and software capabilities. Using SKL, it abstract away the various systems into one easily manageable ontology that allows it to search for all the flights that have been flown, are currently in the air or scheduled, along with all the passengers, bags, stewardesses, pilots, and more. This airline could do this within an SKL Library that allows them to create and edit Schemas in a low- or no-code way. In yet a third example, the Official Library might expose certain Verbs such as herein SUGGESTONTOLOGY or GENERATEONTOLOGY given a particular set of descriptions, data source Schemas, and / or other information such as desired use cases and / or user stories. These Verbs could in turn use artificial intelligence techniques, such as leveraging large language models, to propose the ontology the airline may need as well as the Mappings to all the necessary data sources.

[0430] Beyond unifying software capabilities, SKL can enable this airline to unify its data, for example by deduplicating and / or recommending deduplications and / or other relationships between people across databases, records, etc. This would improve the airline’s ability to create and manage custom software that help provide holistic data, analyses, compliance, automations, and more.

[0431] The airline might then choose to create Mappings between its ontology and other existing Schemas in the Official Dictionary, such as other Nouns, Verbs, Interfaces, etc. As described herein, these relationships could be established and managed in a manual, semi- automatic, or fully-automatic way. As they create the SKL Schemas to represent and translate and / or transform data types (Nouns), capabilities (Verbs), Interfaces, Knowledge Apps, other data sources and systems (Integrations), Mappings, and more into a given ontology, they are all accumulated in a unified index of SKL components (e.g., an SKL Library). This Library of composable components would serve as the repository of “Lego® bricks” (so to speak) that Page 93 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT can be customized and / or put together to make new SKApps, Verbs, automations, etc. according to the airline’s needs.

[0432] Described further, the airline is then able to use their growing SKL Library of components to easily create automations such as a loyalty recognition program where they can choose which passenger(s) on a given flight to recognize and or give special treatment to based on data about each passenger’s flight history, personal information, and more. Where previously this would have required a lot of complex logic tied to various data sources, SKL abstracts and simplifies the process through a semantic integration approach. The airline is then able to use any existing components from the Official Library to build their custom applications, automations, SKApps, etc.

[0433] In some embodiments, these SKL components can be compiled together by a developer building an application using custom code or manually using a code editor interface. In other embodiments, these components can be fit together using a no-code interface. Such an interface would allow non-developers to create new systems by combining and / or customizing components similar to popular no-code application and workflow builders. FIGS. 42-44 illustrate non-limiting embodiments of how Schemas can be parametrically altered to change Interface Components and FIGS. 25-28 illustrate how more easily usable graphical user interfaces can be added over Schemas to facilitate the ability of non-technical users to edit Schemas. Together these examples demonstrate how SKL Libraries could be used find various Schemas, combine them, and customize them in order to build sophisticated applications in no- code ways.

[0434] In yet another embodiment, a user is able to describe (e.g., through natural language, through comparison, through reference, etc.) the software and capabilities they want (e.g., an application that can consolidate all productivity data from file storage tools, communication tools, scheduling tools, and project management tools), the data they want the users to interact with (e.g., where productivity data includes files, messages, tasks, and people), how they want the data stored (e.g,. where each user stores their data in a graph database locally on their Macbook® Pro running Apple® silicon), and how they interact with the application (e.g., and where the users can interact with the application using a search functionality and profiles for entities that look similar to LinkedIn profiles). In this non-limiting example, the SKL Library, and / or the analytics server processing the data, may be able to use a large language model (“LLM”) to find the SKL Schemas most relevant to the description. To do so, a developer may find or create a language model suitable for distinguishing between features Page 94 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT of SKL Schemas. Then, a vector embedding may be created for each SKL Schema and those vectors inserted into a vector database. Next, it may process the description by generating one or move vector embeddings from the input text. The input embedding may then be used to query against a database of vectors representing each SKL Schema using a distance metric (e.g., Euclidean, Cosine, etc.) to collect relevant and / or similar Nouns, Verbs, Interfaces, SKDSs, SKApps, etc. from the Official Library (and elsewhere). The Schemas found most relevant may be combined into a fully working SKApp according to the description. This synthesis step could be performed by a large language model trained on vast amounts of code and possibly aided by some heuristics about SKL so that it can predict how a library like Standard SDK would be used to create the described application.

[0435] In the event that there are multiple options for components, (e.g., multiple ontologies, multiple interfaces, etc.) that can be chosen (e.g., by the analytics server) in the composition of the SKApp, then the AI system could either automatically make a decision, or prompt the user for additional input, feedback, and / or clarification.

[0436] In another embodiment, after receiving the description from the user, the system might generate new Nouns, Verbs, Mappings, Integrations, etc. using a large language model trained with data from SKL Libraries. The LLM might also use third-party data as part of its training set in order to improve the capabilities of the model in generating new components that have not previously existed in SKL Libraries.

[0437] In another embodiment, after receiving the description of the application from the user, the system may also query one or more SKL Libraries and / or other sources to collect relevant and / or similar Schemas and SKL components in order to generate entirely new Schemas and components using generative AI techniques, and then combine them into a cohesive SKApp.

[0438] Due to the potential modular, interoperable, and parametrically editable nature of SKL, a user creating software across any of these examples may use the output of any of these processes as a starting point for further editing of the software. In other words, a user may start programming a custom SKApp, then move it into the no-code / low-code graphical user interface builder mentioned herein to customize certain components. The user could then add in new features and functionality by describing the desired capabilities to an input (e.g., a chat interface) that can use a LLM to help generate new and / or combine existing components and add them to the SKApp. Any output of SKL Schemas that are used to create a SKApp Page 95 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT could then be parametrically altered, tweaked, and customized after the fact according to the methods described above (e.g., through traditional programming and software development, through the configuration of Schemas as shown in FIGS.42-44, through custom interfaces as suggested through FIGs.25-28, some combination of these methods, etc.).

[0439] In these ways and more, SKL Libraries can be used to easily create and manage custom components, Schemas, SKApps, and more that can deliver complex, sophisticated, and powerful solutions through software. SKL APP FRONTEND FRAMEWORKS

[0440] According to some embodiments, the SKL Interface Components may be defined through Schemas and configuration such that a front-end framework can enable application developers to contribute, reuse, and share UI components that are capable of being interoperable over many different data formats. This is referred to herein as the SKL Interface System, SKL Interface Framework, or Standard UI, and may consist of several parts.

[0441] First, a protocol for how applications may automatically translate data types into the particular formats required by UI components. This may be done using SKL Mappings. Second, a protocol for communication between UI components and their embedding application. Third, an open source registry where anyone may publish their UI components and Mappings for other people to discover and use. This is part of the Standard Knowledge Library. MAPPINGS

[0442] According to some embodiments, upon receipt of a specific component to render and data conforming to a specific SKL Noun, the Interface Engine searches for a NOUNINTERFACEMAPPING, which relates the Interface Component and the Noun. This Mapping may be executed using an SKL Engine, and the response may be used to render the component. Optionally, if a Mapping is not found, the Engine may choose to pass the data directly to the component to be rendered as the fields used by the data may naturally match up with the properties expected by the component. To render the component, the Engine may either load the component’s code from its soURCEURL property or recursively render the UI defined in its noDESPROPERty. NODES DEFINITION

[0443] According to some embodiments, Interface Components which do not require complex logic defined through code, may have their entire content specified through their SKL Schema in the nodes field. Many UI frameworks may include a set of built in “primitives.” For Page 96 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT example, HTML may have a set of standard tags which are expected to be implemented in the same way by any HTML rendering engine such as “div,” “p,” “h1,” “h2,” etc. Likewise, the SKL Interface Framework may expect Engines to implement a standard set of primitive interface components. According to various configurations, these components—while not limited to—may include the following:

[0444] Container - defining a section which may contain a sub tree of other components.

[0445] Text - defining a block which contains a text which may be styled.

[0446] Image - defining a block which displays an image through a source URL.

[0447] These primitive components may be constructed as a tree of RDF nodes in RDF serialization. According to one embodiment using JSON-LD (context omitted for brevity): { ... “https: / / skl.standard.storage / properties / nodes”: [ { “@type”: “https: / / skl.standard.storage / interface / Container,” “https: / / skl.standard.storage / properties / styling”: { ... }, “https: / / skl.standard.storage / properties / nodes”: [ { “@type”: “https: / / skl.standard.storage / interface / Text,” “https: / / skl.standard.storage / properties / styling”: { ... }, “https: / / skl.standard.storage / properties / propertiesMapping”: { “@type”: “rr:TriplesMap,” “rml:logicalSource”: { ... }, “rr:subjectMap”: { ... }, “rr:predicateObjectMap”: [ ... ] } } ] ... } Page 97 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0448] As shown herein, in addition to a tree of sub-nodes, a Node may include properties specifying styling, and a property Mapping. STYLING & THEMES

[0449] According to some embodiments, a UI rendering engine may include a specific format or ontology of styling which may be applied to components within the system, for example, CSS within web browsers. Such styling formats as CSS may be constructed of rather simple key value pairs and may thus be translated easily between formats and languages. Thus, the styling field of a node may be written in a generalized styling format and translated by the SKL Interface Engine it is read by into the specific styling language used by the environment that a component is being rendered into (e.g., web browser vs. mobile app).

[0450] In one embodiment, the styling field includes styling rules written in the format required by a CSS-in-JS library (e.g., Emotion, Styled Components, etc.), built to be rendered in React® or another JavaScript® UI framework.

[0451] In another embodiment, the values of the styles defined in the styling field could use a special format to encode Design Tokens following a specification, such as that defined by the W3C Design Tokens Community Group. These values may be swapped out when the component is rendered based on a supplied theme, or “source” of those design tokens. For example, take the styling field defined within a component like so: “https: / / skl.standard.storage / properties / styling”: { “borderRadius”: “{size.radius.3x},” “padding”: “{space.3x},” “Box®Shadow”: “{shadow},” “backgroundColor”: “{color.background.primary},” “border”: “{border.normal},” “display”: “flex,” “alignItems”: “center,” “cursor”: “pointer,” “maxWidth”: “800px,” “margin”: “0 auto {space.2x} auto” }

[0452] Each value within the styling object which contains a value surrounded by curly brackets {…} denotes where a value should be replaced from the currently used theme. Using the Design Tokens specification, a dot within one of these sections of curly brackets, may Page 98 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT denote accessing a nested property of an object. As such, the values for the tokens in the snippet herein would be able to be filled with values from the designTokens field of the following theme (shown in JSON-LD): { “@context”: { “https: / / skl.standard.storage / properties / designTokens”: { “@type”: “@json” } }, “@id”: “https: / / skl.standard.storage / data / LightTheme,” “@type”: “https: / / skl.standard.storage / nouns / StylingTheme,” “https: / / skl.standard.storage / properties / name”: “Light,” “https: / / skl.standard.storage / properties / designTokens”: { “color”: { “$type”: “color,” “shadow”: { “$value”: “#00000014” }, “text”: { “primary”: { “$value”: “#333333” }, “secondary”: { “$value”: “#555555” } }, “background”: { “primary”: { “$value”: “#FFFFFF” }, “secondary”: { “$value”: “#F2F2F2” }, “error”: { “$value”: “#fdb0ba80” }, “success”: { “$value”: “#88ef9080” }, “warning”: { “$value”: “#ffde4080” } }, “border”: { “primary”: { “$value”: “#a6a6a6” }, “secondary”: { “$value”: “#BFBFBF” } } }, “space”: { “$type”: “dimension,” “0x”: { “$value”: “0px” }, “1x”: { “$value”: “5px” }, “2x”: { “$value”: “10px” }, Page 99 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT “3x”: { “$value”: “15px” } }, “size”: { “$type”: “dimension,” “0x”: { “$value”: “{space.0x}” }, “1x”: { “$value”: “{space.1x}” }, “2x”: { “$value”: “{space.2x}” }, “radius”: { “0x”: { “$value”: “0px” }, “1x”: { “$value”: “3px” }, “2x”: { “$value”: “5px” }, “shadow”: { “$type”: “shadow,” “$value”: { “color”: “{color.shadow},” “offsetX”: “0rem,” “offsetY”: “0.25rem,” “blur”: “0.5rem,” “spread”: “0rem” }, “border”: { “normal”: { “$type”: “border,” “$value”: { “color”: “{color.border.primary},” “width”: “1px,” “style”: “solid” } “hover”: { “$type”: “border,” “$value”: { Page 100 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT “color”: “{color.border.secondary},” “width”: “1px,” “style”: “solid” } } }

[0453] According to an embodiment, the SKL Interface Engine may be responsible for resolving the theme styling for any component it renders. As shown in the snippet herein, a theme used by an SKL Interface Engine may itself be a Noun within the SKL framework. In this embodiment, an application developer or user of an application could choose to have several themes available to switch between. An application may hardcode a set of themes, or use an SKL Engine to find the available themes within a user’s chosen Schemas and display them by name somewhere in the application’s interface to choose between. Switching a theme would change the styling of the components rendered by the SKL Interface Engine in real time.

[0454] In other embodiments, styles may also be applied through a list of reusable labels attached to a predefined set of styles, such as CSS classes, specified statically in a field of an SKL Interface Component, or specified dynamically via a property that an SKL Interface Component accepts. In a non-limiting example below, an Interface Component’s configuration may contain one of the following: “https: / / skl.standard.storage / properties / classes”: “left-aligned thick-border medium-padding” “https: / / skl.standard.storage / properties / classes”: [“left-aligned,” “thick-border,” “medium- padding”]

[0455] These additions and variations may be standardized within SKL, or left open to the Engine implementation. In the latter embodiment, it may be that only specific component configurations would be able to be used with specific SKL Interface Engines. PROPERTY MAPPING

[0456] According to some embodiments, Mappings may not be included within a Schema, in other embodiments Mappings may be included within a Schema. In such an embodiment, these Mappings are meant to move properties from a higher-level set of data to a more specific subset. According to some embodiments, the property Mappings are simply selecting certain fields to use within nested primitive components down the tree of nodes. For Page 101 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT example, in constructing the configuration for a Card component, the Card may include an outer Container component, with an image and some text inside. The SKL Interface Engine that will render a Card’s configuration may include support for primitives for ‘Container,’ ‘Image,’ and ‘Text.’ As such, there may be a specification stating that the Image primitive component accepts a parameter called src for the URL of the image, and the ‘Text’ component has a parameter called contents for the text it will contain. The ‘Container’ component may render its sub-nodes inside of a wrapper element.

[0457] According to an embodiment, the ‘Card’ component may be called ‘imageSrc’ and ‘headerText.’ RML may be used to define the configuration so that ‘imageSrc’ and ‘headerText’ get used as the src and contents properties of the primitive Image and Text components respectively. The following is an example of the configuration used to implement the scenario described herein with various omissions for brevity: { “@id”: “https: / / skl.standard.storage / data / cardInterface,” “@type”: “https: / / skl.standard.storage / nouns / InterfaceComponent,” “https: / / skl.standard.storage / properties / name”: “Card,” “https: / / skl.standard.storage / properties / parameters”: { “@type”: “shacl:NodeShape,” “shacl:targetClass”: “https: / / skl.standard.storage / nouns / Parameters,” “shacl:property”: [ “shacl:datatype”: “xsd:string,” “shacl:maxCount”: 1, “shacl:name”: “imageSrc,” “shacl:path”: “https: / / skl.standard.storage / properties / imageSrc” “shacl:datatype”: “xsd:string,” “shacl:maxCount”: 1, “shacl:name”: “title,” “shacl:path”: “https: / / skl.standard.storage / properties / headerText” ] Page 102 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT “https: / / skl.standard.storage / properties / parametersContext”: { “imageSrc”: { “@id”: “https: / / skl.standard.storage / properties / imageSrc,” “@type”: “http: / / www.w3.org / 2001 / XMLSchema#string” “headerText”: { “@id”: “https: / / skl.standard.storage / properties / title,” “@type”: “http: / / www.w3.org / 2001 / XMLSchema#string” } }, “https: / / skl.standard.storage / properties / nodes”: [ “@type”: “https: / / skl.standard.storage / interface / Container,” “https: / / skl.standard.storage / properties / nodes”: [ { “@type”: “https: / / skl.standard.storage / interface / Image,” “https: / / skl.standard.storage / properties / propertiesMapping”: { “@type”: “rr:TriplesMap,” “rml:logicalSource”: { ... }, “rr:subjectMap”: { ... }, “rr:predicateObjectMap”: [ “@type”: “rr:PredicateObjectMap,” “rr:object”: “https: / / skl.standard.storage / Mappings / frameObject,” “rr:predicate”: “rdf:type” }, { “@type”: “rr:PredicateObjectMap,” “rr:predicate”: “https: / / skl.standard.storage / properties / src,” “rr:objectMap”: { “@type”: “rr:ObjectMap,” “rr:reference”: “imageSrc” } Page 103 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT } } ] { “@type”: “https: / / skl.standard.storage / interface / Text,” “https: / / skl.standard.storage / properties / propertiesMapping”: { “@type”: “rr:TriplesMap,” “rml:logicalSource”: { ... }, “rr:subjectMap”: { ... }, “rr:predicateObjectMap”: [ { “@type”: “rr:PredicateObjectMap,” “rr:object”: “https: / / skl.standard.storage / Mappings / frameObject,” “rr:predicate”: “rdf:type” }, “@type”: “rr:PredicateObjectMap,” “rr:predicate”: “https: / / skl.standard.storage / properties / contents,” “rr:objectMap”: { “@type”: “rr:ObjectMap,” “rr:reference”: “headerText” } } ] } ] }

[0458] As seen with the Container node, if any node within the tree does not specify a PROPERTIESMAPPING field, the SKL Interface Engine may be expected to pass all the properties supplied to it to any children it renders (the Image and Textcomponents in this case). The Engine may then perform the Mappings specified in the nested configuration for the Image and Text components and render each with the output of the Mappings. In this embodiment, more Page 104 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT complex or larger interface components may be easily composed out of smaller or simpler building blocks through configuration alone. SOURCE DEFINITION

[0459] In yet another non-limiting embodiment, a component may instead specify a sOURCEURL field from which the source code of the component may be downloaded and run. Depending on the SKL Interface Engine used and the environment that Engine is rendering into, there may be restrictions on the components that may be rendered. For example, using an Engine that is built for rendering SKL Interface Components into web pages, an applicable component’s source code might have to be a JavaScript module, served with the Content-Type: text / javascript header and include specially formatted configuration file (e.g., a package.json file in a node package module).

[0460] Upon encountering a component with a SOURCEURL, an SKL Interface Engine may download the component’s source code, or retrieve it from a cache if it has downloaded the same version of the component before. As noted previously, the Engine may find and perform a Mapping to translate the supplied data into the format required as properties to the component. REGISTRY

[0461] As noted previously, both the configuration of SKL Interface Components and their implementations in code (if they specify a sOURCEURL) may be made available in the SKL Libraries (e.g., the Official Library), according to some embodiments. In addition to documenting their configurations and uses, and showing examples and test cases, the Library may also act as a registry from which component configurations and implementations may be downloaded.

[0462] A major use case of the Official Library may be to facilitate individuals to install SKL Schemas into their personal SKDS so that applications they may access preferred component configurations, themes, and more. However, in other embodiments, the SKL Interface Framework may be used entirely independently of the rest of the Standard Knowledge ecosystem. An application may choose to construct and bundle its own set of custom Schemas for Interface Components, Themes, and Mappings, and use them with an SKL Interface Engine to build its user interface without using the registry nor building in compatibility with users’ SKDSs. Page 105 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT API ABSTRACTION

[0463] According to some embodiments, general API conventions may have standardized and widely used specifications which serve as a bridge between the human and machine understandings of APIs. In these embodiments, these specifications are used for documentation and SDK code generation. SKL Engines may use OpenAPI specifications to dynamically send web requests to REST APIs based on an OpenAPI operation name. OpenAPI specifications may be used by users of Standard API to describe the API endpoints they wish to make available through a SKApp. This SKApp may be called Standard API. Once these are defined, Standard API may dynamically validate and authenticate incoming web requests according to the specification and perform Mappings to fulfill the request’s operation and respond with a response also validate against the specification.

[0464] A user of Standard API may have an OpenAPI operation such as the one below (various omissions for brevity): ... “ / files / get_Metadata”: { “post”: { “summary”: “Files - Get Metadata,” “operationID”: “FilesGetMetadata,” “security”: [ `{ “apiKey”: [] } “requestBody”: { “$ref”: “# / components / requestBodies / GetMetadataRequestBody” “responses”: { “200”: { “$ref”: “# / components / responses / GetMetadataResultResponse” }, “default”: { “$ref”: “# / components / responses / GetMetadataErrorResponse” } } Page 106 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT ...

[0465] According to some embodiments, the Standard API server processing incoming requests on behalf of a user may match requests against the path and method defined in the configuration herein using regular expressions or simple string equality. If there is no configuration matching a request, the server may respond with a 501 HTTP error code to signify that such a method is not implemented. In some embodiments, a Standard API might keep a record of these requests in order to recommend that an administrator or developer using Standard API can create the Schemas and Mappings at a later point in time. In other embodiments, certain Mappings and or components may be automatically generated using one or more methods, as described elsewhere herein. Upon receipt of a matching request, the server may then verify the format and contents of the requests headers, query parameters, and / or body to ensure any parameters required in the specification have been supplied. If not, it may return a 400 HTTP error code signifying a bad request sent by the client. In some embodiments, if the data provided to the server is complete, and is just not in the correct format, the server might use certain techniques to restructure the query according to the correct format.

[0466] After matching and validating the request against an OpenAPI operation, the Standard API server may search the Schemas associated with the user’s account to find one or more Mappings for the operation. In the majority of cases, a Mapping will execute a Verb or query for data from a database and return a response. After performing the Mapping(s) the server may then validate the retrieved response data, or lack thereof, against the OpenAPI operation’s responses field. If the response data is not valid according to the specification, the server may respond with an internal server error with HTTP response code 500. Otherwise, the properly formatted response data may be encoded according to the specification and sent to the client.

[0467] While the embodiments herein use an OpenAPI specification to construct a REST API and dynamically handle requests, roughly the same procedure may be performed using specifications for other types of APIs. For example, a Web Services Description Language (WSDL) document may be used as an abstraction of a SOAP API. In this case, the SKL Engine matching and validating SOAP compliant messages to the server may have to parse the XWL of a WSDL document. Tooling may exist to parse and manipulate XML in most programming languages. Upon receiving a message, the Standard API server may match the message to an operation name defined in the WSDL document, validate the input Page 107 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT parameters according to the operation definition, find a Mapping for the operation, perform the response, then validate and return the response.

[0468] In yet another embodiment, a similar procedure may also be performed for an Asynchronous API or an Event-Driven Architecture (EDA) via the AsyncAPI specification. Within an EDA, the Standard API server may act as a broker. As such, it may register or initialize an endpoint, websocket, or other connection mechanism to listen for events or messages from Producers when it starts up by reading the user’s chosen AsyncAPI specifications. It then may implement an endpoint, websocket, or other connection mechanism for Subscribers to register their subscription per AsyncAPI defined channel. When a Subscriber connects, the Standard API server may keep track of their connection status and channels they have subscribed to by performing a Mapping which writes the Subscribers information into a persistent data store. Upon receipt of a message from a Publisher, the server may use the AsyncAPI specification to validate the existence of the channel the message was sent on and the format of the payload. It then uses a Mapping which queries a data source to translate the channel name into a list of Subscribers to send the event or message to. It may then send the event or message to all subscribers of the channel.

[0469] Even GraphQL, an alternate API format constructed of a type-based query language with its own Schema definition language, may be abstracted into a format that may easily be used by an SKL, according to another embodiment. GraphQL APIs may have the ability to introspect their Schema including types, query types, and mutation types. The result from the introspection query may be a JSON structure. Although this format may not be widely used by GraphQL API designers and engineers, it may be used by the Standard API server to dynamically match and validate GraphQL queries and mutations, and produce a response based on a Mapping. The Standard API system may create a system wherein an API’s possible interactions may be defined through an abstraction and executed according to labeled business logic (called resolvers in GraphQL). However, Standard API may be more configurable and accessible to people with less technical expertise by replacing any custom, ecosystem-specific, or framework-specific code with SKL Schemas and Mappings. MAPPINGS

[0470] According to some embodiments, once a web request or, in the case of an event- driven architecture, a message in a channel, has been matched and validated according to the API abstraction, the Standard API server may find and execute one or more SKL Mappings to perform an operation in a data source or to simply transform the data in some way. A Mapping Page 108 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT for a Standard API operation may include a reference to the identifier of the operation as it exists in the API abstraction. For example, in some embodiments, a Mapping that is to be executed when processing a web request that matched with an operation in an OpenAPI specification may have a field whose value is equal to the operationID of the OpenAPI operation like so: { ... “https: / / skl.standard.storage / properties / operation”: “SearchEvents,” ... }

[0471] According to some embodiments, once such a Mapping is found, it may be executed using an SKL Engine. As noted previously, Mappings may transform data, use constants, compare values, fetch data from other APIs, query databases, and more. According to some embodiments, a Standard API may translate between a request and a data store to perform the operation specified in the API abstraction.

[0472] Some data sources may have a specific query language that is used to send them procedures to execute. Thus, a Mapping may need to construct one or more queries, or otherwise inform a Standard SDK what query to perform.

[0473] One form of querying a data source is one in which queries are hard coded into the Mapping. In some configurations, when Mapping between a web request and a relational database, the R2RML ontology may be used to send a pre-constructed query to the database and translate the result. R2RML is the W3C standard to express customized Mappings from relational databases to RDF. A simple embodiment of an R2RML Mapping follows (prefixes omitted for brevity): <#TriplesMap> rr:logicalTable rr:sqlQuery “““SELECT ID, NAME FROM EVENTS;”““ ; rr:subjectMap [ rr:template “http: / / data.example.com / {ID}”; rr:class Schema:Event; ]; rr:predicateObjectMap [ rr:predicate Schema:name; Page 109 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT rr:objectMap [ rr:column “NAME” ]; ] .

[0474] This embodiment may not be dynamic as it does not include any parameters from the request in the query. APIs commonly paginate the response, filter the retrieved entities, or write data to the database based on the parameters of the request. RML, a more general-purpose Mapping language based on R2RML, may be used to construct queries dynamically through conditional logic and / or string concatenation. For example, to add pagination to the query herein, the following RML Mapping may be used: <#TriplesMap> rml:logicalSource [ a rml:LogicalSource ; rml:iterator “$” ; rml:referenceFormulation <http: / / semweb.mmlab.be / ns / ql#JSONPath> ; rml:source “input.json” rr:predicateObjectMap [ a rr:PredicateObjectMap ; rr:objectMap [ a rr:ObjectMap ; fnml:functionValue [ a fnml:FunctionValue ; rr:predicateObjectMap [ a rr:PredicateObjectMap ; rr:object <http: / / example.com / idlab / function / concat> ; rr:predicate <https: / / w3id.org / function / ontology#executes> a rr:PredicateObjectMap ; rr:object “SELECT ID, NAME FROM EVENTS LIMIT 40 OFFSET “; rr:predicate <http: / / example.com / idlab / function / str> a rr:PredicateObjectMap ; rr:objectMap [ Page 110 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT a rr:ObjectMap ; rml:reference “offset” rr:predicate <http: / / example.com / idlab / function / otherStr> ]; ]; ]. This Mapping generates the query: SELECT ID, NAME FROM EVENTS LIMIT 40 OFFSET {offest}

[0475] Where {offset} is equal to the offset field in the supplied input.json. The SKL Engine may execute this Mapping to get the dynamically created SQL query; it then may execute the query against the database and apply another Mapping to the response from the database to return as the response of the request. This method of string concatenation may be used to allow any part of a query to be parametrically defined.

[0476] Another alternative embodiment to generate queries dynamically is to create multiple Mappings which specify the correspondence between the data models of a data source and the RDF graph. This may make it so that the data sources may be queried as if they were RDF graphs using a query language like SPARQL.

[0477] In yet other embodiments, the same process may be used to translate requests to a Standard API server into other APIs and query languages such as REST, GraphQL, SOAP, or SPARQL. DYNAMIC API FROM NOUNS

[0478] Instead of responding to web requests based on a predefined API specification such as OpenAPI, Standard APIs may also be configured dynamically, based on Noun and Verb Schemas. For example, a Standard API could be implemented to allow for a certain set of standard operations on entities of any type of Noun in a user’s SDKS. To do so, according to a non-limiting embodiment, the Standard API server would accept requests according to a certain pattern. For example: HTTPS: / / EXAMPLE.COM / API / NOUN / {NOUN} where EXAMPLE.COM is the domain of the Standard API server and where {NOUN} is the name of the Noun data type of the entity(ies) a developer is sending a request about. In one REST API approach, this same URL can be used with multiple HTTP request types to create, read, update, or destroy entities (CRUD). Page 111 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT

[0479] According to a non-limiting embodiment, a developer or application may create an entity conforming to the Noun by sending a POST request to the URL with a JavaScript object in the body of the request conforming to an entity of the Noun. Upon receiving the request, the Standard API Server would query the user’s SKDS to obtain the Noun Schema with name matching the {NOUN} part of the path. If the Noun Schema cannot be found, the server may return an error to the developer and / or look for the Noun Schema elsewhere (e.g., the Official Library). If the Noun Schema is found, it can be used to validate the entity in the request body to ensure it is conformant to the Noun Schema. If it is not, the server may return an error to the developer. Otherwise, the Entity is inserted into the user’s SKDS and a success response is returned to the developer.

[0480] According to a non-limiting embodiment, a developer or application can update an Entity conforming to the Noun by sending a PUT or PATCH request to the URL with an entity ID and any fields and corresponding values to update in the body of the request. Just like in the creation example herein, the server can validate the format of the data being updated against the Noun Schema and either return an error or update the entity in the user’s SKDS accordingly.

[0481] According to a non-limiting embodiment, a developer or application can delete an Entity conforming to the Noun by sending a DELETE request to the URL with and Entity ID in the body of the request. No validation needs to occur for this operation, the server can simply delete the entity from the user’s SKDS.

[0482] According to a non-limiting embodiment, a developer or application can obtain one or more Entities of the Noun data type by sending a GET request with the request body containing either (a) one or more IDs of Entities to obtain or (b) one or more field and value pairs acting as filters on the data that the server should return. In the first case, the server can simply query the user’s SKDS for the Entities with matching IDs. In the latter case, the server may first validate that the Noun Schema contains all the fields included in the filters. If not, it can return an error to the developer. If all the queried fields are valid, the server can query the user’s SKDS and return the matching entities.

[0483] According to another non-limiting embodiment, a Standard API server could support a GraphQL interface for which it would expose only one endpoint, but allow a set of queries and mutations corresponding to the CRUD operations described herein. Instead of using a predefined type system, the available types to query may be based on the Noun Schemas Page 112 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT present in the user’s SKDS. Likewise, standard GraphQL mutations may be made available for each Noun Schema, for example to create, update, or destroy an Entity. Instead of a pattern of URLs and HTTP methods, this GraphQL API would be interacted with according to a pattern of queries and mutations by Noun. DYNAMIC API FROM VERBS

[0484] In addition to creating endpoints for performing operations on entities based on their Noun data type, the API could also dynamically respond to endpoints to execute Verbs, according to a non-limiting embodiment. To do so, the Standard API server may accept requests according to a different pattern. For example: HTTPS: / / EXAMPLE.COM / API / VERB / {VERB} where EXAMPLE.COM is the domain of the Standard API server and where {VERB} is the name of the Verb a developer wants to execute. Upon receiving such a request, the Standard API server can search for the Verb Schema by the name of the Verb. As before, if the Schema or Schemas are not found, the server may return an error and / or try and find the missing Schema(s) elsewhere. Otherwise, the server begins performing the same steps as Standard SDK would to perform the Verb. In some embodiments, the Standard API server may use a Standard SDK to perform the Verb. The parameters of the Verb may be any data sent in the body of the request such as data encoded as multipart / form-data or as JSON which should conform to the Verb’s parameters Schema. After executing the Verb, its standard return value will be returned in the response of the request to the developer. AUTHENTICATION

[0485] In addition to controlling which Nouns and Verbs are accessible through API endpoints in a Standard API instance as described herein, a Standard API provider could offer the ability for the API to be secured via different authentication and authorization mechanisms. For example, one set of API endpoints through which consumers can read Entities that do not contain sensitive or personal information could be made public and not require any authentication or authorization. Alternatively, some endpoints which deal with Nouns that are more sensitive may require an Oauth2.0 access token to identify and authorize the consumer. DOCUMENTATION

[0486] In order for developers to know how to use this dynamic API derived from the Schemas in a user’s or developer’s SKDS, the Standard API server can also serve a webpage with documentation derived from the data in a user’s SKDS, and elsewhere (e.g., SKL Libraries, existing API documentation websites that are similar or relevant, etc.). For example, the documentation could describe a developer’s ability to send a HTTP request with the method Page 113 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT POST to HTTPS: / / EXAMPLE.COM / API / NOUNS / NOTE with title, body and tags parameters in the body of the request in order to create an entity of the Noun Note in the SKDS.

[0487] In other embodiments, API documentation can be generated locally by running a script which reads a user’s SKDS, either from local files, a database running on the same computer, or from a remote server, such as a cloud hosted SKDS. The API documentation generated could be in the format of an open-source API documentation standard such as OpenAPI in YAML, XML, or JSON. NO-CODE API BUILDER

[0488] In some embodiments, as a user’s SKDS is filled with more and more types of Nouns and Verbs, the Standard API server will automatically respond to endpoints for manipulating data of any Noun types and executing any Verbs that are existing in the Schema at the time of the API request. In other embodiments, the Standard API server may require users or developers to perform some action to “re-build” the API periodically to update it according to new or updated Nouns and / or Verbs. In other embodiments, the Standard API server may offer an interface (GUI or programmatic) for the user or a developer to customize which specific Nouns and Verbs should be available to interact with via the Standard API and which should not. Such an interface for selection of API endpoints could be marketed as a “No- code” API builder. The Standard API provider offering this service could also enable its users to create multiple versions of their API with different endpoints enabled for different sets of Nouns and Verbs. In this way, a developer using an SKDS could expose different read and write capabilities to different consumers.

[0489] According to a non-limiting embodiment, an analytics server could automatically generate Schemas from APIs and / or Documentation. As described elsewhere herein, certain machine-learning models could be trained and / or tuned with SKL Schemas in order to help with the creation and maintenance of said Schemas. For instance, an AI model may be trained with OpenAPI Schemas and their respective API documentation websites in order to help automatically generate or partially generate one given the other. In other words, given an OpenAPI spec, a certain AI model may generate a documentation website for that API. Similarly, given API documentation, a certain AI model may generate an OpenAPI spec. Furthermore, as described elsewhere herein, a certain AI model might be trained to help generate Mappings between other Schemas. In these ways, certain methods (e.g., using large language models) can be used to automatically generate and / or partially generate SKL Schemas Page 114 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT given other types of information about Integrations and data sources (e.g., documentation about APIs on websites).

[0490] Similarly, according to some embodiments, and using the various methods described herein, API endpoints and / or documentation can be automatically and / or semi- automatically generated and / or manipulated by providing SKL Schemas. Furthermore, in some embodiments the server can combine Schemas and additional information from other data sources, such as SKL Libraries and public sources, in order to include descriptions of Schemas, dummy data for testing, and more. In this way, a Standard API is able to have documentation that is automatically or semi-automatically generated and / or maintained. Similarly, any changes to the API documentation could also be used to update and / or recommend changes to SKL Libraries and / or other SKL components.

[0491] In these ways, and more, Schemas may be automatically generated from information about Integrations (e.g., API documentation, discussion, Q&A forums, etc.). In these ways, and more, API endpoints and / or documentation may be automatically generated from Schemas and information about Schemas. In these ways, and more, API endpoints can be automatically generated from information about data sources.

[0492] Depending on the needs or requirements for a given Standard API, different Verbs, Schemas, and / or other configurations could be used. Different embodiments of Standard APIs could therefore include, but not be limited to, using a virtual database to query and merge data from multiple data sources into one endpoint, triggering a secondary process such as syncing data from multiple data sources into a given data store when a particular endpoint is hit, using a Standard SDK to query one data source at a time with the parameters provided by an endpoint, using Mappings to run hardcoded queries or queries built through string concatenation rather than using abstractions of data sources, and so on.

[0493] Similarly, certain other Verbs and capabilities may be added to Standard APIs, such as certain security services that help identify certain requests and traffic as potentially dangerous, certain performance and analytics services that monitor requests and help track of usage and latency, and so on. As described elsewhere herein, according to some embodiments, some of these various services and expansions on a Standard API SKApp may require payment, which could be processed through the Official Library and / or other SKL Libraries which host the various capabilities and extensions to the Standard API SKApp. Page 115 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT SYNCER

[0494] Standard Syncer (also referred to herein as the “Syncer”) is a non-limiting example of a SKApp which can ingest historical data and continuously monitor and / or listen for changes, additions to, or deletions of data (in near real time), from nearly any data source or Integration that Standard SDKs are compatible with (e.g., a REST API).

[0495] According to an embodiment, it is constructed of a queueing system, a database to store ingestion state, and a proprietary algorithm which reads SKL Schemas to determine how to sync data from each data source. The syncing algorithm goes through a series of parameterized steps in order to sync many different types of data from many different data sources in a scalable way.

[0496] FIG.48 illustrates a conceptual diagram of the Syncer SKApp 4820, according to an embodiment. In this example, the Syncer 4820 uses Schemas and Mappings related to three different file storage Integrations 4810 (e.g., data source configs) in order to transform the data from each API into the relevant Noun Schemas (e.g., FILE) and pass them through a data deduplication process 4822 which creates one or more CueIDs and / or Unique ID and / or Relevance Scores relative to other Entities in the SKDS 4830. As mentioned above, the generation of CueIDs and / or Unique IDs and the comparison of newly processed Entities have been to other existing Entities in the SKDS 4830 can be largely parameterized and configured through Schemas, as well as run in its own background process with its own set of workers in order to prevent the Syncing SKApp from potentially suffering from performance issues while Syncing large amounts of data. Once this step is complete, the Syncing SKApp can write or update the data 4823 corresponding to the newly synced Entities into or in the SKDS 4830. Ultimately, because the Entities are persisted in an SKDS along with their Schemas, various Interface Components 4841 and 4842 can be used interchangeably to view and interact with data as described elsewhere herein.

[0497] FIG.10 illustrates a system architecture diagram of the Syncer, according to a non-limiting embodiment that follows the solid specification. In this example, the Solid- compliant Authentication Server 1021 provides users with WebIDs that can be used across any Solid App that implements the Solid OIDC authentication specification. This particular embodiment of the Authentication Server 1021 stores WebIDs and WebID profile information for users in a Redis database. The overall Syncer application 1010 then provides a front-end 1011 that lets users authenticate through Solid OIDC with the Solid-compliant Authentication Server 1021. Once authenticated, users are able to configure the Syncer backend 1012, which Page 116 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT may write and read data from one or more databases 1013a-b in order to store information about which WebIDs are authorized to use the Syncer backend 1012, configurations and data from given users that don’t have independent SKDSs, and more. In this scenario, the Redis database 1013b may be used to store information about subscriptions and the Postgres® database may be used to store Entities for users that do not have a Solid Pod. For users that do have an SKDS 1022, the Syncer backend 1012 may read and write Schemas, configuration, Entities, etc. to and from a user’s SKDS 1022. A server or external application 1030 may either query the Syncer backend 1012 and / or the SKDS 1022 according to its needs.

[0498] According to the embodiments shown through FIGs. 22-24 and FIG. 50, a Standard Syncer can be configured in a variety of ways in order to solve for any of a variety of use cases as described elsewhere herein. SYNCSTATUS

[0499] According to an embodiment, upon the receipt of a new user’s account needing to be synced, the Syncer creates a record in the database called a SYNCSTATUS. It may include the following:

[0500] 1. The URI of the account. An account here may represent any entity provisioned by a data source for a person or company which has some identifier (e.g., CueID, UID) in that data source (e.g., email address, username, API key, etc.) and may have a set of security credentials for the data source. Each account should have a corresponding SKL Schema from which one can access metadata, API security credentials, and configuration for how to sync the account.

[0501] 2. Standard Syncer may also represent and work with public data sources, for which the account identifier and synced data could be shared across Standard Syncer users, or could be duplicated per user.

[0502] 3. A reference to a user record. For example, a foreign key referencing the ID column of another table in the database. This separate table may hold internal metadata, profile information, and / or sales or subscription information for the user.

[0503] 4. A link to the source of the SKL Schemas to use or a field containing the schemas themselves. The source of the SKL Schemas could point to files publicly accessible over the internet or to data stored in a private database. Schemas being accessed from an external source may be stored on a user’s SKDS where they can be controlled and managed by Page 117 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT the user. In such embodiments, the Syncer may also need to obtain and store authentication credentials like an access token retrieved via Solid OpenID Connect.

[0504] 5. If a user does not require storage of their Schemas to be external, the user can choose to upload their preferred schemas via the Standard Syncer’s API, or choose from a list of preconfigured sets of Schemas offered by the Standard Syncer and / or from the Official Library. In this case, the Schemas may be stored as JSON in a database.

[0505] 6. In an alternate embodiment, all SKL Schemas could be managed and controlled by the Standard Syncer and be constructed on a case-by-case basis per user, customer, or client.

[0506] 7. In an alternate embodiment, the Syncer could use a mixture of both pre-set SKL schemas managed by Standard Syncer and a set of SKL schemas configured and controlled by the user, either on an SKDS or other database or uploaded to the Standard Syncer server.

[0507] 8. Initialized fields to store the state of the syncing process as the account is synced. PROCEDURE

[0508] According to an embodiment, the Syncer can sync an account after initializing the information listed herein. Syncing begins either when the account is created or at the next regularly scheduled syncing interval which finds all accounts that have not started syncing and starts syncing them. The orchestration and syncing interval can be defined through Schemas as defined elsewhere herein (e.g., cron schedules, custom Verbs with triggers, etc.) As such, the choice of when to start syncing is configurable based on the integration and the use case of the user adding the account. For example, if an individual person using a productivity product which syncs their files and folders from a file storage tool, they may want to have synced entities displayed to them in a UI as soo...

Claims

CMK0014-PCT-125056-0147 PATENT CLAIMS What we claim is:

1. A computer-implemented method comprising: receiving, by one or more processors, a user query for a personalized response associated with a profile; interpreting, by the one or more processors, the user query by executing a machine- learning model; generating, by the one or more processors, a data query corresponding to the user query by executing the machine-learning model, the data query configured for execution in a computer model comprising one or more nodes, each node of the one or more nodes having an identifier corresponding to a series of nouns and verbs generated in accordance with a schema associated with a shared knowledge language; receiving, by the one or more processors, a first node of the computer model, wherein the first node is associated with the profile and generated based at least in part on an application accessed by the profile; and presenting, by the one or more processors, the personalized response, wherein the personalized response comprises an indication of the first node of the computer model.

2. The computer-implemented method of claim 1, further comprising: receiving, by the one or more processors, a second indication indicative of a context associated with a computing device associated with the profile; determining, by the one or more processors, a second node of the computer model, the second node associated with the context displayed by the computing device; generating, by the one or more processors, a personalized prompt based on the second node, wherein the personalized prompt is a second output of the machine-learning model; and presenting, by the one or more processors, the personalized prompt.

3. The computer-implemented method of claim 1, wherein the computer model further comprises a nodal data structure of a set of nodes where each node corresponds to data identified as associated with each application within a set of applications accessed and used by each computing device, each node having an identifier corresponding to a series of nouns and verbs generated in accordance with the schema associated with the shared knowledge language, wherein the series of nouns define one or more types of data and the series of verbs define one or more software processes, the computer model transforming the data generated as a result of Page 215 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT at least one computing device accessing and using one or more applications from the set of applications into a series of nouns and verbs using the schema.

4. The computer-implemented method of claim 1, wherein the user query is provided in a natural language syntax.

5. The computer-implemented method of claim 1, further comprising: executing, by the one or more processors, the machine-learning model to review one or more search results from the data query; and selecting, by the one or more processors, a search result from the one or more search results that satisfies a threshold.

6. The computer-implemented method of claim 1, wherein generating the data query further comprises: parsing, by the one or more processors, the user query into one or more search elements; and determining, by the one or more processors, one or more search parameters associated with the one or more search elements.

7. The computer-implemented method of claim 5, further comprising: responsive to receiving a selection of the personalized response, generating, by the one or more processors, a second query based on the search result, wherein the second query is associated with the personalized response; querying, by the one or more processors, the computer model based at least on the second query; receiving, by the one or more processors, a second node linked to the first node of the computer model; and presenting, by the one or more processors, a second personalized response, the second personalized response corresponding to the second node.

8. The computer-implemented method of claim 1, wherein at least one node of the one or more nodes represents contextual data associated with a previous response.

9. The computer-implemented method of claim 1, wherein the personalized response further comprises a verb from the shared knowledge language, the verb associated with the first node of the computer model. Page 216 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT 10. The computer-implemented method of claim 1, further comprising: generating, by the one or more servers, the personalized response by: determining, by the one or more servers, a user interface format for displaying the personalized response; and rendering, by the one or more servers, a user interface with one or more graphical elements representing the first node of the computer model.

11. The computer-implemented method of claim 1, further comprising: executing, by the one or more processors, a machine learning agent to perform one or more actions within a computing environment, wherein the one or more actions correspond to the first node indicated in the personalized response.

12. A system comprising: one or more processors; and a non-transitory computer-readable medium having a set of instructions that when executed, cause the one or more processors to: receive a user query for a personalized response associated with a profile; interpret the user query by executing a machine-learning model; generate a data query corresponding to the user query by executing the machine- learning model, the data query configured for execution in a computer model comprising one or more nodes, each node of the one or more nodes having an identifier corresponding to a series of nouns and verbs generated in accordance with a schema associated with a shared knowledge language; receive a first node of the computer model, wherein the first node is associated with the profile and generated based at least in part on an application accessed by the profile; and present the personalized response, wherein the personalized response comprises an indication of the first node of the computer model.

13. The system of claim 12, wherein the set of instructions further cause the one or more processors to: receive a second indication indicative of a context displayed by a computing device associated with the profile; determine a second node of the computer model, the second node associated with the context displayed by the computing device; Page 217 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT generate a personalized prompt based on the second node, wherein the personalized prompt is a second output of the machine-learning model; and present the personalized prompt.

14. The system of claim 12, wherein the computer model further comprises a nodal data structure of a set of nodes where each node corresponds to data identified as associated with each application within a set of applications accessed and used by each computing device, each node having an identifier corresponding to a series of nouns and verbs generated in accordance with a schema associated with a shared knowledge language, wherein the series of nouns define one or more types of data and the series of verbs define one or more software processes, the computer model transforming the data generated as a result of at least one computing device accessing and using one or more applications from the set of applications into a series of nouns and verbs using the schema.

15. The system of claim 12, wherein the user query is provided in a natural language syntax.

16. The system of claim 12, wherein the set of instructions further cause the one or more processors to: execute the machine-learning model to review one or more search results from the data query; and select a search result from the one or more search results that satisfies a threshold.

17. The system of claim 12, wherein the set of instructions further cause the one or more processors to: parse the user query into one or more search elements; and determine one or more search parameters associated with the one or more search elements.

18. The system of claim 16, wherein the set of instructions further cause the one or more processors to: responsive to receiving a selection of the personalized response, generate a second query based on the search result, wherein the second query is associated with the personalized response; query the computer model based at least on the second query; receive a second node linked to the first node of the computer model; and Page 218 of 220 4863-5732-3227.1CMK0014-PCT-125056-0147 PATENT present a second personalized response, the second personalized response corresponding to the second node.

19. A system comprising: one or more processors; and a non-transitory computer-readable medium having a set of instructions that when executed, cause the one or more processors to: receive a user query for a personalized response associated with a profile; interpret the user query by executing a machine-learning model; generate a data query corresponding to the user query by executing the machine- learning model, the data query configured for execution in a computer model comprising one or more nodes, each node of the one or more nodes having an identifier corresponding to a series of nouns and verbs generated in accordance with a schema associated with a shared knowledge language; receive a first node of the computer model, wherein the first node is associated with the profile and generated based at least in part on an application accessed by the profile; and present the personalized response, wherein the personalized response comprises an indication of the first node of the computer model.

20. The system of claim 19, wherein the computer model further comprises a nodal data structure of a set of nodes where each node corresponds to data identified as associated with each application within a set of applications accessed and used by each computing device, each node having an identifier corresponding to a series of nouns and verbs generated in accordance with a schema associated with the shared knowledge language, wherein the series of nouns define one or more types of data and the series of verbs define one or more software processes, the computer model transforming the data generated as a result of at least one computing device accessing and using one or more applications from the set of applications into a series of nouns and verbs using the schema. Page 219 of 220 4863-5732-3227.1

Images