Re: Next steps

I think two levels (i.e. [criteria]<>[data]) is too simplistic. I would like to see a three level approach:
[criteria]<>[representation]<>[actual data]

This is of course more similar to links on the web. A web link can be represented by a text string, an image etc. In a similar way (AR) POIs should have a separation between the actual data and its representation as a POI.

It could be visual (e.g. flat icon, 3D model, text), audio, tactile feedback and so on. It could also be a combination for a more poweful impression or listing several representations in order to enable different type of devices to deal with it depending on its capabilities (e.g. a device with no screen needs the audio or tactile representation).

Cheers,
Klas

On Aug 18, 2010, at 18:15 , Thomas Wrobel wrote:

> I think I see where your both coming from. Henning was closer to what
> I was picturing.
> Unfortuntely Ive been away with little time to read in detail whats
> been happing.
> 
> I would certainly be very wary of mixing the data up with the critera
> (in this case location), that could quickly get very messy imho.
> 
> Would not the first task be merely to establish a generic way to
> position *ANY* data? I dont think we need to worry about the type of
> data for now.
> The such data could be included inline, or a simple link to a remote source.
> 
> So if the generic global task for positioning any data to any *paturn* is;
> [criteria]<>[data]
> Where data is the contents and criteria is the location (or other
> parameters) to specify when/how it should be displayed.
> 
> Now, if we are taking geolocation as the low-hanging fruit subset of
> this much more wide task
> it would be;
> [positioning information]<>[data]
> 
> So this could be specified in all many of ways, either as triplets, or
> xml style etc.
> We have to just be very clear, that the positioning information could
> be, say, a polygon, that in turn specify´s a data property. (say, a
> text property of ¨public park¨). But we could also have a positioning
> information (say, a simple gps point) that specifies a data that *is*
> a polygon.
> 
> In this scenario we would want the specification to allow this
> scenario, and not allow for confusion.
> 
> Its also posiable at some point we would want a *volume* to be the
> positioning information (say, a building).
> While this might not be something to worry specificly about now, I
> think separating the data to be positioned from the positioning
> criteria would make these possibilitys easier in future.
> 
> Finaly, sorry if Iḿ not as clear as I could be, I have limited time to
> form this response so its a little rushed!
> 
> Cheers,
> Thomas Wrobel
> 
> 
> 
> 
> 
> 
> 
> On 18 August 2010 15:45, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
>> 
>>> - Physical Object Identifier : (maybe Recommendations)
>>>  : it's a URI scheme. and it's a unified identifier (and markup) for any physical object in augmented environment(product, person, location ...)
>>>  Poi:UPC.<upcnumber>
>>>  Poi:Geo.<lat>,<lon>[,<alt>][;u=<uncertainty>]
>>>  Poi:tel.<phonenumber>
>>>  Poi:doi.<publishernumber>/<suffix>
>>>  Poi:ufid.<ufid number>
>>>  Poi:epc.<epc code>
>>>  Poi:ean.<ean code>
>>>  Poi:isbn.<isbn number>
>>>  ...
>> 
>> We already have geo URI (see RFC 5870) and tel URIs (RFC 3996), so it seems unwise to duplicate them.
>> 
>> I admit that I'm having a hard time wrapping my head around the POI description idea. In its most general form, this could include a complete map of the US, with all mark-up, duplicating a full GIS system (see OpenGIS). I suspect we don't want to go there. To have a chance to succeed, a much more narrow first version seems more likely to actually see implementation. There has been significant work in the IETF GEOPRIV WG on describing 2d/3d polygons, among other simple shapes (arc band, circle, ....), as a subset of the OpenGIS effort, which might well hit the 90%-of-likely-usecases mark. Similarly, we don't want to re-invent vCal for a full calendaring description ("A concert occurs here every Tuesday, except on the 5th Tuesday of the month and during the month of July").
>> 
>> To see if we're on the roughly same page, here's a mockup of something I see as plausible (without worrying about precise date formats and the like):
>> 
>> <expires>May 17, 2011</expires>
>> <when>vCal string [not applicable for the park example]</when>
>> <where>a 2D polygon</where>
>> <what>urn:poi:park</what>
>> <details>Central Park, Manhattan</details>
>> 
>> 
>> Henning
>> 
>

Received on Thursday, 19 August 2010 21:20:25 UTC