Re: Next steps

Great to see areas of technical discussion like this already emerging that
would fit very well into the scope of the proposed charter. I think this
bodes well for future of this working group and should be a signal to the
w3c management team to fast track getting this group off the ground while
the community engagement is still strong.

Dan


On 18/08/2010 17:15, "Thomas Wrobel" <darkflame@gmail.com> 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
>> >
> 
>