[Tagging] better classification systems

[Minh Nguyen]

Vào lúc 23:57 2021-02-11, Mateusz Konieczny via Tagging đã viết:
> 
> 
> 
> Feb 12, 2021, 08:47 by 
> tomasstraupis at gmail.com:
> 
>     2021-02-12, pn, 09:24 Mateusz Konieczny via Tagging rašė:
> 
>         Is anyone familiar with some classification system actually
>         better than OSM tagging,
>         used to classify things mapped in OSM (or some subset of that)
>         for use by people without specialized training?
> 
> 
>     Yes.
> 
> Can you give a specific example of actually existing system?
> 
> "well designed system of classification that covers everything
> in field, deals well with new appearing objects, works worldwide,
> is not confusing and is easy to use" sounds relatively simple
> until someone start to actually create one.
> 
> I suspect that "plan properly from the beginning" is not sufficient.
> 
> So I am curious is there any success story in the field.
> 
>     1. You have codes instead of words for key=values.
> 
> It seems to fail due to "requires specialized training to use it" part
> (or description/name would be tightly coupled to codes,
> that would just add extra step for additional complexity without
> any benefit)

There are any number of codelike ontologies that require dictionary 
lookups. These systems are optimized for data consumers at the expense 
of data entry, but a smart UI can streamline the lookup step during data 
entry.

NAICS one of several multinational classification systems for 
businesses. A typical NAICS code looks like 333995 for "Fluid Power 
Cylinder and Actuator Manufacturing" and 484122. (Imagine the debates on 
this list about what to call *that* tag!) If I'm importing POIs from 
government licensing data or benchmarking OSM's coverage, I would need 
to implement a step that translates these codes to tags, possibly based 
on a table similar to [1].

Some commercial map and search APIs also express POI categories 
primarily as numeric codes. For example, TomTom's POI categories look 
like 7320002 [2][3], HERE's look like "300-3000-0023" [4], and Factual's 
look like 287 [5].

If it's considered specialized training for a map designer to look up 
these values when implementing a set of POI icons, then imagine the 
specialized training required to understand OSM tags! Even those of us 
who've been around OSM for a long time can be left stratching our heads 
at something written on the wiki. Just the other day I accidentally 
stumbled upon another way to tag a financial advisor that has been 
documented for years. [6] No lookup table could tell me about it.

It's one thing to create a system of numeric codes but another to 
arrange those codes in a predictable, hierarchical system. The 
classification schemes above are all versioned so that they can evolve 
with industry trends, a much more predictable process than deprecating 
and replacing tags in OSM. By contrast, Wikidata is an example of a 
numeric but unplanned system. Creating or merging a QID doesn't impact 
the rest of the numbering scheme. On the other hand, you need a lookup 
step to know not only a QID's name but also its relationship to other QIDs.

As it happens, Wikidata is the rare classification system whose keys 
(properties) are also numbered arbitrarily. But unlike items, properties 
can only be created by a select few people based on a formal approval 
process, because poor property design can adversely affect a large part 
of the system. Wikidata might have a property for many social media 
sites, but it wouldn't have a property for every website that gives 
users usernames, because that free-for-all would be unusable.

I think this lesson also applies to OSM: a scheme like 
post_partner:<brand>:services=* or payment:<brand>=* can be problematic. 
[7] Mappers have to be circumspect about the brand IDs they introduce, 
while data consumers have to parse the keys instead of just reusing them 
as database columns or GeoJSON properties.

[1] https://wiki.openstreetmap.org/wiki/NAICS/2017
[2] 
https://developer.tomtom.com/search-api/search-api-documentation-poi-categories/poi-categories#response-data
[3] 
https://developer.tomtom.com/map-display-api/map-display-api-documentation/content#point_of_interest_basic-categories
[4] 
https://developer.here.com/documentation/geocoding-search-api/dev_guide/topics-api/code-discover-place.html#search-a-place-by-its-name
[5] https://developer.factual.com/docs/places-categories
[6] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfinancial_advice
[7] 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/shop_as_post-partner#Avoid_arbitrary_keys

-- 
minh at nguyen.cincinnati.oh.us