Downstream Debian `iso-codes` is unmaintained

[brycedewitt]

The most current release 23.12.11 release of pycountry is over a year out of date from recent ISO 3166-2 revisions.

---

Example: Indonesia added region ID-PE on 2022-11-29 (ISO source), but is missing from the pycountry release a few weeks ago.

Further spot checking has revealed that all recent updates from the 2022-11-29 ISO 3166-2 revision onward are missing from this package. I have not checked the other ISOs in pycountry, but assume them to be equally out of date.

Investigation The downstream Debian iso-codes package is also missing the latest ISO changes and has not had meaningful ISO updates in over a year.

I had assumed that the Debian iso-codes package would have an automated update mechanism pulling directly from ISO, but after poking around it seems to be a manual process for one of the maintainers. There's a stale open issue from 3 years ago trying to find funding for more recent updates from ISO itself, as well as a question about nomenclature that has been open for over a year with no activity. The majority of recent commits are translation updates automatically carried in by Weblate.

All things considered, it seems like the downstream dependency can be considered unmaintained and out of date at this point. Updating to more recent iso-codes versions is likely to carry over only the updates to translations, not any meaningful update to the ISO regions themselves, meaning pycountry will continue to be a snapshot-in-time of ISO codes from early 2022.

Solutions There's obviously 2 courses for pycountry to take here:

1. Help maintain & contribute updates to the downstream Debian package Since there's a significant amount of translation work completed on the Debian package, I think it makes sense to push to maintain the package there. I personally don't have a GitLab account/team that could help contribute to that repo, but would welcome some suggestions from anyone familiar with contributing to Debian projects on how to go about reviving it. Additionally, I'm not sure where the maintainers have been pulling the current ISO 3166-2 JSON files from - I can't seem to find an API interface for ISO Online Browsing Platform 🤔

2. Move to a new source of updated regions Poking around a bit, I've found another MIT ISO 3166-2 project that does indeed have recent updates in the published package, but seems like the owner has deleted or brought private the original GitHub repo for it, so I'm not entirely sure what the status is there. I've reached out by email but haven't heard back.

---

I'd love to get others' thoughts on how to go about getting this current (particularly @nschimmoller since you've made the latest commits 😃)

[nschimmoller]

@brycedewitt

ISO 3166 Challenge

---

You're absolutely correct that region ID-PE, added on 2022-11-29 (ISO source), is missing from the pycountry release a few weeks ago. And your understanding of why it is missing, not in Debian ISO source is also correct

However, I'd hesitate to say that the downstream dependency is unmaintained as it's owner @toddy15 is very active on both Salsa and GitHub.

I think the biggest challenge is that it is prohibitively expensive to continue to buy access to ISO Standards which for ISO 3166 (1, 2 & 3) cost 300 CHF or ~$345 for only a year of access. There is a possibility my work may reimburse for something like this. I'll do some research but obviously not something I can commit to long term.

Non ISO 3166 Data Quality

---

Thankfully all others seem to be still public domain:

• ISO 15924 | Scripts is maintained by Unicode and seems to be public domain although more recent additions such as 296 Onao are missing from Debian and pycountry
• ISO 4217 | Currencies is still free of charge, and I just download a XLS list from the ISO website
  • I'm unable to tell if the recent changes have been incorporated in Debian as they maintain changes such as official tender of given countries
• ISO 639-3 and 639-5 | Maintained by iso and are available free online

I think to find any source that is more up to date than Debian's iso-codes and has an active maintainer community is unlikely.

Contributing to Debian

---

This actually isn't too difficult.

1. Register for an account on Salsa
2. Navigate to location you want to clone the repository

cd ~/path/to/location

3. Clone the repository

git clone https://salsa.debian.org/iso-codes-team/iso-codes

4. Create a development branch

git checkout -b 2023_12_15_iso3166_2_updates

5. Make your changes
6. Push your branch

git push origin 2023_12_15_iso3166_2_updates

7. Create a Merge Request

@ctheune have you ever talked to you countryman Tobias Quathamer?

[nschimmoller]

@brycedewitt howdy fellow Bostonian 👋

[nschimmoller]

You could really go off the end if you want and build a webscrapper of the different ISO pages but you would probably want to check their EULA first.

[brycedewitt]

Appreciate the speedy response @nschimmoller - I've actually relocated from Boston -> San Fransisco a few months ago, just in time to dodge snow season on the green line 🚋 😮‍💨

I was admittedly a little quick on the trigger there, "outdated" is probably a more accurate description, and I'm very appreciative of the work y'all have already done here!

Some info on my use case: I'm trying to use pycountry data to talk to some external systems that also use 3166 data, but its a bit messy since each one (including ours) is outdated to their own degree as well. The happypath for me here would be to help setup a better automated pipeline to keep both iso-codes and pycountry as up-to-date as possible, then we can selfishly point our fingers at the maintainers of the other systems for not staying as current as we do and wash our hands of those issues 🤷‍♂️

We might also be able to expense an ISO license as well but it's a little foggy to me (IANAL, obviously) who owns the rights to that data even after purchase. We'd probably be able to purchase our own copy and insert our updated iso3166-2.json into pycountry at build time, but that feels unnecessarily circumspect for something that is de-facto an open standard.

Would be great if ISO/ANSI would just cough up to support the Debian package 🙃

Anyway, happy to help here, just wanted to get a discussion going so we don't reinvent the wheel.

[nschimmoller]

@brycedewitt I think you'll be happy with this

I was able to build a little web scrapper of the ISO website and systematically identify what records needed updating and which needed adding / removing. I wasn't able to find anything against web scraping on their website so I think this is legal. If you'd like a copy of the code I used let me know and I may setup a private repo and could invite you.

Pull Request Comment

Updates in ISO 3166-2 JSON Data file should be in compliance with format of existing JSON. List of additions and removals according to the ISO not reflected in current ISO 3166-2 JSON are listed below along with date of affect. Changes to list pulled on 2023-12-16. All other changes such as updates of parent codes for Country Code UG (i.e. W -> UG-W) are as they are shown on ISO website.

Removal of FR subdivisions:

FR-RE, FR-75, FR-GP, FR-YT, FR- MQ, FR-GF (2021-11-25):

Addition of category European collectivity in eng & fra; Addition of European collectivity
  FR-6AE; Addition of metropolitan collectivity with special status FR-69M; Change of
  category name from metropolitan department to metropolitan collectivity with special
  status for FR-75; Change of subdivision code from FR-75 to FR-75C; Addition of category
  overseas departemental collectivity in eng & fra; Change of category name from overseas
  department to overseas departemental collectivity for FR-971, FR-974, FR-976; Addition
  of category overseas unique territorial collectivity in eng & fra; Change of category
  name from overseas department to overseas unique territorial collectivity for FR-972,
  FR-973; Deletion of category name overseas department; Deletion of overseas region
  FR-GF, FR-GP, FR-MQ, FR-RE, FR-YT; Deletion of category name overseas region; Change
  of parent subdivision of FR-67, FR-68; Deletion of parent subdivion of FR-971, FR-972,
  FR-973, FR-974, FR-976; Modification of Remark part 2; Update List Source and Code
  Source

Removal of GB subdivisions:

GB-NTH (2022-11-29):

Deletion of two-tier county GB-NTH; Addition of unitary authority GB-NNH, GB-WNH;
  Change of category name from two-tier county to unitary authority for GB-BKM; Update
  List Source

Removal of GT subdivisions:

GT-JA, GT-ZA, GT-ES, GT-QZ, GT-CQ, GT-PE, GT-SO, GT-JU, GT-GU, GT-RE, GT-PR, GT-QC, GT-SA, GT-HU, GT-CM, GT-IZ, GT-SU, GT-SM, GT-AV, GT-SR, GT-TO, GT-BV (2021-11-25):

Change of subdivision code from GT-AV to GT-16, GT-BV to GT-15, GT-CM to GT-04, GT-CQ
  to GT-20, GT-ES to GT-05, GT-GU to GT-01, GT-HU to GT-13, GT-IZ to GT-18, GT-JA to
  GT-21, GT-JU to GT-22, GT-PE to GT-17, GT-PR to GT-02, GT-QC to GT-14, GT-QZ to GT-09,
  GT-RE to GT-11, GT-SA to GT-03, GT-SM to GT-12, GT-SO to GT-07, GT-SR to GT-06, GT-SU
  to GT-10, GT-TO to GT-08, GT-ZA to GT-19; Update Code Source

Removal of IN subdivisions:

IN-CT, IN-TG, IN-OR, IN-UT (2023-11-23):

Change of subdivision code from IN-OR to IN-OD, from IN-CT to IN-CG, from IN-TG to
  IN-TS, from IN-UT to IN-UK; Deletion of the asterisk from IN-JH; Update Code Source

Removal of IS subdivisions:

IS-SKU, IS-HUT, IS-HEL, IS-SBH, IS-SSF, IS-BLD, IS-AKH, IS-BFJ, IS-FLD, IS-SEY, IS-DJU (2022-11-29):

Deletion of municipality IS-AKH, IS-BLO, IS-HEL, IS-HUT, IS-SBH, IS-SKU, IS-SSF; Addition
  of municipality IS-HUG, IS-SKR

Removal of KZ subdivisions:

KZ-ALA, KZ-KUS, KZ-PAV, KZ-SHY, KZ-KZY, KZ-YUZ, KZ-AKT, KZ-KAR, KZ-SEV, KZ-ZAP, KZ-ALM, KZ-MAN, KZ-VOS, KZ-ATY, KZ-ZHA, KZ-AST, KZ-AKM (2022-11-29):

Change of subdivision code from KZ-ALA to KZ-75, KZ-AST to KZ-71, KZ-SHY to KZ-79,
  KZ-ALM to KZ-19, KZ-AKM to KZ-11, KZ-AKT to KZ-15, KZ-ATY to KZ-23, KZ-VOS to KZ-63,
  KZ-MAN to KZ-47, KZ-SEV to KZ-59, KZ-YUZ to KZ-61, KZ-PAV to KZ-55, KZ-KAR to KZ-35,
  KZ-KUS to KZ-39, KZ-KZY to KZ-43, KZ-ZAP to KZ-27, KZ-ZHA to KZ-31; Addition of region
  KZ-10, KZ-33, KZ-62; Change of subdivision name for KZ-71 in kaz and rus; Update List
  Source; Update Code Source

Removal of LV subdivisions:

LV-017, LV-006, LV-109, LV-060, LV-100, LV-044, LV-038, LV-078, LV-049, LV-035, LV-061, LV-075, LV-055, LV-105, LV-037, LV-029, LV-032, LV-074, LV-079, LV-012, LV-063, LV-082, LV-084, LV-043, LV-036, LV-048, LV-085, LV-066, LV-009, LV-004, LV-021, LV-065, LV-081, LV-070, LV-051, LV-001, LV-108, LV-013, LV-090, LV-018, LV-020, LV-008, LV-096, LV-023, LV-064, LV-005, LV-040, LV-010, LV-025, LV-069, LV-071, LV-072, LV-053, LV-098, LV-110, LV-076, LV-030, LV-095, LV-014, LV-086, LV-JKB, LV-092, LV-028, LV-VMR, LV-027, LV-083, LV-024, LV-019, LV-045, LV-107, LV-104, LV-034, LV-103, LV-003, LV-057, LV-046, LV-039, LV-031, LV-093 (2021-11-25):

Deletion of republican city LV-JKB, LV-VMR; Deletion of municipality LV-001, LV-003,
  LV-004, LV-005, LV-006, LV-008, LV-009, LV-010, LV-012, LV-013, LV-014, LV-017, LV-018,
  LV-019, LV-020, LV-021, LV-023, LV-024, LV-025, LV-027, LV-028, LV-029, LV-030, LV-031,
  LV-032, LV-034, LV-035, LV-036, LV-037, LV-038, LV-039, LV-040, LV-043, LV-044, LV-045,
  LV-046, LV-048, LV-049, LV-051, LV-053, LV-055, LV-057, LV-060, LV-061, LV-063, LV-064,
  LV-065, LV-066, LV-069, LV-070, LV-071, LV-072, LV-074, LV-075, LV-076, LV-078, LV-079,
  LV-081, LV-082, LV-083, LV-084, LV-085, LV-086, LV-090, LV-092, LV-093, LV-095, LV-096,
  LV-098, LV-100, LV-103, LV-104, LV-105, LV-107, LV-108, LV-109, LV-110; Change of
  category name from republican city to state city for LV-DGV, LV-JEL, LV-JUR, LV-LPX,
  LV-REZ, LV-RIX, LV-VEN; Addition of municipality LV-111, LV-112, LV-113; Update List
  Source

Removal of NP subdivisions:

NP-ME, NP-MA, NP-BA, NP-RA, NP-SE, NP-NA, NP-LU, NP-KA, NP-JA, NP-BH, NP-DH, NP-SA, NP-GA, NP-KO (2022-11-29):

Deletion of development regions NP-1, NP-2, NP-3, NP-4, NP-5; Change of subdivision, 
  name of NP-P4, NP-P6 in nep; Change of subdivision name of NP-P2, NP-P7 in eng and
  nep; Change of subdivision name of NP-P3 in eng; Addition of location variation for
  NP-2 in eng and nep; Modification of local variation for NP-P7 in eng and nep; Deletion
  of zones NP-BA, NP-BH, NP-DH, NP-GA, NP-JA, NP-KA, NP-KO, NP-LU, NP-MA, NP-ME, NP-NA,
  NP-RA, NP-SA, NP-SE: Update List Source; Modification of remark part 2

Removal of PH subdivisions:

PH-MAG (2023-11-23): Deletion of province PH-MAG; Addition of province PH-MGN, PH-MGS

Additions to DZ subdivisions:

DZ-58, DZ-53, DZ-50, DZ-52, DZ-55, DZ-49, DZ-54, DZ-57, DZ-56, DZ-51 (2022-11-29):

Addition of province DZ-49, DZ-50, DZ-51, DZ-52, DZ-53, DZ-54, DZ-55, DZ-56, DZ-57,
  DZ-58; Update List Source

Additions to ET subdivisions:

ET-SW (2022-11-29): Addition of regional state ET-SW; Update List Source ET-SI (2021-11-25): Addition of regional state ET-SI; Update List Source

Additions to FR subdivisions:

FR-75C, FR-69M, FR-6AE (2021-11-25):

Addition of category European collectivity in eng & fra; Addition of European collectivity
  FR-6AE; Addition of metropolitan collectivity with special status FR-69M; Change of
  category name from metropolitan department to metropolitan collectivity with special
  status for FR-75; Change of subdivision code from FR-75 to FR-75C; Addition of category
  overseas departemental collectivity in eng & fra; Change of category name from overseas
  department to overseas departemental collectivity for FR-971, FR-974, FR-976; Addition
  of category overseas unique territorial collectivity in eng & fra; Change of category
  name from overseas department to overseas unique territorial collectivity for FR-972,
  FR-973; Deletion of category name overseas department; Deletion of overseas region
  FR-GF, FR-GP, FR-MQ, FR-RE, FR-YT; Deletion of category name overseas region; Change
  of parent subdivision of FR-67, FR-68; Deletion of parent subdivion of FR-971, FR-972,
  FR-973, FR-974, FR-976; Modification of Remark part 2; Update List Source and Code
  Source

Additions to GB subdivisions:

GB-WNH, GB-NNH (2022-11-29): Deletion of two-tier county GB-NTH; Addition of unitary authority GB-NNH, GB-WNH; Change of category name from two-tier county to unitary authority for GB-BKM; Update List Source

Additions to GT subdivisions:

GT-12, GT-13, GT-22, GT-15, GT-16, GT-11, GT-05, GT-07, GT-20, GT-19, GT-17, GT-18, GT-09, GT-06, GT-01, GT-04, GT-08, GT-10, GT-21, GT-02, GT-14, GT-03 (2021-11-25):

Change of subdivision code from GT-AV to GT-16, GT-BV to GT-15, GT-CM to GT-04, GT-CQ
  to GT-20, GT-ES to GT-05, GT-GU to GT-01, GT-HU to GT-13, GT-IZ to GT-18, GT-JA to
  GT-21, GT-JU to GT-22, GT-PE to GT-17, GT-PR to GT-02, GT-QC to GT-14, GT-QZ to GT-09,
  GT-RE to GT-11, GT-SA to GT-03, GT-SM to GT-12, GT-SO to GT-07, GT-SR to GT-06, GT-SU
  to GT-10, GT-TO to GT-08, GT-ZA to GT-19; Update Code Source

Additions to ID subdivisions:

ID-PD (2023-11-23): Addition of province ID-PD; Update List Source ID-PT, ID-PE, ID-PS (2022-11-29): Addition of provinces ID-PE, ID-PS and ID-PT; Update List Source

Additions to IN subdivisions:

IN-OD, IN-TS, IN-UK, IN-CG (2023-11-23): Change of subdivision code from IN-OR to IN-OD, from IN-CT to IN-CG, from IN-TG to IN-TS, from IN-UT to IN-UK; Deletion of the asterisk from IN-JH; Update Code Source

Additions to IQ subdivisions:

IQ-KR (2022-03-03): Addition of category region in eng, fra, ara, kur; Addition of region IQ-KR; Assign parent subdivision to IQ-AR, IQ-DA, IQ-SU; Update List and Code Source

Additions to IS subdivisions:

IS-SKR, IS-HUG (2022-11-29): Deletion of municipality IS-AKH, IS-BLO, IS-HEL, IS-HUT, IS-SBH, IS-SKU, IS-SSF; Addition of municipality IS-HUG, IS-SKR IS-MUL (2021-11-25): Deletion of municipality IS-BFJ, IS-DJU, IS-FLD, IS-SEY; Addition of municipality IS-MUL; Update List Source

Additions to KZ subdivisions:

KZ-62, KZ-23, KZ-27, KZ-10, KZ-59, KZ-11, KZ-47, KZ-39, KZ-75, KZ-79, KZ-43, KZ-15, KZ-71, KZ-31, KZ-35, KZ-61, KZ-19, KZ-33, KZ-63, KZ-55 (2022-11-29):

Change of subdivision code from KZ-ALA to KZ-75, KZ-AST to KZ-71, KZ-SHY to KZ-79,
  KZ-ALM to KZ-19, KZ-AKM to KZ-11, KZ-AKT to KZ-15, KZ-ATY to KZ-23, KZ-VOS to KZ-63,
  KZ-MAN to KZ-47, KZ-SEV to KZ-59, KZ-YUZ to KZ-61, KZ-PAV to KZ-55, KZ-KAR to KZ-35,
  KZ-KUS to KZ-39, KZ-KZY to KZ-43, KZ-ZAP to KZ-27, KZ-ZHA to KZ-31; Addition of region
  KZ-10, KZ-33, KZ-62; Change of subdivision name for KZ-71 in kaz and rus; Update List
  Source; Update Code Source

Additions to LV subdivisions:

LV-111, LV-113, LV-112 (2021-11-25):

Deletion of republican city LV-JKB, LV-VMR; Deletion of municipality LV-001, LV-003, LV-004, LV-005, LV-006, LV-008, LV-009, LV-010, LV-012, LV-013, LV-014, LV-017, LV-018, LV-019, LV-020, LV-021, LV-023, LV-024, LV-025, LV-027, LV-028, LV-029, LV-030, LV-031, LV-032, LV-034, LV-035, LV-036, LV-037, LV-038, LV-039, LV-040, LV-043, LV-044, LV-045, LV-046, LV-048, LV-049, LV-051, LV-053, LV-055, LV-057, LV-060, LV-061, LV-063, LV-064, LV-065, LV-066, LV-069, LV-070, LV-071, LV-072, LV-074, LV-075, LV-076, LV-078, LV-079, LV-081, LV-082, LV-083, LV-084, LV-085, LV-086, LV-090, LV-092, LV-093, LV-095, LV-096, LV-098, LV-100, LV-103, LV-104, LV-105, LV-107, LV-108, LV-109, LV-110; Change of category name from republican city to state city for LV-DGV, LV-JEL, LV-JUR, LV-LPX, LV-REZ, LV-RIX, LV-VEN; Addition of municipality LV-111, LV-112, LV-113; Update List Source

Additions to ME subdivisions:

ME-25 (2023-11-23): Addition of municipality ME-25; Update List Source

Additions to PA subdivisions:

PA-NT (2021-11-25): Addition of indigenous region PA-NT; Update List Source

Additions to PH subdivisions:

PH-MGN, PH-MGS (2023-11-23): Deletion of province PH-MAG; Addition of province PH-MGN, PH-MGS

Additions to KP subdivisions:

KP-15 (2022-11-29): Addition of metropolitan city KP-15; Update List Source

[ctheune]

Dang. I didn't notice this before. I'd suggest talking to the debian people.

This does sound like a trap regarding copyright and a potential github DMCA takedown. :/

[ghost]

Yup! Made the Pull Request over there and I'm not going to create a public repo of the scraper

[ctheune]

Well even with the scraper hidden, I think we should investigate the license that the ISO org has on the data now. Alternatively we might want to investigate other sources for scraping/integrating. And then I'd still prefer to find a solution that would work for pkg-isocodes.

[ghost]

I checked pretty extensively on their website for any terms of service, privacy, etc. and there is nothing. I checked robots.txt and they just asked to crawl every 5 seconds.

All of this data is available on sites like Wikipedia freely so worst case we just scrape there

[brycedewitt]

@nschimmo Productive Saturday morning for ya, thanks for doing that.

Since Tobias Quathamer committed most of those ISO files to begin with, I expect he's already concluded the ISO licensing to be permissive enough for that, or might even have some connections to or understanding with ISO/ANSI himself (since he seems to be a pretty prolific Debian contributor). I do share the same concerns with @ctheune though, I wouldn't personally want my name on that commit without at least a nod from someone familiar with licensing there.

Regardless, we'll need someone from Debian to take approve & release that update anyway, so hopefully they can shed some light there.

[llimeht]

Rather than having iso-codes from Debian get slurped into this project and then get excised once again to make a pycountry upload to Debian, perhaps the iso-codes package and this one could be merged into one project? That would greatly reduce the friction in both this project and its maintenance in Debian. Maybe in the process, we could all agree on whether there are underscores in the filenames :)

[nschimmoller]

@llimeht welcome back!

I don't want to act like I know all the technical blockers that would present themselves in this effort. However, I think there is enough for us to focus on from an enhancement perspective for us to instead focus on this. A few questions:

"... then get excised once again to make a pycountry upload to Debian..."

Can you explain more of what you mean by this?

"Maybe in the process, we could all agree on whether there are underscores in the filenames"

Moving pycountry to mirror Debian's underscores in the file names doesn't seem overly complex. Somebody else suggested this in #180 , however I'd like to understand the expected benefits of doing so before committing to doing the work.

Could you weigh in with your thoughts?

[llimeht]

Hi @nschimmoller!

"... then get excised once again to make a pycountry upload to Debian..."

Can you explain more of what you mean by this?

To be able to upload pycountry to Debian (and derivatives), the src/pycountry/databases and src/pycountry/locales directories need to be removed from the tarball. What is uploaded as the source tarball for pycountry is only the Python module code, the tests and the necessary metadata files like pyproject.toml, LICENCE.txt etc.

There are a few reasons excising the data files is required:

• There are no .po/.pot files for the .mo files; no-one edits .mo files as they are the compilation output from msgfmt and so a pile of .mo files are sourceless binaries that are probably not acceptable for LGPL2.1 and Debian. In the same way as we wouldn't accept a bunch of .pyc files instead of .py files, we don't want to see .mo files instead of .po files.
• Even with the .po files, this project has a Data Update Policy clearly spelled out in the README that says that these .mo and .json files are not where modifications are going to be made; I understand why that policy exists and it makes sense for this project as a data wrapper and not a data source. However, I think it means that in Debian, these files should be pulled from the iso-codes package not carried within the python3-pycountry binary package, as once again, these files are not really modifiable.
• The 30 MB deduplication isn't huge but is enough to consider.

Basically, it comes down to "are these files practically modifiable" and "where would one send the patches". If pycountry and iso-codes were to merge into one project, all these issues would go away as the source data and code would live in the same place.

"Maybe in the process, we could all agree on whether there are underscores in the filenames"

Moving pycountry to mirror Debian's underscores in the file names doesn't seem overly complex. Somebody else suggested this in #180 , however I'd like to understand the expected benefits of doing so before committing to doing the work.

Maybe I can reflect the question in a different way... "if this is just the data from iso-codes, why are the filenames different?".

Looking at it another way, because we need to unbundle the data from pycountry as outlined above, we then need to keep some sort of shim in place to handle the difference in underscores. Writing patches to improve integration is precisely what distro maintainers do so that the user has a set of components that work together... but we always prefer not to do so. Carrying patches always comes with risks that they introduce additional bugs or incompatibilities. Carrying patches always comes with extra work in maintaining/refreshing/rewriting them for each new release. The preferred situation is that Debian (and derivatives) carry no patches to help integrate the components they ship.

Does that unpack the comments a bit?