Re: Representing time-dependent objects in POI data model

This has been suggested before:
<http://www.w3.org/2010/POI/wiki/Data_Model>
From an existing standards point of view, it would be helpful is someone finds examples of this in other standards (I can think already of GML and KML) and puts a note into the Data Model page.

On Nov 1, 2010, at 7:45 AM, Sara-Jayne Farmer wrote:

> I can't get onto the POI wiki, so can I make a request please?  Many of the points of interest I deal with (in transport and crisismapping) are temporary or moving - for instance, a refugee camp may only exist for a few days or weeks.   Can we consider adding a time field to the POI data model, e.g. "date created", "date updated" to cover these please?
> 
> My apologies if this question seems naïve - I'm new round here, and just starting to feel my way around. 
> 
> Thank you,
> 
> 
> 
> Sara.
> 
> -----Original Message-----
> From: public-poiwg-request@w3.org [mailto:public-poiwg-request@w3.org] On Behalf Of Raj Singh
> Sent: 28 October 2010 16:46
> To: public-poiwg@w3.org W3C
> Subject: POI data model
> 
> I changed centroid to anchor and made a new section for listing types of anchors. We can worry about the extensibility mechanism later. 
> 
> Jens, I worry about anchors that only have 2D or 3D grid references within a building. It seems to me much harder to ensure interoperability and "linked data" without a common geographic reference. Maybe every space can at least have a geographic anchor for the enclosing building, then use a local grid reference system (x,y,z) to go from the building's anchor to the individual space.
> 
> Can you post your suggestions to the wiki?
> 
> ---
> Raj
> The OGC: Making location count...
> http://www.opengeospatial.org/contact
> 
> 
> On Oct 28, at 8:46 AM, Jens de Smit 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.
>> 
> 
> 
> 
> 

Alex Hill Ph.D.
Postdoctoral Fellow
Augmented Environments Laboratory
Georgia Institute of Technology
http://www.augmentedenvironments.org/lab