Add relative links and collect links to one loaction

Author: Charini Nanayakkara

content/blog/entries/smithsonian-unit-code-update/contents.lr

@@ -15,23 +15,27 @@ pub_date: 2020-08-03
 body:
 ## Introduction
 The Creative Commons (CC) Catalog project collects and stores CC licensed images scattered across the internet, such
-that they can be made accessible to the general public via the [CC Search](https://ccsearch.creativecommons.org/)
-and [CC Catalog API](https://api.creativecommons.engineering/v1/) tools. Numerous information associated with each
-image, which help in the image search and categorisation process are  stored via CC Catalog in the CC database.
+that they can be made accessible to the general public via the [CC Search][cc_search] and [CC Catalog API][cc_api]
+tools. Numerous information associated with each image, which help in the image search and categorisation process are
+stored via CC Catalog in the CC database.
 
-In my [previous blog post](https://opensource.creativecommons.org/blog/entries/flickr-sub-provider-retrieval/)
-of this series entitled 'Flickr Sub-provider Retrieval', I discussed how the images from a
-certain provider (such as Flickr) can be categorised based on the sub-provider values (which reflects the underlying
-organisation or entity that published the images through the provider). We have similarly implemented the sub-provider
-retrieval logic for Europeana and Smithsonian providers. Unlike in Flickr and Europeana, every single image from
-Smithsonian is categorised under some sub-provider value where the sub-providers are identified based on a unit code
-value as contained in the API response (for more information please refer to the pull request
-https://github.com/creativecommons/cccatalog/pull/455). The unit code values and the corresponding sub provider values
-are maintained in the dictionary *SMITHSONIAN_SUB_PROVIDERS*. However, there is the possibility of the *unit code*
-values being updated at the Smithsonian API level, and it is important that we have a mechanism of reflecting those
-updates in the *SMITHSONIAN_SUB_PROVIDERS* dictionary as well. In this blog post, we discuss how we learn the potential
+In my [previous blog post][flickr_blog_post] of this series entitled 'Flickr Sub-provider Retrieval', I discussed how
+the images from a certain provider (such as Flickr) can be categorised based on the sub-provider values (which reflects
+the underlying organisation or entity that published the images through the provider). We have similarly implemented
+the sub-provider retrieval logic for Europeana and Smithsonian providers. Unlike in Flickr and Europeana, every single
+image from Smithsonian is categorised under some sub-provider value where the sub-providers are identified based on a
+unit code value as contained in the API response (for more information please refer to the pull request [#455][pr_455]).
+The unit code values and the corresponding sub provider values are maintained in the dictionary
+*SMITHSONIAN_SUB_PROVIDERS*. However, there is the possibility of the *unit code* values being updated at the
+Smithsonian API level, and it is important that we have a mechanism of reflecting those updates in the
+*SMITHSONIAN_SUB_PROVIDERS* dictionary as well. In this blog post, we discuss how we learn the potential
 changes to the *unit code* values and keep the *SMITHSONIAN_SUB_PROVIDERS* dictionary up-to-date.
 
+[cc_search]: https://ccsearch.creativecommons.org/
+[cc_api]: https://api.creativecommons.engineering/v1/
+[flickr_blog_post]: ../flickr-sub-provider-retrieval/
+[pr_455]: https://github.com/creativecommons/cccatalog/pull/455
+
 ## Implementation
 ### Retrieving the latest unit codes
 We are required to obtain the latest *unit codes* supported by the Smithsonian API to achieve this task. Furthermore,