Are more POI properties needed to be standardized for the POI data interchange use case?

[howardtrickey]

Our charter says "The first goal of the PoI standard is interoperable PoI data and systems. Complying with this standard will permit systems that populate a PoI database regardless of authoring platform or application, to do so without transcoding, delays or costs that are incurred when data is compiled from many different contributors using proprietary formats."

and

"Furthermore, when data are encoded in compliance with the PoI standard, third parties are able to create, interact with, and query across platforms from multiple, diverse sources, to compare, merge, and, at the end of life cycle, to archive, PoI without loss of accuracy, metadata or value."

In my experience with working with POIs for 15 years, there is a minimum set of POI properties that are needed for the interchange between different parties of POI data needed for a broad variety of use cases (e.g., the "Choose Restaurant" use case in our repository, which is only representative of a very broad class of use cases supported by many companies / web sites.

These properties are:

• name
• address (ideally, structured, but an alternative of free form for the lowest levels of address need to be supported)
• latitude, longitude of center of POI
• category (ideally, a business/public service ontology that is detailed enough - say, 5000+ entries - to accurately characterize most of the world's POIs)
• business hours (with a minimum of a weekly schedule, with the possibility of multiple open intervals per day)
• phone number

Some very useful other ones are:

• access point (latitude, longitude of where you drive to to access the POI)
• web site

Do we need to be more prescriptive about which other standard(s) (if any) are preferred for this interchange use case?

[geofizzydrink]

We are considering gathering these properties into profiles of the data model rather than defining them directly in that model - we do, however, need to work through this to see how this can be achieved.

This issue should be the main focus for this discussion going forward.

It is related to the following issues:

• https://github.com/opengeospatial/poi/issues/100
• https://github.com/opengeospatial/poi/issues/94
• https://github.com/opengeospatial/poi/issues/75
• https://github.com/opengeospatial/poi/issues/57
• https://github.com/opengeospatial/poi/issues/56

[cmheazel]

Complements issue #94 Can we close this one or issue #94 ?