Re: thoughts towards a draft AR WG charter

If the term trigger is used elsewhere, its best to avoid.
However, I believe the point of using a term like trigger is that it
doesn't just refer to a location triggering a bit of data to appear,
but also could refer to image based triggers, or other potential
trigger types.

You could, I suppose, think of them as "auto triggers". Triggered by
the user moving, or things coming into their FOV rather then a click
which is a more active form of user triggering. As you say, these
would involving query a database at an interval, but it would be
something automatically done by the browser, and not something
specifically coded for like with onClick style javascript events.

The triggers in this context are more akin to links...associating one
thing with another with the code for them to work fixed and part of
the browser itself.
Only in this case the association is not between two web pages, but
rather between some real-world device based event, and a bit of
virtual information.

I think Rob Manson expressed it well as a form of triplet;

>"Well...if we did use the "trigger" model then I'd express this as the
>following RDFa style triplet:
>
>       this [location] is a [trigger] for [this information]
>
>POIs in this format would then become the archetypal AR relationship.
>The most critical and common subset of the broader relationship:
>
 >      this [sensor data bundle] is a [trigger] for [this information]
>
>In the standard POIs case the minimum [sensor data bundle] is "lat/lon"
>and then optionally "relative magnetic orientation"."


You could also just think of it as [criteria]<>[data linked to criteria].
The client would parse over the agrivated stream of these triggers,
looking for matches, and then displaying the data linked if it finds
one. (either inlined or remotely linked)

Whether "trigger" or not is the exact term we want to use, it does
seem fundamentally to me this is the way to go about it.







On 3 August 2010 16:42, Phil Archer <phila@w3.org> wrote:
> Matt, as you know I've stepped back from this now that you've taken over
> (phew!) but, fwiw, +1 (unsurprisingly).
>
> This concept of triggers needs addressing since it keeps coming up.
>
> A location, even one that is defined relative to something else as opposed
> to a fixed point in space, is not a trigger. The trigger is that a device
> has arrived at that location (or that a recognisable object/marker has come
> into view, or that a time has arrived or whatever).
>
> In Web terms, we're talking about events, no? Things like onclick, onchange
> etc. /Those/ are the triggers. A Web App that's triggered by absolute
> geolocation might query the GeoLoc API regularly (say every second) and then
> you'd query a POI database with a machine version of "what do we know about
> this place?" That could be enriched with directional and temporal info etc.
> of course. But, as you say, Matt, that's a /query/ against a dataset.
>
> The term 'trigger' implies dynamism and these are covered by existing
> working groups who are in various stages of looking at things like GeoLoc,
> camera, clock etc.). It is the user (or the user's perspective in a virtual
> tour scenario) that is dynamic and that clearly needs to be reflected in the
> display, but that is orthogonal to the data which is about a point of
> interest (fixed or moving, ancient or modern).
>
> I believe Point of Interest data should be thought of as static. What data
> you take from that data is triggered by the user's actions, location, time
> zone or whatever.
>
> Phil.
>
>
>
> Matt Womer wrote:
>>
>> Hello everyone,
>>
>> First, I'm glad to see this discussion going on, this is great!  My
>> apologies for not sticking to the +/-1 format.  As Christine mentioned I'm
>> the W3C staff person who will be helping out this group.  There's been a lot
>> of great discussion, and I'd like to offer my two cents before we dig into
>> drafting a charter.
>>
>> Looking at the AR workshop report [1], it states two aims for a new WG,
>> one of which is:
>>
>> "To develop a standard for representing Point of Interest (POI) data."
>>
>> This seems like a straightforward statement, but I've noticed that it
>> seems like we don't have a common definition of POI.  Are they represented
>> by a single set of coordinates?  Are they only locations fixed in space
>> relative to Earth?  What is the information that pertains to them?  I'd like
>> to offer a straw-man definition of POI for the purposes of discussion here,
>> lets bat it around and see if maybe some of the issues get resolved along
>> the way.
>>
>> [[
>> A Point of Interest is an entity which has a location and about which
>> information is available.
>> ]]
>>
>> That's hopefully not very controversial, though it does raise more
>> questions:  What is a location?  What information?  So let me take a shot at
>> those definitions too:
>>
>> [[
>> A location is a point in space that may be expressed in a geodetic system
>> (e.g. lat/lng in WGS84), or relative to something else (e.g. "near", "in"),
>> or a qualitative expression (e.g. "indoors", "near public transportation",
>> "unknown").
>> ]]
>>
>> This is more controversial as it includes complex notions of location that
>> are probably beyond what people include in their definition of the term POI,
>> but I think it is more useful in this context.  I don't know that it covers
>> all cases, and I don't know just how much of that is ready for
>> standardization, but it's a starting uh, 'point'.
>>
>> What information might we want to attach to such locations?  Well,
>> anything, and that should be possible in whatever we do, but there is a set
>> of very useful information that we could likely agree would very useful to
>> standardize: name, shape, and temporal information.
>>
>> Name seems fairly straightforward and is probably something we can adopt
>> from elsewhere.
>>
>> Shape information, on the other hand, is more complex.  For starters, not
>> all POIs have a shape (e.g. points such as 'center of this room', 'corner of
>> Mass Ave and Vassar St'), or maybe a point is a shape here?  Some POIs may
>> have a shape that's sufficiently described by a simple 2d circle, bounding
>> box or polygon (e.g. "Empire State Building" may have a rectangle
>> representing it's base at ground level), or 2d with a height (e.g. "the
>> Empire State Building" is a rectangle that is 443 meters tall).  Some POIs
>> might best be represented by a three-dimensional model of varying levels of
>> complexity and detail  (e.g. "the Empire State Building" is a rectangle with
>> a pyramid on top or a complex CAD-like model).  I'm not sure we can
>> standardize each of those cases immediately, but a polygon with a height
>> seems doable, and again could be something that is available elsewhere.
>>
>> Then there's the notion of time.  All of the information about a POI may
>> change over time: the POI could move, its shape or name could change, it
>> could cease to exist, or be created in the future.  The ability to add
>> temporal information to each of the properties would give us quite a bit of
>> power.  Perhaps this isn't required, but I think it opens a whole set of
>> possibilities that could be difficult otherwise.
>>
>> Add "Web-style extensibility" (as Dan called it [2]) to these three
>> concepts (location, shape, and name each possibly annotated with time
>> information), and we've got a pretty flexible definition of a POI that could
>> describe traditional POIs such as "Times Square", as well as more
>> complicated ones like a traveling circus, or even less obvious ones like
>> this pen on my desk.
>>
>> If we could standardize these properties, then we'd have a powerful format
>> that could be used in AR as well as other applications.  If we take
>> advantage of extensibility, we could build a vocabulary for common
>> properties right out of the gate (e.g. description, owner, open/close hours,
>> etc).  Meanwhile, we could also work on covering the more complex possibly
>> AR specific properties such as an image to be used in image recognition
>> property, or other properties that may be used for the non-location-based
>> query use cases.  With these things, we would cover the POI action in the
>> report.  We could of course address other topics, like triggers.  (I haven't
>> addressed that in this message as I'm not 100% sure I understand.  Sometimes
>> they read like complex queries, other times like the POI itself is the
>> trigger.)
>>
>> What would this mean for where the work goes?  Well, given how useful a
>> POI format is beyond AR, and the amount of work, my straw-man proposal would
>> be to create a POI WG with a primary use case of AR that would develop a POI
>> Recommendation, AR vocabularies, etc.  In the future, as the core POI work
>> winds down then perhaps recharter as an AR specific WG.
>>
>> So, that's my thoughts, let me know what you think.
>>
>> Thanks,
>>
>> -Matt Womer
>> W3C staff, Ubiquitous Web Activity Lead
>>
>> [1] http://www.w3.org/2010/06/w3car/report.html#action
>> [2] http://lists.w3.org/Archives/Public/public-poiwg/2010Jul/0004
>>
>>
>>
>>
>
>
> --
>
>
> Phil Archer
> W3C Mobile Web Initiative
> http://www.w3.org/Mobile
>
> http://philarcher.org
> @philarcher1
>
>

Received on Tuesday, 3 August 2010 15:07:24 UTC