Domain Model

Introduction

Share-VDE manages a complex domain composed by several entities. That results in a complex graph of interconnected entities that can be queried and used by external requestors through a rich set of public APIs. The purpose of this section is to describe what a requestor can do in terms of API in order to interact with Share-VDE.

At the heart of the system there's a complex domain model, as depicted in the following diagram:

The domain is composed by functional and technical entities, meaning with that a simple classification where we denote as

• "functional" those entities that are part of the Share-VDE Core Domain Model (e.g. Agents, Opuses, Works, Instances, Items)
• "technical" those entities required by some technical constraint in order to enrich the core entities with additional information (e.g. Collections, Facets, Pagination metadata).

Knowledge Base, Tenants, Provenances

Share-VDE manages a Knowledge Base which consists of clustered, integrated and enriched entities. In Share-VDE, a tenant is represented by a set of institutions contributing to the same Knowledge base.

An institution Pn within a tenant is called provenance. We use that term because we always want to retain the relationship between Share-VDE entities and data that originally contributed to their building.

Multiple Tenants? The Share-VDE Family

Multiple tenants form the Share Family. Family members interoperate through a centralised registry.

Share-VDE Entities

In the following diagram we depicted a high-level overview of the clusters genesis process.

Starting from the left side we have:

• A tenant composed by n institutions (P1...Pn)
• Institutions contribute with their raw data (e.g. bibliographic records, authority records)
• The Share-VDE clusters are created in the Knowledge Base by means of an automatic process we simply call "clustering"

The Share-VDE Entity: The Prism

Each Share-VDE cluster is the result of merging contributions from several sources, including a special enrichment for linking external sources (e.g. VIAF, ISNI).

We like to imagine a cluster like a prism, which is a whole unit and at the same time it retains several faces (the contribution of each source). See the following diagrams for a visual explanation

API Perspective

Each cluster type has a "provenances" field associated which, as the name suggests, indicates the provenances that contributed to that cluster definition.

Here's an example of a request which asks for a specific Person and its provenances:

{
  person(uri: "https://svde.org/agents/201") {
    uri
    name
    provenances {
      uri
      description
    }
  }
}

In the response below we clearly see the Share-VDE cluster for Luiss Carroll has been contributed by 3 institutions: Stanford, Alberta and British Library.

{
  "data": {
    "person": {
        "uri": "https://svde.org/agents/201",
        "name": "Carroll, Luiss",
        "provenances": [
            {
                "uri": "https://svde.org/agents/STANFORD",
                "description": "Stanford University"
            },
            {
                "uri": "https://svde.org/agents/BL",
                "description": "British Library"
            },            
            {
                "uri": "https://svde.org/agents/UALBERTA",
                "description": "University of Alberta"
            }
        ]
    }
  }
}