Proposal talk:ISCED 2011 Education Programme

From OpenStreetMap Wiki
Jump to navigation Jump to search

Specifying the ISCED version in its own tag

Resolved: This won't be in the proposal, since it will lead to a situation where changing one tag will change the meaning of another tag. At the same time it does not provide strong advantages. --Skorbut (talk) 05:28, 8 April 2022 (UTC)

To avoid repeating this mess in the future when a fourth version of ISCED comes out, it does make sense to explicitly state the standard being used. [...] how about combining isced:level=* with isced:version=2011, for consistency with public_transport:version=* and population:date=*? Minh Nguyen at https://lists.openstreetmap.org/pipermail/tagging/2022-January/063666.html (slightly adjusted by Skorbut, hope that's ok)

Reason for not using this was 2011 redefined the meaning of higher levels, made it misleading to use isced:level=5 + isced:version=2011 if some software only knows 1997. Your examples only added new tags, or update them. Could be considered if isced:level=* is abandoned.
--- Kovposch (talk) 03:09, 31 January 2022 (UTC)
Since this proposal already deprecates the "level" terminology in favor of "programme", how about isced:programme=* in conjunction with isced:version=*? Even though one tag can affect the meaning of another tag, I don't think the potential for unsynchronized changes would pose a significant problem compared to mappers potentially thinking they need to retroactively fill in isced:2007:level=*, isced:2011:level=*, and a future isced:20xx:level=*. These tags could all get out of sync with nuances that a data consumer would then have to adjudicate. – Minh Nguyễn 💬 06:17, 1 February 2022 (UTC)
@Minh Nguyen: @Kovposch: : I think a note on the tag's wiki page to not retroactively fill in the tags for old ISCED versions should suffice. However, if a mapper does it anyway, it will not be that bad since it will be visible from the used tags that an outdated version of ISCED was used. This would be certainly less bad than continuing to use isced:level=* where it is not clear which ISCED version we talk about. --Skorbut (talk)

Remove ambiguity with namespace : identifier

I am not a favourite of using isced:version=2011 to distinguish an essentially different system. Using a namespace :2011 might create confusion.

If the new tag refers to a essentially different or extended system (difference in level or programme descriptions + 1 digit to 3 digits if I understood correctly, I would prefer isced2011:programme=*, thus without the namespace : identifier. This avoids confusion with the different order and intend of a year in the tag in comparison to the date namespace.

I can imagine, in the future, the system might be amended or updated, but still internationally be known and used as the ISCED 2011. If an assisting version subtag would be used, it should refer to those versions, not an essentially different system. So this would mean isced2011:programme=* with a standard isced2011:version=2011 (not tagged), or as an amended or new version appears f.i. in 2020,isced2011:version=2020 to overwrite the standard 2011 date.--Bert Araali (talk) 15:23, 14 February 2022 (UTC)

Good question, what happens when ISCED gets an update but is still known as ISCED 2011. I guess, I would update to isced20XX:programme=* anyway. We can always define what the differences and similarities to a previous tag are. IMHO it is important to always know which version of ISCED we are referring to!
  • Obviously, this is not given with isced:level=*. (Neither in the
  • With a (not always required) version number in a separate tag we will have the same mess as we currently have as soon as a next ISCED version comes out.
  • With a (always required) version number in a separate tag we know the version of ISCED
    • but the barrier for mistakes is lower: Someone will come and change the version tag without properly adjusting the programme/level number. It would be like when today someone would retag all isced:level=6 to isced:2011:programme=6 (or whatever the tagging scheme) without noticing that it should be (in some cases) isced:2011:programme=8 for the new (2011) ISCED.
    • And besides: How are we going to make sure someone does indeed use the version tag that we declared as being required?
--Skorbut (talk) 20:37, 14 February 2022 (UTC)
Generally, if the standard changes and our tags are in the vast majority "TAG_1"="old standard value" the action to tag according to the new standard should be TAG_2="new standard value". Trying to make everybody switch from "TAG_1"="old standard value" to "TAG_1"="new standard value" would create a huge mess.
If there is a systematic problem with TAG_1="old" or "new standard value" (mixed, existing values following different systems), then it seems right to deprecate the TAG_1 key and use a new key for each of the standards (possibly explicit, e.g. TAG_1:2011=....). Generally, I would not use 2 different tags that only together make sense, i.e. TAG_1=foo, TAG_1:system=system_A where the interpretation of "foo" dipends on the value of TAG_1:system. In this case, better use TAG_1:system_A=foo. Rather than isced:version=2011 and a generic isced:level tag we should use something like isced:level:2011=x, in other words we'd use a new key for every new version of the standard.--Dieterdreist (talk) 23:52, 19 February 2022 (UTC)

Defining ranges for levels

Resolved: This won't be in the proposal. While it may make tagging slightly easier/shorter, it will make it more difficult to read data using e.g. Overpass queries. It also may still be added later on by another proposal. --Skorbut (talk) 05:36, 8 April 2022 (UTC)

Advantages:

  • Makes it slightly easier to specify multiple levels when mapping
  • Makes the values slightly shorter

Disadvantages:

  • Makes it harder to read data (e.g. when writing an Overpass query)
  • Makes it harder for authors of editors to allow reading/writing data
  • It is (for programmers at least) not obvious, whether in a range "1-3" level 3 would be included or not. The famous computer scientist Edsger Dijkstra has written about this: www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
  • Not possible to use (or at least confusing) when used on (sub-)categories instead of levels
1. I would be more concerned about hyphen as a separator in case they add sub-numbers, like the issue with addr:*=1-2 in building indoor addresses (which also has problem with comma addr:*=3,4 vs semi-colon addr:*=3;4 listing). I like to use dashes (as crude as -- if not at least ) for ranges outside OSM. I don't expect my personal style to be used or recognized.
2. As a non-programmer, a parser should be capable of handling ranges. Is requirement reasonable?
4. You could limit ranges to same-layer only, when there are multiple depths specified.

--- Kovposch (talk) 03:20, 31 January 2022 (UTC)

@Kovposch: The  to  range separator has been floated at various times over the years, including as part of grades=* to avoid conflict with the (dubious) negative grade number syntax. It's unlikely that any data consumer currently recognizes this range separator, but I don't think it would be any more technically challenging to support than -, --, , or . – Minh Nguyễn 💬 06:24, 1 February 2022 (UTC)
Ah yes, Japan likes to use tildes for ranges. If I were to judge it though, ~ isn't as definitive as others, when it can represent an approximate range.
It's not "negative" I'm annoyed by. Aside from grades=* being US-oriented for grade 1 to 12, here we may use prefixes for K1 to K3 (kindergarten), P1 to P6 (primary school), and S1 to S6 (secondary school). If someone writes grades=K-3 (adopted from Key:grades#Examples), - is not entirely clear on whether it's a range or separation symbol: somehow K3 only (although "K-3" is not as common as "P-3" and "S-3"), a probable K1 to P3, or a quite likely K1 to S3. --- Kovposch (talk) 07:20, 1 February 2022 (UTC)
I only mean to point out the precedent for using a separator other than a hyphen, in case that was desired. grades=* isn't really machine-readable anyways. – Minh Nguyễn 💬 19:26, 6 February 2022 (UTC)
@Kovposch:, @Minh Nguyen:: Would you agree to the statement that a range separator comes with certain disadvantages and these could trigger someone to vote no on the proposal? Can we (for the sake of finding an agreed successor for the ambiguous isced:level=*) leave the range separator out for now? You or someone else could make a follow-up proposal that would introduce the ranges into isced:2011:programme=* values. It does not work so well the other way round (first allowing, then disallowing ranges)... --Skorbut (talk) 20:01, 12 February 2022 (UTC)

"Programme"

Resolved: The proposal will use the verbose, but future-proof variant key isced_2011_programme=* . --Skorbut (talk) 15:01, 8 April 2022 (UTC)

This is a good direction to clarify the tier. But in fact, there exists ISCED-A attainment, aside from ISCED-P programme (as well as ISCED-F for fields). Sometimes they are not the same. If we are not expected to differentiate between them, using other words would be better to avoid misunderstanding of having over-specified. --- Kovposch (talk) 03:32, 31 January 2022 (UTC)

I have trouble understanding what you would like to propose. Do you propose to use another key than "programme"? If yes, which one? Did you see that I extended the proposal with the section https://wiki.openstreetmap.org/wiki/Proposed_features/ISCED_2011_Education_Programme#Extensibility that mentions the possibility of introducing isced:2011:field=*? (This is a possibility, but NOT the goal of this proposal.) Skorbut (talk) 20:11, 31 January 2022 (UTC)
You could use simply isced=* unsuffixed (like iata=* and icao=*), if you don't care about anything else at first. isced:level=* will be deprecated in either case. In response to Talk:Proposed_features/ISCED_2011_Education_Programme#Specifying_the_ISCED_version_in_its_own_tag at the top, this would allow optional isced:version=* if needed. The year, whether infix or suffix, can then be removed from keys entirely, Doing so minimizes the existing and potential future namespace bloat.
I forgot Proposed features/ISCED also had isced:field=*.
--- Kovposch (talk) 21:20, 31 January 2022 (UTC)
I am afraid, I still can't quite follow... So, you would use isced=* for ISCED-P, isced:version=2011 for the year and optionally isced:field=* for ISCED-F? I still haven't figured out the problem with namespace bloat. Can you explain or is there a description of it? And don't you also have namespace bloat when using isced:version=2011? Would using isced_2011_programme=* instead of isced:2011:programme=* make anything better? Skorbut (talk) 20:21, 1 February 2022 (UTC)
You will have to include "2011" in every isced:2011:programme=*. This would be avoided for isced=* or isced:programme=*, only adding isced:version=2011 when needed. --- Kovposch (talk) 08:53, 11 February 2022 (UTC)
@Kovposch:, @Fgnievinski: When exactly would specifying isced:version=2011 be necessary? When the next ISCED version comes out? What you propose would then lead to the same sadness we have right now, wouldn't it? People would add isced:programme=* without isced:version=2011 (because currently it is not necessary) and after the next ISCED version has appeared, we are wondering whether the programme was specified using 2011 or 20XX?
And about saving characters to type: isced:2011:programme=* is still shorter than isced=*+isced:version=2011
--Skorbut (talk) 20:28, 12 February 2022 (UTC)

I'm in favor of shortening isced:2011:programme=* to either isced:2011=* or isced=* for the most common case (programme) while still allowing optionally isced:version=2011 Fgnievinski (talk) 00:45, 10 February 2022 (UTC)

Well, isced:2011=* have the same shortcoming as isced:level:2011=*: ambiguity ending in a year suffix. isced:programme=* is basically acceptable ("ISCED 2" can be taken as ISCED-P), only that I try to be more technically correct in case someone wants to add ISCED-A.
Together, isced:version=* will be more coherent with isced=*.
--- Kovposch (talk) 09:11, 11 February 2022 (UTC)

Don’t use numbers

The current proposal will not be an improvement. It is already difficult to remember the meaning of the different numbers 1 to 6. It will be much hard to use this tag without looking at a table or list every time. It would be much better to use English words for the value of the tag, e.g. ISCED=pre-primary thru ISCED=doctoral, or education_level=kinder/pre-primary/primary/.../doctoral or something like that. --Jeisenbe (talk) 20:11, 3 February 2022 (UTC)

@Jeisenbe: I like that idea in general. But, what would you do with two- and three-digit codes? Not allow them? Put them in separate tags? Use words for them as well? As can be seen in the example, these description get quite long... I tend to believe that allowing words or numbers for one-digit codes and numbers only for two- and three-digit codes would be best. In your opinion, would allowing both words or numbers be better compared to numbers only? Skorbut (talk) 20:23, 4 February 2022 (UTC)
The 2 and 3 digit codes do not make sense to me. (What in the world would it mean for a secondary school to be "insufficient for level completion or partial level completion, without direct access to tertiary education" - how is that a secondary school? Is this a tag for an unaccredited school?). But if you are going to include these details, it would be better to make tags for subcategories, e.g. education_level=secondary + secondary=vocational, and then you need to clearly define them - explain what is the verifiable, observable difference between a "vocation" and a "general" secondary school, for example. --Jeisenbe (talk) 04:53, 11 February 2022 (UTC)
  1. Why don't you read the standard first? It's for GCSE/GCE and other split level programmes in different countries. There's an entire list of examples for every level. I believe vocational programmes structuring are also more complex, requiring this. If you don't want to bother with 3-digit, add the 2-digit code first?
  2. What you are asking for is outside the scope of this proposal. ISCED codes should be orthogonal to the actual tags you want. They complement each other. It's simply an internationally recognized classification that we can add directly. "Clearly defining" world's education systems is non-trivial. Eg Proposed features/Education 2.0 tried and failed (not that I agree with it). It's a difficult task. Another issue for example, as seen what the 2011 update handle, is the overlapping terminology in post-secondary, higher, and tertiary education.
I did not read the whole standard because it is a 78 page PDF document, and I like mapping for OpenStreetMap, but do not enjoy reading long international standards. I did read what is proposed on this page, and it is confusing and not clear how mappers would use it in the real world. Since this is a proposal for mappers like myself to use when mapping real schools, it needs to be clear without reading a 78 page PDF. However, I now have read the PDF and it does not answer my questions.
Re: "It's simply an internationally recognized classification that we can add directly" - What do you mean we can add it directly? The ISCED code is not listed on a sign at the school or on a school's website. Does your country publish a database, with appropriate licensing, which can be used to match every educational institution to a code? The USA and Indonesia do not have this, that I am aware. What I see is that mappers guess the ISCED code based on the name and the age of students or the types of degrees offered by the school or university. --Jeisenbe (talk) 01:02, 24 April 2022 (UTC)
--- Kovposch (talk) 08:48, 11 February 2022 (UTC)
The proposal will use numbers only. Using words as values would still be possible by a follow-up proposal. --Skorbut (talk) 15:06, 8 April 2022 (UTC)}}

isced:2011:programme=* vs. isced_2011_programme=*

Resolved: Underscores will be used in order to a) not confuse namespace-aware software, b) not mixing underscores and colons. --Skorbut (talk) 15:08, 8 April 2022 (UTC)

Due to previous discussions, I was wondering whether it would be advantageous to replace isced:2011:programme=* (and variants) with isced_2011_programme=* (or similar). This would prevent consumers from interpreting the colons (:) as part of any past or future namespace concept. I don't have a strong opinion for neither variant... --Skorbut (talk) 20:14, 17 February 2022 (UTC)

@Skorbut: isced_2011_programme=*: I believe this is a good compromise, taking all considerations into concern. Bert Araali (talk) 14:38, 20 February 2022 (UTC)
I'm not convinced this is better. Other possible combinations are isced_2011:programme=* (reserve namspace under isced_2011:*=*) and isced:programme_2011=* (specify the "programme" is according to 2011 update). But still you will make this look out-of-place with upcoming versions without futureproofing. "2011" can be dropped if isced:level=* is not used. --- Kovposch (talk) 10:03, 28 February 2022 (UTC)
@Kovposch: I would be glad if we can try to reduce the number of possible tagging schemes, not increase them... ;-) What variant would you like to see and why? What do you mean by futureproofing? I already wrote elsewhere on this page that to my understanding it is not a good idea to leave out the year (2011) (or make it optional), because with a next ISCED release, this will lead again to a similar situation as we have now: It will not be clear to what ISCED version a given value refers to. Could you please comment on that? --Skorbut (talk) 16:24, 28 February 2022 (UTC)

Mixing text and numbers

Resolved: Only numbers will be allowed in this proposal. Adding text/words in this or another key should be discussed in another proposal. --Skorbut (talk) 15:13, 8 April 2022 (UTC)

It's not nice to have 2 formats together. Either keep it under here by moving numbers to eg isced:ref=*; or start a broader education:*=* update for text, since this is not ISCED-specific (but you can still refer to ISCED definition).
Other issues ISCED number codes abstract to work around are long first degree, and research vs academic master/doctral. The "equivalent" text description is an important reminder to prevent people from wrongly classifying.
Another shortcoming for text is difficulty in mixing of general/vocational or academic/professional. If you are using text, maybe you can promote them to sub-key to have combinations as eg *:bachelor_level=yes + *:master_level=yes
--- Kovposch (talk) 10:31, 28 February 2022 (UTC)

@Kovposch: If you think this is controversial, I tend to go as with the range defintion: Remove it from the current proposal and let anyone who wants to have it, do a follow-up proposal... --Skorbut (talk) 16:38, 28 February 2022 (UTC)

Migration from "old" to "new"

Resolved: Migration instructions have been documented at https://wiki.openstreetmap.org/wiki/Proposed_features/ISCED_2011_Education_Programme#Migration --Skorbut (talk) 05:38, 8 April 2022 (UTC)

I made a final review before voting and quite happy with the proposal. The one thing unclear to me is, you state isced:level=* will be "obsoleted". To me that means, in this case, it's continued use is discouraged (not forbidden, we don't forbid any tag in OSM). The existing isced:level=* will be left untouched, this proposal doesn't have an (automated) migration path to resolve the ambiguity in the "old" tag. This is different from "deprecate" the "old" tag ? Deprecating, in this case, would mean discouraging the use of the "old" tag, and a clear either automated or manual migration plan to the "new" one. Is it feasible even to define such a migration ? I think it could be helpfull to describe the new or expected situation and what the option, or feasible options, are in the future to get rid of the current ambiguity, make more clear what "obsoleted" really means in this context. Bert Araali (talk) 12:00, 2 April 2022 (UTC)

@Bert Araali: That is a fair and constructive critique. Thank you! I have added a section Proposed_features/ISCED_2011_Education_Programme#Migration that should answer/clarify these concerns.

Comments by the author of the proposal after voting started

Words instead of numbers?

  • At Talk:Proposed_features/ISCED_2011_Education_Programme#Don.E2.80.99t_use_numbers it was proposed and discussed to use words instead of numbers for specifying ISCED levels/programmes.
  • I chose to not include words in the proposal due to the following reasons:
    • The second digit of the ISCED programme number is certainly useful since it helps to differ two kinds of school systems with quite different goals (academic vs. vocational education track). Therefore, I did not want to exclude it: But then it would be unclear how to map it onto words. short_tertiary_vocational? And would we then need to skip the third digit? Unfortunately the discussion was not continued.
    • Data consumers and mappers who already work with ISCED will be familiar with the numbers but might have a harder time using words, since they are not defined by ISCED and would be arbitrarily defined by OSM people.
    • A system using words could still be added on top of the current proposal. I tried to write the proposal in a way that focuses on a minimal basis to which hopefully a 75% majority could agree and where further additions can be built on top.

—Preceding unsigned comment added by Skorbut (talkcontribs) 10:52, 18 April 2022 (UTC)

ISCED alternatives

Moved from the voting tally.

While I trust that some ambiguity is revolved, Internationally this is still at best one-sided and educations can't be compared this way and ambiguity is to be tolerated as it can't be avoided. --Kaartjesman (talk) 11:58, 10 April 2022 (UTC)

@Kaartjesman: What aspect of the proposal could be changed to make it acceptable? Do you know about any other system than ISCED that would provide better comparability? --Skorbut (talk) 19:15, 18 April 2022 (UTC)
@Skorbut: I find that using ISCED is creating several problems. First is that it is overly complicated for OSM. I understand the idea behind ISCED and for them that works, but OSM is different. It doesn't have to have the full depth of social interactions in the database, all that is needed is that it needs to be understandable by people that visit the place. Meaning that social implications are implied and don't have to be encoded. On the mailinglist someone pointed out that school=* and grades=* are going to cover a lot of the needs of tagging. Which makes much more sense as "grades 1-10" is universally applicable. Both for a school in the USA as well as one in Kenya. The simple conclusion is to not make it too complex (KISS) and focus on getting a simple system that will likely have much more reach and be much easier to apply without errors by people that may just want to simply tag their environment. —Preceding unsigned comment added by Kaartjesman (talkcontribs) 08:19, 19 April 2022 (UTC)
  1. Grades 10 to 11 and 12 to 13 don't work in differentiating viz GCSE and A-Levels for general education. (as for determining based on the country, a school can in fact offer both 3-year and 2+2-year upper secondary curriculum) They are not designed for vocational education either.
  2. Not everywhere uses Grade 7 to 12 directly. Many restart counting at secondary education, or even numbering middle and high schools separately. These need a conversion anyway, and many will inadvertently add their non-conformal local levels.
--- Kovposch (talk) 06:12, 20 April 2022 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── grades=* is merely an attribute of a school. Even if a school can be classified solely by its grade range in some systems, the grade range is not a classification system per se. On the other hand, school=* is a classification system. I suspect the combination of school=* and grades=* together could satisfy much of mappers' desire for expressiveness, renderers' need for a reliable icon selection heuristic, and geocoders' need for a straightforward conversion to user-friendly descriptions. school=* has developed very organically and probably deserves more discussion, at least to achieve more consistency within each educational system. Several orthogonal aspects have been crammed into that key in the past that should probably be broken out into subkeys.

We're tagging school facilities, not report cards or CVs. GCSE, A-Level, IB, etc. are orthogonal to the grade range and school classification; the UK still has numbered years such as Year Eleven. The possibility of grade numbers resetting also came up in this discussion last year. It would be helpful if a concrete example could be provided, but it doesn't seem like a dealbreaker as long as school=* is also tagged.

 – Minh Nguyễn 💬 02:32, 21 April 2022 (UTC)

Fyi I'm only giving arguments to why ISCED should (co-)exist.
Curriculum is still part of a school basic info and identity. It may also provide hints to school facilities. I'm not suggesting to record the school's entire profile as in a brochure, but people will want to search for specific schools, and know whether the school offers a local, international, or special programmes.
--- Kovposch (talk) 09:14, 21 April 2022 (UTC)
@Kovposch: I agree that it would be useful to tag the fact that a school offers certain programs, especially if that isn't the norm in its own educational system. (IB and special education are particularly notable in the U.S. because schools go as far as to advertise these programs in their names or on signs or flags.) I think it would be more straightforward to tag the names of the programs explicitly rather than going through this normalization step that data consumers will have to reverse-engineer anyways. An attribute like school:programme=* or Proposed features/Education 2.0/Programs would avoid the temptation to treat programs as classifications. Meanwhile, actual classification subkeys like school:FR=* are already in use but would benefit from more scrutiny. – Minh Nguyễn 💬 18:33, 21 April 2022 (UTC)
IBDP, what's commonly referred to as "IB", is only one of the levels they offer. Someone trying to tag this will still have to know or be provided this correct value, instead of treating IB as a "brand". Yes, I do agree with having a possibility to tag the actual programme name at the same time, with any tagging system we choose in the end. But then How do you show a school offers both the standard local curriculum and multiple other programmes (eg IBDP and IGCSE+IAL)? You will have anything from a long *:<some_programme_name>=yes, abbreviations (that a programme may not have) *:ABC=yes + *:*=yes etc, country-prefixed with the similar disadvantages *:FR:ABC=yes + etc, or long and unwieldy *=<programe_name_1;programme_name_2;programme_nam_3>.
But that's a another big problem, compared to for example classifying secondary schools up to form 3 or 5, integrated secondary schools ,and sixth form colleges; or distinguishing law schools and medical schools, from bachelor, taught master, and PhD institutions (oh and what do about research institutes providing PhD programmes...). This proposal does help as a comprehensive formal system, at least as a reference and for now. Even if someone thinks it's a bad attempt, or software will have difficulty interpreting it precisely. If it is considered to have no forseeable need for such tagging system (or it shouldn't be tagged directly for some reasons), the possibility of using ISCED is still left for someone wishing to record this info.
Vocational programmes are yet more complicated across countries, and special education is another wider topic.
school:programme=* you linked to are more subjects, or ISCED-fields so to speak.... School type is not necessary the same thing as programme type either. One school type can offer different programmes, and different ones can offer the same programme. --- Kovposch (talk) 21:09, 21 April 2022 (UTC)
@Kovposch: I'm still trying to understand if ISCED is really what mappers want to record at this level of detail, or if "ISCED" is just a proxy for what they actually want to record. If this were really about mapping a school's "menu" in great detail, then you're absolutely correct that ISCED is the most robust way to do it. But the majority of references to ISCED I've seen on the wiki, mailing lists, iD PRs, JOSM tickets, and JOSM presets suggest a popular misconception that it's the preferred method for classifying schools, a substitute for more straightforward tagging, which is misguided in my opinion and probably incompatible with the vision you've expressed. – Minh Nguyễn 💬 21:46, 21 April 2022 (UTC)
I won't say it's wrong to use ISCED as a "proxy" for now. Commendable over doing nothing. Is it that bad?
By "more straightforward tagging", should they apply grades=* 1 to 12 , and figure out school=* themselves? (Why does school:type=* exist anyway) --- Kovposch (talk) 22:10, 21 April 2022 (UTC)
@Kovposch: The alternative is not to do nothing. If there's a disconnect between what mappers think the tags mean and what they actually mean, especially when mediated by presets, I'm not sure anyone is well served versus a more idiosyncratic approach. I'm pretty confident that, left to their own devices, mappers will come up with reasonable values of school=* that reflect the actual distinctions they've been encoding in various wiki tables or presets until now. school:type=* predates operator:type=* and probably should be reconsidered. – Minh Nguyễn 💬 22:23, 21 April 2022 (UTC)
I mean eg there are already both school=primary and elementary=*. Do you choose one for primary education, or use both separately for 2-tier and 3-tier systems?
Maybe I talked too much about grades=* and school=*. If you think these are enough, ISCED may offer more improvement in amenity=college, than amenity=school.
--- Kovposch (talk) 04:26, 22 April 2022 (UTC)
@Kovposch: You're right that tagging offered programs probably adds more value for postsecondary educational POIs, which are more diverse even under the most rigidly standardized education systems. (Alas, this is the part of the ISCED standard that has been most fluid across its revisions.) Tagging offered programs is a niche form of micromapping that I'm pretty sure would be less interesting to most of the participants in this proposal process than school classification, like tagging a restaurant's individual menu items versus its overall cuisine. [1] If a followup proposal were to distance itself from school classification, then the stakes would be lower and there would probably be far less controversy. – Minh Nguyễn 💬 17:37, 22 April 2022 (UTC)
Additionally on grades=* counter restart: That problem is similar to level=* vs level:ref=*. One format is as if it's a single pre-defined hierarchy; the other is a freeform text record of what's used. Not mutually exclusive. --- Kovposch (talk) 09:23, 21 April 2022 (UTC)
@Kovposch: The level=*/level:ref=* physical-versus-signposted distinction exists because of an acute rendering and routing need for machine readability and consistency. Analysis use cases benefit from machine-readability and consistency, but they benefit even more from comprehensiveness. It just seems less likely to me that, in the long run, we'd be able to achieve better coverage of the ISCED values than of the raw attributes or local classifications from which ISCED values are derived. Anyhow, I'm still waiting for a concrete example of this counter-resetting behavior. – Minh Nguyễn 💬 18:33, 21 April 2022 (UTC)
Sorry, did the previous discussions you mentioned have any example I can explain to you more?
There could still be a need to show the "Year" equivalent of education.
--- Kovposch (talk) 20:25, 21 April 2022 (UTC)
@Kovposch: Unfortunately, I don't see any examples in those previous discussions either. In fact, there was even a mention of grades being counted backwards, which sounds like handwaving... – Minh Nguyễn 💬 21:05, 21 April 2022 (UTC)
The other two most common patterns:
  1. Commonwealth (other than Australia and Canada for example): Primary 1 to 6, Secondary/Form 1 to 6 (or 1 to 5, then 6 to 7; or maybe the latter pre-university years are entirely separated, not sure about Singapore for example)
  2. Taiwan, Japan, Korea, PRC China, maybe more: Middle school / junior secondary 1 to 3, high school / senior secondary 1 to 3 (they call it differently)
I don't know much about Europe and rest of the world, except for a question about school years starting in different months somewhere once. To be honest with you, I and many would have to do some mental calculation/conversion when we see grade 7 to 12.
Would you want to consider Kindergarten years too?... That might be what a negative or backward counting mean. --- Kovposch (talk) 21:22, 21 April 2022 (UTC)

@Kovposch: Thanks, that's helpful. It was my understanding that the continuous year numbering system was introduced to the Commonwealth countries some 20 or 30 years ago. It's unsurprising that the more idiosyncratic traditional system ("Upper Sixth"?) is still used in some places, but at least your examples suggest pretty obvious school=* values to disambiguate, so I don't see a problem with the renumbering at all. If some of these years can be combined under a single roof, creating a numbering conflict, maybe the grades=* values can have some common-sense prefix, similar to how Americans conventionally distinguish the various kinds of Kindergarten with non-numeric grade letters.

I wonder if the idea about negative/backward counting came from this fanciful proposal that, taken to its logical conclusion, would've numbered education levels all the way to conception. :-D

 – Minh Nguyễn 💬 22:09, 21 April 2022 (UTC)

Specialized schools

Moved from the voting tally.

(Following the trend to discuss here instead). So, back in the Voting section, I've identified a granja escuela, a "farming school" (in a Spanish-speaking country). Imagine at least four different kinds of students: the late-teenager who knows she'll inheret the family farm, so in addition to her "high school" (secondary) academic studies, she decides to learn all the skills of animal husbandry (etc.) that this place has to offer, the semi-literate middle-aged migrant farmworker who needs to learn about pesticides and how to better read their complex labels to properly apply them, but he has a long stretch to learn all that, yet the school is equipped to teach him, the young man who is getting his bachelor's degree, but for the summer/off-academic season, decides to study here to see if a career in agriculture could help his studies and future, and a professor of biology with an academic doctorate degree, but because some of her ongoing research takes her to places where she really could use some training that places her "back on a farm," it makes pedagogical sense for her to study here. What number for Category do we apply here? Respectively, you might say 35, 25, 45/55/65, 84/85/86, or even simply 9. And the answer is "all of the above." This sort of artificial, numerical categorization is like being asked to put on a straitjacket for no good reason. Stevea (talk) 02:10, 22 April 2022 (UTC)

Without more information I can't answer. Is it part of the education ladder, or a separate specialist skill school?
You assert a false dichotomy. The answer is "yes." It is both of those. For some, it is part of their "education ladder." For some, it is part of their "specialist skill" school. YOU do not get to determine this, the SCHOOL does not get to determine this (though, true, it can choose to admit or not admit any given student), the STUDENT, their CIRCUMSTANCES and their EXISTING educational attainment levels partly determine this. You may not simply "assign" this, it is way, way more complex than that. Not every school is like this, but enough are such that this paradigm of "one category fits all" deeply breaks down. Stevea (talk) 04:53, 22 April 2022 (UTC)
Acknowledging the complexity in our education life and local education sector doesn't mean we have to abandon all attempts at representing the education institutions. The question of how to apply ISCED to these cases is also open for discussion.
If I have to summarize, it is decided in part based on the minimum entry requirement, and partly on the content. It is likely level 2 or 3. Your student examples for undergraduate and postgrad aren't decisive here.
Huh? You simply "dismiss" these as if they aren't realisitic? That's pretty disingenuous. I paint a realistic picture of how wide the spectra are in an example school and (because of the difficulty of answering?) you simply dismiss this? Hm. Stevea (talk) 05:18, 22 April 2022 (UTC)
Sorry, how does "minimum entry requirement" and "not decisive" translate to how you are describing my reply? Kovposch (talk) 15:24, 22 April 2022 (UTC)
For more detailed examples I read the ISCED Operational Manual more, They are grouped into typical patterns. http://uis.unesco.org/sites/default/files/documents/isced-2011-operational-manual-guidelines-for-classifying-national-education-programmes-and-related-qualifications-2015-en_1.pdf --- Kovposch (talk) 05:04, 22 April 2022 (UTC)
OK, what about the atypical examples? How does this proposal address those? And why should I read what the United Nations has to say about this for OSM? Right now, I can tag amenity=farming_school and be done with this, without this Proposal. That seems OK to me. Stevea (talk) 05:09, 22 April 2022 (UTC)
This proposal offers a possible method that's as widely applicable as possible around the world, in order to make a solution. It doesn't claim to be immediately prescriptive with answers for all cases. To start, we can look at the country's existing mapping (http://uis.unesco.org/en/isced-mappings), and compare the example in question to them.
Not everyone is asked to read these. They are materials users could consult while discussing a problem.
This proposal is about level, not fields. So yes you can tag it as some education feature, without caring what it is exactly. It's trying to show where something is positioned as a amenity=school, amenity=college, or perhaps any amenity=*_school if that is to be adopted. Kovposch (talk) 15:45, 22 April 2022 (UTC)
Is this about ISCED alone, or rather the potential shortcoming for classifying into primary, secondary, and tertiary education in general? The latter will be an issue in any other tagging system. --- Kovposch (talk) 04:33, 22 April 2022 (UTC)

I have no idea how it applies to the vocational side though. How would you show a combined elementary, middle, or high school then? --- Kovposch (talk) 04:21, 22 April 2022 (UTC)

Who are you (or who is the United Nations?) to say whether education received at a "farming school" is academic or vocational? Such brash categorizations are futile. That's why this sort of (numerical) categorization won't work / doesn't work. Stevea (talk) 05:50, 22 April 2022 (UTC)
Ok do you have anything to say about categorization into primary, secondary, and tertiary education too? There are 56 school=vocational, 49 education:type=vocational, 15 vocational=* instances. Some users have found this distinction to be part of their solution. Do you also consider academic vs professional to be an issue in tertiary education? The failed proposal Proposed features/Education 2.0 contained both education_profile:general=* and education_profile:professional=*. They were at least worth considering. --- Kovposch (talk) 15:33, 22 April 2022 (UTC)

Not verifiable on the ground

As mentioned in a comment during the voting: The use of ISCED codes is generally not verifiable on the ground. Schools don't publish an ISCED code. Rather, mappers will have to interpret the descriptions and make a guess That's why we instead need clearly defined tags which are easy to understand, with a clear match to the local category of school in each country. For the next version of a proposal to categorize types of education, please publish a table that shows how each type of school and university would be tagged in different countries. --Jeisenbe (talk) 01:11, 24 April 2022 (UTC)

Amplifying what Jeisenbe says above and in an additional section here in the Talk page, I am happy to add amenity=kindergarten to a node or closed-way polygon, especially if I KNOW that's what the institution is, or it says so on the sign outside ("on-the-ground verifiable"). However, as I see a mixed middle-school/high-school (or one, or the other, and in my country, we have both), there is or very easily may be some "guesswork" involved on what ISCED code might be used to denote this. I don't tag those, as I don't believe in adding "guesswork" to OSM. Other OSM Contributors? Well, I suppose they can, I don't have to agree that's a good way to add these sorts of data to OSM (actually, I do NOT believe this, I would prefer amenity=middle_school or amenity=high_school). No, I prefer both to enter what I know (only) and let other downstream users (renderers, etc.) figure out what to do with the value of a key. After all, OSM is simply data that is verified by the person who enters it, not guesswork that is intended to harmonize with an international standard. If it can or does, well, maybe I can be convinced. But, this Proposal certainly isn't that. Stevea (talk) 01:19, 24 April 2022 (UTC)