SmartSystems

Key Acronyms: CI= Continuous Improvement. CM= Configuration Management. DB= DataBase. KR= Knowledge Representation. GTD= Getting Things Done. OE= Objective Evidence. TM= TopManagement. TC= TransportCanada

Keywords: CI KR GTD operations management, governance, reviews, audits, brainstorming, machine learning, semantic searches, data linking, tagging

Instructions: Insert new rows at the end of the table not between other rows this will prevent possible data corruption and disconnecting relations.

Explanations:

The first step to make 'smart' documents is to organise-structure the data in a spreadsheet of triples which can then be reviewed improved queried sorted filtered to view useful and meaningful relationships and patterns that can emerge when examining the connections and interconnections of data, cells, rows, properties, relations (like in a neural network).

The column RELATION defines the contexts and organisation of the system which are used to coordinate resources, streamline and optimize the system (see GTD).

The second step when enough data is generated is to import the tables into a graph database (like Neo4j or ArangoDB) for machine learning and faster and more refined queries and insights using graphs query languages (in a 400 row worksheet doing a data validation after changing the secondary tables can take a many seconds and in the worst case scenario crash). GraphDB can automatically point to meaningful information in a spreadsheet or relational DB theses insights and discoveries are more manual). So graphDB automates discoveries of useful links or disconnects needing attention.

Requirements and their compliances (OE) are organized in a form that can easily be exported to a graphDB(1) triplestore [TS] of WHO is responsible for WHAT(requirement) and HOW(objective evidences) the relationships are identified in the table RELATIONS. The RELATIONS table provides contexts to improve decision making. The more RELATIONS columns in the WHAT table the more connections and contexts will be established. RELATIONS are the key concept that make the document smarter.

Google FB Paypal etc have been using this type of data structure grapghDB since 2012. Google realized the limitations of Relational DB and in 2012 launched its ‘Knowledge Graph’ and in 2013 Facebook followed suit with its ‘Graph Search’ service, both of which provide a better way to search data by helping users with more contextual information.

The primary table (that defines the triples and the relations) is WHAT which then connects to the secondary supporting tables WHO HOW. The relationships in the RELATIONS table are abstractions absent from other types of database (relational). These relations conections and interconections is what makes the document 'smart' and capable of learning and providing meaning and deeper insights.

Data are linked by common properties in the primary table cells (unlike a relationalDB that connects data through columns). Graphs (nodes edges(relations)) can be drawn to visualise model the process.

This KR DB represents-models a system (like a QMS or a process). It can be inspected at planned intervals to document changes (traceability change-management revision-control-git CM) and determine the differences (delta) between the objectives requirements and the actual data measurements OE and record changes to CI. The more populated with data and connections the more valuable it becomes in decision making and risks prevention and identification of opportunities.

Data validation is used to connect data and to identify disconnects. Changes in main tables are not automatically updated when changes are made in secondary tables (for example if in table WHO john is changed to paul this will be not be reflected in tables WHAT RELATIONS etc.) to identify the changes select all cells then DATA> DataValidation> CircleInvalidData then manually update with the valid data.

Linked data Changes in main tables are not automatically updated via data validation in related tables because how would you know what to update it to? For example let's say you "insert" a value which changes each value position and then after the insert you see a typo in the old value so you change that ... Since the old value no longer exists how does the code determine a typo change versus an insert and an overwrite ? The safer/easier way to go is to draw the attention of the user to the Valdiation cell and have them fix it manually. For example you could use Conditional Formatting to turn the Validation cell bright yellow when the value displayed no longer exists in the Source List.. Data validation is not a relational database. It's just a means of selecting from a few text values to ensure valid input. When the list source changes, you will need to test existing data to see if it still fits. Data validation is for ensuring valid data input, not creating a relational database link. https://answers.microsoft.com/en-us/msoffice/forum/msoffice_excel-mso_other-mso_2013_release/update-values-when-linked-data-validation-list/0d2cc8c3-c418-4198-bcc7-0bae83518fc8

The advantage of organizing the data as a TS is that it can bring it to life (useful relations can be identified, deltas identified to CI); data linking connects it and makes it smarter because it can be sorted for (responsible process objects) which establishes links. This can streamline and optimize systems-processes by connecting the required ressources at the right time. It also helps to visualize the processes and their connections in topological and neural network type of data structure. Data linking gives it context and discoverability.

(1) Wiki: In computing, a graph database is a database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data. A key concept of the system is the graph (or edge or relationship), which directly relates data items in the store. The relationships allow data in the store to be linked together directly, and in many cases retrieved with one operation.

Normes intelligentes: les requis sont organises (sémantiquement indexé) en triplestore graghs git blockchain pour identifier capturer enregister les relations et les optimiser et mieux les organiser en fonction du contexte (ressources risques opportunites talents). 1- populate an excel in a triplestore subject-predicate-object form to human and machine learn and optimize better understand connections. 2- populate the triples in a graphDB (Neo4j) use AI machine learn neural networks to data link add intelligence to the system.

-Smart standards. Adding intelligence to specifications. Add intelligence to standards: the requirements are organized (semantically indexed) in triplestore graphs git (traceability) blockchain to identify capture record relations-histories-evolutions and optimize and better organize them according to the context (resources risks opportunities talents). 1- populate an excel in a triplestore subject-predicate-object form to human and machine learn and optimize better understand connections. 2- populate the triples in a graphDB (Neo4j) use AI machine learn neural networks to data link add intelligence to the system.

GTD (Getting Things Done) is a system of relations, contexts, coordinations and workflows with the following fields ID, WHO, status, Importance, Action, Result, Relations

Data is linked by tagging entities. In this spec the requirements are tagged with their clause and with their predicate (HOW process Objective Evidence) and WHO and RELATIONS

The more extensive and connected the network (knowledge representation KR DB) of WHAT WHO HOW RELATIONS the more useful it becomes.

GraphDB (linked data, contexts based, more relevant and meaningful (search and discover vs search and retrieve (for Relational DB)))

Nodes (~row) represent entities such as people, businesses, accounts, or any other item to be tracked. They are roughly the equivalent of the record, relation, or row in a relational database, or the document in a document database.

Edges (~relationships) also termed graphs, are the lines that connect nodes to other nodes; they represent the relationship between them. Meaningful patterns emerge when examining the connections and interconnections of nodes, properties, and edges. Edges are the key concept in graph databases, representing an abstraction that is not directly implemented in other systems.

Properties (~data in a cell) are germane (relevant to a subject under consideration) information to nodes. For example, if Wikipedia were one of the nodes, it might be tied to properties such as website, reference material, or words that starts with the letter w, depending on which aspects of Wikipedia are germane to a given database.

Compared with relational databases, graph databases are often faster for associative data sets and map more directly to the structure of object-oriented applications.

REF. Neo4j White Paper: GraphDB The Rise of Graph-Based Search In their early days, both Facebook and Google offered users basic ways to access their data – the standard approach of ‘listing’ or ‘keyword’ search, where you type in a word or phrase you’re interested in and get back a list of all the web pages and documents that include said keyword. This method is essentially plain pattern recognition – and many people will be familiar with the cumbersome process of repeatedly redefining your search terms until you finally hit on something of interest. But realizing the limitations of this, in 2012 Google launched ‘Knowledge Graph’3 and in 2013 Facebook followed suit with its ‘Graph Search’ service4, both of which provide a better way to search data by helping users with more contextual information. Knowledge Graph is a database that enhances Google’s search engine results with semantic search information gathered from a wide variety of sources. Likewise, Facebook’s Graph Search enables users to combine search phrases to get more structured and more localized search results, rather than simply using standard keywords and getting the results that match those words. The key to their enhanced search capability is that the first search takes into account the entire structure of connected data available. And because graph systems understand the way data is related, they return much more precise and richer results.

Graph-based search, powered by systems like Neo4j, is able to deliver relevant information that you may not have specifically asked for – offering a more proactive and targeted search experience that allows you to quickly triangulate onto the data points that are of the most interest to you. In essence, graph-based search is intelligent: you can ask much more precise and useful questions and get back the most relevant and meaningful information, whereas traditional keyword-based search delivers results that are more random, diluted and lower-quality. Graph-based search is also much quicker: you can query all of your connected data in real time, then hone in on the answers provided and launch new real-time searches prompted by the insights you have discovered. It’s more of a natural ‘conversation’ with your data, rather than a series of one-off searches. It’s search and discovery, rather than search and retrieval.

Graph-Based Search in Action But if Neo4j’s graph-based search and discovery is superior in nature, what actual business benefits does this provide? The experience of Neo4j users shows that it has allowed them and their customers to discover new business insights and launch new products and services:

Interlinking data with other relevant information in context makes it more visible and useful for improved governance audits compliance awareness validation transparency tracking discovery innovation.

ISO AS

Linking: 4 Context 5 Leadership 6 Plan 7 Support 8 Operations 9 Performance Measurement 10 Improvement.

The inputs are the standards' requirements(object) and the outputs are the objective evidence(predicate) and the person-function responsible to comply(subject). Insights contexts is provided by sorting querying filtering RELATIONS

In the ISO AS standards the more specific the clause number the less abstract-subjective-fuzzy the requirement is for example 4.4.1 is more specific than 4.0. The process sequence is also from the lower to higher so 6.0 planning comes before 7.0 support which comes before 8.0 operations which comes before 9.0 performance evaluation which comes before improvement.

The ISO AS standards (like all documented specifications) are not smart (CI capable of learning adapting improving) they are instead rigid prescriptions (MBO) and like software programs following a declarative-programing-paradigm for the requirements and the processes. The requirements are declared by the standard then the supplier must comply with them and then show demonstrate compliance. It is not symbolic or capable of AI self or machine learning and adapting to the circumstances. It is not like a graph-based-db(triplestore) or an imperative OOE or an imperative procedural where classes modules objects interact together and where the relationships are the priority. The standards can be made smarter by organising the requirements as a graph-db triplestore of Subject(Responsible)-Predicate(Procedure)-Object(Requirement). Then the data can be sorted to determine how the system can be optimized and improved by adding connections relations with knowledge representation AI and neural network. To see more about programming paradigms (1).