RE: Action 25 - POI Relationships

As promised I took a stab at fleshing out the "location primitive".

Locations Primitive

Goal:
Provide a rich and flexible description of a location
De-couple or isolate the description of a Place of Interest from its geospatial location, since many Places can be at the same location, and Places of Interest can change locations.
A Place Of Interest has one location.
A Place of Interest can be a parent to other Places Of Interest each with its own location to allow for the representation of complex places that are the aggregate of a collection of Places (campuses, business with multiple entrances, large constructs like parks, etc.).
It should not be inferred that each of the elements within the location primitive are not spatially synonymous, but do refer to the same place.

High Level Attribution:

Place Of Interest
Location
Identification
Geo-Reference
Map-Reference

Location Attribution Details

Location

Identification
                ID (optional)
Identification System or Service
ID
Associated IDs
Name
Last Updated On : Date/Time  (optional)
Updated By : owner / author (optional)
Use : public, private, restrictions (optional)
Status : Active, blocked, deleted (optional)
Trustworthiness : degree of certainty the author has in the accuracy of the location

Geo-Reference

Point (optional)
                                Type
High-precision - resolved to a level of granularity that enables a person to get within a few meters
Interpolated - estimated point on a street
Low precision - are meant for approximate locations, general areas

Center Point Coordinates (need at least one point descriptor)
System - assumes WGS 84 (optional)
Longitude
Latitude
Altitude : defines the height in meters above or below sea
level

Navigation Coordinates
System - assumes WGS 84 (optional)
Longitude
Latitude
Altitude

Address (optional)
ISO country code (ISO 3166-1 alpha-3 country code)
ISO Language Code (3-alpha MARC language)
Street (can contain a variable mix of house number prefix, suffix, street base name and or street type)
floor (optional)
suite (optional)
area(s) (can contain a variable mix of administrative regions,: neighborhood, city, state, etc.) (optional)
postal code (optional)

                Line (optional)

Points (repeating for a directed linked list of points)
Point
                                                                Start/End/way point
System - assumes WGS 84 (optional)
Longitude
Latitude
Altitude

2D Polygon (optional)
                                Points (repeating for a directed linked list of points)
Point
                                                                Start/End/way point
System - assumes WGS 84 (optional)
Longitude
Latitude
Altitude
3D Object (optional)
TBD

Area - not really needed as can be represented by a Center Point +/-, polygon, and or address with admin area data only

Unknown (optional)

Relative (optional)
Distance
Bearing
Reference
Point (optional) - see above
Address (optional) - see above
Line (optional) - see above
2D Polygon (optional) - see above
3D Object (optional) - see above

Map-Reference (optional)
Supplier
Version
Associated Map Object ID
Side
Spot


_______________________________
Karl Seiler
Director Location Technology & Services
NAVTEQ - Chicago
(T)  +312-894-7231
(M) +312-375-5932
www.navteq.com<http://www.navteq.com/>

From: public-poiwg-request@w3.org [mailto:public-poiwg-request@w3.org] On Behalf Of gary.gale@nokia.com
Sent: Monday, January 24, 2011 10:47 AM
To: public-poiwg@w3.org
Cc: sophia.parafina@gmail.com; darkflame@gmail.com
Subject: Re: Action 25 - POI Relationships

I want to address the points raised by both Sophia and Thomas in a single email, to avoid duplication ...

Sophia ...

<snip>
I (am) curious as to how handle the location semantics for adjacencies. How does one translate terms such as "next to", "in front of", "to the right", "close to" etc. Because these terms are relative to the observer's position, at minimum there seems to be a need for bearing and distance.
</snip>

Thomas ...

<snip>
Quick question; would those parent/child co-ordinates also tie into
the relationship in positioning?

For instance, would a child be positioned relative to the parent ?

This would be very usefull if the case, as it means one AR object
could be stuck on another in the field of view, while still letting
them come from different sources. (so, that is, the child would need
to specify what its parent is, then the client would look up where the
parent us, and use the childs co-ordinates to position it relative to
that).

This obviously wouldn't work for non-locational parent/child
relationships, but it seems something far too usefull to be left out
for real AR applications - especially when one of the POI could be
moving. (so that rather then updating dozens of co-ordinates, your
just updating the parent co-ordinate of,say, a "car" and everything
else the user has stuck to it moves accordingly as they are relatively
positioned)
</snip>

... both of these questions are (from my perspective at least) coming to this from a strong AR world view. There's absolutely nothing wrong with this (indeed it's to be both applauded and expected given the charter of the WG).

However, when I wrote my original mail I deliberately wasn't considering the AR perspective. Why? For two reasons. Firstly, we need a basic building block of a POI to be defined, one we can (via the extensibility attribute) extend to meet higher level use cases, such as (but not limited to) AR. Secondly, the vast majority of POI usage out there on the internet has a very strong location and spatial pedigree and I felt that the base POI definition would find real-world application with this location/spatial heartland.

So my response basically is, there's no reason why we can't expend the POI model and the relationships to more (AR friendly) terms such as "close to" and "in front of" but I deliberately wasn't considering this.

I think it's not unfair to reiterate (via the medium of copy and paste) a comment I made in the WG conference call of 12th. January 2011 ...

<snip>
I need to reiterate things we mentioned in (the WG face-to-face meeting in) Atlanta. I think we agreed that we want to achieve here is not to describe every single thing in the world, as that's a monumental task, but at the same point in time we don't want to make the model so rigid and brittle that it cracks when someone tries to use it in a way we didn't expect.

... This is why we came up with this set of primitives that have a strong geo location and geo spatial bias, but the fact is that the work being done out there in industry and in the community is at the moment predominated by geospatial/located constructs.

... I haven't heard anything yet that keeps us from having short temporal things, or things in motion.
</snip>

... hope this is of help and (at least partially) provides an answer to why your questions and comments haven't been directly answered.

Best

G
On Jan 19, 2011, at 5:39 PM, ext sophia parafina wrote:


I curious as to how handle the location semantics for adjacencies. How does one translate terms such as "next to", "in front of", "to the right", "close to" etc. Because these terms are relative to the observer's position, at minimum there seems to be a need for bearing and distance.

sophia
On Wed, Jan 19, 2011 at 4:24 AM, <gary.gale@nokia.com<mailto:gary.gale@nokia.com>> wrote:
At a bare minimum it's now pretty much established that the definition of a POI contains attributes which detail both what the POI is and where the POI is. But we can significantly enrich the definition of a POI by including relationship information. This serves the dual purpose of increasing both discoverability and relevance of POI information ... two things which are highly attractive in today's internet economy.

So to kick start the discussion on POI relationships, I'm going to propose a minimum set of relationships that a POI can (and should) have, plus another possible extension to the minimum set.

Minimum Relationship Set ...

Parents - the superiors for a POI, either from a hierarchical administrative perspective or from a more colloquial or umbrella perspective ... establishing a "belongs to" relationship. A POI can have many different parents and those parents can be of many different types (administrative, postal code, colloquial, etc).

Children - the inferiors of a POI, again either from a hierarchical administrative perspective or by means of an "is contained by" relationship. As with parentage, a POI can have (and will have) many different children of many different types.

Adjacencies - those POIs which adjoin the current POI; an adjacency relationship should be considered to be
"near" but not necessarily sharing a border or being contiguous (as other geographical features such as rivers may prevent such a relationship but a bridge across the river allows the relationship).

Possible Extension Set

Another extension to the above relationship sets offers the ability to differentiate parents and "belongs to" and children and "is contained by". Whilst it could be argued that these extensions are simply specializations of the parent and child relations, applying such specialization increases discoverability by removing the need to traverse a POI hierarchy simply to determine whether a parent is an administrative one or a "belongs to" one.

Three immediate use cases spring to mind, regardless of whether the minimum set is utilized or the extensions.

1) Traverse the administrative hierarchy of a given POI, either "up" towards the top of the hierarchy (nominally the Earth) or "down" towards the lowest level of administrative granularity there is (nominally a street level address or a postal code).

2) Traverse adjacency relationships ... "find me POIs in a given neighborhood and if none are found, allow me to easily discover those POIs in an adjacent neighborhood"

3) Discover POIs in a colloquial geography, such as a non formalized neighborhood (such as London's Soho) or other construct (such as the UK's "Home Counties" or California's "Silicon Valley").

No doubt people will have comments on this ...

Best

G

--
Gary Gale
Director, Ovi Places Registry, Nokia Gate5 GmbH
Schönhauser Allee 180, 10119 Berlin, Germany
UK: +44.7508.000336 | DE: +49.1515.5150909
gary.gale@nokia.com<mailto:gary.gale@nokia.com>




--
Gary Gale
Director, Ovi Places Registry, Nokia Gate5 GmbH
Schönhauser Allee 180, 10119 Berlin, Germany
UK: +44.7508.000336 | DE: +49.1515.5150909
gary.gale@nokia.com<mailto:gary.gale@nokia.com>



The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above.  If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited.  If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.