diff --git a/src/Plugin/VersionNegotiation/VersionByRel.php b/src/Plugin/VersionNegotiation/VersionByRel.php
index 12dc1ad..61a76c3 100644
--- a/src/Plugin/VersionNegotiation/VersionByRel.php
+++ b/src/Plugin/VersionNegotiation/VersionByRel.php
@@ -112,24 +112,26 @@ class VersionByRel extends PluginNegotiationBase implements ContainerFactoryPlug
    * Resolves a revision ID given a relative version argument.
    *
    * The `predecessor-version`, `working-copy-of`, `prior-working-copy` and
-   * `subsequent-working-copy` version arguments are not very useful unless the
+   * `subsequent-working-copy` version specifiers are not very useful unless the
    * requester can specify a relative version. If not, then these can only be
-   * resolved for the current default revision.
+   * resolved relative to the latest version.
    *
    * For example, assume that a client would like to view the most recent
-   * changes. To do so, the latest revision must be compared with the preceding
-   * revision. The site has Content Moderation enabled and the latest revision
-   * is not the default revision.
+   * changes to an entity. To do so, the latest revision must be compared with
+   * the preceding revision. The site has Content Moderation enabled and the
+   * latest revision is not the default revision.
    *
    * Remember, under RFC5829, the latest revision is known as the
    * "working copy". Thus, the client needs to request the working copy using a
    * `?resource_version=working-copy` query string to fetch the latest revision.
    *
-   * Now, the client must request the second-to-last revision. How? One might
-   * guess `?resource_version=prior-working-copy`, but this would be ambiguous.
-   * Does the requester want the revision prior to the default revision or the
-   * latest revision? What if there are many revisions after the default
-   * revision?
+   * Now, the client must request the second-to-last revision. How?
+   *
+   * One might guess `?resource_version=prior-working-copy`, but this would be
+   * ambiguous. Does the requester want the revision prior to the default
+   * revision or the latest revision? One would assume the latest revision since
+   * that is the working copy, but what if there are many revisions after the
+   * default revision? How would the client show a history of changes?
    *
    * The requester must be able to indicate the relative version. This is
    * accomplished by concatenating a relative version specifier with a fixed