Make it easier to keep semantics of object-oriented models

In object-oriented programmes the meaning of a property name of a class Employee is bound to a class. An Employee_name is not the same as a Company_name (a name property bound to a class Company). In this respect every OOP type is closer to a separate context (and may even have its own vocabulary).

In contrast, JSON-LD by default, uses a purely term-based mapping of properties onto IRIs (or IRIs onto properties) where a term is assumed to mean the same everywhere. To illustrate this, consider the following example:

{
  "@context": {
    "@vocab": "https://data.my.org/vocab/#"
  },
  "@id": "123-123",
  "@type": "Company",
  "name": "Tesla",
  "people": [
    {
      "@id": "123-124",
      "@type": "Employee",
      "name": "Nikola"
    }
  ]
}

the internal view of a JSON-LD parser is

{
  "@id": "123-123",
  "@type": "https://data.my.org/vocab/#Company",
  "https://data.my.org/vocab/#name": "Tesla",
  "https://data.my.org/vocab/#people": {
    "@id": "123-124",
    "@type": "https://data.my.org/vocab/#Employee",
    "https://data.my.org/vocab/#name": "Nikola"
  }
}

where the IRIs of both name properties indicate semantic equivalence. On the one hand this makes it easy, e.g. to assign or declare a certain meaning (IRI) for all occurences of a term by mapping it onto a different URI, like in this example:

 "@context": {
    "@vocab": "https://data.my.org/vocab/#",
    "name": "https://schema.org/name"
  },

But as an object-oriented developer I often do not want to assign meaning like this, but rather keep meaning when mapping JSON structures onto a graph (e.g. in order to load it into a triple store). However, keeping the semantics of an object-oriented model encoded in JSON requires that properties are mapped onto different IRIs, depending on the (OOP-) type they belong to. For example, I am looking for something like this:

{
  "@id": "123-123",
  "@type": "https://data.my.org/vocab/company/Company",
  "https://data.my.org/vocab/company/name": "Tesla",
  "https://data.my.org/vocab/company/people": {
    "@id": "123-124",
    "@type": "https://data.my.org/vocab/employee/Employee",
    "https://data.my.org/vocab/employee/name": "Nikola"
  }
}

Indeed this is possible with JSON-LD. An idiom I use for this is (see JSON-LD Playground)

{
  "@context": {
    "comp": "https://data.my.org/vocab/company/",
    "empl": "https://data.my.org/vocab/employee/",
    "Company": {
      "@id": "comp:Company",
      "@context": {
        "@vocab": "comp",
        "@propagate": true
      }
    },
    "Employee": {
      "@id": "empl:Employee",
      "@context": {
        "@vocab": "empl",
        "@propagate": true
      }
    }
  },
  "@id": "123-123",
  "@type": "Company",
  "name": "Tesla",
  "people": [
    {
      "@id": "123-124",
      "@type": "Employee",
      "name": "Nikola"
    }
  ]
}

1. for every @type declare an IRI prefix "prefix": IRI (resp. "construct an IRI for the type-specific vocabulary")
2. create an expanded term definition for the type name
3. optional: use "@id": "prefix:Term" to make the typename a term of the type-specific vocabulary rather than the default vocabulary
4. declare a "type-scoped context"
5. use the type-specific prefix IRI as the default vocabulary within the type-scoped context
6. optional: propagate the type scope to any embedded object without its own type declaration

But, well, that doesn't look compelling and soon becomes verbose if a data model is a bit more involved. There should be some option and algorithm to automatically create a type-scoped context for each type and apply type-dependent IRI expansion rules based on the default vocabulary.

Edit: replaced preserve semantics with keep semantics

Start with the linked JSON-LD Playground example and the JSON-LD 1.1 specification's context rules. The issue names no repository files or tests; research the existing type-scoped context behavior, then define an implementable algorithm for automatic type-specific vocabulary expansion and the examples or conformance coverage needed to establish completion.