Points of Interest Working Group Teleconference -- 15 Dec 2010

<trackbot> Date: 15 December 2010

<andy> good morning

<alex__> *

<matt> Use Cases

<matt> Core Principles

Use Case Review

<inserted> Scribe: Ronald

<matt> Scope chart

Alex: is a search for rich content (entrance fee) part of POI or is it a web search

gary: rich content out of scope
... only add it as extensible, but don't make it part of the POI core. Principle 10

Alex: how is rich data facilitated

gary: extension mechanism. it is up to the content provider
... let's go over all use cases and see what's in scope and what is out
... getting really rich content is a specialised effort with high cost

alex__: all search use cases are out of scope

gary: historical pricing information is not part of the spec, but extension supports it

matt: we should look at one or two use cases and describe how it would be done

alex__: thinks it is a useful exercise, but not for the F2F

andy: concerned on why to adopt the standard

gary: standard does not enforce the business model

karl: standard helps in aggregating data

alex__: in an AR browser like Layar will benefit from a standard

karl: categorization will be proprietary, but knowing what field contains the category helps in mapping

<alex__> what is qdos?

gary: being the first to implement the W3C standard is good for your company

kudos

alex__: standardisation will help more people to create content
... end value seems to lie in the extensibility, but we should not underestimate the power of the core

karl: separating of the location from the POI is useful

<matt> [[ I poked around looking for free/cheap YP databases, and I am distressed at how limited the data set is: ID, Categorie, SubCategorie, Name, Address, City, State, Postal Code, Phone, Fax.]]

gary: every current system embeds the location in the information, and it gives an editorial nightmare
... POIs are human artifacts and can change, but locations are static
... principles are good, but it will take effort to flesh out the primitives provided in the principles
... we have a skeleton of a draft recommendation, but we have a lot to flesh out to get the draft recommendation

<matt> Terminology

matt: lets review terminology page and check if it fits the things we discussed

gary: should be an action for post F2F to reflect the new reality we defined

andy: are we done with the use cases

<matt> ACTION: Gary to scrub wiki and terminology pages to reflect consensus notion of location and place terms [recorded in http://www.w3.org/2010/12/15-poiwg-minutes.html#action01]

<trackbot> Created ACTION-23 - Scrub wiki and terminology pages to reflect consensus notion of location and place terms [on Gary Gale - due 2010-12-22].

alex__: no, let's go over them all
... location is broader than the current definition, it is any type of attribute to define the location
... computer vision might be used to detect the an object and use that as the location

karl: is it a landmark that can be recognized?

alex__: yes, but we may not care about the location, but we know that the object is in front of the user

gary: instead of computer vision, can we call it proximity sensor, as that covers much more

<matt> PROPOSED RESOLUTION: A location may be a number of things, including: wgs84 coords, civic address, a vector with absolute or relative positioning, minimum bounding rectangle, unknown, a 3d model, or (?? computer vision stuff)

gary: is proximity something we should include? it does not specify the location
... if you just use proximity, you still don't know your location. all you know is that you are close

<matt> PROPOSED RESOLUTION: A Proximity Sensor is something that determines the location of something else relative to the sensor.

<matt> Gary: No, it doesn't tell you the location, just distance

<matt> alex__: That's maybe a technological limitation that you're carying.

<matt> Gary: I think it's out of scope.

<matt> matt: I think we are all comfortable with wgs84, even if it is getting updated next year, addresses, a pain in the neck, but understood, going down the list? 3d model? proximity sensor? How do we pick what those are and how we represent them?

<matt> matt: Can we say something like "proximity" rather than "proximity sensors"? e.g. standardize on "I am within X meters of Foo_POI and Y meters of Bar_POI and Z meters of Bang_POI" -- what those POIs are -- bluetooth sensors, whatever -- is irrelevant.

<matt> scribe: Matt

Gary: With RFID you're saying things like "this parcel is now in this warehouse"
... I'm okay with relative location.

alex__: I don't care, if you open that door.

PROPOSED RESOLUTION: A location may be a number of things, including: wgs84 coords, civic address, a vector with absolute or relative positioning, minimum bounding rectangle, unknown, 3d model, TBD relative location spec

matt: Is an MBR just two WGS84 coords?

Gary: In it's pure form it's a spatial box with minimal information. Always two opposite corners. Using a positioning coordinate system.
... In this world it's typically two Cartesian points relative to WGS84.

kseiler: The footprint and MBR seem similar, MBR being a subset of footprint.

alex__: I was going to flesh out extents for this meeting.
... Extent and location are related in that it's you can derive a location from MBR extent.

<cperey> hello

Gary: sometimes it's all you have though.

alex__: The breakout may have real value though.

Gary: Extent I think is an attribute of location.

<cperey> dialing into Zakim

<cperey> +q

<cperey> yes! I hear you

<cperey> I was listening!

cperey: I sent a message to the list saying it's sometimes absolute and sometimes relative.

<cperey> location is a point in place. three dimensional world

<cperey> can be absolute. can be relative and can be inferred

<cperey> +1 on that last statement

alex__: Location is a point in space somewhere with an extent around

<cperey> technologies which can be used to infer where you are from other data

Gary: They can be relative and infered.

<cperey> used as a feedback cycle to verify the veracity of the data you have received

<cperey> relative to some frame of reference

<cperey> but you also have to have explicitly called out so that it is workable

<cperey> if we start throwing around semantic terms such as relative, we will ignore it. Real world workable

<cperey> gary says: sure, you could argue that location is a relative system, but include that it includes relative frames of reference to other points, potential, to oursevelves, to a device, or relatie to an adress

alex__: We need to codify that it can be relative to things via proximity, or relative like an address, or 100 meters from blue house.

<cperey> as long as we agree that we have relative frames of reference...

alex__: While we're deep in location, let's talk about this notion of where is something.
... The driveway to the McDonalds really matters, but some people would argue it's just part of going to McDonalds and it's just extra data.

<cperey> Karl said (recapping) is this notion of where is something (discussion about driveway to McDonalds) is just a part of something ELSE, the "extra" data

alex__: How are we going to codify these things as they get more complex?
... I say we associate them with further points of interest.

<cperey> Alex feels we should go with basic principle that there is no short list...a POI is any place you would want to go

PROPOSED RESOLUTION: A location may be a number of things, including: wgs84 coords, civic address, a vector with absolute or relative positioning info, a minimum bounding rectangle, unknown, a 3d model w/wgs84 or TBD relative location spec,

Karl: Yesterday I tried to push name into location, but we decided location is where it is, everything else is in this other bag called place
... Place is the bag for everything else: names, locations, ids, etc.

alex__: We think this method is maybe how increasing fidelity is dealt with.
... It's a bit scary how much data there will be.

andy: Didn't we eliminate unknown?

karl: Maybe a business is forming, but has no location yet. Can it have a POI?

alex__: There's some semantics on pointers being null, whatever, but what's important here is if Alex's office is contained within the TSRB and it exists as a POI, is it okay that it's location is unspecified further.
... Maybe it has no parent and has no location it has little value, but they exist.

andy: Example?

alex__: A welcome message.

<cperey> this has a location, I simply don't know where it is at the moment

<cperey> this was suggestion by Matt

<cperey> still come back to the loosey goosey of the word POI

matt: I think there is value to having an "unknown" location rather than just no location.

<cperey> place vs. stuff

karl: McDonalds a store vs McDonalds as a whole thing. One is a place the other isn't.

alex__: My car for instance, I can tell where it is until I'm in a tunnel. Then I could probably guess with low accuracy that I'm still on earth. Place seems a bit rigid.
... A person, place, or thing -- there are extremes that make your hair stand up, but there are real things like OnStar trying to find my car, then there are places that might not have a known location.

Gary: I don't see why there isn't a way for people to create things from places that we've described here, but I think it's a minimal edge case. So minimal we should move on. No reason you can't do this, I would question why, and if you wanted to, you wouldn't call them places.

<cperey> NO this is not all about places

<cperey> that is a negative attitude

<cperey> on the contrary

<cperey> AR is very general topic

<cperey> thank you, Alex

Gary: This is the POI working group, so we're about places.

matt: I see no reason why we shouldn't be working towards such a thing.

<cperey> let's not hamstring to the point where people can't use it that way

<cperey> we're not creating the theory of stuff

alex__: Let's not hamstring it so that it can't be done this way.

Gary: We're not creating ethereal stuff, we're agreeing on what a place is.

<cperey> we're creating a workable definition of ...

Gary: We agreed on what a place is yesterday.

<cperey> I didn't see that agreement

matt: I think unknown location is still key.

<cperey> was it sent out to the list?

Gary: We have to have temporal and unknown locations sure.
... We have to say the location is unspecified/unknown.

alex__: I want to make sure the door isn't slammed in the face of these esoteric use cases.

andy: I would prefer we didn't say they're esoteric, I think there's far more use cases for stuff than places.

Gary: But this isn't the stuff WG.
... We're not here building a data model of everything in the world and their relationships.

andy: I think the movie poster is a POI and it has an unspecified location.

Gary: I'm saying it is too, but it has to explicitly have an unspecified location. If you make it optional --

andy: I think that's fine.

alex__: The movie poster is in front of you, it is a location.

andy: It's just not important.

alex__: It is. Someone could walk in front of it and the information goes away.

<cperey> +q

alex__: If you take out where it is, just recognize that there is a movie poster, then go to a website, that's not a POI.
... POI is about where it exists in the world.

andy: The location advertising use case.

cperey: Wanted to suggest that if important things to go to the list please.

<cperey> thanks matt :-)

andy: In location based advertising, pushed info or whatever, those have locations?

alex__: They do matter where you are.

<cperey> this is exciting and I understand 100%

alex__: Those are about POIs definitely.

<cperey> I would rather you SCRIBE

karl: What's the point? To drive you to the store front?

<cperey> than pay attention to me

gary: Geofence advertising is based on position, proximity and your movable point and radius.
... a geo-fence is not a place, it's a boundary trigger.
... What we're doing here with place intersects with boundary, and geo-fencing and boundaries intersect on the other side, but doesn't imply that geo advertising is part of place.
... You may utilize a place based repository to figure out where the geo boundary occurs, e.g. these POIs for Arbys are here, and the geo-fence is therefore around them.
... We said Chicago is a place, but it's an abstraction. I don't think you are going to stop people from creating abstract places with this spec.
... But it doesn't mean it's part of geo based advertising. You can setup a fence without knowing the place: just the vector that describes it.

alex__: Is it unreasonable to have a Theater District described by this spec to then fire off a coupon?

Gary: Yes, but place is not fundamental to the concept of location based advertising. Place is just one tool to define a geofence.

alex__: If people use this spec for this, do we need some other construct to achieve that or can they use/abuse POI to do that?

Gary: You can create Karl's geofence.
... Going back to small granular POIs: we can create a place for this table in this room, and you can say I'm going to derive a geofence from that place. That will fire whenever I'm within a foot of this table. I know it's a place, I know it's extent, I've got a vector that describes it's shape.
... Within a meter, it sets off a coupon or whatever. But as an advertiser, I can make a vector trace somehow [walks around table], I don't need the table to create it, the table is just a stepping stone.
... One is a tool to create the other.
... The point is you can have a geofence without a place.
... Most geotargetted advertising looks at say, newspaper press zones and those zones have these zips, and then aggregate those together and make the vector and then target those.

<cperey> haha!! funny

<cperey> what has happened?

<cperey> Hi Matt

<cperey> can you take me off speaker so I can speak with you?

[[Walking through Informational Use Cases]]

-> http://www.w3.org/2010/POI/wiki/Use_Cases#Informational

-> http://www.w3.org/2010/POI/wiki/Use_Cases#Augmented_Reality AR Use Cases

alex__: People mention XMPP, but I don't see anything that changes to our data format based on transport.

Ronald: Agreed.

-> http://www.w3.org/2010/POI/wiki/Use_Cases#B2B B2B use cases

alex__: Sounds like this is a use case for richer names?

Gary: Sounds like a specialization/expansion of the name primitive.

Andy: Text strings much have language code.

matt: xml:lang?

Gary: No, the ISO code.

-> http://www.rfc-editor.org/rfc/bcp/bcp47.txt Language codes from IETF

Gary: I would say any text field is UTF-8 and the text is an aggregate structure of text and language code.

karl: I think we're fleshing out what the name primitive is.
... I think we should also consider a label.

<cperey> I like label, but express that as a "trigger"

<cperey> +q

karl: Common name, etc, different names for the same thing.

alex__: I was assuming from the get go that name would subsume that. That we don't need another field for that sort of thing.

karl: Name consists of a UTF string plus a language code and a label.

Gary: Normalized form of the address could be used to populate the name primitive.

<cperey> is this an IETF classification code topic?

<cperey> I want to wait until I have the floor :-/

Gary: 180 Lunvaden Straße and 180 Lunvaden Strasse and 180 Lunvaden Str are all the same thing.

karl: We need the name, the language code, and then there are all sorts of vanity addresses that exist.

Gary: There are all sorts of valid names, maybe we need a textual primitive, a unicode text string together with the language code that is then used.

<Gary> It's Invalidenstraße by the way :-)

alex__: If a POI establishes that there is something at a location, or somewhere, it has an extent, I might bump into it or say something to it or whatever. So, what defines the interactivity between me and it. A div on a website that's clicked for instance is a trigger. So what's the trigger mechanism between my behavior and POIs?
... I think that Christine was saying that there be some linkage between the name/label and triggers.

<cperey> Yes, I was asking if there

<cperey> is a connection

<JonathanJ> we need to consider the I18N(Internationalization) of POI. Ref: http://www.w3.org/International/

<cperey> but a little bit no!

Gary: Isn't that an application level thing?

alex__: It's on the borderline of being out of scope.

<cperey> if you define a label/extensions, then you have to be able to use the extensions

alex__: There's extensions and extensibility for things down the line for AR, but it's not obvious to me that it needs to be built in.

Gary: That seems like a business specific specialization.
... Does this trigger metadata be part of the place itself? It's one way you'd facilitate discovery of the data based on this, but it is but one of a multitude of business specific specializations. It could almost be a use case.

alex__: On one hand it sounds like geofencing. There's information within a POI that would facilitate that, but there is also other information that may help. There's a tacit implication that the discovery will come from things like a geospatial search. The notion of a trigger could get more rich down the line.
... Imagine a future where a proximity searched doesn't matter, but what I can see is the search.

karl: That's not even the future.

alex__: We should consider whether what we're putting forward can handle that. Right now I'm inclined to say it can.

<cperey> Matt I need to change phones. I'll hang up and dial back in

alex__: If only information a POI has is lat/lng coordinates, you can't do that type of search, but with richer info you can do different types of searches.

<cperey> OK matt

<cperey> are you ready?

<cperey> BTW, I stayed on line and heard the discussion between Alex and Gary

<cperey> point to someone else for what?

<Ronald> address representation

<cperey> that sounds important for me to have heard

<cperey> will those standards bodies be at the International AR Standards meeting in Feb?

<cperey> IETF

<cperey> they have 50 fields

<cperey> complicated, GeoLocation WG decided on 12 fields

<cperey> If I ask for POI and I get back a string, I get the POI from the string, I have to hand it off to a service to do anything with it

<cperey> if , at that data exchange level, have we created enough?

<cperey> we (NOkia) have to GeoCode official address and relative addresses

<cperey> you are telling me rightnow, if I have a normalized text string, there's enough information in that.

<cperey> there's some service which I can start talking to to get more detailed informatoin (Alex)

<cperey> is that Karl?

<cperey> or who?

<andy> yes

<andy> karl

<cperey> Alex: when you say preferred service you mean, what exactly?

<cperey> Alex: this is a big issue. I have some data. Now I want more, what do I do?

<cperey> Alex: I got a POI, great, but I really want more...What happens?

<cperey> Karl: we had it at too high a level. You want URIs for ???

<cperey> chop chop (can't hear)

<cperey> who is scribing?

<cperey> thanks matt

karl: I'm trying to get in the spec a URI primitive so that someone can attach a service to a piece of data.

alex__: Other bodies must have tackled this issue.

<cperey> cperey agrees with alex_

Gary: Isn't this the same problem as going to the post office and you end up shoe-horning another countries address format into the form? I appreciate the sentiment, but isn't it meaningless except to other implementors who implement it the same way.

karl: I was thinking every primitive could have a URI attached to it.
... All of the primitives have an URI, and then when looking at an address you could use the URI to render that address.
... (render, geocode, whatever)

<JonathanJ> +1

karl: You give this URI the address and I'll give you a fully extricated location.

alex__: I give you a link for say a car, and you could use a URI to find where the car is?

karl: It's like the category primitive. You could get more info about it when using the URI.

alex__: My hesitancy is similar to my hesitancy to adding timestamps. It's a potential explosion of the data model. I agree whole heartedly with the notion, but I hope we can find a more succinct way than tacking on all over the place.

karl: I have the same comment on ID. What is it?

<cperey> I"m signing off

<cperey> bye

<JonathanJ> In Korea, we are developing a spec for one of idea that like the Physical Object Identifier

andy: Would each bit have a uri?

karl: Yes.

matt: Sounds like RDF.

karl: Yes.

alex__: We're a bit under-represented for experts in some of this stuff.

matt: Lots of participants that will help us. We can also get it out for review...

<JonathanJ> our idea of Physical Object Identifier, like URN - http://bit.ly/i7DTK4

alex__: Tidy this up now?

<andy> ok

Document Drafting

andy: The principles are the starting point for now.

alex__: Summarize what we've talked about in the principles.

matt: There's no fixed format beyond the header, Status of the Document section, ToC and references. I'm happy to work on it in a wiki and then I'll turn it into a spec looking doc.

karl: In the full doc, will we have the principles, the use cases, data model, etc?

andy: Those things, maybe use cases are in there.

alex__: What's the name?

matt: POI Core Recommendation

alex__: And do these have the use cases in them typically?

matt: Some times in the doc, sometimes separate Note, sometimes just a web page that's referenced.

karl: We can have them, put them in an appendix, whatever.

alex__: We can have examples that demonstrate a typical use case that we'd have.
... i.e. a typical POI with a wgs84 location, name, etc.

Gary: How do we document the data model with examples unless we chose some normalized XML schema that we knock together.

alex__: We're not going to XML out an example today.
... We agree there's an example section.

<andy> minutes will be replaced by live wiki updates

[[Discussion about what serialization we'll have, whether we should rely on XML, IDL, etc, or refer to those in normative appendicies as serializations]]

<JonathanJ> Demo Link: http://x3dom.org/x3dom/example/flar/x3dom_flar.html

<JonathanJ> draft of AR Landscape : http://bit.ly/hgjzU7

<JonathanJ> Today's presentation file: http://www.w3c.or.kr/~hollobit/presentation/20101215-W3C-hollobit-r1.pdf

AR landscape

[[Jonathan presents demo and slides]]

matt: I think we'd like people to volunteer to help.

Ronald: I can fill in some information about the European offerings.

alex__: I can contribute too.
... The Air Tagging struck me as specific.
... You could imagine AR balloons, or new construction, or a tweet over your head.
... Maybe something a bit more generic than Air Tagging, like "user generated content"
... Addressing user interaction -- UI is a big issue.
... Some capabilities discovery needed -- processing power to run FLAR type stuff.
... I would point you at a paper we submitted to ISMAR that wasn't accepted. I can send that to you.
... I think it is valuable for someone to survey the existing technologies.
... Not a big list: feature tracking, marker tracking, GPS tracking.

Ronald: What does it support on those levels?

alex__: That's useful, but to me the interesting part is how people author this? How do they describe what they want to do? Is it interoperable?
... We need AR to become something like the Web, where I can put up content and people will be able to consume it.

Ronald: I think the survey should focus on those aspects.
... I'm not sure how FLAR or marker based AR fits in. Are you going to put them all into one class?
... Or are you really targeting the platforms, the browsers, those with lots of content?

alex__: When I saw the demo at the AR Standards workshop it was on a handheld. The X3D stuff seems oriented towards making this work on mobile devices.
... A lot of the conversation with Khronos involved low level device protocols.
... Nokia had a camera spec, etc.
... There is this whole stack from low level to high.

Ronald: Important for us to look at these initiatives.
... There's lots of platforms that would benefit from such a standard.

alex__: When we're looking at AR here, are we talking mobile or desktop?

JonathanJ: No, AR on the Web

alex__: Standardization will be coming from the mobile direction, rather than HMDs, desktops, etc.

Ronald: Agreed, and we'd definitely help support this.

Next Steps

andy: Next teleconference is 5 January.
... Next face to face location?
... Western Europe?

Gary: I could look at hosting in Berlin.

matt: Just want to establish that next TPAC is November in North America, do we want to do some rotation?

andy: Maybe first week of April?

<scribe> ACTION: Andy to propose next F2F April in Berlin [recorded in http://www.w3.org/2010/12/15-poiwg-minutes.html#action02]

<trackbot> Created ACTION-24 - Propose next F2F April in Berlin [on Andrew Braun - due 2010-12-22].

matt: Sounds like we'll meet at TPAC.

Karl: I think if we meet again in March we'll be pretty much there and ready to close in November.

Gary: One in Berlin in March/April, another in November in N. America, and maybe survey the mailing list for one in between with the summer vacation caveat.
... Maybe get people to detail their commitments, so we can narrow down dates, e.g. Nokia World, Web 2.0, etc.

Andy: Meeting Adjourned!

- DRAFT -

Points of Interest Working Group Teleconference

15 Dec 2010

Attendees

Contents

Use Case Review

Document Drafting

AR landscape

Next Steps

Summary of Action Items

Scribe.perl diagnostic output