H-3809: Update glossary pages (#5900)

apps/hashdotai/glossary/actor-model.mdx

@@ -5,7 +5,7 @@ slug: actor-model
 tags: ["Simulation Modeling", "Software Engineering"]
 ---
 
-[HASH Engine](/platform/engine) (which powers [HASH Core](/platform/core) and our [cloud compute platform](/platform/cloud)) provides an ultra-fast framework for running large-scale simulations in a distributed fashion. To enable this, an _actor model_ is utilized, and simulations built atop HASH must take this into account. This sets HASH apart from more traditionally _object-oriented_ simulation packages.
+[HASH Engine](/platform/engine) provides an ultra-fast framework for running large-scale simulations in a distributed fashion. To enable this, an _actor model_ is utilized, and simulations built atop HASH must take this into account. This sets HASH apart from more traditionally _object-oriented_ simulation packages.
 
 ## What is object-oriented simulation?
 
@@ -86,7 +86,7 @@ In the actor model, agents consist of **state**, have **behaviors**, and communi
 
 ## Actor-based implementation
 
-The same simulation shown in object-oriented form can easily be implemented using the actor-based framework in HASH. This simulation is available to view and run on [hIndex](https://simulation.hash.ai/@hash/random-coins). We start by initializing the simulation — specifying which agents should be created and setting their initial state. This may be performed declaratively as shown in `init.json` below.
+The same simulation shown in object-oriented form can easily be implemented using the actor-based framework in HASH. This simulation is available to view and run on [HASH](https://simulation.hash.ai/@hash/random-coins). We start by initializing the simulation — specifying which agents should be created and setting their initial state. This may be performed declaratively as shown in `init.json` below.
 
 ```json
 [
@@ -108,7 +108,7 @@ The same simulation shown in object-oriented form can easily be implemented usin
 ]
 ```
 
-There a few interesting points of note here. First, agents in hash can create other agents. The simulation is initialized with a single agent which in-turn creates all people agents in the model. Second, behaviors compose with each other. All people agents have two behaviors: `make_bet.js` and `@hash/random-movement/random_movement.rs`. The first is a user-defined behavior which allows an agent to engage in bets, and the second allows agents to move throughout the grid as the simulation progresses — one of the many behaviors made available by the community on [hIndex](https://simulation.hash.ai/index).
+There a few interesting points of note here. First, agents in hash can create other agents. The simulation is initialized with a single agent which in-turn creates all people agents in the model. Second, behaviors compose with each other. All people agents have two behaviors: `make_bet.js` and `@hash/random-movement/random_movement.rs`. The first is a user-defined behavior which allows an agent to engage in bets, and the second allows agents to move throughout the grid as the simulation progresses — one of the many behaviors made available by the community on [HASH](https://simulation.hash.ai/index).
 
 The `make_bet.js` behavior is shown below.
 
@@ -148,4 +148,4 @@ The behavior logic is similar to that of the object-oriented method, but is cruc
 
 The actor model allows HASH to present a user-friendly and intuitive approach to agent-based modelling. Because only agents can modify their own state, the requirement that object-oriented frameworks place on the user to implement lock-based synchronization is removed, allowing for much more scalable world-building. The very same simulations run locally on multiple cores, and scale seamlessly to large clusters running in the cloud.
 
-For users looking for an approach to class inheritance offered by object-oriented programming, HASH provides [Agent Types](https://hash.dev/docs/simulations/behaviors/inheritance). Agents in HASH can have any number of types, allowing agent logic to be similarly clustered, inherited, and attached in the form of grouped behaviors.
+For users looking for an approach to class inheritance offered by object-oriented programming, HASH provides [Entity Types](/glossary/entity-types) which allow both [attribute](/glossary/attributes) and [behavior inheritance](https://hash.dev/docs/simulations/create/behaviors/inheritance). Agents in HASH can have any number of types, allowing agent logic to be similarly clustered, inherited, and attached in the form of grouped behaviors.

apps/hashdotai/glossary/agent-based-modeling.mdx

@@ -7,7 +7,7 @@ tags: ["Simulation Modeling"]
 
 ## What is ABM?
 
-An Agent-Based Model (ABM) is a construction of how entities (agents) act in an imagined environment. Typically used as aides when modeling difficult or complex real-world systems, ABMs allow environments to be synthesized in digital form, with differing scenarios run within them, in order to observe how the behavior of agents changes under varying conditions, and itself can impact the broader system. This coevolution, and modeling of interdependencies, can be hard to capture via other means. ABMs are often used in support of probabilistic modeling efforts.
+An Agent-Based Model (ABM) is a construction of how [entities](/glossary/entities) (agents) act in an imagined environment. Typically used as aides when modeling difficult or complex real-world systems, ABMs allow environments to be synthesized in digital form, with differing scenarios run within them, in order to observe how the behavior of agents changes under varying conditions, and itself can impact the broader system. This coevolution, and modeling of interdependencies, can be hard to capture via other means. ABMs are often used in support of probabilistic modeling efforts.
 
 Agents in ABMs do not necessarily have ‘agency’ in the traditional sense of the word, but should be thought of as component parts of a wider system capable of impacting it and/or being affected by it. Varying any the the number, type, or properties/behaviors of agents can have a ripple effect on the system as a whole. Experiments within ABMs seek to tweak these variables to explore how different scenarios unfold, and what end-states are likely to result.
 

apps/hashdotai/glossary/attributes.mdx

@@ -0,0 +1,12 @@
+---
+title: Attributes
+description: "Attributes are the properties and links that exist on and describe an entity."
+slug: attributes
+tags: ["Data Science", "Graphs"]
+---
+
+Attributes describe [entities](/glossary/entities) and are either [properties](/glossary/properties) or [links](/glossary/links).
+
+The attributes that exist on an entity are determined by an [entity's type](/glossary/entity-types), which in turn defines what kinds of properties and links can be associated with it (through [property types](/glossary/property-types) and [link types](/glossary/link-types)).
+
+A single entity can be of more than one entity type. For example, a `Person` entity might also be an `Employee`, allowing specific employment-related information to be stored in conjunction with a person's record in HASH.

apps/hashdotai/glossary/block-protocol.mdx

@@ -13,43 +13,47 @@ tags: ["Software Engineering", "Standards"]
 
 The Block Protocol is an open standard which standardizes the means by which [blocks](/glossary/blocks) and applications are able to communicate, so that any block can be embedded in any application, without either one possessing any special knowledge about the other.
 
-The Block Protocol consists of a **Core** specification, and various optional **modules**, each with their own additional specifications. You can learn about these in full by reading the Block Protocol documentation and specification at blockprotocol.org/docs.
+The Block Protocol consists of a **Core** specification, and various optional **modules**, each with their own additional specifications. You can learn about these in full by reading the [Block Protocol documentation](https://blockprotocol.org/docs) and [Block Protocol specification](https://blockprotocol.org/spec).
 
-Blocks built in accordance with the Block Protocol are also made available on the Block Protocol Hub, located at blockprotocol.org/hub
+Blocks built in accordance with the Block Protocol are also made available on the [Block Protocol Hub](https://blockprotocol.org/hub).
 
 A high-level summary of the Block Protocol is provided below.
 
 ## Target Audience
 
-The Block Protocol is written for two audiences:
+The Block Protocol was designed to be understood by two different audiences:
 
 1. Potential block developers who wish to build interoperable, cross-application blocks
 1. Potential embedding application developers who wish to build block-based ‘embedding applications’ that leverage the Block Protocol.
 
+While end-users of block-embedding applications may interface with Block Protocol blocks, they are not required or expected to understand its technical implementation or even be aware of its existence.
+
 ## Architectural Overview
 
 ### Block Protocol Core
 
-The Block Protocol Core outlines what constitutes a bare minimum block publishable to the Block Protocol Hub. Namely, a publishable block combines:
+The [Block Protocol _Core_](https://blockprotocol.org/spec/core) specification outlines what constitutes a block publishable to the Block Protocol Hub. At minimum, a publishable block combines:
 
 - some source code; and
 - a block metadata file (which can be used to identify a block by potential embedding applications).
 
 The combination of these two things is called a **block package**, and it is these that can be submitted for listing on the Block Protocol Hub, for download and use by others as **blocks**.
 
-The Block Protocol Core also defines how modules can be specified.
-
 ### Block Protocol Modules
 
-The Block Protocol Core specifies how a block is defined, and how they communicate with embedding applications. Modules define what blocks and applications can communicate.
+While the Block Protocol Core specifies how a block is defined, and how it communicates with an embedding application, modules define what kinds of things blocks and applications can communicate about.
 
 Modules provide logical groups of functionality or aim to solve a specific problem related to block-application interaction. Modules are defined in their own specifications that live separate to, but alongside, the Block Protocol Core.
 
 Most blocks will want to use one or more modules defined as part of the Block Protocol specification.
 
-For example, the **Graph** module defines the protocol by which blocks can create, read, update or delete **entities** -- as well as any **links** between those entities -- within an embedding application’s datastore.
+For example:
+
+- the [Graph](https://blockprotocol.org/spec/graph) module defines the protocol by which blocks can create, read, update or delete **entities** -- as well as any **links** between those entities -- within an embedding application’s datastore;
+- the [Hook](https://blockprotocol.org/spec/hook) module defines a protocol via which embedding applications can take over specific parts of a block to insert a native application experience, if one exists (e.g. a file picker, or photo gallery);
+- the [Service](https://blockprotocol.org/spec/service) module provides a standardized capability for blocks to interact with external APIs, without needing to ship with their own API keys or prompt users to insert their own.
 
-There are many different types of modules under discussion for inclusion in the Block Protocol, which are described alongside the specification.
+There are many different types of modules under discussion for inclusion in the Block Protocol, which are described [alongside the specification](https://blockprotocol.org/roadmap#new-modules).
 
 In their metadata, blocks can declare which modules (and which version of those modules) they support.
 

apps/hashdotai/glossary/blocks.mdx

@@ -24,3 +24,7 @@ A single individual block can be referred to as an ‘instance of a block’, or
 ## The Block Protocol
 
 The [Block Protocol](/glossary/block-protocol) is an open standard for developing blocks, and block-based applications. It defines the methods by which blocks may communicate and interact with the applications that embed them (“embedding applications”).
+
+## Using blocks
+
+Blocks are most prominently used within HASH in [pages](/guide/pages). You can learn more about [using blocks within pages](/guide/pages/blocks) in the HASH user guide.

apps/hashdotai/glossary/digital-twin.mdx

@@ -7,9 +7,9 @@ tags: ["Business Intelligence", "Simulation Modeling"]
 
 The term digital twin (sometimes used interchangeably with "synthetic environment") refers to an in-silico, computer simulated analogue to a real-world system. It is often used to describe computer simulations that mirror real-world biological systems, engineering projects (like jet engines, wind turbines, or vehicles), and architectural spaces, as well as individual factories and warehouses within larger supply chains.
 
-These "digital twins" (computer simulations) mirroring real-world counterparts can be placed in different virtual environments. This allows them to be inexpensively and safely examined under a wide range of conditions, often exceeding the number and range of environments affordable or practical to test in the physical, offline world.
+These "digital twins" (individual [entities](/glossary/entities) or entire [simulation models](/glossary/simulations)) mirroring real-world counterparts can be placed in different virtual environments, and have their parameters modified, to allow them to be inexpensively and safely examined under a wide range of conditions, often exceeding the number and range of environments affordable or practical to test in the physical, offline world.
 
-These simulations can also be used to generate [synthetic data](/glossary/synthetic-data-generation), perform low-cost tradespace analyses by modifying the digital system, and generate risk assessments by introducing simulated stochastic failures, among other things.
+These simulations can also be used to generate [synthetic data](/glossary/synthetic-data-generation), perform low-cost tradespace analyses, and generate risk assessments (e.g. by introducing simulated stochastic failures).
 
 All of these things can be fed back into the design of real-world systems, allowing them to be tested and improved online, before being built "in the real world" offline.
 

apps/hashdotai/glossary/graphs.mdx

@@ -9,15 +9,15 @@ tags: ["Graphs", "Machine Learning", "Software Engineering"]
 
 ### In HASH
 
-In the context of HASH, a graph is a collection of entities which may be connected to other entities by [links](/glossary/links).
+In the context of HASH, a graph is a collection of [entities](/glossary/entities) which may be connected to other entities by [links](/glossary/links).
 
-The data in a single HASH workspace can be thought of as a graph, some of which may be kept private, and parts of which may be public.
+The data and [types](/glossary/types) in a single HASH workspace are known as a [web](/guide/webs), and these can be thought of as a graph in which some information might be kept private, while other parts may be shared publicly.
 
-The totality of all public data in HASH may also be thought of as a graph, as many individual workspaces are connected through [linked entities](/glossary/entities#Linked-entities) and shared [types](/glossary/types).
+The totality of all public data in HASH, sometimes called the "[HASH public web](https://hash.ai/guide/webs#hash-public-web)", may also be thought of as a graph, as many individual workspaces are connected to each other through [linked entities](/glossary/entities#Linked-entities) and shared types.
 
 ### In the Block Protocol
 
-The [Block Protocol](/glossary/block-protocol) module which deals with entities and the links between them is known as the _Graph Module_.
+The [Block Protocol](/glossary/block-protocol) module which deals with entities and the links between them is known as the _Graph_ module.
 
 ### In mathematics and computer science
 

apps/hashdotai/glossary/properties.mdx

@@ -5,10 +5,12 @@ slug: properties
 tags: ["Data Science", "Graphs"]
 ---
 
-Properties store individual pieces of information about [entities](/glossary/entities) as [values](/glossary/values). All properties on an entity are inferred from its [entity type(s)](/glossary/entity-types).
+Properties store individual pieces of information about [entities](/glossary/entities) as [values](/glossary/values). All properties on an entity are inferred from that [entity's type(s)](/glossary/entity-types).
 
 Property values (the contents of a property field) can either be **required** or **optional**. In either case, marking a property as required or not will be specified on the thing _using the property_ (e.g. the entity type which requires the property) rather than on the property itself.
 
+Properties are one of two kinds of [attributes](/glossary/attributes) (things which describe entities), with the other being [links](/glossary/links).
+
 ## Property types
 
 A **property type** is how a property is defined. It can be used by one or more entity types, or _other_ property types. A property type: