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

Re: WG Objectives - A Personal Take

From: Carl Reed <creed@opengeospatial.org>
Date: Fri, 29 Oct 2010 08:06:58 -0600
Message-ID: <0A1DC689D1354E7B9234A3D055AA909E@CarlandSusieOf>
To: "Seiler, Karl" <karl.seiler@navteq.com>, "Philipp Slusallek" <slusallek@cs.uni-saarland.de>, "Marengo Marco" <marco.marengo@telecomitalia.it>
Cc: <cperey@perey.com>, "Raj Singh" <rsingh@opengeospatial.org>, <public-poiwg@w3.org>, <gary.gale@nokia.com>, <member-poiwg@w3.org>
I should add that your examples are very close to what a POI is as defined 
in the OGC Open Location Services standard. In the OGC definition, location 
is a property of the POI.

Cheers

Carl

----- Original Message ----- 
From: "Seiler, Karl" <karl.seiler@navteq.com>
To: "Philipp Slusallek" <slusallek@cs.uni-saarland.de>; "Marengo Marco" 
<marco.marengo@telecomitalia.it>
Cc: <cperey@perey.com>; "Raj Singh" <rsingh@opengeospatial.org>; 
<public-poiwg@w3.org>; "Carl Reed" <creed@opengeospatial.org>; 
<gary.gale@nokia.com>; <member-poiwg@w3.org>
Sent: Friday, October 29, 2010 8:00 AM
Subject: RE: WG Objectives - A Personal Take


>I am concerned that we keep trying to define systems to define the richness 
>of stationary locations and not POIs.
>
> Back to...
>
> To kick off a thread on Gary's challenge
> 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
>
> I propose in the simplest sense:
> A place is a location / anchor
> A POI is what is at that place
>
> Thus:
> Location/anchor - x/y, 123 Main st
> POI - Karl's Car Wash...
>
> Location/anchor - x/y
> POI - Buckingham Fountain in Grant Park...
>
> Location/anchor - x/y, 425 W Randolph..., 17th floor, Office 17B103...
> POI - Karl Seiler - Office
>
> Location/anchor - POLY: (x/y >> x/y >> x/y >>x/y),...
> POI - Sheppard's Crook Golf Course (area)
>
> ...
>
> Let's first tackle the simple definition of what is a POI and then link it 
> to location definitions.
>
> _______________________________
> Karl Seiler
> Director Location Technology & Services
> NAVTEQ - Chicago
> (T)  +312-894-7231
> (M) +312-375-5932
> www.navteq.com
>
>
> -----Original Message-----
> From: Philipp Slusallek [mailto:slusallek@cs.uni-saarland.de]
> Sent: Thursday, October 28, 2010 11:20 PM
> To: Marengo Marco
> Cc: Seiler, Karl; cperey@perey.com; Raj Singh; public-poiwg@w3.org; Carl 
> Reed; gary.gale@nokia.com; member-poiwg@w3.org
> Subject: Re: WG Objectives - A Personal Take
>
> Hi,
>
> [For a short introduction of myself please see
>        http://graphics.cs.uni-saarland.de/slusallek/]
>
> 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
> magnitude.
>
> 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.
>>
>>
>
>
>
> 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.
>
> 
Received on Friday, 29 October 2010 14:56:02 UTC

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