Add guidance on abbreviation usage in semantic attribute names

[trask]

ECS has https://www.elastic.co/guide/en/ecs/8.9/ecs-guidelines.html#_guidelines_for_field_names

Avoid abbreviations when possible

• Exceptions can be made, when the name used for the concept is too strongly in favor of the abbreviation. Example: ip fields, or field sets such as os, geo.

It would be good to document some (same or different) guidance for OpenTelemetry semantic conventions to help with:

• Remove abbreviation of kubernetes in resource semantic conventions #58
• Add enduser.anon_id to general attributes #443 (comment)
• db.* vs database.*
• hw.* vs hardware.*

(and probably others, these are just ones on top of mind)

[jcocchi]

+1 for documentation and guidance on abbreviations, but I'm in favor of using common abbreviations where reasonable to reduce overhead

db is a prefix for most database semantic conventions, and I don't think using database instead adds value

[trask]

I'm unlinking this from the Database semconv project board as I think db is a common enough abbreviation to justify using it.

Some examples:

• CosmosDB
• MongoDB
• CouchDB
• DynamoDB
• DB2
• https://en.wikipedia.org/wiki/List_of_computing_and_IT_abbreviations

[trisch-me]

@trask should we proceed on this guidance?
I have a case with hw versus hardware
I would in this case vote for using hardware.