Locations

[This is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders.]

Most Parties are associated with one or more physical locations. There are benefits to being able to enumerate all the Locations of specific types, the Parties associated with those Locations, the Locations associated with Parties, and so on.

In the System.Identity schema, locations are factored out of the Party definitions and modeled as independent Location entities, just as names are factored out and modeled as IdentityKeys.

One Location can be associated with multiple Parties (For example, a building may contain multiple organizations and People), and conversely, one Party can be associated with multiple Locations (For example, both office and home). Therefore the schema includes a PartyLocation many-to-many relationship that also allows specification of date ranges. The PartyLocation itself has a Kind (For example, Summer Home or Winter Home). Thus the schema can represent all Locations of all kinds a Party has occupied throughout its lifetime.

Like IdentityKeys, PartyLocation contain not only a PartyId, but the ID of the specific Role specialization with which that Location is associated (For example, if someone has two employee roles, different offices can be associated as locations with each role).

Locations are fractal, in the sense that one location may be within another. Thus a Location can include the ID of another “Parent” Location, which facilitates hierarchical queries that could join on all Locations below a parent Location in the hierarchy.

Locations include a definition of geographic location as a point. However, it can also be useful to define their boundaries. This is done by GeographicBoundaryPoints, which represent a set of co-ordinates that bound the Location.

Fill out a survey about this topic for Microsoft.