Fix old github URLs for CI

Author: hadro

scripts/check_jsonld.py

@@ -80,7 +80,7 @@ def read_js(filepath):
 dirs.remove('18')
 
 # Remove 24,25,29,31,36 as embedded @contexts will disappear
-# This would be fixed in 3.0 by https://github.com/IIIF/iiif.io/issues/1121
+# This would be fixed in 3.0 by https://github.com/IIIF/api/issues/1121
 dirs.remove('24')
 dirs.remove('25')
 dirs.remove('29')

source/image/2.1/change-log-211.md

@@ -21,27 +21,27 @@ For the significant changes between 2.0 and 2.1, please see the [2.1 Change Log]
 ### 1.1. Clarify availability of `width` and `height`
 
 The `width` and `height` properties do not necessarily imply that an image of that size is available. Other constraints may be declared that limit the maximum size that can be requested. The `width` and `height` are still required to construct tile requests and to know the aspect ratio of the image.
-See issue [#477](https://github.com/IIIF/iiif.io/issues/477)
+See issue [#477](https://github.com/IIIF/api/issues/477)
 
 ### 1.2. Clarify the canonical form of `max`
 
 The size keyword `max` will replace `full` in version 3.0 of the Image API, at which time it can be used in the canonical form of requests. Until then, the canonical form of requests equivalent to `max` must continue to use the `w,` syntax, or the `full` syntax if they are equivalent.
-See issue [#883](https://github.com/IIIF/iiif.io/issues/883)
+See issue [#883](https://github.com/IIIF/api/issues/883)
 
 ### 1.3. Typo in `@context` for Complete Response example
 
 The URI for the `@context` of the physical dimensions service used in the example Complete Response was incorrect and has been fixed.
-See issue [#935](https://github.com/IIIF/iiif.io/issues/935)
+See issue [#935](https://github.com/IIIF/api/issues/935)
 
 ### 1.4 Update `@context` for GeoJSON example
 
 The URI of the `@context` for GeoJSON services has changed and the example use from the Image API has been updated.
-See issue [#1001](https://github.com/IIIF/iiif.io/issues/1001)
+See issue [#1001](https://github.com/IIIF/api/issues/1001)
 
 ### 1.5 Use better URIs for example rights/licenses
 
 The URIs were not helpful in giving realistic examples. The examples were updated to use Creative Commons and Rights Statements URIs to promote the use of shared agreements.
-See issue [#1094](https://github.com/IIIF/iiif.io/issues/1094)
+See issue [#1094](https://github.com/IIIF/api/issues/1094)
 
 ## 2. Changes to Non-Semantically-Versioned Documents
 
@@ -52,7 +52,7 @@ These changes were scheduled to coincide with the release of 2.1.1 to benefit fr
 #### 2.1.1 Change in location of `@context` for GeoJSON example
 
 The URI of the `@context` to be used for GeoJSON services has changed and the [Services Annex Document][service-profiles] has been updated.
-See issue [#1001](https://github.com/IIIF/iiif.io/issues/1001)
+See issue [#1001](https://github.com/IIIF/api/issues/1001)
 
 [image-api]: {{ site.api_url | absolute_url }}/image/2.1/ "Image API 2.1"
 [changelog-21]: {{ site.api_url | absolute_url }}/image/2.1/change-log.html "Image API 2.1 Change Log"

source/image/2.1/change-log.md

@@ -21,52 +21,52 @@ This document is a companion to the [IIIF Image API Specification, Version 2.1][
 ### 1.1. Added `square` Region
 {: #added-square-region}
 
-The `square` [region keyword][region] selects a region where the width and height are both equal to the length of the shorter dimension of the complete image. The region may be positioned anywhere in the longer dimension of the image content at the server’s discretion, and centered is often a reasonable default. The corresponding feature name `regionSquare` has also been added to the [profile description][profile-description]. It is an open question whether support for `square` will become mandatory at levels 1 and 2 in the next major version of the Image API. See [issue 425](https://github.com/IIIF/iiif.io/issues/425), [issue 560](https://github.com/IIIF/iiif.io/issues/560), and [issue 501](https://github.com/IIIF/iiif.io/issues/501).
+The `square` [region keyword][region] selects a region where the width and height are both equal to the length of the shorter dimension of the complete image. The region may be positioned anywhere in the longer dimension of the image content at the server’s discretion, and centered is often a reasonable default. The corresponding feature name `regionSquare` has also been added to the [profile description][profile-description]. It is an open question whether support for `square` will become mandatory at levels 1 and 2 in the next major version of the Image API. See [issue 425](https://github.com/IIIF/api/issues/425), [issue 560](https://github.com/IIIF/api/issues/560), and [issue 501](https://github.com/IIIF/api/issues/501).
 
 ### 1.2. Added Rights and Licensing Properties
 
-[Rights and Licensing Properties][rights] `attribution`, `license` and `logo` properties have been added to the Image Information. They have the same semantics and requirements as the properties of the same names in the Presentation API. See [issue 227](https://github.com/IIIF/iiif.io/issues/227) and note also deferred change of the JSON-LD tag name from `license` to `rights`.
+[Rights and Licensing Properties][rights] `attribution`, `license` and `logo` properties have been added to the Image Information. They have the same semantics and requirements as the properties of the same names in the Presentation API. See [issue 227](https://github.com/IIIF/api/issues/227) and note also deferred change of the JSON-LD tag name from `license` to `rights`.
 
 ### 1.3. Removed Recommendation to include HTTP Link Header to JSON-LD Context
 
-Version 2.0 incorrectly recommended the inclusion of a HTTP link header for the JSON-LD context, which was unnecessary as the `@context` key in the JSON document would override it. Therefore, the description of the [Image Information Request][image-information-request] no longer includes this. See [issue 556](https://github.com/IIIF/iiif.io/issues/556).
+Version 2.0 incorrectly recommended the inclusion of a HTTP link header for the JSON-LD context, which was unnecessary as the `@context` key in the JSON document would override it. Therefore, the description of the [Image Information Request][image-information-request] no longer includes this. See [issue 556](https://github.com/IIIF/api/issues/556).
 
 ### 1.4. Added `sizeByConfinedWh` and `sizeByDistortedWh` Feature Names
 {: #added-sizebyconfinedwh-and-sizebydistortedwh-feature-names}
 
-New feature names `sizeByConfinedWh` and `sizeByDistortedWh` in the [profile description][profile-description] provide clear indications of support for `!w,h` and distorting `w,h` size requests respectively. As a result the related feature names `sizeByWhListed` and `sizeByForcedWh` have been [deprecated][deprecated-sizebywhlisted-and-sizebyforcedwh]. See [issue 720](https://github.com/IIIF/iiif.io/issues/720) and additional discussion on [pull pequest 727](https://github.com/IIIF/iiif.io/pull/727).
+New feature names `sizeByConfinedWh` and `sizeByDistortedWh` in the [profile description][profile-description] provide clear indications of support for `!w,h` and distorting `w,h` size requests respectively. As a result the related feature names `sizeByWhListed` and `sizeByForcedWh` have been [deprecated][deprecated-sizebywhlisted-and-sizebyforcedwh]. See [issue 720](https://github.com/IIIF/api/issues/720) and additional discussion on [pull pequest 727](https://github.com/IIIF/iiif.io/pull/727).
 
 ### 1.5. Added `maxWidth`, `maxHeight` and `maxArea` Properties
 
-The `maxWidth`, `maxHeight` and `maxArea` properties in the [profile description][profile-description] provide a way for image servers to express the limits on its supported sizes for image requests. See [issue 620](https://github.com/IIIF/iiif.io/issues/620).
+The `maxWidth`, `maxHeight` and `maxArea` properties in the [profile description][profile-description] provide a way for image servers to express the limits on its supported sizes for image requests. See [issue 620](https://github.com/IIIF/api/issues/620).
 
 ### 1.6. Added `max` Size Keyword
 
-The [size keyword][size] `max` may be used to request that the image or region is returned at the maximum size available, as indicated by `maxWidth`, `maxHeight` and `maxArea` properties. See [issue 663](https://github.com/IIIF/iiif.io/issues/663) and the related [deprecation of the size keyword `full`][deprecated-size-full].
+The [size keyword][size] `max` may be used to request that the image or region is returned at the maximum size available, as indicated by `maxWidth`, `maxHeight` and `maxArea` properties. See [issue 663](https://github.com/IIIF/api/issues/663) and the related [deprecation of the size keyword `full`][deprecated-size-full].
 
 ## 2. Deprecations
 {: #deprecations}
 
 ### 2.1. Deprecated Size Keyword `full`
 {: #deprecated-size-keyword-full}
 
-The [size keyword][size] `full` will be replaced by `max` in version 3.0. It is impractical to deliver the full size of very large images, and thus the keyword is not helpful when the Image Information has not been read. When the Image Information has been read, clients can request the explicit `w,h` size. See [issue 678](https://github.com/IIIF/iiif.io/issues/678).
+The [size keyword][size] `full` will be replaced by `max` in version 3.0. It is impractical to deliver the full size of very large images, and thus the keyword is not helpful when the Image Information has not been read. When the Image Information has been read, clients can request the explicit `w,h` size. See [issue 678](https://github.com/IIIF/api/issues/678).
 
 ### 2.2. Deprecated `sizeByWhListed` and `sizeByForcedWh` Feature Names
 {: #deprecated-sizebywhlisted-and-sizebyforcedwh-feature-names}
 
-The feature names `sizeByWhListed` and `sizeByForcedWh` will be removed from the [profile description][profile-description] in version 3.0. The feature `sizeByForcedWh` was inconsistently defined in version 2.0. The feature `sizeByWhListed` is implied by including `sizes` in the image information document and is therefore not required as a named feature. See [issue 720](https://github.com/IIIF/iiif.io/issues/720) and related [addition of `sizeByConfinedWh` and `sizeByDistortedWh`][added-sizebyconfinedwh-and-sizebydistortedwh].
+The feature names `sizeByWhListed` and `sizeByForcedWh` will be removed from the [profile description][profile-description] in version 3.0. The feature `sizeByForcedWh` was inconsistently defined in version 2.0. The feature `sizeByWhListed` is implied by including `sizes` in the image information document and is therefore not required as a named feature. See [issue 720](https://github.com/IIIF/api/issues/720) and related [addition of `sizeByConfinedWh` and `sizeByDistortedWh`][added-sizebyconfinedwh-and-sizebydistortedwh].
 
 ## 3. Deferred Changes
 {: #deferred-changes}
 
 ### 3.1. Change Canonical Syntax
 
-The [canonical URI syntax][canonical-uri-syntax] will change in the next major release to use the `w,h` size syntax in a manner compatible with the `sizes` array, and to use `max` instead of `full` as the size keyword. See [issue 554](https://github.com/IIIF/iiif.io/issues/544) and [issue 678](https://github.com/IIIF/iiif.io/issues/678).
+The [canonical URI syntax][canonical-uri-syntax] will change in the next major release to use the `w,h` size syntax in a manner compatible with the `sizes` array, and to use `max` instead of `full` as the size keyword. See [issue 554](https://github.com/IIIF/api/issues/544) and [issue 678](https://github.com/IIIF/api/issues/678).
 
 ### 3.2. Change `license` property name to `rights`
 
-The mapping of the [`license` property][rights] has already been changed to `dcterms:rights` in the [JSON-LD context][context] to more accurately represent its use for both rights and licensing information. However, the change of the property name will be a breaking change and thus must wait for the next major version release. See [issue 644](https://github.com/IIIF/iiif.io/issues/644).
+The mapping of the [`license` property][rights] has already been changed to `dcterms:rights` in the [JSON-LD context][context] to more accurately represent its use for both rights and licensing information. However, the change of the property name will be a breaking change and thus must wait for the next major version release. See [issue 644](https://github.com/IIIF/api/issues/644).
 
 
 [added-sizebyconfinedwh-and-sizebydistortedwh]: #added-sizebyconfinedwh-and-sizebydistortedwh-feature-names "Added `sizeByConfinedWh` and `sizeByDistortedWh` Feature Names"

source/image/2.1/index.md

@@ -238,7 +238,7 @@ If the resulting height or width is zero, then the server _SHOULD_ return a 400
 The image server _MAY_ support scaling above the full size of the extracted region.
 
 __Deprecation Warning__
-The size keyword `full` will be replaced in favor of `max` in version 3.0. Until that time, the `w,` syntax should be considered the [canonical form][canonical-uri-syntax] of request for the `max` size, unless `max` is equivalent to `full`. Feedback is welcome via [iiif-discuss][iiif-discuss] or on the [Github issue](https://github.com/IIIF/iiif.io/issues/678).
+The size keyword `full` will be replaced in favor of `max` in version 3.0. Until that time, the `w,` syntax should be considered the [canonical form][canonical-uri-syntax] of request for the `max` size, unless `max` is equivalent to `full`. Feedback is welcome via [iiif-discuss][iiif-discuss] or on the [Github issue](https://github.com/IIIF/api/issues/678).
 {: .warning #full-dep}
 
 Examples:

source/presentation/2.1/change-log-211.md

@@ -22,51 +22,51 @@ For the significant changes between 2.0 and 2.1, please see the [2.1 Change Log]
 ### 1.1. Clarify use of `viewingHint`
 
 Not all of the `viewingHint` values were clearly described as to which resources they could be used with. The validity was clarified and the descriptions improved.
-See issue [#878](https://github.com/IIIF/iiif.io/issues/878)
+See issue [#878](https://github.com/IIIF/api/issues/878)
 
 ### 1.2. Clarify if Canvas id should be dereferencable
 
 The text of the document said that the id MAY be able to be dereferenced, whereas the summary table said SHOULD. The summary table was updated to reflect the normative text. This issue does not set a precedent for changing to SHOULD or even MUST in future major versions.
-See issue [#884](https://github.com/IIIF/iiif.io/issues/884)
+See issue [#884](https://github.com/IIIF/api/issues/884)
 
 ### 1.3. Use better URIs for example rights/licenses
 
 The URIs were not helpful in giving realistic examples. The examples were updated to use Creative Commons and Rights Statements URIs to promote the use of shared agreements.
-See issue [#960](https://github.com/IIIF/iiif.io/issues/960)
+See issue [#960](https://github.com/IIIF/api/issues/960)
 
 ### 1.4. Clarify use of non-rectangular region annotations
 
 The description of non-rectangular regions confusingly talked about rectangular regions at the same time.  The description was improved, including better links.
-See issue [#941](https://github.com/IIIF/iiif.io/issues/941)
+See issue [#941](https://github.com/IIIF/api/issues/941)
 
 ### 1.5. Update references to other specifications
 
 The introduction referred to a "future specification", meaning the Search API. The reference was updated now that API is available.
-See issue [#1003](https://github.com/IIIF/iiif.io/issues/1003)
+See issue [#1003](https://github.com/IIIF/api/issues/1003)
 
 ### 1.6. Clarify ranges without children are permitted
 
 The specification was clear that empty Collections are possible but was not obvious whether the same was true of Ranges (a Range with no child Ranges or Canvases).  This was clarified as possible, with the same proviso that this is discouraged without careful thought.
-See issue [#1016](https://github.com/IIIF/iiif.io/issues/1016)
+See issue [#1016](https://github.com/IIIF/api/issues/1016)
 
 ### 1.7. Expand thumbnail examples to promote good practice
 
 The examples that included thumbnails did not include information about the thumbnail representation, which would be valuable to viewing applications.  The examples were updated to promote better practice.
-See issue [#1098](https://github.com/IIIF/iiif.io/issues/1098)
+See issue [#1098](https://github.com/IIIF/api/issues/1098)
 
 ### 1.8. Update deprecation warning for Ranges
 
 The discussions about Ranges in the Audio-Visual work has led to a proposal for a significantly more consistent and functional representation in a future version of the Presentation API.  The deprecation warning for `canvases` and `ranges` was made less specific to not assume any particular conclusion from those discussions.
-See issue [#1118](https://github.com/IIIF/iiif.io/issues/1118)
+See issue [#1118](https://github.com/IIIF/api/issues/1118)
 
 ### 1.9. Typos for `ContentAsText`
 
 There were several typos for `ContentAsText` in the example JSON documents. These were corrected.
-See issue [#1139](https://github.com/IIIF/iiif.io/issues/1139)
+See issue [#1139](https://github.com/IIIF/api/issues/1139)
 
 ### 1.10. Typos for Image Profile URI
 
-There were two typos for the Image Profile URI that included an extra `profiles` path component. These were corrected.  See issue [#1170](https://github.com/IIIF/iiif.io/issues/1170)
+There were two typos for the Image Profile URI that included an extra `profiles` path component. These were corrected.  See issue [#1170](https://github.com/IIIF/api/issues/1170)
 
 
 ## 2. Changes to Non-Semantically-Versioned Documents
@@ -78,39 +78,39 @@ These changes were scheduled to coincide with the release of 2.1.1 to benefit fr
 #### 2.1.1. Missing Search API terms
 
 The terms for `exact`, `prefix` and `suffix` were missing from both the Search and Presentation context documents. They were added to the Presentation context to ensure availability.
-See issue [#952](https://github.com/IIIF/iiif.io/issues/952)
+See issue [#952](https://github.com/IIIF/api/issues/952)
 
 #### 2.1.2. Unnecessary types prevent compaction
 
 The intended-to-be-helpful types provided in the context such as `ViewingHint` and `ViewingDirection` instead just prevented the values from being compacted correctly when these types were not asserted. The types were removed to make this easier.
-See issue [#946](https://github.com/IIIF/iiif.io/issues/946)
+See issue [#946](https://github.com/IIIF/api/issues/946)
 
 #### 2.1.3. Choice options should always be a set
 
 The specifications were not clear as to how to represent a single option other than the default, whether it should be a list with a single item, or just the item. This is clarified that it should always be a list, and the context updated to add `@container: @set` to the definition.
-See issue [#1120](https://github.com/IIIF/iiif.io/issues/946)
+See issue [#1120](https://github.com/IIIF/api/issues/946)
 
 ### 2.2. Frames should use `@explicit` to ensure correct summaries
 
 The frame documents used `@embed: false` for referenced resources such as an external AnnotationList.  This meant that only the URI was included, but not `@type` or `label`. The solution was to use `@explicit` to list the set of terms that should be included.
-See issue [#959](https://github.com/IIIF/iiif.io/issues/959)
+See issue [#959](https://github.com/IIIF/api/issues/959)
 
 ### 2.3. Fixtures
 
 #### 2.3.1. Fixture 6 did not have multiple descriptions
 
 The fixture example for multiple descriptions did not actually have multiple descriptions.  The bug in the generation software was fixed that was stripping the second description.
-See issue [#1122](https://github.com/IIIF/iiif.io/issues/1122)
+See issue [#1122](https://github.com/IIIF/api/issues/1122)
 
 #### 2.3.2. Fixture 64 had unnecessary array
 
 The fixture object had an array around a single description, which made it incompatible with the JSON-LD framing algorithm.
-See issue [#1123](https://github.com/IIIF/iiif.io/issues/1123)
+See issue [#1123](https://github.com/IIIF/api/issues/1123)
 
 #### 2.3.3. Fixture 65 had typo for startCanvas
 
 The fixture for `startCanvas` instead had the pre-2.0 use of `start_canvas` before snake and camel case were reconciled.  This was corrected.
-See issue [#1125](https://github.com/IIIF/iiif.io/issues/1125)
+See issue [#1125](https://github.com/IIIF/api/issues/1125)
 
 {% include acronyms.md %}