Re: WG Objectives - A Personal Take

+1 to "anchor" term. It seems to fit very well to me.

I do say though I'm not  sure linking to a building(name?) would be
better then just linking to its co-ordinates; buildings don't move, so
if its location is looked up at run-time, surely thats adding
unnecessary overhead on the client end?
There could, however, be some sort of system for swapping building
names for co-ordinates; an "infrastructural looked-up" style
system/api. Possibly used as a optional "snap too" function for
clients submitting data. ("Did you mean to post on [building name]?
Yes - post on buildings anchor, No - post at my exact co-ordinates
specified"). This would be used when submitting data, but not every
time a client needs to read the data.
(imagine a client wants to see things within a certain range, if it
can just look down a list of co-ordinates, thats much quicker/less
bandwidth then converting a list of names first to a list of
co-ordinates and thne checking).

Expansion potential to link to dynamic objects is a must though.
Partly this could be just another form of image anchor (markers being
a sub-set of that), but you could also at some point have RFID
anchors. I love the tv highlighting use-case, but I can only see it
working as advanced image recognition or the player carrying a "becon"
of some form.




On 28 October 2010 14:46, Jens de Smit <jens.desmit@surfnet.nl> wrote:
> On 27/10/2010 20:09, Raj Singh wrote:
>> I made a page for the data model discussion:
>> http://www.w3.org/2010/POI/wiki/Data_Model
>
> Hello all,
>
> Thanks Raj for writing this down, this gives us something to start a
> discussion from. It seems you based your list primarily on Marco's
> "smallest subset if information which can describe a POI" which in turn
> was based on Gary's contributions. However, one thing Marco also
> mentioned as being important was "extensibility"; I'd like to agree with
> that and propose to make a significant change to the data model along
> the following lines:
>
> Replace "centroid" by a more flexible "anchor" (terminology subject to
> discussion) property which describes where in the world the POI belongs.
> This anchor property should have an attribute/subtype that specifies how
> its data should be interpreted. A lat/lon/alt in WGS84 type anchor seems
> to be a very obvious anchor type to define, but the following anchor
> types come to mind as well:
>
> - x,y locations on a 2D grid/ x,y,z locations on a 3D grid
> Use case: situations where lat/lon/alt are impractical, such as in
> buildings where dimensions are usually measured in meters. Much easier
> and faster authoring
>
> - fiducial markers or images
> Use case: Augmented Reality experiences obviously, but could also be
> applied to virtual worlds
>
> - buildings
> Use case: again, easier authoring than looking up lat/lon coordinates
> for everything you want to describe. Also, it conveys a string
> connection between the POI and the real-world entity that is being
> described. This allows for smarter and nicer user interfaces; for
> example see
> http://www.perey.com/ARStandards/Nokia_A_Web_Services_Platform.pdf by
> Nokia's Petros Belimpasakis et al for some functional AR examples of
> tying POIs and buildings together, but the same usability holds for maps
> and virtual worlds.
>
> - dynamic entities
> Use case: wouldn't it be neat to describe a car or person as POI? As
> computer vision improves, computers can track and recognize more and
> more of the world around us. The AR use case is again obvious, but what
> if you could dsignate your favourite football player as a POI? Apply
> some CSS-like "outer-glow: 3pt yellow;" effect to your POI, link it to
> the WebTV stream you're watching and you'll never lose track of him again.
>
>
> So the last example is a bit futuristic and probably won't be part of
> the first spec but I hope it conveys why I think having a flexible (and
> extensible) "anchor" property would be better than hardcoding a centroid
> for each point. All the other properties that have been written down
> (except perhaps address) are useful for any of these use cases which is
> why I would really like this flexibility in the spec.
>
> Looking forward to your opinions!
>
>
> Best regards,
>
> Jens
>
> Also, this list is not exhaustive and I welcome other suggestions as well.
>
>

Received on Thursday, 28 October 2010 13:11:24 UTC