Do we need relationships in the core schema between location/organization?

Originally we were thinking about locations and then the ownership of those locations. My thinking has evolved to "organization" there are many more relationships beyond ownership. How should we show those relationships?

A few possible types of organizations:

Unions
Audits
Owners
Customers

I think it definitely makes sense to have all locations as organization and then map them with relationship types.

A few relationship ideas:

Partnerships
Suppliers/Vendors
Regulators
Subsidiaries
Franchisees/Franchisors
Investors
Licensors/Licensees
Distributors
Joint Ventures
Industry Associations

I agree that establishing relationships between the core objects is essential for creating a flexible schema and representing the dynamics of a supply chain ecosystem.

I am sharing here how we currently capture these dynamics on Wikirate in case it will help further the discussion on how we can develop the concept of relationships on this standard. As background, I need to mention that the data on Wikirate is organised under metrics and one type of metric we support is relationship metrics. Each relationship metric has also an inverse relationship metric which is populated automatically.

One of our most populated relationship metrics currently on the platform is Supplied by, where each company can be supplied by several facilities each year. The Inverse Relationship Metric is Supplier of which is automatically populated.

The schema to express the relationship between two entities looks like the following:

[{
      "id": 15630744,
      "name": "Commons+Supplied By+Hugo Boss AG+2022+Square Fashions LiTD.",
      "type": "Relationship Answer",
      "metric":"Commons+Supplied By",
      "subject_company": "Hugo Boss AG",
      "object_company": "Square Fashions LiTD.",
      "value": "Tier 1 Supplier",
      "year": 2022,
      "url": "https://wikirate.org/Commons+Supplied_By+Hugo_Boss_AG+2022+Square_Fashions_LiTD.json",
      "metric_id": 2929009,
      "inverse_metric_id": 2929015,
      "subject_company_id": 42714,
      "object_company_id": 6298030,

    },
    {
      "id": 15630749,
      "name": "Commons+Supplied By+Hugo Boss AG+2022+Navy Fashion Textile EOOD",
      "type": "Relationship Answer",
      "metric":"Commons+Supplied By",
      "subject_company": "Hugo Boss AG",
      "object_company": "Navy Fashion Textile EOOD",
      "value": "Tier 1 Supplier",
      "year": 2022,
      "url": "https://wikirate.org/Commons+Supplied_By+Hugo_Boss_AG+2022+Navy_Fashion_Textile_EOOD.json",
      "metric_id": 2929009,
      "inverse_metric_id": 2929015,
      "subject_company_id": 42714,
      "object_company_id": 13567589
    }]

Based on the discussions around relationships, I was wondering if it would make more sense to use JSON-LD to develop the standard since it can allow us to create these links between our currently core objects Location, Organization and I think it will provide an extra layer of interoperability since it will be compatible with the wider web of linked data. So, if I try quickly to express the relationships above using JSON-LD, I would do something like the following:

{
  "@context": {
    "id": "@id",
    "type": "@type",
    "name": "https://schema.org/name",
    "location-type": "https://schema.org/locationCategory",
    "address": "https://schema.org/address",
    "suppliedBy": "https://schema.org/supplier",
    "supplierOf": "https://schema.org/supplier",
    "organization": "https://schema.org/Organization",
    "place": "https://schema.org/Place",
    "inverse_metric": "https://schema.org/relatedTo",
    "url": "https://schema.org/url"
  },
  "@graph": [
    {
      "@type": "Organization",
      "id": "https://wikirate.org/Organization/Hugo_Boss_AG",
      "name": "Hugo Boss AG",
      "supplierBy": [
        {
          "@id": "https://wikirate.org/Location/Navy_Fashion_Textile_EOOD",
          "name": "Navy Fashion Textile EOOD"
        },
        {
          "@id": "https://wikirate.org/Location/Square_Fashions_LiTD",
          "name": "Square Fashions LiTD"
        }
      ]
    },
    {
      "@type": "Place",
      "id": "https://wikirate.org/Location/Navy_Fashion_Textile_EOOD",
      "name": "Navy Fashion Textile EOOD",
      "location-type": "Factory",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "123 Industry Road",
        "addressLocality": "Sofia",
        "addressRegion": "Sofia",
        "postalCode": "1000",
        "addressCountry": "BG"
      },
      "supplierOf": {
        "@id": "https://wikirate.org/Organization/Hugo_Boss_AG",
        "name": "Hugo Boss AG"
      }
    },
    {
      "@type": "Place",
      "id": "https://wikirate.org/Location/Square_Fashions_LiTD",
      "name": "Square Fashions LiTD",
      "location-type": "Factory",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "456 Garment Ave",
        "addressLocality": "Dhaka",
        "addressRegion": "Dhaka",
        "postalCode": "1205",
        "addressCountry": "BD"
      },
      "suppliedOf": {
        "@id": "https://wikirate.org/Organization/Hugo_Boss_AG",
        "name": "Hugo Boss AG"
      }
    }
  ]
}

thanks for that example @vasgat do you think it should be within the 2 core objects or are relationships another type of object?

I tend to think graph concepts are hard for a layperson, so I like to hide the complexity a bit.

I am not sure what is the right approach for this. In a discussion, we had with Ethan, he proposed a separate object named Affiliation. In this case we can more flexibly define different types of relationships between entities.

{
    "subject_guid": "d9f233d8-e306-45e7-92e5-db604e4ad79a"
    "object_guid": "8ac0fe52-5194-48bd-8cc8-78cf7606e50d"
    "relationship": "supplied by"
    "status": "active"
}

The relationship here can be also renamed to affiliation-type.

Just chiming in, I'm glad you raised this topic. From a database perspective, my original thought is that objects (or foreign keys) would be useful for most fields, following Kimball design principles.

That said I don't know if this is needed in the context of the schema. I imagine it would be possible to keep the schema simple for the sake of wider adoption, and then do the object matching on whatever system dealing with the data (processing). In other words: is the burden of "deduplicating" and selecting the right object on the user side or on the processor side?

Or it could be that the schema highlights all objects and connections, but an interface given to users simplifies it.

I'm not as close to the details when it comes to how the schema will be made available to the users so apologies if I'm off topic.

@fredsourcing when you say objects for most fields are you saying treat each field as an object? I was thinking the main core data objects would benefit from unique identifiers, but I wasn't thinking that we require it depending on the use case.

I was hoping to make the schema simple enough that we could create tools to easily translate between spreadsheets and other systems.

So for example I would think of location and organization as having linkages and the object linking them would be embedded in each of them instead of a table to look the keys up if the data was being modeled in a spreadsheet.

@wonderchook yes, similar to the example posted by Vasgat (where we have metric_id, inverse_metric_id etc...) essentially each field would have a link to an object id from another table. For examples countries would be a separate table, with United Kingdom being id 123 etc... If the schema ends up using SIC codes or similar that would make sense too. I would argue that you can do that even for things like the address field. This standardises the data and makes querying faster when the data gets big.

BUT - this is for database design, this is not necessarily relevant to the schema (although it's good to think about it). I absolutely agree with you that the schema should be simple to understand and use. The most important is standardisation I believe.

I think maybe a way to achieve this standardisation on an open schema for data exchange might be to rely as much as possible on existing standard, like Vasiliki said on Slack. This would basically force user to use the given standard, which would be the virtual equivalent to having a separate table for each value. For example, with the country field, requiring Alpha-2 or Alpha-3 country code would ensure standardisation. This could be done for company category, the product category, perhaps for the language too.

For fields that would be difficult to standardise like the "processing-types" field for example (if this is kept) then another approach would be needed. I like your suggestion, that makes sense. I guess a list of possible options would be made available in the schema description for user to choose from?

To clarify: In the context of spreadsheets, all the data would be in clear text. For example, the country would be "GB", category using SIC code would be either "46420", processing type would be one of the option like "spinning" etc...

This is how I currently imagine it but I might be over complicating things :)

@fredsourcing I'd agree with leveraging existing standards as much as possible, so this schema where ever there is a pre-existing standard that's open for use is pulled in, and where the category isn't as simple and broadly defined already as country (using alpha-2/alpha-3), we can end up referencing OSIDs or Global Field IDs. I wonder what standard(s) might already exist for "processing-types"

Coming back to the question of "is relationship type a field within location, or organization, or standalone", a use case that @ethn and I chatted through was what would happen if you had:

A factory location, let's call this FactoryA (OSID as main identifier)
A second factory location, let's call this FactoryB (also OSID as main identifier)
An industrial park (GlobalFieldID as main identifier)
An organization (LEI as main identifier)

In this case, you might have the relationships:

Factory A is a supplier of Factory B
Factory B is a supplier of Organization
Factory A is located within Industrial Park
Factory B is located within Industrial Park
Industrial Park is owned by Organization

So you'd need the option of having the affiliation/relationship type attachable to both location and organization (because there's location to location and, presumably, you could add in the ownership affiliation to any of the factories as well, so organization to organization would matter too). Would describing/appending this be cleaner if affiliation is a separate field, or as @wonderchook is saying in going the embedding route, would that add an extra step in having to do a look up?

I am coming back to this after a while but I was wondering how the relationships would look like after the latest updates on the schema . I have seen that affiliation-type is included there as a field in both location & organization objects but I have a hard type translating relationships between location/organization objects based on that schema. @shuyag could you provide an example for better understanding?

As I mentioned on the discussion, we had with @shuyag earlier on zoom. I feel the current version of the schema is incomplete in the sense that it is challenging to capture relationships between our core objects. I was trying to think an example based on the current version of the schema for both core objects Location & Organisation:

[{
    "guid": "82d39ac8-1a12-4801-835a-85d319927548",
    "location-type": "factory",
    "language": "en",
    "products": ["Accessories","Hats"],
    "sector": 131,
    "processing-types": ["Final Product Assembly", "Cutting", "Embroidery", "Finishing", "Ironing", "Knitting"],
    "os-id": "CN2021250D1DTN7",
    "name": "Huai An Yuan Tong Headwear Mfg. Co., Ltd.",
    "coordinates": { "latitude": 33.7862099, "longitude": 119.2787399},
    "address": "No.30 & 32 & 99 Yan Huang Avenue, Lian Shui Economic Developmental District, Huaian ,Jiangsu - China",
    "affiliation-type": "is supplier of"
},
{
    "guid": "91582fdd-6f72-47cf-a113-f68fe4e74865",
    "organization-type": 5600,
    "language": "en",
    "lei": "3538002LJMRZ83SU0B85",
    "organization-identifier": ["lei:3538002LJMRZ83SU0B85"],
    "affiliation-type": "supplied by"
}, 
{
    "guid": "91582fdd-6f72-47cf-a113-f68fe4e74866",
    "organization-type": 5600,
    "language": "en",
    "lei": "353800ZCXKHDPY0N5218",
    "organization-identifier": ["lei:353800ZCXKHDPY0N5218"],
    "affiliation-type": "supplied by"
},
{
    "guid": "91582fdd-6f72-47cf-a113-f68fe4e74866", 
    "organization-type": 5600, 
    "language": "en", 
    "lei": "549300D9GZ4BMLDW5T40", 
    "organization-identifier": ["lei:549300D9GZ4BMLDW5T40"], 
    "affiliation-type": "supplied by"
}]

What’s missing is a clear way to capture the actual relationships between these core objects. How can we adjust the schema to better reflect these connections? I think can think of two alternatives. The first one requires the definition of a third object: affiliation and the second requires encapsulation of these affiliations object within the core objects. Schema adjustments based on the first alternative:

{
  "locations": [
    {
      "guid": "82d39ac8-1a12-4801-835a-85d319927548",
      "location-type": "factory",
      "language": "en",
      "products": ["Accessories", "Hats"],
      "sector": 131,
      "processing-types": [
        "Final Product Assembly",
        "Cutting",
        "Embroidery",
        "Finishing",
        "Ironing",
        "Knitting"
      ],
      "os-id": "CN2021250D1DTN7",
      "name": "Huai An Yuan Tong Headwear Mfg. Co., Ltd.",
      "coordinates": {
        "latitude": 33.7862099,
        "longitude": 119.2787399
      },
      "address": "No.30 & 32 & 99 Yan Huang Avenue, Lian Shui Economic Developmental District, Huaian, Jiangsu - China"
    }
  ],
  "organizations": [
    {
      "guid": "91582fdd-6f72-47cf-a113-f68fe4e74865",
      "organization-type": 5600,
      "language": "en",
      "lei": "3538002LJMRZ83SU0B85",
      "organization-identifier": [
        "lei:3538002LJMRZ83SU0B85"
      ]
    },
    {
      "guid": "91582fdd-6f72-47cf-a113-f68fe4e74866",
      "organization-type": 5600,
      "language": "en",
      "lei": "353800ZCXKHDPY0N5218",
      "organization-identifier": [
        "lei:353800ZCXKHDPY0N5218"
      ]
    },
    {
      "guid": "91582fdd-6f72-47cf-a113-f68fe4e74867",
      "organization-type": 5600,
      "language": "en",
      "lei": "549300D9GZ4BMLDW5T40",
      "organization-identifier": [
        "lei:549300D9GZ4BMLDW5T40"
      ]
    }
  ],
  "affiliations": [
    {
      "from-guid": "82d39ac8-1a12-4801-835a-85d319927548", 
      "to-guid": "91582fdd-6f72-47cf-a113-f68fe4e74865",
      "affiliation-type": "is supplier of"
    },
    {

      "from-guid": "82d39ac8-1a12-4801-835a-85d319927548",
      "to-guid": "91582fdd-6f72-47cf-a113-f68fe4e74866",
      "affiliation-type": "is supplier of"
    },
    {
      "from-guid": "82d39ac8-1a12-4801-835a-85d319927548"
      "to-guid": "91582fdd-6f72-47cf-a113-f68fe4e74867"
      "affiliation-type": "is supplier of"
    }
  ]
}

Schema adjustments based on the second alternative:

[
  {
    "guid": "82d39ac8-1a12-4801-835a-85d319927548",
    "location-type": "factory",
    "language": "en",
    "products": ["Accessories", "Hats"],
    "sector": 131,
    "processing-types": [
      "Final Product Assembly",
      "Cutting",
      "Embroidery",
      "Finishing",
      "Ironing",
      "Knitting"
    ],
    "os-id": "CN2021250D1DTN7",
    "name": "Huai An Yuan Tong Headwear Mfg. Co., Ltd.",
    "coordinates": {
      "latitude": 33.7862099,
      "longitude": 119.2787399
    },
    "address": "No.30 & 32 & 99 Yan Huang Avenue, Lian Shui Economic Developmental District, Huaian, Jiangsu - China",
    "affiliations": [
      {
        "affiliated-guid": "91582fdd-6f72-47cf-a113-f68fe4e74865",
        "affiliation-type": "is supplier of"
      },
      {
        "affiliated-guid": "91582fdd-6f72-47cf-a113-f68fe4e74866",
        "affiliation-type": "is supplier of"
      },
      {
        "affiliated-guid": "91582fdd-6f72-47cf-a113-f68fe4e74867",
        "affiliation-type": "is supplier of"
      }
    ]
  },
  {
    "guid": "91582fdd-6f72-47cf-a113-f68fe4e74865",
    "organization-type": 5600,
    "language": "en",
    "lei": "3538002LJMRZ83SU0B85",
    "organization-identifier": [
      "lei:3538002LJMRZ83SU0B85"
    ],
    "affiliations": [
      {
        "affiliated-guid": "82d39ac8-1a12-4801-835a-85d319927548",
        "affiliation-type": "supplied by"
      }
    ]
  },
  {
    "guid": "91582fdd-6f72-47cf-a113-f68fe4e74866",
    "organization-type": 5600,
    "language": "en",
    "lei": "353800ZCXKHDPY0N5218",
    "organization-identifier": [
      "lei:353800ZCXKHDPY0N5218"
    ],
    "affiliations": [
      {
        "affiliated-guid": "82d39ac8-1a12-4801-835a-85d319927548",
        "affiliation-type": "supplied by"
      }
    ]
  },
  {
    "guid": "91582fdd-6f72-47cf-a113-f68fe4e74867",
    "organization-type": 5600,
    "language": "en",
    "lei": "549300D9GZ4BMLDW5T40",
    "organization-identifier": [
      "lei:549300D9GZ4BMLDW5T40"
    ],
    "affiliations": [
      {
        "affiliated-guid": "82d39ac8-1a12-4801-835a-85d319927548",
        "affiliation-type": "supplied by"
      }
    ]
  }
]

My preference lies with the first alternative. I think it is cleaner. We first define the location objects then the organisation objects and then the affiliations. The affiliations can be also extended to support additional data such as: products, product_volume, affiliation-starting-date, affilation-ending-date etc.

Trying out a third option here, per @wonderchook's suggestion to look at the schema and how they've set up locations, organizations, and their relationships: https://docs.openreferral.org/en/v2.0/hsds/logical_model/

In particular, the part of the model I'm interested in is this analogous "service_at_location - a link table used to record where particular services are available, and to over-ride any default service or location information, with information specific to the service at a specific location."

What if we thought about it similarly, so that locations nest within the organizations (but could be empty if just trying to express organizations)? This way, the affiliations could sit at both the location and organizational level. It might look something like "organization_at_location"

@shuyag I was having a closer look to the logical model, you attached above, of Open Referral, trying to understand how the service_at_location could fit our case but it is a bit challenging. At open referral they do have three entities they want to link instead of two. They have location, organization & service and then service_at_location expresses available services offered by a specific organization in a specific location.

To be honest, having locations nest within organizations does not resonate very well. I expect the example I have attached above to look like the following:

{
  "locations": [
    {
      "guid": "82d39ac8-1a12-4801-835a-85d319927548",
      "location-type": "factory",
      "language": "en",
      "products": ["Accessories", "Hats"],
      "sector": 131,
      "processing-types": [
        "Final Product Assembly",
        "Cutting",
        "Embroidery",
        "Finishing",
        "Ironing",
        "Knitting"
      ],
      "os-id": "CN2021250D1DTN7",
      "name": "Huai An Yuan Tong Headwear Mfg. Co., Ltd.",
      "coordinates": {
        "latitude": 33.7862099,
        "longitude": 119.2787399
      },
      "address": "No.30 & 32 & 99 Yan Huang Avenue, Lian Shui Economic Developmental District, Huaian, Jiangsu - China"
    }
  ],
  "organizations": [
    {
      "guid": "91582fdd-6f72-47cf-a113-f68fe4e74865",
      "organization-type": 5600,
      "location-guid": "82d39ac8-1a12-4801-835a-85d319927548",
      "language": "en",
      "lei": "3538002LJMRZ83SU0B85",
      "organization-identifier": [
        "lei:3538002LJMRZ83SU0B85"
      ]
    },
    {
      "guid": "91582fdd-6f72-47cf-a113-f68fe4e74866",
      "organization-type": 5600,
      "location-guid": "82d39ac8-1a12-4801-835a-85d319927548",
      "language": "en",
      "lei": "353800ZCXKHDPY0N5218",
      "organization-identifier": [
        "lei:353800ZCXKHDPY0N5218"
      ]
    },
    {
      "guid": "91582fdd-6f72-47cf-a113-f68fe4e74867",
      "organization-type": 5600,
      "location-guid": "82d39ac8-1a12-4801-835a-85d319927548",
      "language": "en",
      "lei": "549300D9GZ4BMLDW5T40",
      "organization-identifier": [
        "lei:549300D9GZ4BMLDW5T40"
      ]
    }
  ],
  "location_at_organisation": [
    {
      "guid":"91582fdd-6f72-47cf-a113-f68fe4e74897",
      "organization-guid": "91582fdd-6f72-47cf-a113-f68fe4e74865",
      "affiliation-type": "is supplier of"
    },
    {
      "guid":"91582fdd-6f72-47cf-a113-f68fe4e74898",
      "organization-guid": "91582fdd-6f72-47cf-a113-f68fe4e74866",
      "affiliation-type": "is supplier of"
    },
    {
      "guid":"91582fdd-6f72-47cf-a113-f68fe4e74899",
      "organization-guid": "91582fdd-6f72-47cf-a113-f68fe4e74867"
      "affiliation-type": "is supplier of"
    }
  ]
}

and in this case we express only one type of relationship "supplied by" with only one location. What if we want to express the relationship of those organisations to another facility. Then, we need to have something like the following:

{
  "locations": [
    {
      "guid": "82d39ac8-1a12-4801-835a-85d319927548",
      "location-type": "factory",
      "language": "en",
      "products": ["Accessories", "Hats"],
      "sector": 131,
      "processing-types": [
        "Final Product Assembly",
        "Cutting",
        "Embroidery",
        "Finishing",
        "Ironing",
        "Knitting"
      ],
      "os-id": "CN2021250D1DTN7",
      "name": "Huai An Yuan Tong Headwear Mfg. Co., Ltd.",
      "coordinates": {
        "latitude": 33.7862099,
        "longitude": 119.2787399
      },
      "address": "No.30 & 32 & 99 Yan Huang Avenue, Lian Shui Economic Developmental District, Huaian, Jiangsu - China"
    },
    {
      "guid": "82d39ac8-1a12-4801-835a-85d319927638",
      "location-type": "factory",
      "language": "en",
      "products": ["Accessories", "Hats"],
      "sector": 131,
      "processing-types": [
        "Final Product Assembly",
        "Cutting",
        "Embroidery",
        "Finishing",
        "Ironing",
        "Knitting"
      ],
      "os-id": "LT20222809DJKDR",
      "name": "SIUVIMO AB ZEMKALNIJA",
      "coordinates": {
        "latitude": 54.6456075,
        "longitude": 23.0502244
      },
      "address": "VYTAUTO G. 4, VILKAVISKIS, Marijampole County - Lithuania"
    }
  ],
  "organizations": [
    {
      "guid": "91582fdd-6f72-47cf-a113-f68fe4e74865",
      "organization-type": 5600,
      "location-guid": "82d39ac8-1a12-4801-835a-85d319927548",
      "language": "en",
      "lei": "3538002LJMRZ83SU0B85",
      "organization-identifier": [
        "lei:3538002LJMRZ83SU0B85"
      ]
    },
    {
      "guid": "91582fdd-6f72-47cf-a113-f68fe4e74122",
      "organization-type": 5600,
      "location-guid": "82d39ac8-1a12-4801-835a-85d319927638",
      "language": "en",
      "lei": "3538002LJMRZ83SU0B85",
      "organization-identifier": [
        "lei:3538002LJMRZ83SU0B85"
      ]
    }, //this is actually the same organization, with a different guid and another location-guid is linked here
    {
      "guid": "91582fdd-6f72-47cf-a113-f68fe4e74866",
      "organization-type": 5600,
      "location-guid": "82d39ac8-1a12-4801-835a-85d319927548",
      "language": "en",
      "lei": "353800ZCXKHDPY0N5218",
      "organization-identifier": [
        "lei:353800ZCXKHDPY0N5218"
      ]
    },
    {
      "guid": "91582fdd-6f72-47cf-a113-f68fe4e74867",
      "organization-type": 5600,
      "location-guid": "82d39ac8-1a12-4801-835a-85d319927548",
      "language": "en",
      "lei": "549300D9GZ4BMLDW5T40",
      "organization-identifier": [
        "lei:549300D9GZ4BMLDW5T40"
      ]
    }
  ],
  "location_at_organisation": [
    {
      "guid":"91582fdd-6f72-47cf-a113-f68fe4e74897",
      "organization-guid": "91582fdd-6f72-47cf-a113-f68fe4e74865",
      "affiliation-type": "supplied by"
    },
    {
      "guid":"91582fdd-6f72-47cf-a113-f68fe4e47892",
      "organization-guid": "91582fdd-6f72-47cf-a113-f68fe4e74122",
      "affiliation-type": "supplied by"
    },
    {
      "guid":"91582fdd-6f72-47cf-a113-f68fe4e74900",
      "organization-guid": "91582fdd-6f72-47cf-a113-f68fe4e74865",
      "affiliation-type": "supplied by"
    },
    {
      "guid":"91582fdd-6f72-47cf-a113-f68fe4e74898",
      "organization-guid": "91582fdd-6f72-47cf-a113-f68fe4e74866",
      "affiliation-type": "supplied by"
    },
    {
      "guid":"91582fdd-6f72-47cf-a113-f68fe4e74899",
      "organization-guid": "91582fdd-6f72-47cf-a113-f68fe4e74867"
      "affiliation-type": "supplied by"
    }
  ]
}

I thinks this introduces unnecessary complexity.

Redundant data: Each organization is linked to locations through the location-guid, and then again through the location_at_organisation object. This duplication creates redundancy and makes the schema harder to maintain and read. We are expressing relationships twice-once via location-guid in the organizations object and again through location_at_organization.
Multiple representations of the same organization: Representing organizations that supplied by multiple locations result on duplicating organization objects with different guids to represent their presence at each location. This forces us to treat what is essentially the same organization as different entities, making it harder to keep track of the true nature of the organization.
Limited flexibility: This structure tightly binds relationships to specific locations, and it doesn't allow for easy scalability or flexibility. If we need to express relationships beyond organizations and locations, we'd have to redesign or add more complexity to the schema.

I think the schema on the first option presented on my previous answer is more abstract, scalable and could support any kind of relationship between any entities, not just between organizations and locations. For example, you could add an affiliation between two organizations, two locations, or even two products (if we include this entity in an extension in the future). This makes it more flexible to capture multiple types of relationships in the future.

Hi all-- I am coming into this a little late, and I am not an expert at schema design, but I am curious about a few use cases that it was not clear to me how this structure could accommodate.

the dimension of time. transformations of materials into products happens through processes at locations. and locations make products that are supplied to other locations. but locations change what processes they perform, over time, and also which other locations they supply to, over time. organization affiliations also change over time (ie location ownership and other relationships). On the surface it looks to me like this schema assumes these attributes and relationships are fixed and don't change. What am I missing about how this schema provides for change over time within and between entities?
organization relationships. I was looking at https://wikirate.org/Relationship to understand more the kinds of relationships being considered in this schema. For locations that are owned via joint-ventures, or may be owned by one organization and operated by another, would that be multiple subsidiary-of relationships to different organizations? For a manufacturer company (organization) that owns and operates multiple factories (locations), what would be the relationship type to use in this schema? Would that also be a subsidiary? In my mind a subsidiary relationship make sense when describing an organization<>organization relationship, but not necessary an organization<>location relationship. It makes me wonder if there should be a richer set of defined relationships than what is listed on wikirate, or if I am just missing something.

Thank you!

Hi @d76danieletra! You are not late at all to the discussion, the SCDEX is still under constuction and we are still discussing the core schema, so your input is really valuable.

Note that, our approach with the SCDEX core schema is to maintain a minimal structure that captures foundational entities (like locations, organizations, and their relationships) to encourage wide adoption. However, the core schema is designed to be extensible. This means that more complex or specialized use cases, such as tracking changes in processes over time or handling intricate organization relationships, can be addressed through schema extensions. These extensions will enable us to add layers of complexity without overloading the core schema, giving flexibility to users with varied needs.

I will start with your second concern around relationships. I agree with your concern around the types of relationships we are planning on supporting. Indeed, wikirate is more focused on organization<>organization relationships. Personally, I look at https://wikirate.org/Relationship as a subset of relationships we can support in SCDEX and I agree that a richer set of relationships should be considered. We can use the set in https://wikirate.org/Relationship as a starting point and discuss further additional relationship/affiliation types supporting in SCDEX.

I think you raised a critical point around the dynamic nature of supply chains and the need to incorporate the dimension of time. There have been already some discussion around this here and here. Feel free to add your thoughts there as well. One approach we could consider is to incorporate attributes like validity periods or "effective dates" within the schema, which would help define the timeframe during which a particular data point is relevant. This could involve including expiration dates or specifying validity windows for data attributes, making it possible to reflect historical and evolving relationships accurately.

opensupplyhub / supplychaindata.exchange

Do we need relationships in the core schema between location/organization? #3