Provide consistent compatability guidance for signals

Author: thompson-tomo

docs/general/events.md

@@ -36,7 +36,7 @@ the event.
 
 <!-- Body use cases are not clear - see https://github.com/open-telemetry/semantic-conventions/issues/1651 for the context.-->
 
-## External event compatibility
+## Compatibility
 
 When recording events from an existing system as OpenTelemetry Events, the system
 may lack a single name field or require multiple fields to identify the event.

docs/general/profiles.md

@@ -58,7 +58,9 @@ They may be used in any Profiles record they apply to.
 <!-- END AUTOGENERATED TEXT -->
 <!-- endsemconv -->
 
-## Compatibility with pprof
+## Compatibility 
+
+### Pprof
 
 Existing [pprof][pprofLink] formats can be unambiguously mapped to this data
 model. Reverse mapping from this data model is also possible to the extent that

docs/general/trace-compatibility.md

@@ -1,6 +1,6 @@
 <!--- Hugo front matter used to generate the website version of this page:
 linkTitle: Trace
-aliases: [trace-general]
+aliases: [trace-general, trace-compatibility]
 --->
 
 # Trace semantic conventions
@@ -21,7 +21,6 @@ can still be easily correlated and cross-analyzed.
 The following semantic conventions for spans are defined:
 
 * **[General](attributes.md): General semantic attributes that may be used in describing different kinds of operations.**
-* [Compatibility](trace-compatibility.md): For spans generated by compatibility components, e.g. OpenTracing Shim layer.
 * [CloudEvents](/docs/cloudevents/README.md): Semantic Conventions for the CloudEvents spans.
 * [Cloud Providers](/docs/cloud-providers/README.md): Semantic Conventions for cloud providers spans.
 * [Database](/docs/database/database-spans.md): For SQL and NoSQL client call spans.
@@ -36,4 +35,43 @@ Apart from semantic conventions for traces, [metrics](metrics.md), [logs](logs.m
 OpenTelemetry also defines the concept of overarching [Resources](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.49.0/specification/resource/sdk.md) with their own
 [Resource Semantic Conventions](/docs/resource/README.md).
 
+## Compatibility
+
+This section defines trace semantic conventions used by the
+compatibility components, e.g. OpenTracing Shim layer.
+
+### OpenTracing
+
+`Link`s created by the OpenTracing Shim MUST set `opentracing.ref_type`
+with one of the accepted values, describing the direct causal relationships
+between a child Span and a parent Span, as defined by
+[OpenTracing](https://github.com/opentracing/specification/blob/master/specification.md).
+
+<!-- semconv opentracing -->
+<!-- NOTE: THIS TEXT IS AUTOGENERATED. DO NOT EDIT BY HAND. -->
+<!-- see templates/registry/markdown/snippet.md.j2 -->
+<!-- prettier-ignore-start -->
+<!-- markdownlint-capture -->
+<!-- markdownlint-disable -->
+
+| Attribute  | Type | Description  | Examples  | [Requirement Level](https://opentelemetry.io/docs/specs/semconv/general/attribute-requirement-level/) | Stability |
+|---|---|---|---|---|---|
+| [`opentracing.ref_type`](/docs/registry/attributes/opentracing.md) | string | Parent-child Reference type [1] | `child_of`; `follows_from` | `Recommended` | ![Development](https://img.shields.io/badge/-development-blue) |
+
+**[1] `opentracing.ref_type`:** The causal relationship between a child Span and a parent Span.
+
+---
+
+`opentracing.ref_type` has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.
+
+| Value  | Description | Stability |
+|---|---|---|
+| `child_of` | The parent Span depends on the child Span in some capacity | ![Development](https://img.shields.io/badge/-development-blue) |
+| `follows_from` | The parent Span doesn't depend in any way on the result of the child Span | ![Development](https://img.shields.io/badge/-development-blue) |
+
+<!-- markdownlint-restore -->
+<!-- prettier-ignore-end -->
+<!-- END AUTOGENERATED TEXT -->
+<!-- endsemconv -->
+
 [DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status