Provide guidance when there is conflict with ECS conventions

[mx-psi]

When adopting ECS conventions following open-telemetry/oteps/pull/222, there are certain cases where ECS conventions could be improved in some way. For example a given ECS convention may suffer from any of the following problems:

1. It may not follow existing OTel semantic conventions guidelines (e.g. plural vs singular guidelines).
2. Its namespacing is too lax for the usual OTel standards (e.g. maybe the convention name could be a namespace instead).
3. It could be too general and more specific conventions would be needed to allow for certain use-cases.
4. There could be overlap with existing OTel conventions

Three specific cases where this issues arise are as follows:

• On Add kernel related semantic conventions #66 I proposed adopting semantic conventions related to kernels. ECS already has os.kernel but this could be a namespace, it has a full uname output that would need to be manually parsed
• On Resource attributes for network addresses of a host #131 both host.ip and host.mac don't follow the usual plural guidelines and IP could be a namespace for IP protocol related conventions.
• On Add more ECS url fields #181, url.domain overlaps with server.address significantly

I would like to have a document with specific guidance as to what to do when we have these conflicting requirements between compatibility with ECS and existing guidelines/good practices. Some questions I would like to have answered in the document are:

1. Should ECS conventions be amended to follow plural guidelines?
2. Can an ECS convention be used as namespace? If not, what should be done? (e.g., should the kernel version be os.kernel_version to avoid namespacing?)
3. Are redundancy or possible better names valid arguments when considering if renaming an ECS convention?

This relates to #181 (comment)

cc @AlexanderWert

[ChrsMark]

Thanks for filing this @mx-psi !

Regarding the plural VS singular guideline I guess we can revisit this?

To my mind it's not as helpful as it should be. For example when we cannot choose host.ip because of this but we need to go for sth like host.ip_addresses then I see this as a non practical "rule".

Another example is host.mac which is relevant to the original discussion.

In general it makes sense to have this pluralisation guideline but in some cases like in the above abbreviations it does not: ips, macs ?

Thinking the equivalent of defining a Web API: Would we go for sample_api/ip/4 or sample_api/ip_addresses/4?
I would choose the first one which is simpler/cleaner and widely understandable.

To my mind the ip_addresses/mac_addresses is an overkill when we can just go for the well known ip/mac and rely on the type which would be an array :).

[mx-psi]

PTAL at #333. I want to make this a bit more general than the plural guidelines but we can also discuss this on a separate PR