Why do locations need to belong to an organization?

[timgdavies]

The current location table has a non-required organisation_id field defined as:

Each location must belong to a single organization. The identifier of the organization should be given here.

However - it seems that many organisations could operate from the same location. And to identify all the services at a given identified location a user might want to retrieve services from different organisations.

Should this field be dropped, or better defined to relate only to 'the lead organisation' for the location, or something that helps identify the organisation responsible for administering the location overall, without implying that duplicate 'location' entries should be created for other co-located organisations.

[monfresh]

The Location table represents more than just a physical address. Multiple organizations can operate from the same building, but that does not mean it's the same Location in the schema since a Location does not actually have any address properties directly. A Location is tied to an Address, which is a separate entity in the schema. In Ohana API, there is the concept of virtual locations that don't have a physical address. For example, if they can only be accessed online or via phone.

In addition, even if they're in the same building, they might be on a different floor, or room number, so they might not have the exact same address.

In Ohana API, organization_id is required for a Location.

A common way for a user to identify all the services at a given physical location is to use a map search. They can zoom in on a particular area of the map and see all the "locations". In http://www.smc-connect.org/, for example, if multiple "locations" are in the same physical spot, the map will group them together into one dot that you can click and see all the different entries.

[timgdavies]

Ok. I'm still wondering about the semantics and redundancy of organization_id in locations.

At the moment we say:

The location tables provides details of the locations where organizations operate. Locations may be virtual, and one organization may have many locations.

But we also have services_at_location which relates a service and location, and then each service must have an organisation - so the link of location and organisation is inferred from there.

I can see that there are different use cases between:

• Which other services are located near here? (Remembering that map interfaces are not always the easiest or most useful for some users)
• Which other organisations and services operate out of exactly this location (e.g. this specific clinic)?

Insights on how Ohana or other apps currently use organization_id welcome.

(This issue is tagged 1.1 - so no imminent changes proposed)

[monfresh]

I haven't been following all the updates here closely, but I'm glad this project is moving along. I can only speak about Ohana API, where a location must belong to an organization, hence the required organization_id. In Ohana, a Service does not have a direct relationship with an Organization. Services are provided at Locations, so you can look up a Service's Organization via its Location. An Organization has many Locations, which in turn have many Services. Ohana does not have services_at_location. If you want to know which services belong to a Location, you query the Location, and the API will return all of its services. For example: https://api.smc-connect.org/locations/senior-advocates-program

If you want to know which organizations and services operate out of, or near a specific address, you can use the search feature with the location and radius filters to determine how far out to expand the search. For example, here are the services within a 1-mile radius of 330 Twin Dolphin Drive, Suite 155. Redwood City, CA 94065, sorted by proximity to the searched address.

http://www.smc-connect.org/locations?utf8=%E2%9C%93&keyword=&location=330+Twin+Dolphin+Drive%2C+Suite+155.+Redwood+City%2C+CA+94065+&org_name=&radius=1

Yes, this returns more results than you might have wanted, but in the end, you still get what you were looking for at the top of the results.

Here is the API documentation for more details: https://codeforamerica.github.io/ohana-api-docs/

[NeilMcKLogic]

In iCarol, the "location" object (we have different nomenclature) must belong to exactly one "organization". This is beneficial for many reasons, including:

-Making it clear who is responsible for updating the location record (both internally by the database curator and the external organization doing so in a self-serve way) -Differentiating between subtle differences in the same building (floor, suite number, etc) -Reflecting other attributes of the location that are different for different organizations that we associate with the location object (phone numbers, contact persons, etc)

Tim I see your point about redundancy but in practice it is pretty rare for two different organizations to offer services at exactly the same location. So the benefits above outweigh the extra effort needed for those rare cases.

[greggish]

FWIW, I can think of quite a few examples of different organizations offering services at the exact same location.

Bread for the City's facilities, example, have the DC Bar Pro Bono Program, the Employment Justice Center, food stamp enrollment, and I think tjob training programs all providing third-party services at their site.

I can't speak to the tradeoffs involved.

[klambacher]

Even when organizations share a space, the control over the description of that service location and how it applies to that organizations' delivery of services needs to be independently reviewed and maintained. A change to one does not imply a change to the other, and there are usually subtle differences between the description of that location even if they are, for example, in the same building or even on the same floor. Though there might be a minimal argument for the ability to see what other services are offered at the same location independent of the organization offering them, this can be accomplished with a "services nearby" type feature without the potential for confusing data provenance by linking a location to two independent organizations.

Knowing what other Services are nearby can be a nice to have feature, but practically speaking, people are driven by the service they need first not the offerings that happen to exist at a given location. Related Services (determined by associated categories of need) is a more useful next step vs Nearby Services IMO :)

[pmackay]

A Location is tied to an Address, which is a separate entity in the schema

Small thought on this, would it be better if Addresses could be potentially canonical, and that a Location has an address_id rather than an Address having a location_id? That way in a scenario where there is a canonical list of addresses (this is starting to happen in a few places around the world) then they can be referenced without duplication?

[cwisdo]

There is a semantic difference between the "owner" (or lead organization) of a location vs an association of an organization with a location by virtue of providing a service at that location which I think is captured by having the organization_id on both the location (as @NeilMcKechnie noted to designate who the responsible entity is for updating the record) and separately on the service to designate who is providing the service ( so a subtle case where those two organization_ids are not the same).

I am thinking of the case where many different organizations might provide services at a school say.

I don't know how this might be handled with Ohana

[timgdavies]

Thanks all for the discussions here.

To summarise:

• Some applications have a requirement that a location MUST have a linked organisation: as this is how control over editing that location is managed. However, we can't assume that all possible sources of data will have this linkage.
• Many use cases require have cases where, even when two services from different organisations are physically co-located, their location should be described differently;
• The use-case of providing a page that lists all the services at a given address could be served by giving Location an address_id rather than the current reverse approach. This use-case is not seen as a strong priority, and there may be other (address parsing; geolocation etc.) of indicating other nearby services.

On this basis, I suggest just a minimal descriptive change so that:

Each location entry should be linked to a single organization. This is the organization that is responsible for maintaining information about this location. The identifier of the organization should be given here.

With this small change:

• In HSDS, including a link between location and organisation will remain optional;
• The reason for this linkage will be clearer;

As a consequence:

Publishing applications can continue to maintain the link between organisation and location and express this.

Consuming applications should generally ignore this, and only use Location.organisation_id for purposes such as allowing an organisation to claim ownership of a location record to update it.

All information about the organisation delivering services at a given location should be identified from the link between service and organisation, and not from Location.organisation_id.