Add geolocation semantic annotation recommendation - closes #137

[benfrancis]

This assertion recommends the use of the schema.org ontology for geolocation semantic annotations, as discussed in #17 and #137.

I've included two examples of how to use the geolocation annotations which I think are equally valid:

1. To add static geolocation metadata to a Thing at the top level of its Thing Description
2. To add a dynamic geolocation property to a Thing as a PropertyAffordance

Note that this PR depends on #260 which adds a Semantic Annotations section under Common Constraints. Please only review the final commit cfa5716

---

Preview | Diff

[mlagally]

This MR contains changes out of scope of the geolocation section.

I reviewed that section, i.e. lines 1834-1884 only.
We have to be more specific on which of the schema.org properties should be used, to define which types from schema.org MUST be supported on the consumer.

I think we should clarify that only properties for GeoCoordinates:elevation, altitude and longitude are defined in the profile.
On elevation there's a dependency of 'UNITOFMEASUREMENT' with a default of meters. We should clarify if non-metric values must be supported, or if we constrain to meters and leave it to the consumer to convert to the locale of the user.

Properties from GeoCoordinates

PostalAddress  or Text | Physical address of the item.
Country  or Text | The country. For example, USA. You can also provide the two-letter ISO 3166-1 alpha-2 country code.
Number  or Text | The elevation of a location (WGS 84). Values may be of the form 'NUMBER UNITOFMEASUREMENT' (e.g., '1,000 m', '3,200 ft') while numbers alone should be assumed to be a value in meters.
Number  or Text | The latitude of a location. For example 37.42242 (WGS 84).
Number  or Text | The longitude of a location. For example -122.08585 (WGS 84).
Text | The postal code. For example, 94043.

Properties from GeoCoordinates
address PostalAddress or
Text Physical address of the item.
addressCountry Country or
Text The country. For example, USA. You can also provide the two-letter ISO 3166-1 alpha-2 country code.
elevation Number or
Text The elevation of a location (WGS 84). Values may be of the form 'NUMBER UNITOFMEASUREMENT' (e.g., '1,000 m', '3,200 ft') while numbers alone should be assumed to be a value in meters.
latitude Number or
Text The latitude of a location. For example 37.42242 (WGS 84).
longitude Number or
Text The longitude of a location. For example -122.08585 (WGS 84).
postalCode Text The postal code. For example, 94043.

[benfrancis]

This MR contains changes out of scope of the geolocation section.

Please see my comment from above:

Note that this PR depends on #260 which adds a Semantic Annotations section under Common Constraints. Please only review the final commit cfa5716

This text is being added to a section created in #260 and so depends on that PR. I can rebase this PR if and when that one lands.

We have to be more specific on which of the schema.org properties should be used, to define which types from schema.org MUST be supported on the consumer.

I don't object to the idea of making support for schema.org's latitude, longitude and elevation properties mandatory, if we can define what "supports" means, to the extent that the assertions are testable.

However, I think we need to have a group discussion about the principle of making support for for certain semantic annotations mandatory for Consumers. Semantic annotations are intended as hints to the Consumer about additional semantic context of data emitted from or consumed by a Thing, but it's difficult to define exactly what a Consumer needs to implement in order to "support" them. What does it mean for a Consumer to "support" geolocation annotations? Does it need to be able to plot them on a map, plot them on a 3D model, import them into a knowledge graph, or simply display the values to a user? What if the Consumer doesn't have a graphical user interface?

Additionally, if we accept the principle that some semantic annotations must be supported by Consumers in all three of the current profiles, then it opens the door to expand this to many other semantic annotations and ontologies in the future. What criteria do we use to decide which annotations should be mandatory to support, and where do we stop?

Simply recommending support for certain very common cross-domain semantic annotations could be a compromise which helps improve interoperability by nudging implementations towards certain ontologies, whilst not creating too much of an implementation burden for Consumers which may not actually need them, and accepting the richness that the extensible nature of semantic extensions allows.

[benfrancis]

Since #137 has been tagged as postponed until WoT Profile 1.1, should I close this PR?

[sebastiankb]

I would not support this PR since geolaction has different facets. There are different approaches

[sebastiankb]

I think, it is not a good idea to concentrate only on a single geo ontology. The proposal should be open to use different geo location approaches that, e.g., work indoor and outdoor. Building typical uses different location information such as zone, level, room number, etc. . I think many or most IoT devices are used within buildings, so we should support these approaches.

[benfrancis]

Closing, as we will re-visit this in 1.1. Tagged as Profile-1.1 to remind us.