First draft of completed lesson

_episodes/01-COperson.md

@@ -12,9 +12,9 @@ keypoints:
 
 # 1. The CO Person
 
-People are represented in COmanage by a :gear: `CO Person` object. Some information is stored in this object, and it is connected to several other types of useful objects.
+People are represented in COmanage by a `CO Person` :gear: object. Some information is stored in this object, and it is connected to several other types of useful objects.
 
-The information stored in the :gear: `CO Person` object typically includes
+The attributes (information) stored in the `CO Person` :gear: object typically includes
 
 * The organization or collaboration of which the person is a part (in the form of an identifier)
 * The person's status within that organization or collaboration
@@ -26,7 +26,7 @@ The information stored in the :gear: `CO Person` object typically includes
 
 This object also is connected to several other structural items that we will talk about in this lesson, including
 
-*  **External Representations** - representations of the person in other contexts outside of COmanage (including real life!) These representations include attributes and information about the person related to the other context. Each :gear: `CO Person` must have at least one of these, though multiple are allowed.
+*  **External Representations** - representations of the person in other contexts outside of COmanage (including real life!) These representations include attributes and information about the person related to the other context. Each `CO Person` :gear: must have at least one of these, though multiple are allowed.
 * **Roles** - the roles that the person assumes within your organization.
 * **Group Memberships** - membership in a specific COmanage organizational object called a :gear" `CO Group`. We will learn more about :gear" `CO Groups` in a later lesson.
 * **Authenticators** - methods for the person to sign into COmanage
@@ -35,7 +35,7 @@ This object also is connected to several other structural items that we will tal
 
 # CO Person status
 
-Each :gear: `CO Person` object has a status attached to it. This status is a calculated value based on the person's status in each of the Roles that the person has assumed in your organization or collaboration. We will review the calculation method when we talk about Roles. Status can be changed manually, or can change automatically based on conditions that you may set, or by workflows that you put in place.
+Each `CO Person` :gear: object has a status attached to it. This status is a calculated value based on the person's status in each of the Roles that the person has assumed in your organization or collaboration. We will review the calculation method when we talk about Roles. Status can be changed manually, or can change automatically based on conditions that you may set, or by workflows that you put in place.
 
 The status value will affect what someone is able to do, including affecting what information is shared with external systems for access and resource provisioning. We will review how status affects provisioning when we talk about provisioning in a later lesson.
 
@@ -58,30 +58,30 @@ Preference | Status | Description
 13 | Deleted | 
 14 | Duplicate | The record is a duplicate of another 
 
-# About names
+# About name attributes
 
-Each :gear: `CO Person` object must include the person's name. :gear: `CO Person` objects can have more than one name, but exactly one of the names must be designated as the _primary name_. Names can be encoded in any one of several languages / character sets.
+Each `CO Person` :gear: object must include the person's name. `CO Person` :gear: objects can have more than one name, but exactly one of the names must be designated as the _primary name_. Names can be encoded in any one of several languages / character sets.
 
-# About identifiers
+# About identifier attributes
 
 _< NOTE: Laura wrote this section, but isn't sure about her understanding of identifiers for CO Person. From the documentation it sounds like the recommendation is to have one CO Person identifier that is auto assigned, and for this identifier to be used for provisioning to at least some kinds of services rather than tying that provisioning to an org identity (like eppn) that may change if affiliation does. BUT... this may be totally wrong. >_
 
-Identifiers allow for unique identification. In COmanage, each :gear: `CO Person` may be associated with [an?] identifier[s?]. [These identifiers | The identifier] can be important when provisioning services to :gear: `CO Persons`.
+Identifiers allow for unique identification. In COmanage, each `CO Person` :gear: may be associated with [an?] identifier[s?]. [These identifiers | The identifier] can be important when provisioning services to `CO Persons` :gear:.
 
-We recommend that you configure at least one identifier for each :gear: `CO Person` to represent the person within COmanage. While it is possible to manually assign identifiers, we suggest that you allow COmanage to automatically assign these identifiers. You are able to configure what these identifiers will look like.
+We recommend that you configure at least one identifier for each `CO Person` :gear: to represent the person within COmanage. While it is possible to manually assign identifiers, we suggest that you allow COmanage to automatically assign these identifiers. You are able to configure what these identifiers will look like.
 
-# About email addresses
+# About email address attributes
 
 COmanage can track email addresses, though it does very little with them directly. Email addresses can be verified from within COmanage (which we will not review during this workshop). Email addresses can also be used for mailing lists using the mailman provisioner (which we will review, time allowing.)
 
-When storing email addresses, more than one can be associated with the :gear: `CO Person`, and can contain a type to help distinguish the conditions under which to use each. For example,
+When storing email addresses, more than one can be associated with the `CO Person` :gear:, and can contain a type to help distinguish the conditions under which to use each. For example,
 
 * **official** - the address to render in a directory entry, especially for use in a "To:" or "Cc:" field. _LDAP attribute: mail_
 * **personal** - Alternate addresses to accept for mail delivery or forwarding. _LDAP attribute: mailAlternateAddress_
 * **delivery** -  the delivery location (e.g., mailbox). _LDAP attribute: mailForwardingAddress_
 * **forwarding** - Address to forward mail to, perhaps if there is no delivery address, or an official or personal address is not functioning. _LDAP attribute: mailForwardingAddress_
 
-# About physical addresses
+# About physical address attributes
 
 This information is not used by COmanage, but since it is handy to have physical address information in your registry, it is included. Any number of physical addresses may be associated with a :gear" `CO Person` object.
 
@@ -91,7 +91,7 @@ This information is not used by COmanage, but since it is handy to have physical
 
 ![Interactive system activity](../assets/img/hands-on-keyboard.png)
 
-As we build our understanding of how people are modeled in COmanage, we will use people in your organization as examples. In your printed packet, there are sheets for [ :memo: Modeling People](/files/handouts/CO310_ExamplePerson.pdf).
+As we build our understanding of how people are modeled in COmanage, we will use people in your organization as examples. In your printed packet, there are sheets for [ Modeling People :memo:](/files/handouts/CO310-ModelingPeople.pdf).
 
 Think of at least three people in your organization that you can use as examples. The three that you choose should assume different roles in your organization or collaboration. Maybe they have different levels of authority, have access to different kinds of systems or services, form and manage their own groups. One of the people you choose may even work for a different organization, though collaborates with individuals in your organization.
 
@@ -107,14 +107,14 @@ Once you have thought about who you will use as your examples, write their names
 
 OBJECT | DESCRIPTION
 ------ | -----------
-:gear: `CO Person` | the representation of a person in COmanage
-:gear: `CO Group` | a specific COmanage organizational structure for representing certain collections of :gear: `CO Persons`
+`CO Person` :gear: | the representation of a person in COmanage
+`CO Group` :gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons` :gear:
 
 ## Worksheets
 
 WORKSHEET | DESCRIPTION
 --------- | -----------
-[ :memo: Modeling People](/files/handouts/CO310_ExamplePerson.pdf) | Planning sheet used in this lesson for understanding how to model people in COmanage. This sheet is used to organize how specific people and their relationships would be expressed within COmanage
+[ Modeling People :memo:](/files/handouts/CO310-ModelingPeople.pdf) | Planning sheet used in this lesson for understanding how to model people in COmanage. This sheet is used to organize how specific people and their relationships would be expressed within COmanage
 
 ## Slides