Cognite is a global industrial Software-as-a-Service (SaaS) leader, with an eye on the future and a drive to digitalize the industrial world. We’ve created a new class of industrial software which allows asset-intensive industries to operate more sustainably, securely, and efficiently. Our core software product is Cognite Data Fusion (CDF), designed to quickly contextualize OT/IT data to develop and scale company solutions. We use technology like hybrid AI, big data, machine learning, and 3D modelling to get there. We serve oil and gas, power and utilities, renewable energy, manufacturing, and other heavy-asset industries. Our technology helps them operate through transitions, sustainably and to scale, and without sacrificing bottom lines. We believe data must be made accessible, insightful, and open. In other words, we help our customers make data do more. And with that pave way for a full-scale digital transformation of heavy industry. Founded in 2016, we now number 700 strong, including some of the best software developers, data scientists, designers, and 3D specialists in the field. Hailing from 50 nationalities, we’re talented, curious, and fun to be around. Get to know us better: Life at Cognite: linkedin.com/company/cognitedata/life/ Make data do more: makedatadomore.cognite.com/ Twitter: @CogniteData Facebook: @CogniteData IG: @CogniteData Youtube: /c/cognite

Cognite

Kristy is in her final year of computer science at the University of Waterloo (UW). Since her enrollment, she has interned for Paypal, Cognite AS, Peggy, Cockroach Labs and Google — all as a software engineer. When she graduates, she plans to work as an engineering manager. At the moment, Kristy is a technical project lead for UW Blueprint initiative, which focuses on accessible technology and promoting public and social welfare. The initiative partners with non-profit organizations to provide websites, mobile applications and analysis tools for free. Under UW Blueprint, Kristy leads a project that builds web applications to help Planet Read coordinate volunteers to translate and review children’s stories. “Currently how they process their translations is through email and Word documents, so we’re building a platform to hopefully change that,” she says. “It’s kind of like my brainchild for the last few months and we will be deploying in [January].” Kristy’s journey to UW’s computer science program was possible through a handful of positive reinforcements. Growing up in Guelph, ON. alongside her older sister to Chinese immigrant parents, Kristy fostered a keen interest in computer science through video games and mathematics. From catching Pokemons to rummaging through online indie games, Kristy began to see the correlation of mathematics in them. “I always liked tinkering with things…it seemed like computer science was a natural concept to try out,” she says. Although in high school, Kristy did not find the computer science courses to be challenging enough, she admits having an excellent teacher was a game-changer. She is also proud that she was part of a tight-knit comradery of the few female students looking to venture into computer science careers. “It gave me a lot of inspiration to try it out myself, and I really don’t know where I’d be if they were not there,” the 22-year-old says. “I think that it was really huge for me.” Then there were hackathons. “Hackathons really connected me with the community I wanted to be a part of, I met a lot of students from Waterloo while I was in high school in the hackathon community.” she says. For Kristy, hackathons were a way for her to connect with people who wanted to build and create. What attracted her to hackathons weren’t the elaborate and complex projects, but the simple ones that embodied the spirit of learning and having fun. Throughout high school, hackathons became Kristy’s staple extracurricular, but for her it was more than just an after-school activity. In 2016, she would become the founder of SpartaHacks, introducing Guelph to the first high school hackathon, organized alongside her friends from September to December. This was Kristy’s first time organizing and finding major success. “I really wanted to give back to a community that gave me so much.” Kristy says. “My school, on a smaller level, didn’t have much of a computer science environment or community, I felt really passionate about bringing it to my school and convincing my friends to enjoy these things.” As Kristy found herself studying at UW, her passion for hackathons continued. Soon, Kristy will be working with Hack the North as a logistics organizer and backend engineer. “I wanted to find people I could relate to more, I think it’s important to be able to have people in your life who can support you in the way that you need to be supported,” she says. “It’s hard.” Kristy does not shy away from talking about identity politics in the computer science industry, including her time at UW. As a queer woman of colour, finding a space in the industry isn’t as easy as it seems. In her experience, having mentors who either are allies or individuals from your community is a way to feel connected to a stereotypically heteronormative space. “It was huge for me that I had mentors in high school, who were women in computer science.” “It’s great to have a diverse network, and be friends with people from all walks of life, regardless of the background you come from.” Kristy spoke of the hope she feels in the growth of inclusion in the industry. “I think the onus is on everyone to make the space more welcoming and inclusive,” she says. When looking at Ontario, Kristy stated that there needs to be more change in regards to learning in programming, as computer science isn’t offered in every school, public or private. This would mean providing more resources, funding programming camps and implementing programming courses in schools that are subsidized. “If you grew up in rural Ontario, where there might not even be upper calculus classes, then it’s going to be hard to get a hold of programming classes,” she says. “Having the resources and the opportunities to go to programming camp, or go to hackathons, can be really influential with that.” With the ever-growing environment of STEM careers, Kristy believes there are many ways for students and people interested in computer science to increase their skills. For Kristy, co-op programs changed her life for the better, giving her a chance to explore different paths. Kristy spent time in California and Norway where she worked remotely for international companies during the pandemic. Through these experiences, her love for startups and entrepreneurship grew. “You receive valuable hands-on experiences on building software and websites from scratch,” she says. The desire and focus to build and create is what Kristy believes is the most important factor in figuring out what a student or someone just entering the STEM industry needs. She also emphasizes the need for expanding people’s creativity, and not just sticking to one type of building. “Take time to take care of yourself, do some art, some construction, woodwork, things like that,” she says. “Those are all important in keeping the spirit of building things alive, and to keep the spirit healthy.” There’s more interesting interviews like this at Thinking Cap!

In Conversation with a Computer Science Major, Kristy Gao

by Ricardo Goncalves Before you go any further, you should know that Code Mesh is now a part of , our new family of global tech conferences. Code Sync Learn more -> This year’s saw the conference go from strength to strength. So much so, I couldn’t fit the highlights from the entire conference in a single blog post. Code Mesh So here’s my take on the talks I attended on day one of Code Mesh 2017: Keynote: Automatically Scalable Computation — Margo Seltzer Margo Seltzer, (at the time) Herchel Smith Professor of Computer Science and the Faculty Director for the Center for Research on Computation and Society in Harvard’s John A. Paulson School of Engineering and Applied Sciences Speaker: This was the first keynote of CodeMesh and what a way to start. The main question was basically: “Can programs get better at running programs with practice?” The idea seems far-fetched and even Margo herself said that initially she thought the idea (coming from a young student) was a bit “naive”, in the sense that it was not possible and/or practical. Also keep in mind that she was talking about feeding the same program to the computer and it ran faster with time, and not some higher-level “neural network/deep learning” middleware that was being used. This idea works on the lowest level possible, the bits and bytes running inside your CPU, and it’s like branch prediction on steroids, where the program execution is divided in smaller parts and pre-computed (possibly in different cores). Over multiple runs, heuristics are built for that program that make these pre-computation somewhat accurate, depending on the program itself. Some of the benchmarks were pretty amazing, but to truly that this to the next step, it seems like hardware-support will be needed from the CPU. There is a lot more to it than this, but suffices to say that it was a great beginning to CodeMesh. A Practical Functional Relational Architecture: Building Systems with Datomic — David Nolan David Nolan, Software Engineer at Cognitect Speaker: David Nolan gave us a pretty good talk on immutability on the database with Datomic. Most of the talk was motivation for why we should care for an immutable database, which makes sense, since actually using one (like Datomic) seems pretty straightforward, given that you can’t screw up your data :) He argued that immutability, a characteristic of functional programming, was already an option on the front-end with technologies like React or ClojureScript (which Nolan is the creator) and on the back-end with functional languages (Erlang, Clojure, Haskell, etc.). This leaves the database as the odd one out. Datomic was born from that sentiment of bring the benefits of immutability for the entire stack. The live demo where Nolan trivially queried data from the past was also nice (and seems really useful for auditing, etc.). As an interesting side note, Datomic can actually delete data due to legal reasons. Beyond Eventual Consistency (FaunaDB, Calvin) — Jamie Allen Jamie Allen, Director of Engineering for the Unified Commerce Project at Starbucks Speaker: Jamie is the head of engineering at Starbucks, a company with a global presence, so you can imagine the scale at which they deal in their systems / databases. When he arrived at Starbucks, Cassandra was the DB of choice. But it turns out that eventual consistency is not ideal for every use case, and in particular for some the uses that Starbucks has (which I believe is the reward program that customers can sign-up for). So the engineering team lead by Jamie started their journey on finding a replacement for Cassandra that provided stronger guarantees than eventually consistency. He also argued that the CAP theorem is still misunderstood and maybe not the best way to frame the problem of data consistency, availability, etc. He suggests to use the PACELC theorem instead. The rest of the talk was a small review of the options that they looked at for their next DB: Amazon Aurora, Microsoft Cosmos, Google Spanner, CockroachDB and finally FaunaDB, which seems like the current option, based on internal evaluation. Metaphors We Compute By — Alvaro Videla Alvaro Videla, former Core Developer for RabbitMQ and co-authored the book “RabbitMQ in Action” Speaker: Video coming soon. Subscribe for notifications. Alvaro gave a pretty different talk, one which most non-technical people could see, follow along and appreciate. Alvaro took inspiration from the book “Metaphors We Live By”, and produce an article for ACM Queue. The talk was based on that article. The main point is that we as people think and process things using metaphors (or abstractions) all the time. For example, we may start learning mathematics with simple examples for counting, which is a metaphor / abstraction of the underlying mathematical concept. And we build on that over the years to other levels of the abstraction, using different metaphors. And software developers do the same, using different metaphors for all kind of problems (e.g. “Rumor Mongering” or “Gossiping”). The bottom line is that we should be aware of these metaphors and choose the right ones for the situation. A less technical talk that gave a well-rounded feel to a tech-conference like CodeMesh. Pony for Safe, Fast, Concurrent Programs — Sophia Drossopoulou Sophia Drossopoulou, Professor in Programming Languages at Imperial College London. Speaker: Video coming soon. Subscribe for notifications. Sophia gave an interesting talk on a emerging language called Pony. It is an Actor-based language like Erlang or Elixir, but compiles to native code. It also has a pretty innovative type system, which was the focus of this talk. All types and their respective rules can seem a bit intimidating for beginners, but Sophia says that you get used to it pretty quick. The good this is that this type systems gives you a lot of guarantee that you can’t find in most languages like: safe mix of mutable and immutable data, data-race free and efficient programs. Similar to Erlang/Elixir, it has a Garbage Collection mechanism that runs per-process concurrently, without distributed locks. I found it interesting that it also supports (or needs?) causal delivery for messages between actors, something rarely seen at a language level. Everything is Terrible — Fred Hebert Fred Hebert, author of ‘Learn You Some Erlang for Great Good!’ and ‘Erlang in Anger’, and system architect at Genetec. Speaker: Video coming soon. Subscribe for notifications. This is the perfect talk to watch if you want to have some laughs and also feel a bit sad at the state of software. Fred goes through a journey of multiple software abstractions of everyday software that we all use sooner or later. He emphasised six “terrible” topics: Data Structures, Time, IDs, Numbers, String/Text and Network. This is a talk that is clearly better to watch than to read some short summary like this. But essentially, the touched on horror stories involving: floating-pointer precision, UUIDs (lack of standardisation), queues/microservices (asynchrony is hard), JSON (every parser is different), time and time-zones, leap seconds, unicode mess and the (in)security of software. or learn more about , our new family of global tech conferences which now includes Code Mesh. Watch more videos from Code Mesh 2017 Code Sync Originally published at www.erlang-solutions.com .

Code Mesh 2017: Day 1 review

Photo by on Alex Knight Unsplash I love working with and am amazed at the evolution of this frontend paradigm. React and are two brilliant pieces of technology. Any amount of praise will fall short for them. React Redux But one question that kept coming to me was, am I being enough DRY ? Coming from the world of vanilla flux, Redux felt succinct. But a few big projects later, I was doing the same thing, over and over again. One part of the entire cycle which felt particularly verbose was writing reducers. We take an action and a payload and emit a mutation. I first wanted to eliminate the process of writing reducers, so I came up with — A flux without side effects but never finished it because came up with a similar library called . Mutex JayStack Repatch Looking back, Repatch’s idea was on the same line, but extremely mature. If I had worked on Mutex for about 2 years, I would have got Repatch. And being the lazy programmer I’m, it was best to just drop my own lib and use Repatch instead. But then came the realization of legacy code (and mental models) I spent a lot of time tweaking the and it was dependent on raw Redux. Although, Repatch was inline with my philosophy, I didn’t feel comfortable betting on it because : Fractal — A react app structure for infinite scale, Tightly coupled actions and reducers made it hard to write automated tests. Working on Repatch meant there is no going back. If I build an application and it doesn’t feel right after sometime, I am stuck. There were other notable projects like but the second point still held true. redux-zero, What I wanted Ideally, I wanted a system that : Fits well in our Fractal pattern Doesn’t bloat the build Reduces (or completely eliminates) the need to write reducers Doesn’t affect the testability of the store Cost of switch should be minimal The Eureka ! While bootstrapping a new project and copy pasting my usual authentication modules, I observed that most of my reducers : only took the payload and slapped them onto my state and reducer was a function that I define (with a big ass switch case) And I thought of writing a function, which generates a default reducer that slaps the payload onto the state. It’s called Keducer (“Kay-Deu-Cer”; and it’s just 5 lines of code that has eliminated 95% of my reducers). I so wanted to build an npm module for this but felt like it would be best to not contribute more to js fatigue, so a gist is all I made. How Redux works without keducers In a general Redux setting, here’s what a typical login reducer looks like : export default function reducer(state={}, action) {switch (action.type) {case 'auth.loginError':return {...state, loginErrors: action.payload.errors}; case 'auth.loginSuccess':  
  return {...state, isUserLoggedIn: true};

default:  
    return state; }} And the action definition might be on the lines of : export function login(email, password) {return (dispatch) => {api.post('/auth/login', {email, password}).then((res) => {Promise.all([storage.setItem('token', res.token),storage.setItem('user', JSON.stringify(res.user)),]).then(() => {dispatch({type: 'auth.loginSuccess'});});}).catch((err) => {dispatch({type: 'auth.loginError',payload: {errors: Object.values(err.data)}});});};} You simply load this reducer on a store and `Provide` it to the root component and then function on click events. dispatch(login) How Redux works with keducers With a keducer, whatever you pass as a payload is sticked on top of your state. But it does expect your actions to be separated strings so you might have to do some work there. . (dot) Step one : Setup a module Module is basically a ducks structure term for actions + reducers in one file. You can read more about it in my article. Fractal Structure The only notable difference is the absence of a reducer and export of a default keducer instead. Note that a keducer takes a key named that basically tells it to listen to all actions which have an prefix. auth auth. Now keducer will automatically take your payload and append it to state under the auth tree. import config from 'config';import api from 'utils/api';import storage from 'utils/localStoragePromise';import keducer from 'utils/keducer'; export default keducer('auth'); // <---- Where the magic happens export function login(email, password) {return (dispatch) => {api.post('/auth/login', {email, password}).then(res => {Promise.all([storage.setItem('token', res.token),storage.setItem('user', JSON.stringify(res.user)),]);dispatch({type: 'auth.loginSuccess', payload: {token, user}});}).catch(err => {dispatch({type: 'auth.loginError',payload: {loginErrors: err.data.err}});});};} Step 2 : Setup your root store Because keducer returns a function, there is nothing new that you need to do here. Just combineReducers as normal and pass it to the Provider. const rootReducer = combineReducers({auth,}); const store = createStore(rootReducer,compose(applyMiddleware(thunk),window.devToolsExtension ? window.devToolsExtension() : f => f)); This should be enough to get started, but if you are a Redux power user, you might be thinking : “Huh, this kills the entire concept of Redux because you can’t possibly share actions among various reducers” and “You can’t even update the state if it’s dependant on a previous state (for example loading more items in a list when user scrolls to the bottom of a page)”. Don’t worry power user, keducer has you covered. Step 3 : Access old state or share actions among keducers The function takes a second argument, which is a map like : keducer export default keducer('users', {'auth.loginSuccess': (state, payload) => ({...state, ...payload, ...{customStuff: true}})}) The keys of this map are action types that you wish to capture and the values are functions which get the state and the payload as a parameter. This state is the local reducer state, not the app state, so you can expect to do all your normal redux sorcery if you wish too (but you rarely would). A demo project I’m working on one and will have one soon. The soon is relative to the amount of claps and views this article gets. Closing thoughts These 5 lines of code save a lot of time writing reducers, but the bigger point here is that someone like me (without a lot of experience) was able to come up with something so obvious, whereas the entire js community bets on the verbose version. Also, the competing standards and js fatigue stopped me from building yet another module. I was kinda pissed with the way js is taught, used and improved and it all seems like a fad. I went searching for better solutions and have found one in clojurescript. My understanding about it is not as mature as js, but it is very very very promising. Very very. It’s like targeting js as a JVM and is backed by Cognitect (the company behind clojure, where Rich Hickey works). 🤙 I’m currently experimenting heavily with it (clojurescript), and please let me know if you want me to write about it. 🙏🏼 Thanks for taking time to read my work. I hope it will be helpful for your projects. ❤️ You might also like to read : Fractal — A react app structure for infinite scale Blockchain is like the transistor of the main frame Financial System [POEM] & The 99 that went before 14 life lessons learnt after 1 year of graduation

Keducer — Automate writing redux reducers with 5 lines of javascript

AI’s Cognitive Mirror: The Illusion of Consciousness in the Digital Age

A longer read about how Asimov’s Robopsychologist might be coming to life in AI as the Cognitive Architect. Last week at AI Engineer World Fair in San Francisco, engineers and technologists presented cutting-edge AI technology being developed. The conference was motivated by a think piece published by @swyx and @FanaHOVA, defining the role of the AI Engineer (AIE). This role sits at the intersection of product and technology, specializing in applying Large Language Models to software development. There was a common trend in some of the work presented: a need to overcome these models' more messy, probabilistic nature by making them more reliable and engineering-like. This is no surprise since AI Engineering focuses on applying these models to real-world problems. From building a question-answer engine like Perplexity to a tool for better note-taking like Granola, a certain level of determinism is needed to create products that can withstand real-world use. While at the conference, I also followed @hwchase17 on Sequoia's Training Data podcast, as he talked the notion of cognitive architectures. While this was part of a larger conversation about turning LLMs into reasoning agents, this notion of cognitive architecture pointed toward the idea that using LLMs is as much about human-to-machine cognition as it is about technology. Human-machine cognition means understanding human agency and translating it into instructions, considering the intricate steps we take when performing tasks (both conscious and subconscious), and translating them into machine code—that is, model language. Now, a small detour into science fiction: In Asimov's I, Robot, robopsychology is the field of understanding and troubleshooting the complex psychological and behavioral issues that arise as robots (read: AI) become more sophisticated and integrated into human society. Dr. Susan Calvin, a robopsychologist, navigates the dilemmas posed by the laws of robotics. Here, I see a parallel between Asimov's study of robotic psychology and the challenges of training AI models to do what we want them to do. We've built a technology we're still working to understand. @mustafasuleyman even suggests it isn't just a technology, but a new kind of digital species—what an idea! Given the challenges of engineering with language models and their incredible power, there might be a gap in applied AI waiting to be filled by Cognitive Architects—a role most likely already in existence in research labs at OpenAI, Anthropic, or Google. Much like an architect works alongside a civil engineer to research how humans live, the Cognitive Architect may work with computer scientists to study human cognition and its relation to model cognition. From examining the boundaries of the model's probabilistic knowledge (latent space) to using the right keywords and canonical definitions to express instructions, to decomposing complex human tasks into the flows of actions, tools, and models, the Cognitive Architect might be part of the recipe to applying these models in ways that don't just tame it down to an engineering feature, but also harness their true nature: To predict where we're most likely to go next. A longer read about how Asimov’s Robopsychologist might be coming to life in AI as the Cognitive Architect. Last week at AI Engineer World Fair in San Francisco, engineers and technologists presented cutting-edge AI technology being developed. The conference was motivated by a think piece published by @swyx and @FanaHOVA , defining the role of the AI Engineer (AIE). This role sits at the intersection of product and technology, specializing in applying Large Language Models to software development. @swyx @FanaHOVA There was a common trend in some of the work presented: a need to overcome these models' more messy, probabilistic nature by making them more reliable and engineering-like. This is no surprise since AI Engineering focuses on applying these models to real-world problems. From building a question-answer engine like Perplexity to a tool for better note-taking like Granola, a certain level of determinism is needed to create products that can withstand real-world use. While at the conference, I also followed @hwchase17 on Sequoia's Training Data podcast, as he talked the notion of cognitive architectures. While this was part of a larger conversation about turning LLMs into reasoning agents, this notion of cognitive architecture pointed toward the idea that using LLMs is as much about human-to-machine cognition as it is about technology. @hwchase17 Human-machine cognition means understanding human agency and translating it into instructions, considering the intricate steps we take when performing tasks (both conscious and subconscious), and translating them into machine code—that is, model language. Now, a small detour into science fiction: In Asimov's I, Robot, robopsychology is the field of understanding and troubleshooting the complex psychological and behavioral issues that arise as robots (read: AI) become more sophisticated and integrated into human society. Dr. Susan Calvin, a robopsychologist, navigates the dilemmas posed by the laws of robotics. Here, I see a parallel between Asimov's study of robotic psychology and the challenges of training AI models to do what we want them to do. We've built a technology we're still working to understand. @mustafasuleyman even suggests it isn't just a technology, but a new kind of digital species—what an idea! @mustafasuleyman Given the challenges of engineering with language models and their incredible power, there might be a gap in applied AI waiting to be filled by Cognitive Architects—a role most likely already in existence in research labs at OpenAI, Anthropic, or Google. Much like an architect works alongside a civil engineer to research how humans live, the Cognitive Architect may work with computer scientists to study human cognition and its relation to model cognition. From examining the boundaries of the model's probabilistic knowledge (latent space) to using the right keywords and canonical definitions to express instructions, to decomposing complex human tasks into the flows of actions, tools, and models, the Cognitive Architect might be part of the recipe to applying these models in ways that don't just tame it down to an engineering feature, but also harness their true nature: To predict where we're most likely to go next.

The Rise of the Cognitive Architect

This paper is available on arxiv under CC 4.0 license. Authors: (1) Vogt, Lars, TIB Leibniz Information Centre for Science and Technology; (2) Konrad, Marcel, TIB Leibniz Information Centre for Science and Technology; (3) Prinz, Manuel, TIB Leibniz Information Centre for Science and Technology. Table of Links Abstract & Introduction Interoperability Semantic interoperability and what natural languages like English can teach us Requirements for successfully communicating terms and statements Parallels between the structure of natural language statements and data schemata with implications for semantic interoperability What makes a term a good term and a schema a good schema? The need for a machine-actionable Rosetta Stone for (meta)data that acts as an interlingua for specifying reference terms and reference schemata to support cognitive and semantic interoperability Rosetta Stone and machine-readability: UPRIs, XML Schema datatypes, and RDF for communicating terms, datatypes, and statements Rosetta Stone and machine-interpretability: Wikidata and a modeling paradigm for (meta)data statements based on English Rosetta Stone and semantic interoperability: Specifying term mappings and schema crosswalks Rosetta Stone and cognitive interoperability: Specifying display templates and using a query builder Discussion Related work Conclusion, Acknowledgements, & References Rosetta Stone and cognitive interoperability: Specifying display templates and using a query builder Display templates Humans usually do not want to see the (meta)data of a knowledge graph in the form of triples—they do not want to read them in any of the RDF serializations, nor do they want to visualize them as a graph. In order to display the content of a (meta)data statement modeled according to the Rosetta approach in a human-actionable way, a frontend application needs a display template that specifies how a rendering function can translate a given (meta)data structure into a human-readable statement. Display templates organize information from the (meta)data structure along with additional prepositions to be presented in the UI. For example, if a weight measurement with a 95% confidence interval were stored according to an appropriate reference schema, the schema would specify four literal-object-positions (MAIN_VALUE, UPPER_VALUE, LOWER_VALUE, INTERVAL_VALUE) and one resource-object-position (UNIT). The form-based display template could specify that this information should be displayed in the frontend as ‘SUBJECT has weight (INTERVAL_VALUE% conf. interval): MAIN_VALUE (LOWER_VALUE-UPPER_VALUE) UNIT’. Another example is a travel statement where the corresponding reference schema specifies one required resource-object-position (DESTINATION_LOCATION), two optional resource-object-positions (DEPARTURE_LOCATION, TRANSPORTATION), and one optional literal-object-position (DATETIME). The corresponding display template would display a travel statement in the frontend as ‘PERSON travels by TRANSPORTATION from DEPARTURE_LOCATION to DESTINATION_LOCATION on the DATETIME‘. In other words, the subject-position and the various object-positions (i.e., the syntactic positions with their associated semantic roles) are mapped to corresponding variables within a string to form a human-readable statement (see Fig. 10, top). We call such textual display templates dynamic labels. In addition to textual display templates, it is also possible to specify graphical display templates for a mind-map-like representation of a statement using dynamic mind-map patterns. Dynamic mind-map patterns use a label for the predicate underlying the corresponding statement type and, if there is more than one object-position, labels for relating the various objects to the predicate. As a result, the statement can be visualized as a mind-map like graph, where each subject and object is represented as a node with the label of the corresponding resource from the underlying graph of the (meta)data statement (see Fig. 10, bottom). Such graphical representations of statements can also be combined to form a mind-map of larger contexts and interrelationships that connect the dynamic mind-map patterns of multiple statements. Mind-map-like representations of complex interrelationships between different entities are easier to understand than form-based textual representations, thus increasing the human-actionability of a knowledge graph. (Meta)data can be communicated to the presentation layer in the UI, with the templates filtering the complex data structure for the information relevant to a human user, using dynamic labels and dynamic mind-map patterns to present statements, decoupling human-readable data display from machine-actionable data storage. A given reference schema can have multiple dynamic labels and dynamic mind-map patterns associated with it. It can be beneficial to be able to choose between different display templates depending on the context in which the (meta)data are accessed (PC vs. smartphone, expert user vs. layperson, etc.). The specifications of each display template should be associated with its corresponding reference schema and statement class, thus contributing to the easily accessible and usable Rosetta module mentioned above, moving it even closer to the concept of Knowledge Graph Building Blocks (64). A Rosetta Query-Builder We believe that findability is the most important aspect of any tool that stores and documents (meta)data. If relevant (meta)data cannot be found, no other operations can be performed on it, and interoperability issues become secondary. In the context of knowledge graphs, specific query endpoints have been established along with corresponding graph query languages to interact with the graph. These are SPARQL for RDF- and OWL-based knowledge graphs and Cypher for labeled property graphs such as Neo4J. Our personal experience is that most users and software developers have no experience with graph-based databases, are not familiar with graph query languages and their benefits, and therefore do not see the need to learn them. And even those who are familiar with them report that writing more complex queries can be challenging. Apparently, the need to write SPARQL or Cypher queries is a barrier to interacting with knowledge graphs and hinders their wider use (65). The semantic unit framework introduced some-instance and every-instance resources as two new types of resources in addition to named-individuals, classes, and properties (50). This allows, besides specifying universal statements and negations without having to use blank nodes and simplifying negations and cardinality statements, modeling them as ABox expressions, also representing questions as statements in the graph (for a discussion, see (10,64)). Instead of named-individuals, one uses some-instance resources of a given class for a given slot of a reference schema to specify that the answer to the question may have any instance of that class at that position in any statement of the type to which the reference schema is associated. If you are asking about universal statements, you would use the every-instance resource instead. The resulting statement can be stored as a question within the knowledge graph, by classifying its statement resource to instantiate the ‘question statement’ class. Since all question statements in a given knowledge graph would reflect the structure of their corresponding reference schema, and since all reference schemata have been created according to the same modeling paradigm, one could develop a Rosetta Query-Builder that converts the question into a query that returns a Boolean true/false answer if the subject and object-positions contained fully specified inputs (i.e., named-individual resources), or a list of statements as the answer that match the specifications provided by the question statement if one or more of these positions contained underspecified input (i.e., some-instance, every-instance, or class resources). The same idea provides the basis for developing query interfaces for knowledge graph applications: users can create their own queries with the input forms for creating statements using named-individuals, some-instances, every-instances, classes, and datatypes as inputs for subject and object-positions without having to know and use any graph query languages. The Query-Builder translates the question statements into actual graph queries. The generic structure of the reference schemata greatly facilitates the development of procedures for this translation step. By using Boolean operators (AND and OR) and by reusing object resources as subject resources in another question statement, multiple question statements can be combined to form a more complex question. Question units not only allow you to document questions in the graph, but also to make them operable. This can be used, for example, to document competency questions for a project in a readily actionable way within the knowledge graph itself. The ability to store question statements and make them operable moves the Rosetta Framework another step closer to the concept of Knowledge Graph Building Blocks (64) and further enhances its overall cognitive interoperability.

Rosetta Stone and Cognitive Interoperability: Specifying Display Templates and Using a Query Builder

I have always been very conscious about how and where I spend my time. While I paid a lot of attention to the obvious ways to be more productive—create a distraction-free focused zone, limit time on social media, divide my work into small blocks of time, and take regular breaks to revive and rejuvenate—I missed a crucial element that often gets in the way of our productivity. Our brain. The human brain has this remarkable cognitive capacity to perform at levels far beyond what we consider our natural abilities, but it’s not without its limits. The that enable the brain to prioritize and process large amounts of information quickly also get in the way of our productivity. These mental shortcuts are the brain's way to conserve energy and work more efficiently. But they also lead to many thinking errors. cognitive biases Here are the 4 cognitive biases that have the biggest impact on our productivity—how we prioritize, make decisions, manage time, and get work done. Urgency effect Zeigarnik effect Complexity bias Planning fallacy Urgency effect When an urgent task comes knocking at the door, do you push important work aside because urgent tasks demand your immediate attention while important goals are far off into the future and can wait until later? Urgency effect makes us jump at every chance to solve time-sensitive urgent matters while putting off important work. Rationally our brain knows that important tasks have a larger payoff and bigger rewards in the long run, but under the effect of this bias, we fall victim to perceiving urgent as important. Urgent tasks keep us busy and make us feel important, but they also suck into our time. Prioritizing it at the expense of more impactful work keeps us trapped in an illusion of productivity. Why we fall for the urgency effect Important tasks typically have no specific deadline. They are time-consuming and complex as they often require looking into the future and proactively identifying its needs. Giving clarity to vague ideas, making crucial decisions, or laying out a future strategy is not only time-consuming, it’s also mentally taxing. Urgent tasks have easy-to-reach, visible goals. They bring instant gratification with a big hit of dopamine. Since dopamine serves as a reinforcement for remembering and repeating pleasurable experiences, you end up dedicating more time to urgent tasks at the expense of more impactful work. Continuously pushing important tasks to the back burner keeps us locked in a never-ending cycle of unproductive choices—dedicating less time to important work inevitably creates more urgency later. Important tasks become urgent in due course of time if delayed too much, not given proper attention, or carried out without real interest. Example of urgency effect Gina is the tech manager of the CRM team. The latest releases in ChatGPT and other AI innovations is becoming a threat to her business. But instead of spending time planning how to make them a part of their future strategy, Gina ends up spending most of her time on emails, meetings, and other urgent tasks. Her busyness keeps her locked in a cycle of unproductivity and inefficiency. Urgency effect makes her pay more attention to the work right in front of her—emails, chat notifications, customer escalations—while pushing important work aside. How to avoid urgency effect A great practice to avoid urgency bias involves using The Eisenhower Matrix for prioritization. To put the Eisenhower matrix to use, go through each task one by one and separate them into four possibilities: Important and Urgent (Quadrant 1): reduce time spent here Important and Not Urgent (Quadrant 2): consciously prioritize and schedule these tasks Not Important and Urgent (Quadrant 3): delegate these tasks Not Important and Not Urgent (Quadrant 4): declutter and eliminate. Consciously scheduling dedicated hours on the calendar to do important work makes it more likely that you attend to them without interruptions. A few other practices to adopt: Set aside specific blocks of time for responding to emails, chats, or other such tasks. Reduce time spent in meetings. Utilize your peak productivity period to do your most important work. Matching your energy with the physical and mental demands of work will enable you to do your best work making it more likely for you to continue instead of giving up. Set deadlines for important tasks and hold yourself accountable for meeting them. Zeigarnik effect Thoughts of unfinished tasks keep popping up in our head right when we get down to work or are trying hard to focus. *Emails we haven’t replied to.* Pending design to compete. Meetings to schedule. … so on and on. These intrusive thoughts that take away our attention even for a split second make it hard to concentrate and get any meaningful work done. Distractions from incomplete work prevent us from entering into a state of flow—which is when we are completely immersed in a task and the time seems to stand still. Flow minimizes distractions, prevents procrastination, and lead to high performance and productivity. Named after psychologist Zeigarnik who first discovered it, the effect refers to the tendency to remember unfinished or interrupted tasks better than completed ones. Letting our brain continually remind us that we haven’t done something is quite unpleasant and it can even lead to stress, anxiety, and burnout. Why we fall for the Zeigarnik effect Zeigarnik and her professor Kurt Lewin observed that their restaurant waiters remembered everyone’s orders despite never writing anything down. But as soon as the bill was paid, they had little or no memory of who their customers were or what they had ordered. This led to a series of experiments based on which Zeigarnik concluded that human minds treat tasks that have been completed differently from those that are still left to be completed. A task that has already been started establishes a task-specific tension, which keeps it at the forefront of our memory. The tension is relieved upon completion of the task but persists if it is interrupted or not yet completed. That’s why unfinished tasks keep coming back to haunt us. Look another way, these reminders can be useful to help us finish incomplete projects only if they do not spoil our attention right in the middle of another project. Attention is like energy in that without it no work can be done, and in doing work is dissipated. We create ourselves by how we use this energy. Memories, thoughts and feelings are all shaped by how we use it. And it is an energy under control, to do with as we please; hence attention is our most important tool in the task of improving the quality of experience. ― Mihaly Csikszentmihalyi Example of Zeigarnik effect Zeigarnik effect is used in gamification: Progress trackers informing users of how close they are to completing a task. For example, when users see a message like "Your profile is 34% complete", they are more likely to spend a few minutes providing all the missing details. This technique is used by to collect user information in a super smart way. LinkedIn Checklists that provide users with a clear step-by-step flow to onboard users faster and more effectively. Interrupted commercials are more likely to be remembered than those that are not due to the Zeigarnik effect. Advertisers use it to catch the attention and memory of viewers. How to avoid the Zeigarnik effect by Florida State University shows that planning work upfront and writing it down can free your mind from distracting thoughts about unfinished work. Have daily, weekly, and monthly rituals to review, prioritize, and plan what you intend to do. When you miss something and it pops up in your head, don’t leave it hanging there, immediately write it down. Research Moving tasks from your head onto paper relaxes your brain and helps you focus on the task at hand. A few other practices to adopt: Avoid procrastination by using the Zeigarnik effect to your advantage. Instead of putting things off because they are big or complex, simply take a very small step towards it. Once you get started, your brain will kick off the Zeigarnik effect enabling you to keep going till the end. Use the Pomodoro method to divide your work into small chunks of focused time. The tactical breaks in the Pomodoro method improve memory and keep productive momentum going. Complexity bias Given a choice between two competing solutions, we are likely to choose the more complex one. Jargon catches our attention over simple explanations. Difficult-to-execute strategies impress us over straightforward ones. Sophisticated products appear more authoritative while ordinary ones appear inferior. But complexity has many problems: Knowing upfront that something is difficult can prevent us from getting started. Obstacles and challenges along the way make it hard to persist and we may give up too soon. It can delay decision-making. It’s costly as it requires more time, effort and resources to get done. It can be potentially dangerous. Not understanding something fully can lead to wrong assumptions and conclusions. It can lead to hiding mistakes and fundamental flaws. Complexity bias is the tendency to prefer complicated explanations, solutions, and arguments over easy ones. Why we fall for the complexity bias Many people mistake simple for easy. Finding simple solutions to problems may sometimes require more effort—a conscious effort to dig deeper and give way to our creative mind, avoiding biases to cut through complexity and finding solutions that do not require too much scaffolding to support. Complexity in such cases could be an excuse to label the problem as too confusing and shove it aside. We choose complexity over simplicity for another reason: it’s falsely associated with expertise, innovation and authority. The more complex or advanced the approach is, the more superior it appears. Put another way, if a solution is too simple, we assume it won’t solve the problem. This makes us inject complexity and over complicate things instead of choosing a simpler approach. \As Edsger Wybe Dijkstra, a Dutch computer scientist once said “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” Example of complexity bias Jim got an opportunity to prepare and present the design of a new product to his entire team. He wanted the solution to stand out and establish credibility with others. But instead of asking the question “What problem is this product required to solve and how can I solve it in the simplest way possible?” he asked, “What problem is this product required to solve and how can I make it look good?” Trying to make the solution appealing led to poor choices: Instead of choosing a simple technology he understood well, he decided to use a new technology with no experience or expertise. He made complex architectural decisions to make the product look sophisticated. He introduced features that added little to no value to a customer but sounded interesting to implement. Complexity bias in his case led to poor decisions and terrible choices. How to avoid the complexity bias To counteract complexity bias, apply Occam’s razor. It is one of the most useful mental models to solve problems. Occam’s razor advocates simplicity by focusing on key elements of the problem, eliminating improbable options, and finding solutions with fewer assumptions. Another useful mental model to reduce complexity is first principles thinking. It requires breaking down a problem into its fundamental building blocks (its essential elements), asking powerful questions, getting down to the basic truth, separating facts from assumptions, and then constructing a view from the ground up. A few other practices to adopt: Since complexity bias shields you from seeking simple solutions, asking for others' opinions may be helpful. You may ask “Is my solution too complex or confusing?” Question your intent. Reframe the end goal to align it with the outcomes you wish to achieve. Show bias for action. Instead of being stuck in analysis paralysis, take a small step towards your goal, see how it works, and slowly improve it over time. Planning fallacy When it comes to setting deadlines, most of us are highly optimistic. Even if it’s something similar to what we have done in the past, we are still likely to underestimate how much time it will take to do it in the future. It took one week to finish a design proposal last time, but if you have to do it again, you’re positive it will get done in less than a week. It took more than a month for your new hires to get onboarded last time, but while planning for the new batch coming in next week, you allocated only 2 weeks. The planning fallacy is what makes us commit to overly optimistic timelines, miss those deadlines, and then drown in guilt, anxiety, and stress. Not factoring in realistic demands of the task leads to poor planning for the future. It harms your reputation and also breaks trust because when you miss those deadlines, others assume that you don’t take your commitments seriously. Why we fall for the planning fallacy When estimating the time it will take to complete a specific task, we ignore risks and other unlikely events that may prevent us from completing the task on time. Taking the best-case scenario into account and ignoring the obstacles we might encounter along the way leads to wishful thinking. We have the best intentions to get the work done quickly and efficiently, but good intentions aren’t always enough. Good planning needs good estimation skills. Another reason why we are highly optimistic about completing a specific job is our tendency to get stuck in the nitty gritty while ignoring the big picture. Not taking the big picture into account leads to poor estimation—we make wrong assumptions and ignore the time it will take to integrate our work into the bigger picture. We are also really bad at accurately judging our skills and abilities. Our enthusiasm to meet our goals adds to the planning fallacy. \Worst part? We don’t even learn from our past mistakes. Even when we can recognize past mistakes when we are overly optimistic, we keep on making the same mistakes in the future. We focus on our goal, anchor on our plan, and neglect relevant base rates, exposing ourselves to the planning fallacy. We focus on what we want to do and can do, neglecting the plans and skills of others. Both in explaining the past and in predicting the future, we focus on the causal role of skill and neglect the role of luck. We are therefore prone to an illusion of control. We focus on what we know and neglect what we do not know, which makes us overly confident in our beliefs. ― Daniel Kahneman Example of the planning fallacy Tina is working on the estimates of a new product. She has worked on a similar product in the past. The last time she built the product, it took her 3 months to complete. The project was initially estimated for 2 months but took an additional month due to requirements changes, a longer testing cycle, and other unforeseen issues. Tina has experience from the past that she should put to use to determine how long it will take to complete the current project. However, due to the planning fallacy, she commits to a 2-month deadline again. She justifies it by assuming that her experience from the past project will help her finish the tasks sooner while completely disregarding the additional time it will take to handle unexpected issues. How to avoid planning fallacy Break down the project into small parts and estimate how long each one will take. Doing this work upfront will make your effort estimates much closer to reality than being vaguely guided by hunch. Another great strategy is the one recommended by Daniel Kahneman - He suggests taking an outside view of your estimates by consulting others—asking questions and identifying problems and mistakes they made on similar projects in the past. You can’t do this for all your tasks but definitely do it for your most crucial ones. Irrespective of how good you’re at estimation, some unlikely event can crop up and make your project fall through the cracks. It isn’t possible to take every such scenario into account and plan for it. But what’s possible is to add a little buffer to your estimates—add 20% breathing room while considering the effort it takes to do something. Finally, and this is the most important one: implement a feedback loop in your process. Track your time. Make a note of how long it takes to do something. When you miss deadlines, identify what mistakes you made and what changes you need in your planning process to do better next time. When you’re conscious of how these biases—Urgency effect, Zeigarnik effect, Complexity bias and Planning fallacy—affect your time and apply the right strategies to overcome them, you can be your most productive self. Summary Most of us struggle with getting work done efficiently because we don’t pay attention to the cognitive biases that get in the way of using time productively. Urgency effect makes us waste time attending to urgent tasks at the cost of important tasks. Not paying attention to the future needs keeps us trapped in a cycle of unproductivity. The Zeigarnik effect prevents us from giving our best to the task at hand. When our mind keeps reminding us of incomplete or interrupted tasks, it’s hard to stay focused and pay attention. Complexity bias makes us add unnecessary complexity to solutions which increases the time, effort and cost to solve even simple problems. Planning fallacy tricks our mind to give highly optimistic estimates to achieve a certain goal despite our previous experience telling us that it will be impossible to achieve it. This story was previously published . here Follow me on or here for more stories. LinkedIn

Tackling the Saboteurs Within: 4 Cognitive Biases That Affect Your Productivity

এর মধ্যে নাশকতাকারীদের মোকাবেলা করা: 4টি জ্ঞানীয় পক্ষপাত যা আপনার উত্পাদনশীলতাকে প্রভাবিত করে

Die inneren Saboteure bekämpfen: 4 kognitive Vorurteile, die sich auf Ihre Produktivität auswirken

Enfrentando a los saboteadores internos: 4 sesgos cognitivos que afectan su productividad

S'attaquer aux saboteurs intérieurs : 4 biais cognitifs qui affectent votre productivité

भीतर के तोड़फोड़ करने वालों से निपटना: 4 संज्ञानात्मक पूर्वाग्रह जो आपकी उत्पादकता को प्रभावित करते हैं

内部の妨害者に対処する: 生産性に影響を与える 4 つの認知バイアス

내부의 파괴자 대처 방법: 생산성에 영향을 미치는 4가지 인지 편향

Enfrentando os sabotadores internos: quatro preconceitos cognitivos que afetam sua produtividade

Борьба с внутренними саботажниками: 4 когнитивных искажения, которые влияют на вашу продуктивность

İçimizdeki Sabotajcılarla Mücadele Etmek: Verimliliğinizi Etkileyen 4 Bilişsel Önyargı

Giải quyết những kẻ phá hoại bên trong: 4 thành kiến nhận thức ảnh hưởng đến năng suất của bạn

解决内部破坏者：影响生产力的 4 种认知偏差

DARPA is putting together the Intrinsic Cognitive Security ( ) research program “to build tactical mixed reality systems that protect against cognitive attacks.” ICS As the Pentagon sees (MR) becoming ubiquitous in future military missions, the US ( ) is looking to protect users against cognitive attacks in this hybrid environment. mixed reality Defense Advanced Research Projects Agency DARPA “The ICS program seeks breakthrough innovation for computational science to build tactical mixed reality systems that protect against cognitive attacks” DARPA, Intrinsic Cognitive Security (ICS) program, October 2023 According to the DARPA , such attacks can include: ICS program description Information flooding to increase equipment latency and induce physical illness. Planting real-world objects to overwhelm displays. Subverting a personal area network to sow confusion. Injecting virtual data to distract personnel. Using objects to overwhelm a user with confusing false alarms. Assessing user status through an eye tracker. And other potential attacks. Apart from military applications, DARPA’s new program could provide us with a glimpse into the future of the commercial metaverse and how bad actors could manipulate mixed reality environments in nefarious ways. ICS Criminal groups, governments, and corporations could weaponize the by manipulating mixed reality systems in real-time to be able to see what you see, to know what you are feeling, and to potentially plant deceptive information in order to achieve a desired reaction. metaverse A published in in 2020 lists five types of threats to mixed reality environments: research paper Procedia Computer Science : Involves challenges towards ensuring the security and privacy of data gathered and inputted to MR platform. Input Protection : The MR eye-wear can capture the sensitive information on the user’s desktop screen such as e-mails, chat logs. These necessary protections can be mapped to properties of concealment, unobservability & undetectability, and content awareness. Example : A large amount of data collected from the sensors is stored in the database or other forms of data storage. The main threats to data collection are tampering, denial of service, and unauthorized access among others. Data Protection : An adversary can tamper MR targets to elicit a different response from the system or to outright deny a service. Aside from security threats, likability, detectability, and identifiability are some of the privacy threats that results from continuous or persistent collection of data. Example : After the data is processed, the application sends output to the MR device which is to be displayed. In MR the applications may have access to other application outputs and thus can modify those outputs making them unreliable. Output Protection : Output displays are vulnerable to physical inference threats or visual channel exploits such as shoulder-surfing attacks. These are the same threats to user inputs especially when the input and output interfaces are on the same medium or are integrated together. Example : MR includes the utilization of other sensing and display interfaces to allow immersive interactions. One of the key prospects is how users can share MR experiences with guarantee of security and privacy of information. User Interaction Protection : An adversarial user can potentially tamper, spoof, or repudiate malicious actions during these interactions. As a consequence, genuine users might go through denial of service. Additionally, their personal data might have been compromised, leaked and used. Example : The MR interfaces are exposed to malicious and harmful interpretation leading to discovery of input and output display information. Device Protection : The head mounted displays (HMDs) display the content through its lenses, which other people can see from outside leading to leakage and external observation. Devices like a camera, which are also categorized as visual capture devices, are used to capture and extract this information which was leaked from the HMDs. Example A report by adds, “ .” Kaspersky It is nearly impossible to anonymize VR and AR tracking data because individuals have unique patterns of movement. Using the behavioral and biological information collected in VR headsets, researchers have identified users with a very high degree of accuracy – presenting a real problem if VR systems are hacked For DARPA’s program, the core technical hypothesis is that “formal methods can be extended with cognitive guarantees and models to protect mixed reality users from cognitive attacks.” ICS As “cognitive models represent aspects of human perception, action, memory, and reasoning,” DARPA’s program will “extend formal methods by explicitly creating and analyzing cognitive and other models as part of MR system development to protect the warfighter from adversary attacks.” ICS “Mixed reality integrates virtual and real worlds in real-time and will be ubiquitous in future military missions, including missions involving dismounted soldiers” DARPA, Intrinsic Cognitive Security (ICS) program, October 2023 For years, the US Department of Defense (DoD) has been funding research to equip its warfighters with . technologies to augment their capabilities For example, both DARPA and the Defense Innovation Unit (DIU) have been looking to mixed reality and hand-held devices for operators to interact with upwards of 250 autonomous vehicles through a military tactic known as swarming. In 2018, DARPA launched its OFFensive Swarm-Enabled Tactics ( ) program to leverage augmented and virtual reality, along with voice, gesture, and touch-based technologies, to enable users to interact with potentially hundreds of unmanned platforms simultaneously in real time. OFFSET And in March 2021, the that would allow soldiers to operate multiples types of unmanned air and land vehicles using wearable and handheld controllers. DIU was looking for commercial solutions Now, the Pentagon is looking to protect users from cognitive attacks in those mixed reality environments. Will solutions coming out DARPA’s program make their way into the commercial sector to protect private citizens in the metaverse? ICS Could the technology and tactics developed be used for future in their own right? PSYOPs and influence campaigns The program proposers day will be held on October 20, 2023 in Arlington, Virginia. ICS This article was originally published by on Tim Hinchliffe The Sociable.

DARPA Readies Program to Safeguard Mixed Reality Users from Cognitive Attacks

জ্ঞানীয় আক্রমণ থেকে মিশ্র বাস্তবতা ব্যবহারকারীদের রক্ষা করার জন্য DARPA প্রস্তুত প্রোগ্রাম

DARPA bereitet Programm zum Schutz von Mixed-Reality-Benutzern vor kognitiven Angriffen vor

DARPA prepara un programa para proteger a los usuarios de realidad mixta de ataques cognitivos

La DARPA prépare un programme pour protéger les utilisateurs de réalité mixte contre les attaques cognitives

DARPA ने मिश्रित वास्तविकता वाले उपयोगकर्ताओं को संज्ञानात्मक हमलों से बचाने के लिए कार्यक्रम तैयार किया

DARPA、複合現実ユーザーを認知攻撃から守るプログラムを準備

DARPA, 인지 공격으로부터 혼합 현실 사용자를 보호하기 위한 프로그램 준비

DARPA prepara programa para proteger usuários de realidade mista contra ataques cognitivos

DARPA готовит программу для защиты пользователей смешанной реальности от когнитивных атак

DARPA, Karma Gerçeklik Kullanıcılarını Bilişsel Saldırılardan Korumak İçin Program Hazırlıyor

Chương trình sẵn sàng của DARPA để bảo vệ người dùng thực tế hỗn hợp khỏi các cuộc tấn công nhận thức

DARPA 准备计划保护混合现实用户免受认知攻击

COGNITE

cognite.com

501-1K employees

Since 2016

COMPANY RANKING

COGNITE

EVERGREEN INDEX #3683

Representing this company? Click here to claim and customize this page!

Cognite WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

COGNITE

cognite.com

501-1K employees

Since 2016

COMPANY RANKING

COGNITE

EVERGREEN INDEX #3683

RELATED COMPANIESRANK

STORIES ABOUT COGNITE

Representing this company? Click here to claim and customize this page!

Cognite WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!