Evaluate geolocation terms in TD model (input from Profile TF)

[sebastiankb]

There are new vocabulary proposed in the latest Profile draft (also see w3c/wot-profile#17). Which should evaluate how those should be covered in the core model. Which should also clarify which existing ontologies can be re-used for this kind of vocabulary.

See for a justification why loc_altitude is problematic.

[sebastiankb]

for the geo based terms (loc_latitude, loc_longitude, loc_altitude, loc_height, loc_depth) we should check GeoSPARQL https://www.ogc.org/standards/geosparql which seems also to be used by SSN.

[sebastiankb]

here is another source https://www.w3.org/community/geosemweb/

[sebastiankb]

another (prominent) ontology https://lov.linkeddata.es/dataset/lov/vocabs/geo

[sebastiankb]

In today's TD call we discuss the option to define a geo container like geoLocation that embeds all geo-location based terms.

• There is a discussion in the Use Case TF about different geo location standards: Update OAuth2 section #927
• A promising one seems to be https://www.w3.org/TR/geolocation-API , however, there is no RDF representation yet.
• @mmccool will ask Dan Brickley if there are some plans
• we should also check https://schema.org/GeoCoordinates and NGSI-LD

[benfrancis]

• we should also check https://schema.org/GeoCoordinates

E.g.

{
  "@context": [
        "https://www.w3.org/2019/wot/td/v1",
        { "s": "http://schema.org" }
    ],
    "id": "urn:dev:ops:32473-WoTLamp-1234",
    "s:longitude": "40.75",
    "s:latitude": "73.98",
    "s:elevation": "15",
    "s:manufacturer": {"name": "Acme"},
    "title": "MyLampThing",
    ...
}

[egekorkan]

I would also be for using the already existing vocabularies in schema.org

[takuki]

In Spatial Data on the Web Best Practices (2017), there is a Best Practice provided for "State how coordinate values are encoded" (Best Practice 8).

It uses both Basic Geo (WGS84 lat/long) Vocabulary and Schema.org.
It is also noted the definitions provided in schema.org do not indicate the unit of measure, as of 2017 at least.

[sebastiankb]

From today's TD call:

• for next draft it is recommended to provide examples how geo-based data can be integrated in TDs (e.g., based from schema.org)
• there should be examples at top level and also within interaction level like in a property
• it should be also explain that different ontologies can be used based on the use cases
• @sebastiankb will provide a PR

[mmccool]

Don't think we should close this until we discuss with SDWIG and OCG, maybe write up an example (and include in the TD spec?). I've labelled this issue so it shows up in the joint meeting planned for Dec 10 (see w3c/wot#939).

[sebastiankb]

@mmccool I think this issue can be closed. We have introduced a new section about geolocation semantics here https://w3c.github.io/wot-thing-description/#semantic-annotations-example-geoloc

[mlagally]

@sebastiankb
I reviewed the example and did not see an encoding of the altitude / elevation, height and depth, that were in the profile.
I believe we have a gap between the required representations of geolocation data and the current example.
I'm reopening the issue.

[egekorkan]

Altitude can be simply added. What is meant by height and depth? Do you mean the size of the object? We have the following:
https://schema.org/height and https://schema.org/depth

[mlagally]

Thanks @EGE for the pointers.

Height and depth are object dimensions, used for example for geofencing.
They could be used from schema.org, we also should include width.

Altitude is the height above seal level, normal null, or some other 0 reference point.
We have to carefully chose the reference level (E.g.: there are different reference sea levels of the atlantic and mediterranean) to make the system work globally.