Re: thoughts towards a draft AR WG charter

Thomas Wrobel wrote:
> If the term trigger is used elsewhere, its best to avoid.

I've not heard it used elsewhere (that doesn't mean that it's not used 
elsewhere of course, just that I've not heard it!)

> 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.

It's clear to me that that a point of interest does not and should not 
necessarily refer to a location on the Earth's surface (or any other 
planet for that matter). Recognising an image (such as a label on a 
bottle of wine) does not imply a geographical location other than one's 
proximity to said bottle.

The trigger here is that an image captured by the device has been passed 
to some sort of image recognition software that has been able to 
associate it with an identifier that can then be used to access the 
(static) data about that particular bottle.

> 
> 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.

Not sure I quite agree here. The query (to the browser) might be "where 
am I and which way and I pointing?" That's what GeoLoc does/will enable.

I might like to have a slightly different query that said "alert me when 
we get to Trafalgar Square" or "alert me if a bottle of 2000 St Emillion 
Grand Cru passes within camera range.

The first one could, perhaps, be built into the browser (although it 
would be "alert me when my lat, long and altitude is within these 
parameters"). Equally, this could be accomplished with a bit of 
JavaScript that could be made into an efficient, minified, re-usable 
library, just using the GeoLoc API.

The other one - tell me when object X is seen - is achievable if you 
have a universal database of things with an agreed identifier structure 
that is used by all image recognition software. The internet of things 
and all that. The browser API could then have two functions "can you 
give me an identifier for the thing the camera is looking at?" and "tell 
me when an object with x identifier comes into view." Analogous to the 
GeoLoc discussion above, just having API access to an identifier for 
objects in front of the camera is sufficient here although, yes, it 
could also be made part of the API for the browser to implement.

My understanding is that we're not quite there yet with a universal 
identifier scheme for things but it might be possible to think about 
that before long. You don't need everyone to agree on the same 
identifier for the same thing of course. I might choose 
http://philarcher.org/wine/st_emillion/2000/grand_cru and you might 
choose http://www.darkflame.co.uk/over_priced_plonk but if we agree to 
use URIs (as I have here) then linked data techniques can do the heavy 
lifting (owl:sameAs is grossly over used but in this instance it seems 
appropriate!)

> 
> 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.

Makes sense to me - we're both talking about identifiers.

> 
> 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]

I agree with the sentiment here if not the syntax.

>>
>> 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"."

That doesn't work as a triple as you have a literal (the sensor data) as 
a subject. We need to express this as a query along the lines of:

SELECT ?poi_data WHERE {
?sensor_bundle <returns_value> "sensor value we're interested in" .
?sensor_bundle <makes_relevant> ?poi_data
}

Such a query achieves exactly what Rob proposes - i.e. it returns data 
when the sensor returns a defined value. You can do regex matching on 
literals in SPARQL so it's pretty powerful.

> 
> 
> You could also just think of it as [criteria]<>[data linked to criteria].

Yes. I agree. We're linking criteria to data. The data is static. The 
trigger is that the criteria have been met.

> 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)

Thinking about aggregated streams of triggers might be useful in future. 
i.e. a way to say "tell me when my location is within 200 metres of a 
shop that sells 2000 St Emillion Grand Cru for less than €50. What's 
aggregated here is the list of criteria and they might only be 
accessible by different sensors and data sources.

> 
> 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.

I have no problem at all with the word trigger, I think it's useful. My 
only real point is that data about an object, be it geographically fixed 
or otherwise, is not a trigger. The trigger is that the user has moved 
into a context in which a defined subset of the available data is 
relevant and needs to be displayed.

It feels as if we're in pretty close agreement here, Thomas. Certainly 
close enough to agree on the wording a POI WG charter!

Phil.

> 
> 
> 
> 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
>>
>>
> 
> 

-- 


Phil Archer
W3C Mobile Web Initiative
http://www.w3.org/Mobile

http://philarcher.org
@philarcher1

Received on Tuesday, 3 August 2010 16:15:30 UTC