Update references to "UUIDs" in index.bs (#4)

index.bs

@@ -14,7 +14,7 @@ Introduction {#intro}
 
 DID-Linked Resources are digital files that can be retrieved and referenced using a persistent and unique DID URL. 
 
-This specification defines common requirements, algorithms including their request formats and response formats, architectural options, and various considerations for how DID-Linked Resources SHOULD act as persistent identifiers for referencing and retrieving digital Resources (such as data schemas, status lists, trust registries, governance documents, or policy definitions). This specification complements the <a href="https://w3c-ccg.github.io/did-resolution/">DID Resolution Specification</a>, including its patterns and algorithms for DID URL resolution and dereferencing. 
+This specification defines common requirements, patterns, algorithms including their request formats and response formats, architectural options, and various considerations for how DID-Linked Resources SHOULD act as persistent identifiers for referencing and retrieving digital Resources (such as data schemas, status lists, trust registries, governance documents, or policy definitions). This specification complements the <a href="https://w3c-ccg.github.io/did-resolution/">DID Resolution Specification</a>, including its patterns and algorithms for DID URL resolution and dereferencing. 
 
 By using DID URLs which remain conformant with W3C Decentralized Identifiers (DIDs) v1.0 Recommendation [[DID-CORE]] and the <a href="https://w3c-ccg.github.io/did-resolution/">DID Resolution Specification</a>, existing DID Resolvers will be able to dereference these DID URLs to retrieve the identified resources using the DID URL query syntax in this specification.
 
@@ -82,14 +82,14 @@ Using traditional web endpoints to store digital resources that are critical for
 DID-Linked Resources construction {#contruction}
 ---------------------
 
-"Resources" SHOULD be identifiable using a Decentralized Identifier (DID) and a Universally Unique Identifier (UUID) that acts as a permanently-accessible identifier to fetch the Resource from a Verifiable Data Registry or other storage endpoint. We refer to this UUID as the "Resource ID".
+"Resources" SHOULD be identifiable using a Decentralized Identifier (DID) and a permanently-accessible unique identifier to fetch the Resource from a Verifiable Data Registry or other storage endpoint. We refer to this identifier as the "Resource ID".
 
-Using UUIDs ensures a high level of confidence that no two identical Resource IDs will ever be created. This is important for ensuring the integrity and unambiguity of each individual DID-Linked Resource.
+Using unique identifiers increases confidence that no two identical Resource IDs will ever be created. This is important for ensuring the integrity and unambiguity of each individual DID-Linked Resource. Throughout this specification, we will therefore use UUIDs for the Resource IDs in examples, although different method implementations may specify other Resource ID formats.
 
 The following path-based syntax is an example of how a DID Method may construct a DID URL to point to a DID-Linked Resource:
 
  ```json
-did:example:<unique-identifier>/resources/<universally-unique-identifier>
+did:example:<unique-identifier>/resources/<unique-identifier>
 ```
 
 <div class="note"> <b>Note:</b> The above path-based syntax would be an implementation-specific way of referencing a resource. </div>
@@ -123,7 +123,7 @@ To create a "DID-Linked Resource", you MUST first create a "parent" DID, from wh
 
 Next, to create a digital Resource associated with the "parent" DID, you MUST provide the following Request inputs:
 
-1. `resourceId`: Generate a new, unique UUID for the Resource
+1. `resourceId`: Generate a new, unique identifier for the Resource
 2. `collectionId`: Specify the Collection ID as the same unique identifier of the parent DID
 3. `resourceName`: Provide a name for the Resource of your choice
 4. `resourceType`: Specify the type of Resource and make reference to the DID Spec Registries to utilise consistent and registered Resource Types. 
@@ -393,7 +393,7 @@ Composition of Resource Preview {#preview}
 Resource previews will appear within DID document metadata. These do not include the actual core data of the resource and only reference the metadata:
 
 * Resource Collection ID: (`did:example:...:`) (supplied client-side)\*\*
-* Resource ID: UUID ➝ specific to resource, also effectively a version number (supplied client-side)
+* Resource ID: identifier ➝ specific to resource, also effectively a version number (supplied client-side)
 * Resource Name: String (e.g., `JSONSchema2020` (supplied client-side))
 * Resource Type (supplied client-side)
 * Resource Version (supplied client-side)