Proposal talk:Certification

From OpenStreetMap Wiki
Jump to navigation Jump to search

certification:source=* vs. accredited=*

key *:source=* is already in common use in the wiki and across OSM. When we first started discussing this, I took accredited=* to mean the same as certification:source=*. Is there a scenario where a POI would have a certification without an accreditation? For the tagging examples, I can see an alternative being: 

certification=amtb
certificaiton:source=kasa

certification=kosher
certificaiton:source=ou

Kosher especially already has in it's wiki page that it " indicates that the food sold has Kosher certificate." So there may be a possible duplication. In addition, diet:kosher:certification=* is listed under possible synonyms.

-- GA Kevin (talk) 16:08, 30 January 2025 (UTC)

source=* is used for the data source, how you come to know that info. It can be from other websites, organizations, and databases, besides the source=* in changesets. It's not the same as who certified it, except when you obtained the list from the certifying organization directly. Confusion will arise when someone adds source:certification=*
—— Kovposch (talk) 18:43, 30 January 2025 (UTC)
Kovposch I agree that the :source carries to much OSM meaning for supporting contributed details. I do see there these has been some minimal use of the :certification namespace namely diet:kosher:certification=*, but I don't believe taking :certification onto everything related to certification is the correct approach either. Additionally, as it was brought up in Slack threads :operator is common but it likewise carries it's own inferences and confusion as a certifier doesn't operate anything in context of businesses or trails ratings for instance. My present consideration is to replace the accredited=* with certification:certifier=* while I have looked at others I'm leaning towards the sometimes the similest/clearest option is the best. I had someone else point out to me that maybe having tiered tagging might be better than trying to address everything via :namespaces. They used the example highway=path + path=sidewalk as an example based on this pattern they suggested that for existing tags that could be certification extensible like diet:kosher=* rather than doing diet:kosher:certification=* instead consider doing certification=diet:kosher then for the existing tags of diet:kosher:certification=* tags which largely list the name of the certifier those could be migrated to be something like certification:certifier=Chicago Rabbinical Council with only 29 tags this is hardly a established enough standard that some porting would hurt. This also can consolidate additonal tags like diet:kosher:dairy=yes/no (also non-english chalav_yisrael milk tag as well) and diet:kosher:meat=yes/no (Note: I'll reach out to top contributors to get feedback.) Thus the above example could look a little like the below. JPinAR (talk) 22:55, 30 January 2025 (UTC)
diet:kosher=yes
certification=diet:kosher
certificaiton:certified=Chicago Rabbinical Council
certification:rating=kosher;meat;fish
certification:certifier=* looks verbose to me, so I didn't love it much. It should simply be certifier=* if wanted. While a direct *:operator=* is awkward, *:certification:operator=* would be fine. Mainly, it's better to avoid inventing certifier=* that has a similar meaning to *:operator=* for the entity managing something.
certification=* doesn't work when there are multiple certifications, or multiple certifiers. The certification:rating=* can't work in those cases.
—— Kovposch (talk) 09:30, 31 January 2025 (UTC)

Should the type of certification and rating be distinct?

I'm submitting this one myself based on input from Slack OSM.US which has pointed out for many things that while sometimes just listing what party has certified is sufficient. Many certifiers have rating systems complex and tiered rating systems for instance U.S. Green Building Council's LEED certification consists of:

  • A Rating System: Building Design & Construction (BD+C) is different from Operations + Maintenance (O+M)
  • Optional 'adaptations' like New Construction, Core & Sheel, and Data Centers
  • Rating Versions which used to be years like v2009 but have switched to versions v4.1 or v 5
  • Then based on these you get your actual Platinum, Gold, Silver, etc. rating.

This is the 'worst case' scenario I've seen brought up but the main take away from this discussion is that just accredited=* ended up getting overloaded. US:GBC_LEED_v5_Platinum is a real possibibility and it could be longer. Thus, the call out was that perhaps the certifier and their rating should be separated. Thus I'm looking at the potential for certification:rating=* as an additional tagging namespace off of certification. Based on the above section this would mean the new tagging could look like this: 

certification=sustainably_built
certificaiton:certified=US:Green_Building_Council
certification:rating=LEED_v5_Platinum
LEED is only one standard. There's BREEAM. certification=sustainably_built + certification:rating=* seems to suggest there's only one possible system.
Although fhrs:rating=* was stopped, it was for other reasons. The format is fine, so I don't see the necessity for certification:rating=* to specify the *:rating=* is for the certification=* at this moment.
Underscores don't make a data format. It's only a replacement for whitespaced words. Mixing underscores and uppercase is even worse.
I have already explained why colons are a false sense of hierarchy. In your example, it's arbitrary to not use US-IL:Chicago:Chicago_Rabbinical_Council=* , as done in network=* for roads mostly consistently.
—— Kovposch (talk) 10:03, 31 January 2025 (UTC)

Food

—— Kovposch (talk) 10:03, 31 January 2025 (UTC)

Environment

A
—— Kovposch (talk) 10:03, 31 January 2025 (UTC)

Businesses

It's redundant to specify what it's on for on the feature, unless there are multiple professions. office=accountant and office=lawyer already means the same.
FRC regulates audit work standards, not auditor license. ACCA is an organization, not the title, which should be "chartered" as "Chartered Certified Accountants". But there can be confusion between the legal status, and the member level. https://www.gov.uk/find-licences/become-a-registered-auditor
The states where a lawyer is allowed to practice aren't really a "rating" class. In other countries, there may be actual different titles to obtain. Aren't lawyers licensed by the state bar associations?
But the biggest problem here is how these are the staff being certified, not the company. Companies can get their own licences. An audit company is a "registered"/"statutory" auditor, with 2 different requirements of registration in an association as a firm, and having staff as qualified auditors. In engineering and construction, contractor licensing is not the same as PE licensing.
—— Kovposch (talk) 10:03, 31 January 2025 (UTC)

Kovposch Wow, a lot of good feedback and thoughts I'm going to need to perhaps address them topically because there is a mix of things here, all good things though:
  1. National/Local for certifier - I was looking at Key:cycle_network and maybe it need to be cleaned up or merged with Key:network, not part of this proposal, which as you call out is more consistent in this prefix which is organized where the ISO 3166-1 (Country) and ISO 3166-2 (Sub-country divisions) can be prefixed as namespaces as a means to indication national and sub-national alignment with International Organizations just simply not being prefixed. I find this cleaner and more concise for indicating not just that something is national or sub-national but what nation and what sub-national alignment there is. I do think the call out here that I will take some action upon is two fold:
  • I'll add a section explain the country, sub-country prefix namespace conventions as part of a deeper dive on the certification:certifier=* convention. You do also make a good point for the consistency on keeping things lower case and tagged to be consistent with ISO 3601-1 & -2. (Pardon my propensity for upper-case my career is in B2B standards developed back when mainframes ruled and everything is default upper not lower so OSM convention and my day job are at odds.)
  • You also make good points about when to abbreviate and when not to abbreviate for certifier convention, I think for international/national that have reached 'de facto' industry wide acceptance then abbreviation is fine, so long at within the certification category there isn't room for confusion withing the same space (international or national namespace). For sub-country I would say governmental groups are still safe but independent groups may need to use free form, and for local group free form is pretty much necessary.
  1. I like the suggestion to split certification name from certification rating, however LEED as a rating is a bit of an outlier and more exception that rule for tiered/versioned rating systems. I'm thinking of holding off and just combining these for now and if future demand warrants the 'version' namespace it can always be added at a later point. (I also think most people will just exclude the version building type and only put their Platinum, Gold, Silver as that is what they mostly care about.) I get that you are aiming to split things out to eliminate all possible underscores. I only worry that by the time we split hair over versioning of a rating we've reached the 'perfect being the enemy of "good enough"' threshold. Trust me being in B2B standards my historic tendency is the same as yours to micro categorize everything but at this point the LEED rating system is making a choice to go into a lot of nuance that I ultimately see being left out for most tagging situations.
  2. '(Example) seems to suggest there's only one possible system' - then I need to work on more explanation and maybe competing examples the whole reason I separated the type from the certifier is so that searching can be done agnostic of certifier. If I want to find everything Kosher certified and don't care who certifier them only that they are certified I should be able to search certification=diet:kosher and ignore the others, same with certification=sustainably_built.
  3. With respect to having certification be it's own tag vs. slap it as a namespace onto anything and everything I think the it's own tag prevent Over Namespacing (see Namespace#Over-namespacing ). Thus why I'm willing as part of this tagging proposal to contact primary contributors to existing tagging and help bring existing tags to be consistent with this Tagging convention.
  4. 'agroecology:certification' to be blunt I'm not going to design around two instances of one tag with key values one of while is just the first instance misspelled. As far as I'm concerned this tag does not exist and I will not consider it for future design.
  5. Thanks for the clarity on UK Auditing I'll remove as example. Also, you are correct that Lawyers in US are typically only licensed by state bars, but there is one federal governing 'American Bar Association' hence... us:aba that quasi-governs the state bars and handles federal and interstate law practice issues. I'll add on as a bonus that there is a separate Federal District admittance distinct from state bars as if that's not confusing enough. So perhaps certification:certifier=us-ia:bar association;district8 without a rating would be more appropriate, I'll change that.
  6. As for the 'redundancy' of certain certifications I agree that sometimes the certification is redundant and not needed. However, this is not always the case to give two scenarios:
    1. For adaptive trails there is a rating for 'how much ride support is needed?' that gives people a 'gist' for can I ride and do I have the support I need. Adding a trail designed for adaptive certification doesn't replicate the assistance rating it support that the rating is likely more reliable.
    2. Next 'financial_advice' or just 'financial' sound like they mean a lot but in the U.S. there is no regulation around that title and I could slap 'Financial Advisor' on a business card with no real fear of anyone coming to crack down on me, even if I charge fees for my services which is pretty interchangeable with the word advice as it carries the same weight. In contrast some financial advisors are Certified Financial Fiduciaries (CFF) and can legally only give client financial advice in the clients best interest. This isn't common knowledge in the U.S. but I'll pay for a fiduciary but not a "Financial Advisor". This is the best example of title and even office type being almost nothing alike based simply on a certification.
    3. To summarize this point 'redundancy' is that I'm less worried about redundancy especially as that tends to just mean this won't be used as much there as I am are there scenarios where a distinction between title and certification matter and there are a LOT of situations where it really does matter.

JPinAR (talk) 20:46, 31 January 2025 (UTC)

0. It's not only the implementation detail on formatting. There's no need for country prefixes at all. It prevents people from directly entering the certifying organizations. If needed, *:wikidata=* should be used to distinguish them.
2. This is still mixing different certificates in certification=* together. You can't group different categories easily and predictably, for analysis and applications.
3. Over-namespacing doesn't mean no namespacing, or deciding from length. It's based on need. certification=* could refer to the feature itself inherently, eg what licence a amenity=fast_food affecting whether it's take-away only, or permission to accept outside customers. Furthermore, there are other multiple certificates. Besides diet:*=* , amenity=cafe could have fair_trade=* and organic=* , and your *=blv (which also can't be understood directly from this abbreviation). Don't forget there can be multiple applicable diet:*=* as well, eg diet:gluten_free=* . Semicolon doesn't work, as there can be multiple ratings for each certificate. Having diet:*:certification=* + fair_trade:certification=* + organic:certification=* etc separates them properly and correct for both human and machine readability.
4. Whether you like it or not, it has been voted. I can't changed it either. Proposals need to consider the effect on them.
5,6. The crucial difference you are mixing up is certifying staff vs company. These are basically akin to a practitioners:certification=* . As it stands, licensing of a contractor and its engineers would be bunched together.
—— Kovposch (talk) 11:20, 3 February 2025 (UTC)


Responses to feedback from Kovposch (talk)
0. First, good suggestion on *:wikidata=* I'll include this. Next, I see your point but with so many certifying organizations being abbreviated in contexts that only mean something withing a national or sub-nations context I still think this is a value(s) that needs to still be kept but maybe split out. What would your thought be on a *:ISO3166-1=* and *:ISO3166-2=* route?
2. I think your point on the semi-colon not being practical when there are multiple certifications is a good one so I do thing that your take on the namespace expansion work and your don't look the ability to search for all within a classification. So I'll switch to *:certification=* and derivatives. The way you phrased it this time around made more sense, thanks.
3. I'll switch to blindlowvision for examples (I know this isn't a tag that exists at the moment and sensory is in voting I'll notate this as a potential future use for the purposes of demonstration of present and/or future application
4. When I was looking at agroecology:certification on TagInfo and didn't see a wiki like (I see now that there is one under the key not the namespace and I'll be honest I assumed that this was but something out found searching for 'certification' that someone just put in and wasn't a recognized tag. I'd simply say that I'd switch the two tags and page if implemented to agroecology:certification=participatory and then I might have the main keys be *:certification=yes/no/participatory/third_party instead.
5,6. practitioners=* speaks to an 'all' or 'specificity' which I think is how you are viewing this. I see *:certification=* not as answering the 'all' or 'specific' question, but the 'some' or at least 'someone' question for a business. This is a different question if 'someone' at business is a CPA that as a customer is really all I care about the entire staff doesn't have to be. If someone at a law firm can represent by case in a specific jurisdiction I don't care as a customer that all the staff needs to be. I'm going to give two more real world examples below. The key here is that this is NOT trying to answer 'all' or 'specifics' the way practitioners=* is this is only for a business answering the consumer question of 'can someone at this business do X?'
  • Real world application demonstrating the 'some' vs. 'all' or 'specific' distinction:
    • My sister is a dental hygienist she previously worked for an independent private practice dentist (a 'some' of one or more) who decided that he wanted to reenter military service as a dentist but this meant he'd have to close his practice. This would bring my sister's job to a halt because she in only allowed to practice under 'some' dentist and that would result in 'none'. Luckily he looked out for that staff and found a dental group that was willing to take over his practice and now my sister works at a business with multiple dentist (a 'some' of one or more). Thus, for purposes of certification the 'some' is the important part.
    • As a FAA licensed drone pilot I will at time employ individuals without FAA licenses to be 'Visual Observers' this is required if I'm operating using a headset. My customers however don't care about the FAA licensing of my visual observer, because they don't have to be licensed for me to do my job commercially. I however need them to be legal. To the customer they don't care that 'all' are licensed only that 'someone' is available that is licensed for commercial operation.
—— JPinAR (talk) 17:38, 3 February 2025 (UTC)
I'm coming back to add a note after trying to apply the splitting between certification:certifier=* and *:ISO3166-1=* and/or *:ISO3166-2=* and I realized that I'm not running into the unable to have multiples issues that you pointed out as to why certification needs to be a namespace tag, because places can hold multiple certifications. The issue is when applying this to legal where you have completed the bar in multiples states and or districts that by separating the country/sub-country prefix namespace to be independent tags that you can't list multiple certifiers from different country/sub-country combinations as the bar association in different states is distinct and there are not technically ratings so moving these there also doesn't make sense. Just thought I'd mention the different complication that this added. Still open to ideas on alternate routes. Till something better comes along I've paused updates for this specific scenario.
JPinAR (talk) 04:19, 4 February 2025 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Certification&oldid=2808426"