Re: Next steps

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 Wednesday, 18 August 2010 16:15:37 UTC