I would avoid any attempt to see a parallel between specialisms (marine law, patent law etc) in law and specialties/specialities in medicine. I think it would be better to use a different word in the key.
In the former case these are built up through practice and one lawyer or law firm may practice in multiple areas of law. In the latter case there are usually training programmes lasting from 10-15 years before someone is fully qualified in a single specialty. Specialty in medicine is usually easily determined by examining a doctor’s position, their registration and possibly their qualifications (in UK & Ireland they may belong to different Royal Colleges). None of these pretty objective factors are likely to be true for lawyers and legal practices.
In some countries training for General Practice may also be associated with training for Paediatrics (my cousin’s sister-in-law is so qualified in Poland), but this is probably an integrated programme leading to a dual qualification (and may be better treated as a single specialty, e.g. general_practice_with_paediatrics). In fact this seems to be regarded as primary care paediatrics, which may also make a suitable tag value.
But in many times a lawyer in Germany doesn’t has/need a formal additional qualification (beside his degree) and just list his fields in law, where he has experience.
For special applications and for performance reasons, you are right, but these always require other type of data preprocessing too. For general e.g. relational databases, a single column for the key (as afaik in the OSM database) are enough.
In the US, a lawyer has to get a degree and pass a state level examination. Neither has any effect on thier final choice of speciality(s). My understanding is that speciality is more based on a combination of job training as a para-legal and particular courses chosen while pursuing the degree.
Using name spaced boolean values requires either a mechanism that can search on key values (with some kind of regexp mechanism), or an application needs to be able to enumerate all possible keys. Naturally the later is typically not possible so you will miss values.
Compare that to a single key that has multiple values in list format. That will work even for values that are unknown to the application and doesn’t require any special handling of keys.
Not to mention all the other problems of using names / proper nouns in keys which in general ends in a gigantic mess (see payment and other similarly broken schemes).
Thanks @Discostu36 & @fabi2: the wikipedia article is informative. As @Fabi2 says only about a quarter of German lawyers have a specialism (I’m deliberately avoiding specialty here). Qualification seems largely to be by approval by a panel of peers, rather than through a rigorous training system with several stages of examinations.
There appears to be something a bit similar in the UK, via some kind of non-homologated study & examination (i.e., not regulated by law as in DE).
I’m sure there are many other services and crafts where it might be useful to distinguish those with particular skill sets, in which case I think a more generic tag could suffice.
I saw no end user application that uses or displays tags in raw format, as they are most times not descriptive enough for end users. So you also have to know for what you are looking. If you have an index on the key column, this can be quite efficient. What an index on the value will not help you in any kind, as you always must search for your multi-values in the value.
Your application will so always miss possible values, if it is not a QA- or maintenance application, which display all (additional) object keys based on some other found known tags. Also for objects that have many multiple values, such as the specialties of a large hospital, you will almost hit the 255 char limit, I already reached it with some opening_hours and even for a Facebook url, where the facility came on the idea to use Unicode which are the url-encoded to five chars/char to make the url look nicer.
Usually it is preferred to have as little deviation from the English version as possible. So if that content was added parallel to the English version, it would be sensible to remove it in the same manner (I did not check version history though as I am quite busy currently).
