Triplestore in Drupal

I've been thinking about how I'm going to build a triplestore in Drupal for Silk Floss. I think this is how I'm going to it. I'll create a new Triple (triple) Structured Data (sd) module. The name is available where item isn't. This module will consist of these entities:

• Item
  An object.
  The label for the entity should be hoisted from a name, label, or title statement.
  The entity should be revisioned and does not allow for user fields since anything can be specified in the Statements.
  Of the three entities, this is the only one that is surfaced in the UI and API. The others are only accessed through the Statements field.
  • Statements
    A field that has references to a Statement.
    This field is a lot like the Paragraph field as it extends from Entity Reference.
    This field could be added to any entity type.
• Statement
  A property and a set of values.
  A entity field representing the triple.
  The field is only designed to be on the Item a single time with unlimited number of values.
  • Item
    Single-value entity revision (?) reference to an Item of any type.
  • Property
    Single-value entity reference to the Property entity record (below). These are created on-demand if they do not exist.
  • Value
    URI and/or single-value entity reference to an Item and/or single-value entity revision reference to a Value entity.
    I imagine this will be two different columns in the database.
  • Statements
    A hidden field that can be used by modules that allow Statements to have other Statements. This converts a Statement Group into a Role.
• Property
  A simple entity that records the current list of all properties. Either a URI and/or entity reference to an Item. This item is entity only exists for referencing from the Statements field or the Item Tree.
  I imagine this will be three columns (id, uri, item). The uri will have a unique index.
• Item Tree
  An entity that is a closure table of Items, Properties, and depth to maintain the heirarchial relationships of statements. For instance, the subclass / instance of hierarachy.
• Value
  An single value
  Each bundle should represent a different primitive data type (String, URL, Item, Node, Media, etc.).
  Users may create whatever data types they want.
  Each bundle should indicate (in config) the standard primitives it is the same as.
  • Value
    A single-value field specified by the bundle
  • Statements
    A hidden field that can be used by modules that allow Value to have other Statements. This converts a Value into a Role.

After all this, we'll figure out how to implement SPARQL in Drupal which will allow us to actually INSERT content into the store. I think datatypes, properties, and classes will need to be matched to existing ontologies (and each item will need to be mapped) or if it cannot be found, will be auto-created. This should work even if the class is mapped to an entity other than Item (above). For instance, if a MediaObject is mapped to a media entity in Drupal, then that is what should be created on INSERT. A report should be generated (and a status in Drupal?) to ensure that there is not more than one destination for an object. If there is, then both should be created.