fix links, little formatting (#82)

book/src/move-basics/drop-ability.md

@@ -38,8 +38,6 @@ Links:
 
  -->
 
-## Drop ability
-
 The `drop` ability - the simplest of them - allows the instance of a struct to be _ignored_ or
 _discarded_. In many programming languages this behavior is considered default. However, in Move, a
 struct without the `drop` ability is not allowed to be ignored. This is a safety feature of the Move

book/src/programmability/capability.md

@@ -8,7 +8,7 @@ owner to perform administrative operations, which regular users cannot.
 
 ## Capability is an Object
 
-In the [Sui Object Model](./../concepts/object-model.md), capabilities are represented as objects.
+In the [Sui Object Model](./../object/), capabilities are represented as objects.
 An owner of an object can pass this object to a function to prove that they have the right to
 perform a specific action. Due to strict typing, the function taking a capability as an argument can
 only be called with the correct capability.

book/src/programmability/dynamic-fields.md

@@ -121,7 +121,7 @@ As you can see, custom types do work as field names but as long as they can be _
 module, in other words - if they are _internal_ to the module and defined in it. This limitation on
 struct packing can open up new ways in the design of the application.
 
-This approach is used in the [Object Capability]() pattern, where an application can authorize a
+This approach is used in the [Object Capability](./object-capability.md) pattern, where an application can authorize a
 foreign object to perform operations in it while not exposing the capabilities to other modules.
 
 ## Exposing UID

book/src/programmability/object-capability.md

@@ -0,0 +1,3 @@
+# Object Capability
+
+<!-- TBD -->

book/src/storage/key-ability.md

@@ -1,7 +1,7 @@
 # The Key Ability
 
 In the [Basic Syntax](./../move-basics) chapter we already covered two out of four abilities -
-[Drop](./drop-ability.md) and [Copy](./copy-ability.md). They affect the behaviour of the value in a
+[Drop](./../move-basics/drop-ability.md) and [Copy](./../move-basics/copy-ability.md). They affect the behaviour of the value in a
 scope and are not directly related to storage. It is time to cover the `key` ability, which allows
 the struct to be stored.
 

book/src/storage/storage-functions.md

@@ -138,9 +138,9 @@ A quick recap:
 
 ## Freeze
 
-The `transfer::freeze_object` function is public function used to put an object into an _immutable_ state.
-Once an object is _frozen_, it can never be changed, and it can be accessed by anyone by immutable
-reference.
+The `transfer::freeze_object` function is public function used to put an object into an _immutable_
+state. Once an object is _frozen_, it can never be changed, and it can be accessed by anyone by
+immutable reference.
 
 The function signature is as follows, only accepts a type with the
 [`key` ability](./key-ability.md). Just like all other storage functions, it takes the object _by
@@ -216,8 +216,8 @@ To summarize:
 
 ## Owned -> Frozen
 
-Since the `transfer::freeze_object` signature accepts any type with the `key` ability, it can take an
-object that was created in the same scope, but it can also take an object that was owned by an
+Since the `transfer::freeze_object` signature accepts any type with the `key` ability, it can take
+an object that was created in the same scope, but it can also take an object that was owned by an
 account. This means that the `freeze_object` function can be used to _freeze_ an object that was
 _transferred_ to the sender. For security concerns, we would not want to freeze the `AdminCap`
 object - it would be a security risk to allow access to it to anyone. However, we can freeze the
@@ -234,9 +234,9 @@ public fun freeze_gift(gift: Gift) {
 
 ## Share
 
-The `transfer::share_object` function is a public function used to put an object into a _shared_ state.
-Once an object is _shared_, it can be accessed by anyone by a mutable reference (hence, immutable
-too). The function signature is as follows, only accepts a type with the
+The `transfer::share_object` function is a public function used to put an object into a _shared_
+state. Once an object is _shared_, it can be accessed by anyone by a mutable reference (hence,
+immutable too). The function signature is as follows, only accepts a type with the
 [`key` ability](./key-ability.md):
 
 ```move

book/src/storage/store-ability.md

@@ -10,7 +10,7 @@ required for the type to be used as a field in a struct that has the `key` abili
 put it is that the `store` ability allows the value to be _wrapped_ in an object.
 
 > The `store` ability also relaxes restrictions on transfer operations. We talk about it more in the
-> [Restricted and Public Transfer](./restricted-and-public-transfer.md) section.
+> [Restricted and Public Transfer](./transfer-restrictions.md) section.
 
 ## Example
 

book/src/storage/uid-and-id.md

@@ -70,9 +70,9 @@ The ability to return the UID of an object may be utilized in pattern called _pr
 is a rarely used technique, but it may be useful in some cases, for example, the creator or an
 application may incentivize the deletion of an object by exchanging the deleted IDs for some reward.
 
-In framework development this method could be used to ignore / bypass certain restrictions on "taking"
-the object. If there's a container that enforces certain logic on transfers, like Kiosk does, there
-could be a special scenario of skipping the checks by providing a proof of deletion.
+In framework development this method could be used to ignore / bypass certain restrictions on
+"taking" the object. If there's a container that enforces certain logic on transfers, like Kiosk
+does, there could be a special scenario of skipping the checks by providing a proof of deletion.
 
 This is one of the open topics for exploration and research, and it may be used in various ways.
 
@@ -82,8 +82,9 @@ When talking about `UID` we should also mention the `ID` type. It is a wrapper a
 type, and is used to represent an address-pointer. Usually, `ID` is used to point at an object,
 however, there's no restriction, and no guarantee that the `ID` points to an existing object.
 
-> ID can be received as a transaction argument in a [Transaction Block](). Alternatively, ID can be
-> created from an `address` value using `to_id()` function.
+> ID can be received as a transaction argument in a
+> [Transaction Block](./../concepts/what-is-a-transaction.md). Alternatively, ID can be created from
+> an `address` value using `to_id()` function.
 
 <!--
 ```move