W3C home > Mailing lists > Public > public-poiwg@w3.org > October 2010

Re: WG Objectives - A Personal Take

From: Philipp Slusallek <slusallek@cs.uni-saarland.de>
Date: Fri, 29 Oct 2010 06:19:44 +0200
Message-ID: <4CCA4B60.4080201@cs.uni-saarland.de>
To: Marengo Marco <marco.marengo@telecomitalia.it>
CC: "Seiler, Karl" <karl.seiler@navteq.com>, "cperey@perey.com" <cperey@perey.com>, Raj Singh <rsingh@opengeospatial.org>, "public-poiwg@w3.org" <public-poiwg@w3.org>, Carl Reed <creed@opengeospatial.org>, "gary.gale@nokia.com" <gary.gale@nokia.com>, "member-poiwg@w3.org" <member-poiwg@w3.org>

[For a short introduction of myself please see

Let me comment a bit on the definition of POIs.

I see two levels of specification here: One defines a point or a region
in space and/or time directly, while the other defines some data that
can be converted by some internal/external "service" into the former.
We could call these "direct" and "indirect" POI specifications.

In the latter case, e.g. an address/term of a place ontology/etc can be
converted into a point on the street in front of the house (albeit
typically not yet into the extent covered by the house/ground referred
to by the address, see below) by Google Maps or such. I would call such
direct or indirect addresses "absolute" with respect to some fixed
coordinate system (such as WGS84).

Having the ability to nest several such POIs relative to each other
would certainly be very useful, in order to describe related POIs, e.g.
multiple entries to a building/site. Having the ability to link POIs to
each other via URLs and a href-like structure seems useful too as it
allows for expressing the relationship without having to change the
referred to POI.

There are also "relative" POI markers, relative to some observer: E.g.
given some optical features (e.g. SIFT or similar AR features), a
service (AR) can convert them to coordinates relative to the camera
("some direction X relative to the viewing direction of the camera and
about 150m away").

Such relative coordinates are often combined with at least rough
absolute coordinates such that you do not have to search the complete
data base of relative features to find the one that are likely to apply
(this is more of an optimization but can also be used as a refinement of
the absolute position).

If relative features have associated absolute coordinates, the relation
(transform) between the two is usually also given, such that an absolute
position can be derived from seeing the relative features (and vice
versa). But this is a separate and independent step.

Let me comment also on the absolute coordinates some more: While points
are simple, its often unclear how to interpret them -- they do not have
any scale. E.g. the notion of two points being "near" to each other does
not make any sense -- unless there is some sort of scale given as well.
However, that scale (e.g. distance) essentially defines a region around
one of the points and the "near" query really converts to a "point in
region" query (that query is symmetric, though). Often the scale is
implicitly defined by the query point ("being near" for a walking person
is different to "being near" for a fast driving car) but this might not
apply or make much sense in some applications.

As a consequence, I believe it is useful to at least conceptually always
consider POIs to be a region of some sort -- just to be able to have a
notion of this "scale" independently from the query. A "point" would
then simply be a region with a really small/zero extent/radius. This
also generalizes nicely to cases where the POI really is defined by a
region (polygon, 3D space enclosed by polygons, whatever).

Finally, the definition should be extended to also include the time
dimension, where similar concepts do apply almost equally.

Things get quite a bit more involved though, when the space and time
dimensions are no longer independent. In graphics we would talk of an
"animated POI". And that might really be what we need to describe them
and where to borrow the ideas for representations from. However,
animations are often evaluated in a forward direction ("given some
time, tell me what the object looks like at that point in time"). For
many queries this is perfectly fine, as we know the current time and can
thus find the query region to work with.

Sometimes, however, we are facing a different issue that we want
to answer a query in space-time ("what are the points/intervalls in time
where this space-time point is inside the animated region"). They are a
bit more difficult to answer and process.

Finally, on a related note, let me point you to some new activities we
have started recently to take a fresh look at interactive 3D for the
Web: XML3D. "Not again a new format for 3D on the Web" is the usual
reaction at this point, which we understand and actually share :-).

However, as we argue in our recent paper
(https://graphics.cs.uni-saarland.de/index.php?id=534) existing 3D
approaches are severely lacking in respect to the Web. So XML3D starts
exactly where the Web/HTML5 is today adding 3D as a minimal but
orthogonal extension to HTML. Essentially our approach is to make 3D
programming as similar to 2D Web design, such that all Web designers
could immediately start applying their 2D Web experience also to 3D,
expanding the pool of 3D application developers by several orders of

Instead of seeing 3D as an add on, our approach sees 3D as an integral
part of HTML, even going to the point where 3D concepts (e.g. like
procedural shaders) could apply as well to 2D content as they do for 2D
content (note that not all of this described is in the above paper yet,
but will be in a follow up).

Initial alpha versions of our implementations in Firefox and
Webkit/Chromium as well via WebGL are available on xml3d.org, of course
also including the current spec for XML3D.

We are organizing a "3D on the Web" session for the TPAC W3C conference
next week (Monday afternoon), where we will discuss where we are with
respect to 3D on the Web and suggest/discuss next steps to be taken.
Note: that in addition to our XML3D approach, X3DOM will also be
presented as we have joined forces with the Fraunhofer group now to
define a common approach for 3D embedded directly into HTML. I believe
this could be very interesting also for the POI working group.

Thanks for listening,

	Philipp Slusallek

Let me also comment
Am 26.10.2010 16:38, schrieb Marengo Marco:
> Hi,
> +1 to extensibility. I think our goal as a W3C WG is to try to provide a recommendation which facilitates the distribution of point of interest information. Just as RSS did in other contexts: from news sharing to podcasting... that's a success story.
> I've been thinking of a definition of POI, starting from Carl Reed's input:
> "Point of Interest (POI): A location (with a known position at a certain time) where one can find a place, product or service, typically identified by name rather than by address and characterized by a URI, which may be used as a reference point or a target in a location based service request, e.g., as the destination of a route."
> And this is imho the smallest subset of information which can describe a POI (this is built on top of Gary Gale's contribution):
>         1. A centroid (latitude, longitude)
>                         in a widely adopted  system (e.g. WGS 84)
>         2. An extent (described either by a vector set or by an MBR)
>         3. A category / type
>                         possibly referring to a Place Ontology. Otherwise every POI Provider will define its own vocabulary
>         4. A URI
>         5. An address (although the larger the place the less meaningful this becomes)
>                         although the address may be really generic, as highlighted by Carl Reed
>         6. Contact information (if applicable)
>                          using a widely adopted standard (e.g. OMA CAB, or whatever standard we agree upon)
> We should also suggest a set of extensions, which will cover (hopefully) all the use cases that we want to support.
> Marco
> Il giorno 26/ott/2010, alle ore 15.23, Seiler, Karl ha scritto:
>> Right, the key term here is extensibility.
>> In defining the base / core attributes shared by most POIs our goal should be to make it easy for data to participate in the standard:
>> Name (can range from legal name, chain/brand name, to doing-business-as name) - I recommend for the base attribution we try to define what a "common use" name is
>> Location (this can range from a single point in the center of the building, to an address, to street geometry, to multiple locations to describe a place, to...) - I recommend making this as simple as a X/Y of the center point, and an optional (official) address
>> Contact (this can range from phone, to URL, to lists of contacts) - Probably the minimum is an optional phone number
>> Type (this can range from high level - is a business vs. a landmark, to industry standard business descriptors, to emerging models, to open ended hierarchical tagging) - I recommend we consider one or more existing business classification standards and not try to reinvent
>> A universal ID would be very nice addition to the Core / Base attributes if possible...
>> Beyond that the key to me is to define an open-ended way to define the richness of the world of places that enhances system to system use/reuse while maintaining ease of compliance.
>> _______________________________
>> Karl Seiler
>> Director Location Technology & Services
>> NAVTEQ - Chicago
>> (T)  +312-894-7231
>> (M) +312-375-5932
>> www.navteq.com
>> -----Original Message-----
>> From: member-poiwg-request@w3.org [mailto:member-poiwg-request@w3.org] On Behalf Of Christine Perey
>> Sent: Monday, October 25, 2010 11:19 PM
>> To: Raj Singh; public-poiwg@w3.org
>> Cc: Carl Reed; gary.gale@nokia.com; member-poiwg@w3.org
>> Subject: Re: WG Objectives - A Personal Take
>> +1 to what Raj wrote.
>> Today's POI definition does not fit all evolving use cases.
>> Keywords:
>> - extensible
>> - encoding standard
>> - covers "stationary POI" (what I call the "fixed POI") as well as
>> non-stationary (probably needs another name to say "everything that can
>> be a trigger for an AR experience")
>> +1+1 on
>>> Basically, the same ethic that underlies HTML and Atom.
>> Regards,
>> --
>> Christine
>> Spime Wrangler
>> cperey@perey.com
>> mobile +86 132 6171 6195
>> VoIP (rings in Beijing) +1 (617) 848-8159
>> Skype (from anywhere) Christine_Perey
>> On 10/25/2010 7:30 PM, Raj Singh wrote:
>>> I like this definition of POI (and not just because I'm also on OGC staff!). However, I also see that it will not fit all the evolving use cases in this group.
>>> I'd like to see us create an extensible POI encoding standard, such that very simple things--such as a stationary POI--can be encoded very simply and more complex things can still be encoded, but can also still be partially understood by software designed for the simpler markup. Basically, the same ethic that underlies HTML and Atom.
>>> ---
>>> Raj
>>> The OGC: Making location count...
>>> http://www.opengeospatial.org/contact
>>> On Oct 22, at 9:36 PM, Carl Reed wrote:
>>>> Gary -
>>>> The OGC has a standard titled, "Open Location Services Core". That standard was originally developed by a number of OGC Members and continues to be enhanced and extended. The key Members involved were/are NavTeq, Hutchison 3G, ESRI, MobileMapping, Image Matters, Webraska, Intergraph, MapInfo, Oracle, Autodesk, ERDAS (now part of Hexagon), Tele Atlas, and DeCarta and then agreed to by the OGC Membership. In that document, there is a definition of POI as an abstract data type. Perhaps this can be a "strawman" definition.
>>>> Point of Interest (POI): A location (with a fixed position) where one can find a place, product or service, typically identified by name rather than by address and characterized by type, which may be used as a reference point or a target in a location based service request, e.g., as the destination of a route.
>>>> Now of course since this definition was agreed to in the OGC, there is the perhaps the issue of mobility to be considered.
>>>> Regards
>>>> Carl
>>>> ----- Original Message ----- From:<gary.gale@nokia.com>
>>>> To:<member-poiwg@w3.org>
>>>> Sent: Friday, October 22, 2010 5:48 AM
>>>> Subject: WG Objectives - A Personal Take
>>>> Hi everyone,
>>>> Here's my take on what I'd like to see coming out of the group ...
>>>> 1) a definition of what actually constitutes a POI
>>>> 2) following on from the previous definition ... what the difference is, if any, between a POI and a Place
>>>> 3) what basic attributes and metadata should be utilized in order to define a POI/Place
>>>> 4) how to articulate that definition and set of attributes in terms of best practice
>>>> 5) how to showcase and encourage innovative uses of POI data
>>>> Best
>>>> G
>>>> --
>>>> Gary Gale
>>>> Director, Ovi Places Registry, Nokia Gate5 GmbH
>>>> Invalidenstr 117, 10115 Berlin, Germany
>>>> UK: +44.7508.000336 | DE: +49.1515.5150909
>>>> 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.
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
> This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Received on Saturday, 30 October 2010 15:48:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:26 UTC