Points of Interest Working Group Teleconference -- 14 Dec 2010

<trackbot> Date: 14 December 2010

<cperey> I guess I got my time wrong, was on the Zakim bridge since 8:30 AM Eastern

<Gary> +1 for donuts .... hmmm .... Krispy Kreme

<cperey> so... is there one for me?

<cperey> what about just someone to talk with/listen to on the bridge?

<matt> Agenda: http://lists.w3.org/Archives/Member/member-poiwg/2010Dec/0009

<JonathanJ> http://lists.w3.org/Archives/Member/member-poiwg/2010Dec/0009.html

<andy> hi

<andy> matt: describes the difference between recommendatins and notes

<matt> Charter: http://www.w3.org/2010/POI/charter/

<matt> Related Specifications list

<matt> Geolocation API current version

<andy> i will try

<cperey> I can just barely hear so I can't be scribe!

<matt> Scribe: matt

Agenda Hacking

matt: I was thinking spec review could provide us with a few ideas, and maybe things we can reuse.

kseiler: We've already invented our own specifications, and new people are already jumping in with new things. If we can provide something that they can adopt and adapt, that would be great, this would allow us to have greater reach.

alex__: Not maybe find something that's adaptable, but definitely.
... In KARML we set out to make out the minimal changes to something in use.

<andy> +1 on minimum movement

gary: It's an hourglass. At the top layer it's the existing specifications. They're somewhat top friendly, and perhaps overkill for what we're trying to achieve there.

alex__: What's predominant?

kseiler: YP, yellow pages. It's a common use, not a spec.
... A consortium of suppliers generating business listings with extensions.
... It's CSV and XML.

<cperey> :-/ maybe

<cperey> lot of echo

gary: YP, OGC... it's overkill and dilutes what we'd do here.

[[Gary's Diagram]]

<cperey> thanks!

-> http://www.w3.org/2010/POI/wiki/File:Specification_Hour_Glass.png Gary's Specification Hour Glass

matt: Maybe we can get some scope before hand and then look at the specs comparing against those.

alex__: Right, look at them when we know what we're looking for.
... I'm inclined to start with the datamodel.

gary: Maybe at a high level talk about what's in scope and out?
... Let's take a consensual cut right now on what's in and what's out.
... In Scope: POI, Place...

kseiler: As far as I can tell you think of places as a collection of POIs

gary: Location, Temporal Meta-data...

alex__: GML has transitions too.

kseiler: I'm concerned about events.

gary: Out of Scope: detailed data format -- I don't want to see objects, or namespaces, or anything.
... In scope: extensibility

alex__: How we get extensibility is out of scope?

gary: Right, all those things that get the engineers going. Just for the purposes of getting something out at this meeting.

Ronald: Focus on Data model, fields, POI, those things.

gary: It shows you what is going to be where, if you do this, this happens. It doesn't say "this is the function callback", it tells you how it needs to be, not how to write it.

matt: I'm thinking presentation is out of scope, e.g. labels. Perhaps it's in scope for AR extensions.

alex__: That's part of why I'm interested. There are some things that are important there. Orientation, etc.

Ronald: I think orientation is part of location.

matt: We can address them in the AR extension.

gary: Similar to how HTTP specs don't define Web services.
... A lot of the use case buckets that we have, AR is a big one, it's more about how you make use of the core Rec, it's a view point on whether it fits your needs, but the two are not the same.

kseiler: I keep worrying about events, movie listings, air travel...
... The fact that someone is having a party at some place, I see those as extensions.

gary: Is that not covered by extensibility?
... You could argue that "is within" and "contained by" covers some of those short duration events, it's the same relationship, just a different temporal range.

kseiler: Does time applicability cover that?

gary: To my mind yes.

matt: +1

gary: At this time we don't need to say that, but we can say it's extensible, and has temporal attributes from the beginning.

alex__: I like that. My litmus test for this data: if I wasn't looking at it as a map or an AR view, would it be on a web page? If it can't be then, I'm not sure we need it.
... When you think about temporality, where you can scrub back and forth through time, it's useful to be built into it, but it's potentially part of the extensibility of it.

kseiler: I'm just trying to bound the core.
... What about mobile stuff? People?

<cperey> movable things must be in scope

<cperey> they cover everything which is NOT fixed in space!

<cperey> we called them "things" which was weak IMHO

<cperey> dynamic is fluctuation over time

-> http://lists.w3.org/Archives/Public/public-poiwg/2010Aug/0031 Danbri's list of "what's a POI"

<cperey> yes, but you need to define a moving object as part of the recommendation

gary: In scope: Dynamism/mobility

kseiler: It's a location with a time bounding.

<cperey> in scope

kseiler: Is that in scope or out?

matt: +1 to time applicability

gary: It's critical, people want to know the latest cut of what the information is, and we have to be cognizant of people referring to things by their old names, etc.

<cperey> frame of reference

<cperey> is local and temporal

gary: This also goes a ways towards solving the synonym problem, e.g. historical names.

<cperey> that;s the cup is half full or half empty

gary: So you could argue that people aren't POIs, but where they are is.

andy: I want to see "people" in scope.

<cperey> +1 for having people in scope. They are a subcase of all movable things

andy: It's no different than a truck.

<danbri> POIs are more map than territory

gary: I think that goes into extensibility.

<cperey> it's a question of what is the object and what is the reference

andy: POIs don't have to have a location.

gary: I disagree.

kseiler: If it doesn't have a location it doesn't exist.

andy: I would say Alex doesn't have a location, it's just at this time he has one.

gary: I think this goes to temporality.
... There's a stream or a queue of temporal data, and the head represents the current location.

<cperey> NO!

<cperey> it isn't out of scope!

andy: I'd rather identify Alex by his face, which also has a temporal issue to it, but he's recognized by his face not his location.

kseiler: I think everything has it's location, but is it helpful to have a POI for this cup?

<cperey> not that I know of

<cperey> there may need to be one, if the W3C POI WG elects not to define it

alex__: A person might have a few different POIs, and they might or might not follow one around.
... They don't necessarily have to be uniquely tied to me. Anyone can attach POIs to anything they want, whether it's static or mobile, but they may not all, in some sense, be associated with a universally identifiable object.
... If it doesn't go that way, if you gave a URI to the TSRB, you can't just give a lat/long. That's not good enough. If someone else drops a POI there, and the only thing that binds the two is six digits of coordinates, they aren't necessarily the same place.

kseiler: That's the difference between a POI and a place.

alex__: I understand the relationships, but if we take a building, what is going to be the universal description of that building. Is it a location?

gary: It's a location and an extent.

alex__: If I give a location and an extent and you give a location and an extent, are they the same place?
... Are they the same place, have we bound the two

kseiler: It might be that we have enough information to bind the two, but they might not be the same data.

gary: I think it falls within the extensibility camp.

matt: It could be there are other things that are outside of the protocol, like geo uris.

alex__: We're saying right now that maybe this isn't in our scope right now.

gary: Based on what we've said is in scope, it's inherently there, in terms of relationships and how it hangs together.

kseiler: You're identifying the value of the binding of these things, if they don't have a unique id --

alex__: Then you have to calculate it every time.

kseiler: So you think we'd need a unique ID is in scope?

gary: I think it's out of scope. There are many of those already.

kseiler: So the fact that the core POI scope might not include the identifier.

gary: Has a field that can identify, sure.
... It could be a UK grid id, or a WOEID. What that ID is, is out of scope.
... So, in scope is "IDs" and out of scope is "IDs (definition + service)"

kseiler: Are people in or out of scope?

<cperey> every object is a POI

andy: Is the location how a POI is identified?

kseiler: It's part of it.

andy: If there was an AR app to put tweets around your head, then there's no reason to have a POI of you.

gary: That's out of scope.

alex__: If I find a rock on the ground, the phone sees this rock, and identifies that. There's something that describes that, maybe it's shape, whatever. At this point it has a location, but there's an argument to be made that location is not the canonical data.
... It could be found in lots of ways, a visual identifier, etc.

matt: I don't see location as a special property of a POI. There's lots of ways to find POIs, by name for example.

gary: Mapping is probably the most prevalent, but it's not all about mapping.

alex__: Why do we have location?

<cperey> mapping is prevalent in Western world but it is only way of representing information in other parts of the world

gary: So that we can position our selves spatially to a point of reference.
... You have not just "Find me an Arby's", you might have "find me grilled fat within this area".

matt: I would say you can search on any arbitrary property.

gary: But you still need the location to find it.

alex__: I can see a future where a lat/long stops being the holy grail.

kseiler: A location can be as arbitrary as "30 feet from big blue house", it's not map relevant.

gary: You may have arbitrary natural language stuff in play, not to say that assembly code is not there, it's just further abstractions.
... With blue house fifteen paces to the left, you still need to know a starting position to know where fifteen paces is, and you need a house to have metadata to say a color blue, etc.

alex__: I wrote in out of scope is "location service".

andy: The two most common AR use cases are: 1. how to make a conference call by taking a picture of the phone ("Guide" use case) 2. Boeing layover diagrams

kseiler: Describe the universe, give three examples.

andy: I have a sensor on this device that can aid in identifying it, much like the location sensor.

alex__: Any sane system will start with IP data and geo if it has it, then narrow it down, take the picture, send to a database, etc.

andy: So, is the Boeing engine a POI?
... It has no location.

gary: Everything has a location.

andy: It's got no interesting location.

gary: Sure it does, it's right in front of you.

alex__: Why not?

kseiler: I think for us to succeed we need to be able to get to closure, and I worry that if we try to include too much in the definition of the POI, then we're describing everything in the world.
... I think there is a SKU for everything in the world, and it might be associated with a POI, and people will have unique identifiers as well. Are we going to describe persona in a POI? Isn't there another standards group that can do that?

gary: Somewhere in between the Earth and a quark we need to draw a line.
... Parties are above the line, boeing engines are below the line.

<cperey> I am signing out for a while, will return for more fun later!

<cperey> by the way, I think that the exercise has been good, but please try to capture this discussion as closely as possible!!!

<cperey> I'll signal when i want to dial back in

<cperey> bye

matt: I think we should make the frame of reference settable in the format, default to say, WGS84, but settable to anything.

andy: Are dogwood trees out of scope [[??]]

gary: If you are interested in seeing a tree's genus and species or whatever, then it's out of scope, but if it's worthy of being in a place dataset then it's probably in scope.

alex__: You could probably find it via some service then construct a POI.

andy: So we're resolving that a POI must be defined by a location.
... What we're saying is what uniquely identifies a POI is some sort of coordinates.

alex__: Some geospatial location relative to some coordinate system.

gary: Can we say for the purposes of this draft that there is a location coordinates field and that unless explicitly specified is WGS84, but the document acknowledges that there is some way of identifying it.

kseiler: What about "downtown"?
... The core spec could help in figuring out how to do these roll ups from room to building to earth.
... If you embed that in part of the core, how to define the relationships is useful.

alex__: To describe a park do you have to have linkage to all the items in the park?

kseiler: If place is in scope, then you should.

gary: I think we could get away with a set of entity relationships that POIs have.
... "For a given POI these are the relationships that these can have" -- parentage and childrenage, adjacency, etc.
... What we're trying to define is a POI, not how you draw insight from the relationship.

kseiler: How about a persistent bus route.

gary: Could say it's a very long narrow vector, or that the route is represented by points of each stop.

alex__: To go back to downtown: there might be something delivered to me that is a location and extent, and there might be something that derives that POI, but I need to feel more comfortable about what the spec is. Is it that database? Is it requiring those relationships, etc?

gary: From what we're trying to define here, there should be no difference between "downtown", "my neighborhood", "near me", "soho", "the bay area", "the Pacific Northwest" -- they are all different levels of scales for places, and they will all have different relationships, but it's up to you the implementor to determine what populates those relationships.

kseiler: Downtown can be a bounded poly, wanna eat down town, look up the POIs in that poly. Or it could just be a collection of POIs. "I want to eat downtown" could be the POIs that opted in to being downtown. Their proximity is not relevant, just that they opted in to being downtown.

matt: I think it's fine to find POIs not on their location but on any property, e.g. based on it's relationship say to downtown, if it's "in downtown".

kseiler: My point is that they all have a location.

alex__: What's the minimum requirement to describe a POI? I think we came to this with a POI is a minimum of a location plus something else.

kseiler: Agreed.

alex__: So, a POI for downtown has a location, coordinates and an extent?

kseiler: It's not a polygon, it's just a collection of POIs.

gary: Is that not trying to put a place into a different slot into the model?
... The model where the POIs have said they are related to downtown, seems unacceptable.

kseiler: Theater district then, they want to nav to it, but representing it as a fixed location is tough.

andy: If it's a POI it's represented by a POI with an extent, and if it's not then it's something else in the implementation.

gary: If POIs want to associate themselves with the theater district, then it's an attribute of a POI, and then there is no POI for the "theater district".
... But you could also, and to my mind a far more satisfactory way to do it is to create a place, which is called the "theater district", and because it's nebulous and vague, we'll make it our business feature that we'll actually try to go get it hammered down as much as we can, so we'll have an MBR for this.

matt: Or you could have a hybrid.

kseiler: Are relationships between POIs in scope or out of scope? Are those associations named entities?

matt: +1 to in scope.

gary: We've said there are relationships, we haven't said how we'll implement it.

andy: Why are relationships in scope?

alex__: They're in scope because you don't want to come up with a spec that doesn't give anyone guidance on how to relate POIs them.

andy: What would you want?

kseiler: Inside, near, etc.

andy: But you could get that all from location.

alex__: You don't to accidentally have your bathroom not be part of your house.

andy: I think you're more likely to miss it through tagging it.

kseiler: [[zipcode example]]

andy: A zipcode is a POI?

gary: It can be.

andy: I'm thinking place is not in scope.

[[Place

An aggregate term that can be used to refer to a point, a location, a POI or a meaningful combination thereof.]]

alex__: A zipcode might be a location and extent, plus relationships between things within.

kseiler: Parcels wiggle in their shape and size, but the abstraction remains the same.

gary: I think it's also about what you're trying to represent within this core recommendation.
... If you build a system and say I'm going to feed into the ultimate in relationship and place truth, then you could construct the entities higher up the hierarchy from their atomic components.
... But if you take the approach to say that the data we've got here is only as good as those who went out and got it.
... You do what makes sense to your model.

alex__: As long as the underlying data model allows a business to formulate things in these ways and deliver the results, even if it's a polygon and a centerpoint, we are debating whether the spec allows it.

gary: I think both approaches are equally valid. Depends on what angle you're coming at.
... They're not diametrically opposed.

alex__: Are relationships in scope?

matt: +1 to in scope.

<JonathanJ> +1

Ronald: +1

kseiler: Then there's the question: do you allow sets as a named entity. Or is that in the Recommendation?
... e.g. "This is an airport, it has X terminals, 15 Starbucks".
... Relationships give you an atomic point, can you create a named set. Does it persist in the core POI rec?

gary: Yes, you can create a set or choose to create a place...

andy: What's the difference between a set and a place?

kseiler: They are synonyms.

<JonathanJ> Semantical extensibility can be represent to Relationship ?

gary: It depends on the direction you come at it from. Yes, place and set are synonymous, you can create them by inclusion, or you can choose to create a meta-POI in order to have linkages.

andy: A POI is the core thing with a location. A place/set is a set of relationships.
... Any place with a location could become a POI.

kseiler: I'd like to be able to create a set with a unique polygonal with some things in it.

matt: I think that's what I meant by hybrid.

gary: I think we're saying the same thing here.

Luca: Why do we need a different name for saying the same things? Better to have one.
... Set seems to be a set of POIs, while place is a known area.

[[Place: An aggregate term that can be used to refer to a point, a location, a POI or a meaningful combination thereof.]]

gary: If we say a place is the same as a POI, I'm okay with that, but people tend to have a sense of scale associated with those two phrases.
... It's not just a synonym --

Ronald: Central park is a POI, but the lake and carousel within are also POIs.
... If you're talking in scale, then a set of POIs *is* a POI.

kseiler: I'd propose we get rid of the word place.

alex__: And we have relationships which allow what we think of as "places" can describe.

kseiler: I can create a location, an address. A POI of NAVTEQ corporate headquarters could be "is at" that address.

matt: We can also use the frame of reference attribute to say "alex's body" rather than wgs84 and find your liver there somewhere.

<alex__> alex scribbing

-> http://www.w3.org/2010/POI/wiki/Core_Scope Scope chart

<scribe> Scribe: alex__

<matt> [["Are we Points of Interest or Places of Interest?" discussion]]

points of interest can determine their location from a location relationship OR by inference from child relationships

if a POI's location is infered from the children then it may actually be a PLACE of interest

in fact a POI that only has a parent relationship may not have a specific location but we know if is INSIDE the extent of another POI

gary: location is a way of decribing where (i.e. WGS84 or Address or MBR)

<JonathanJ> http://www.w3.org/2010/POI/wiki/Terminology

<JonathanJ> lunch time - http://www.stcharlesdeli.com/menu_lunch.cfm

<andy> back

<inserted> Scribe: Luca

<matt> XML lang

kseler: Can location has a name?

http://www.w3.org/2010/POI/wiki/index.php?title=File:2010-12-14_12.15.12.jpg

thanks matt

alex__: having a picture + location is not sufficient to be a POI

Gary: so we can say that picture can be associated to a POI but ?!A

alex__: there are location that doesn't need a name

kseler: POI must have a name
... POI can have a rel with POI, and POIs can have a rel with LOC (?)
... i forget MUST, POI must have a Location

alex__: try to find some conclusion

kseler: POI must have a Loc, and it also can have more than one

<JonathanJ> POI must have a location ? or POI must have an unique identification mechanism ?

zseler: every POI should have three things: an area, an entrance and then a civil address

<JonathanJ> my question : an URI cannot be a POI ?

kseler: try to discuss with Mc Donald example
... POI is Mc Donald
... POI.location is addr zzz, yyy
... POI[mcD].loc_Point-> x.y

andy: do the relationship implies hereditance

kseler: as soon as you have relationship we should address the problem of the hereditance

Gary: POI has rel so therefore I don't see the hereditace should come in

<matt>

kseler: POI has a Name, Loc, optionally has rel with POI

member: rrsagent, draft minutes

Principles:

<inserted> Scribe: JonathanJ

1. Location primitive uses one or more systems to describe. WHERE

<Gary> While we're talking Twitter, if you want to do the mutual follower thing I'm twitter.com/vicchi

2. POI must have 1 location primitives (is at)

3. POI can have "contained within", "contains" 1-to-many relationships

question: If POI must have location primitives, how can we describe the POIs for celestial map ?

<inserted> Scribe: Matt

gary: For example, Silicon Valley is made up of four counties, whose parent wouldn't be SV but California.

alex__: When we talk about parentage, let's not get caught up on ownership or administrative.

andy: Geospatial relationships are enough.

Gary: To answer Jonathan, it would be the same to do terrestrial and celestial, just different frame of reference from WGS84.
... Nearby is an abstraction of adjacency.

alex__: Is nearby needed? We are nearby everything.

Gary: When discovering POIs, it's the fallout from NLP to use near. Normally done via point and radius. Works until it doesn't.

kseiler: Until you have a mountain in between, etc.

Gary: Adjacency is contiguous with.
... In order to facilitate near or by as an NLP search, a well-known web mapping company did a point and radius.
... That worked ok in London to do a point and radius, but it failed in Dublin where it returned results in Whales.

alex__: This seems to me having lack of smarts on the server end. What's the end value?

karl: It's the same as contained/contains, you could calculate it, but the human value is useful.

Gary: I use adjacency to mean contiguous nearby.

<JonathanJ> 4. POI can have "adjacent" 1-to-many relationships

-> http://www.w3.org/2010/POI/wiki/Core_Scope Scope list

<JonathanJ> http://www.w3.org/2010/POI/wiki/Main_Page

<JonathanJ> 5. POI must have a "name" primitive (human description)

6. POI must have an "id" primitive

<andy> ping

<JonathanJ> 7. POI must have a "categorization" primitive

<JonathanJ> 8. POI can have a "meta data" primitive

<scribe> ACTION: andy to update the definition of POI in wiki to reflect the principles laid out in these minutes [recorded in http://www.w3.org/2010/12/14-poiwg-minutes.html#action01]

<trackbot> Created ACTION-22 - Update the definition of POI in wiki to reflect the principles laid out in these minutes [on Andrew Braun - due 2010-12-21].

-> http://www.w3.org/2010/POI/wiki/File:Location_Reference_Types.png

-> http://www.w3.org/2010/POI/wiki/File:Specification_Hour_Glass.png

-> http://www.w3.org/2010/POI/wiki/File:2010-12-14_12.15.12.jpg

<andy> ping

<JonathanJ> 9. POI must have a "time" primitive

<andy> ping

matt: I'd suggest that we could apply temporal information to any one of these primitives.

<andy> karl: haiti eartquake perfect example of temporal use case

<JonathanJ> Do we need to consider "security policy" primitive ? - it's private. it's public.. who can access it..

<andy> yes

<Gary> +1 for visibility and/or privacy

<JonathanJ> +1 for visibility

<JonathanJ> 10. POI must be extensible (method of payment, opening closing hours, 3D content, images, multimedia...)

<andy> ping

<alex__> matt says he was toasted at 5 til 4:00

rrssagent, draft minutes

- DRAFT -

Points of Interest Working Group Teleconference

14 Dec 2010

Attendees

Contents

Agenda Hacking

Summary of Action Items

Scribe.perl diagnostic output