Re: WG Objectives - A Personal Take

+1 to Philipp's well written remarks which cover so many points about 
which I only glimpsed unclearly until I read this post carefully. Thank you!

+1 +1 to a remark made (by can't recall who) and which is precisely the 
point Carl makes for us (thank you), that we could benefit greatly from 
understanding better the landscape of what already exists. I believe 
that the terminology compilation should include citations from all the 
other possible sources of which we are aware.

For AR standards, a group of us  in Seoul approached the process of 
identifying gaps in standards by way of mapping what we believed to be 
relevant standards.

Maybe there is a better way to accomplish the objective but on Oct 11

1. we began with a map of related features/capabilities and services

2. we then simply "attached" (in boxes which were color coded (sorry no 
key) acronyms of organizations or standards with which those in the 
group had some acquaintance.

We published, for future refinement, the first draft here: 
http://www.perey.com/ARStandards/Landscape_of_AR_topics.pdf

Our goal was to return/refine this on the following day however:

1. we recognized that we did not have all the organizations represented 
in the workshop and risked missing major blocks.

2. we moved to other tasks which we felt were equally important for us 
to begin.

This process will be continued on a separate mailing list.

-- 
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/29/2010 7:34 PM, Carl Reed wrote:
> Philipp -
>
> Thanks for the great comments and thoughts!
>
> You might be interested that many of these discussion topics that you
> suggest this group consider have been discussed at length in the IETF
> GeoPRIV Working Group (http://datatracker.ietf.org/wg/geopriv/charter/)
> . There are numerous internet GeoPRIV related RFCs as well as documents
> in progress. The issue of "uncertainty" is a big consideration. (you
> point of a POI being represented by a polygon geometry as opposed to a
> point geometry. Relative location is another big discussion topic. The
> GeoPRIV documents can be found here:
> http://datatracker.ietf.org/wg/geopriv/ . Also note that there is a GML
> application schema used to represent location elements, including
> uncertainty regions, that is used in numerous internet RFCs.
>
> I have been working with this group as the OGC representative since 2002.
>
> Regards
>
> Carl
>
>
>
>
>
> ----- Original Message ----- From: "Philipp Slusallek"
> <slusallek@cs.uni-saarland.de>
> To: "Marengo Marco" <marco.marengo@telecomitalia.it>
> Cc: "Seiler, Karl" <karl.seiler@navteq.com>; <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: Thursday, October 28, 2010 10:19 PM
> 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.
>>>
>>>
>>
>>
>
>
>
>

Received on Saturday, 30 October 2010 06:05:40 UTC