13:47:02 RRSAgent has joined #poiwg 13:47:02 logging to http://www.w3.org/2011/05/26-poiwg-irc 13:47:04 RRSAgent, make logs public 13:47:04 Zakim has joined #poiwg 13:47:06 Zakim, this will be UW_POI 13:47:06 ok, trackbot; I see UW_POI(POIWG)10:00AM scheduled to start in 13 minutes 13:47:07 Meeting: Points of Interest Working Group Teleconference 13:47:07 Date: 26 May 2011 13:47:07 zakim, ping me in 12 minutes 13:47:08 ok, matt 13:48:05 Luca has joined #poiwg 13:48:22 Agenda: http://lists.w3.org/Archives/Member/member-poiwg/2011May/0055 13:48:37 ISSUE-33? 13:48:37 ISSUE-33 -- Is the map georeference type needed? -- raised 13:48:37 http://www.w3.org/2010/POI/track/issues/33 13:52:30 robman has joined #poiwg 13:59:08 matt, you asked to be pinged at this time 13:59:20 UW_POI(POIWG)10:00AM has now started 13:59:23 zakim, dial matt-voip 13:59:23 ok, matt; the call is being made 13:59:27 +??P9 13:59:32 fons has joined #poiwg 13:59:37 ahill2 has joined #poiwg 13:59:42 zakim, drop matt 13:59:42 sorry, matt, I do not see a party named 'matt' 13:59:48 zakim, dial matt-voip 13:59:48 ok, matt; the call is being made 13:59:49 +Matt 14:00:03 zakim, who is on the phone? 14:00:03 On the phone I see ??P9, Matt 14:00:09 zakim, ??P9 is ahill2 14:00:09 +ahill2; got it 14:01:03 + +1.312.894.aaaa 14:01:12 +??P30 14:01:25 zakim, aaaa is Karl 14:01:29 kseiler has joined #POIWG 14:01:31 zakim, ??p30 is robman 14:01:37 +Karl; got it 14:01:40 zakim, who is on the phone? 14:01:46 +robman; got it 14:01:56 On the phone I see ahill2, Matt, Karl, robman 14:02:18 i've muted my phone 14:02:40 -> http://www.w3.org/TR/2011/WD-poi-core-20110512/ POI Core FPWD 14:03:01 zakim, who is making noise? 14:03:03 +fons 14:03:11 matt, listening for 10 seconds I heard sound from the following: ahill2 (85%), ??P15 (16%), Matt (22%) 14:03:39 zakim, who is on the phone? 14:03:39 On the phone I see ahill2, Matt, Karl, robman, fons 14:03:50 -ahill2 14:04:59 +[IPcaller] 14:05:02 +cperey 14:05:07 zakim, IPCaller is ahill2 14:05:07 +ahill2; got it 14:05:36 zakim, who is on the phone? 14:05:36 On the phone I see Matt, Karl, robman, fons, ahill2, cperey 14:06:04 cperey has joined #poiwg 14:06:04 scribe: Matt 14:06:09 hi 14:06:12 hi 14:06:18 Topic: Next F2F 14:07:03 ahill2: Need to resolve this. We have a problem, as it turns out, I won't be able to make Budapest, and neither can Andy. With that date rushing up on us, I think we've got some consensus among matt/andy/me to have next f2f sometime in July at MIT. 14:07:32 ahill2: We really appreciate your effort cperey, I know you went through a lot to broker a place for us with OMA, but it's a failure of matt/andy/I to know whether we could make it. 14:07:54 cperey: It's not my concern, but the guy who arranged it, with support for the meals, etc, talked to his bosses, etc. He's the one taking it on the chin. 14:08:14 matt: I'll take the hit for the miscommunication and write to him after this call. 14:08:51 ahill2: With Budapest off the table, we were going to do a poll between to between meeting in September in Denver or between now and then. It seems that September is too long to wait. 14:08:54 ahill2: That leaves us with MIT. 14:09:09 cperey: Clarification: how sure are you about September in Denver? is that 100% nailed in? 14:09:15 ahill2: Logistics and coordination? No. 14:09:22 cperey: In all senses of the question. 14:09:41 ahill2: It was the top vote getter in the poll, followed by OMA and MIT. 14:10:57 matt: TPAC could still be done, but it's very close to September. I really want to nail down just the next F2F at this point, as it's getting late. 14:11:06 cperey: True, but the next one will impact the following one. 14:11:20 cperey: Late July is also close to mid-September. 14:12:20 cperey: The benefit of Denver is co-locating with other SDOs. Plus, there's less cost, for the meeting itself. 14:13:21 ahill2: I don't think we can resolve today whether it's going to be TPAC or Denver OGC. We haven't done a very good job of making this happen with polls. This is a members decision, but we're in a position now where we're having to make an executive decision. 14:13:35 ahill2: As far as Denver vs TPAC goes, that should be group-wide decision. 14:14:06 ahill2: I resolve that we will meet at MIT in July. Date is TBD, as I need Andy to chime in. He'll be chairing. 14:14:13 ahill2: Objections? 14:14:24 ahill2: None. 14:14:41 -> http://lists.w3.org/Archives/Member/member-poiwg/2011May/0055 Agenda 14:14:47 Topic: Actions/Issues clean up 14:14:55 danbri has joined #poiwg 14:15:00 +??P7 14:15:27 zakim, ??p7 is Carl_Reed 14:15:27 +Carl_Reed; got it 14:15:39 ISSUE-33? 14:15:39 ISSUE-33 -- Is the map georeference type needed? -- raised 14:15:39 http://www.w3.org/2010/POI/track/issues/33 14:16:07 kseiler: Do we need to go back in one of these meetings and adjust the timeline? It's starting to feel open-ended. 14:16:20 ahill2: let's put that in the agenda for the next meeting. 14:16:22 +1 14:16:31 ACTION: ahill2 to put time-line on next week's agenda 14:16:31 Created ACTION-83 - Put time-line on next week's agenda [on Alex Hill - due 2011-06-02]. 14:16:43 ahill2: It seems to me the consensus is that we don't need a map georeference. 14:17:29 kseiler: I'm probably the primary representative of the map community on the call. I stewed on this a bit, and can appreciate the complexity of it. The problem is with geocoding, if we only care about lat/long of various points, then that means there has to be a service in the world that will bind that to a map. 14:18:01 kseiler: X/Y is not map relative. You don't know what street it's on until you snap to a link. That function, how you best get there, etc, is pretty complicated. Manually nuanced in many cases. 14:18:33 kseiler: So in the spec, being able to hard bind to a point on the map would relieve ambiguity. 14:18:37 +Raj 14:18:46 rsingh2 has joined #poiwg 14:19:22 Carl: If you have the appropriate coordinate reference system that explicitly tells you the parameters of what's being used, then you've got some measure of accuracy and certainty. Maybe not as accurate as you are talking about, but you can snap to. 14:19:58 kseiler: Take the case of the US: if we're carrying lat/long in the spec and someone wants to navigate to a POI -- some service is going to have to provide the translation from lat/long to map. 14:20:27 Hard to argue with the need for a map reference, but hard to incorporate it cleanly 14:20:29 kseiler: The complexity of binding to a map reference is that there are all kind of maps and vendors, etc. What we might do is not try to address it, but make sure the spec is extensible, so that a map reference could be added on. 14:21:01 kseiler: I'm going to carry a map reference either way, because recomputing cost is too high. Maps are changing frequently, and calculating the snap-to is very expensive. If we have to do it as an extension, then we will do that. 14:21:14 ahill2: Is there value in talking about how to approach that? 14:21:27 kseiler: I don't know if it's part of the core spec, or a recommended model, or a soft advisory or something. 14:21:32 ahill2: Can a map reference be as simple as a URI? 14:21:36 kseiler: Yes. 14:21:45 ahill2: The way it's going to be implemented is going to be vendor specific. 14:21:57 kseiler: Make it optional, and a URI and then it could go in the core spec. 14:22:19 ahill2: So, is it important enough to add to the core spec? Obviously, it'd be optional. 14:23:02 ahill2: Sounds like the issue remains open. 14:23:07 issue-32? 14:23:07 ISSUE-32 -- Does map georeference side definition need additional info? -- raised 14:23:07 http://www.w3.org/2010/POI/track/issues/32 14:23:24 ahill2: Anything else to say about map georeference? 14:23:27 ahill2: OK, moving on. 14:23:38 ahill2: Move on to namespaces. 14:23:58 kseiler: Going back a bit. I'm not necessarily current. Have you talked about locations that are a little bit ambiguous. 14:24:03 s/./?/ 14:24:29 kseiler: There are 6000 hamlets in France. It's a valuable thing for navigating. It's not an address, it could be an x/y, but how would the spec carry things like that? 14:24:56 ahill2: What kind of information do we have about where a hamlet is? 14:25:12 +nick 14:25:17 kseiler: Typically, it's X/Y is the intersection of a main thoroughfare. It's usually got some administrative naming associated with it. 14:25:22 kseiler: Name neighborhoods too. 14:25:53 Zakim, +nick is Luca 14:25:53 sorry, Luca, I do not recognize a party named '+nick' 14:25:53 kseiler: Is this type of thing handled by map reference, or is there an open ended construct? 14:25:58 zakim, nick is Luca 14:25:58 +Luca; got it 14:26:18 Sorry I'm late 14:26:24 ahill2: I don't think anything has changed dramatically since you were last here. We want to accommodate POIs that are fuzzier, rather than very strict geospatial POIs. 14:26:27 zakim, who is on the phone? 14:26:27 On the phone I see Matt, Karl, robman, fons, ahill2, cperey, Carl_Reed, Raj, Luca 14:26:37 things like hamlets seems more like a combination of "define as an area geometry" and an open ended discussion about international address formats 8) 14:26:57 ahill2: There has been a lot of confusion about this, but that is the plan. 14:27:13 ahill2: For instance, we have the relationship primitive which I believe facilitates that kind of thing. 14:27:38 ahill2: Somebody just recently posted an OGC thing about the kinds of relationships. 14:28:36 ahill2: Talking about POIs that aren't specifically geographic areas 14:29:00 [[3.3 Relationship Primitives 14:29:00 These section should perhaps simply reference the OGC/ISO Simple Features 14:29:00 Interface standard, section 6.1.15 Ð Relational Operators.]] 14:29:14 -> http://lists.w3.org/Archives/Public/public-poiwg/2011May/0028 OGC comments, relationships 14:29:25 carl: A series of POIs? 14:29:46 ahill2: At one point we had discussion about having a whole bunch of POIs that could have relationships like "contains" that establishes -- 14:30:03 ahill2: The example was Silicon Valley. It's not a part of a city necessarily, but is a region within it. 14:30:08 ahill2: We wanted to capture that kind of relationship. 14:30:34 carl: There's a group in ISO called @@??@@ 14:30:49 carl: In our terminology that's known as a feature collection, or a multi-point/polygon geometry. 14:31:39 carl: At OGC we work with just the geometries. But if you want real-world phenomenon, such as a city or a restaurant, we call those features, they have geometry properties and properties like "contains". 14:32:08 carl: A feature could contain a collection of features. You could have a feature called San Jose, that contains all of the buildings in San Jose and all of the relationships between them. 14:32:15 carl: The question is, do you want all of that complexity in the data model? 14:32:43 carl: Can you keep a simple core data model, but have an extension mechanism that allows you to get to more interesting cases without making the core data model so complex that we may never come to agreement. 14:32:52 +1 for a simple point based data model with a feature collection relationship extension 14:33:02 kseiler: I agree with simple data model. 14:33:11 ahill2: How do you represent these POIs at navteq? 14:33:34 kseiler: In our POI spec, we have an area that is a center point plus administrative information. It's not a bounded poly because those are too crisp. 14:34:01 kseiler: We also know the administrative hierarchy. 14:34:05 kseiler: That suffices for consumption. 14:34:12 ahill2: This also deals with LOD? 14:34:27 ahill2: As you zoom, you don't see all of the boundaries. 14:34:56 kseiler: I don't work on rendering, but on getting people to places, so something like a hamlet, if we give them a center point on a major thoroughfare, that's good enough for us. 14:35:43 ahill2: So we need to accommodate points that don't have geometric boundaries. That's pretty obvious, right? The question is, is the relationship you're describing, administrative types, have we made space for those types of relationships? 14:35:52 this is actually a very interesting discussion (for me!) and I do not want to interrupt but I must sign off. I'll be on the call next week bye 14:35:55 kseiler: I think civic addresses are hierarchical. 14:36:10 cperey waves to matt 14:36:15 -cperey 14:36:16 bye cperey 14:36:17 kseiler: The administrative hierarchy varies from country to country, culture to culture. That's very expensive. 14:36:36 kseiler: I'd recommend that you have a construct for addresses, or reference out to something, but keep it light. 14:36:46 [[+1 to keeping address light, or even non-existent]] 14:37:00 ahill2: Where in the spec do we put these administrative relationships? Carl, Raj? 14:37:40 Carl: I'll have to think about it a bit. When we develop standards at OGC, they tend to be very generic, obviously based on requirements and use cases, but pretty much content model agnostic and application agnostic. 14:38:10 Carl: You could take our standards and code a POI fifty different ways. We've never sat down a defined a POI, other than our location services standard, which just has a POI as a point. I'd have to give some thought to it. 14:38:43 Raj: I'm remember that on this call, we discussed that admin categories could be captured in the categorization element. That we would have a term library for administrative levels that you could then reference the administrative boundary unit for that country. 14:39:27 rsingh2: If you wanted to say something was province, you'd say this is "Manatoba", and you'd reference the term dictionary for Canada, and the value would be "province" 14:39:59 ahill2: Sounds reasonable, but in practical matters, kseiler, are you imagining that this administrative relationship is from POI to POI, or will categories as rsingh2 described suffice? 14:40:11 ahill2: e.g. going out of the data model to define the relationship. 14:40:26 ahill2: If he says "administrative area, Manitoba" he's not referring to another POI. Is that a problem? 14:41:14 kseiler: It's easy for me to imagine that people want to have POIs for features: Silicon Valley, Theater District. Then there are the real world administrative names for things. Do we expect the user community to create POIs that represent say Illinois? Or can the POI just reference the administrative metadata? 14:41:31 kseiler: And then, who maintains the admin data? Those things are all in flux. 14:41:51 kseiler: I think we should have the spec make a POI for Illinois is allowed, but it's a descriptive tag. But if the category covers it, that might be the right thing to do. 14:42:14 surely the POIs are simply binding references to a relatively content free CRS - then POI publishers can create things like features and map content, etc 14:42:26 ahill2: What we came to made some sense. If we're referring to say, McDonald's Cooperation, that's not in the purview of the spec, not that we want to make them impossible. 14:43:14 ahill2: It seems to me that we want people to use and refer to POIs that aren't physical places. But we also want to have a POI that is Illinois, and Chicago, and we want to have a relationship between them. 14:43:25 ahill2: The WD has "contained-within" and "adjacent-to". 14:43:56 rsingh2: Chicago or Illinois could be POIs, and the Chicago one could link to Illinois via contained-within. Then Chicago could have a US category of city. 14:44:08 rsingh2: What we don't have is a real hierarchical taxonomy. 14:44:12 so perhaps we need is "an instance of" 14:44:15 rsingh2: e.g. "all cities are children of states" 14:44:34 rsingh2: That taxonomy is a big part of a gazetteer. 14:44:57 kseiler: What you just said lets one build out that hierarchy. Our spec lets someone else build it. 14:45:09 kseiler: We kind of did the same thing with civil addresses. 14:45:24 kseiler: It sounds like in the POI spec we've got the ability to build these hierarchical constructs. 14:45:40 kseiler: I think the tinker-toy blocks are there if someone wanted to build it out. 14:46:23 ahill2: Do we need an "instance-of" relationship? How do I indicate that Illinois is an instance of a state? Is it sufficient to say it's a category of state? 14:46:26 kseiler: I think that works. 14:47:13 rsingh2: One thing we don't get is automatic hierarchy building. Just because you have a relationship of Chicago to Illinois, you don't get to say it's in the US unless you put it in there. 14:47:28 kseiler: These things are constantly in flux at navteq. 14:47:35 rsingh2: Not good for an international standard. 14:47:44 ahill2: It might be nice if the spec could also be used in that way. 14:48:13 ahill2: They will want to use it in a more flexible manner. It may be possible to say that a POI is a country and then use the spec to say that there are POIs that are states that are contained within it. Maybe there's a possibility it could be used that way. 14:48:15 category queries 14:48:45 ahill2: About tangents, I don't want this call to be about topics that no one cares about, so tangents can be good. 14:48:47 ISSUE-12? 14:48:47 ISSUE-12 -- Should object be a georeference? -- raised 14:48:47 http://www.w3.org/2010/POI/track/issues/12 14:49:24 ahill2: One topic I wanted to hit was objects vs areas. Some confusion over whether this separation between representation and content -- some people thought 3d models would be defining space. 14:49:28 theoretically all features and extents could be externalised and just linked to a POI 14:49:58 ahill2: I think OGC folks would agree that their specs accommodate building geometric areas, but I think we should put a line in the sand and say that a 3d model to define an area is different than say putting a 3d model of Mickey Mouse in a football field. 14:50:10 robman: Inline or external? 14:50:16 ahill2: That's a separate discussion. 14:50:27 rsingh2: You're talking 3d for the physical surface vs say kinematics. 14:50:42 ahill2: One is representation -- I think we're getting to a future where a centroid will not suffice anymore. 14:50:57 ahill2: Something like CityGML that has a detailed hierarchical info on the area. 14:50:57 ahill2 I think you're right - one is a description and one is a representation 14:51:18 description is geometry - representation is how it should look visually 14:51:22 ahill2: There's going to be a collision at some point, not sure what to do about that, at some point they're going to be the same thing. 14:51:56 kseiler: I had this problem around the location primitive. There's a point, and a polygon, and then there is "the building". It's less of a wireframe, but could become the point cloud from our lidar imagery. 14:52:06 kseiler: I couldn't draw a clean line. Why does it end at a 2d polygon. 14:52:10 s/./?/ 14:52:21 i think that's just a choice made by the POI publisher 14:52:22 ahill2: It is a touchy subject. You need rendering experts and animators to comment on it. 14:52:41 and possibly supported by content negotiation in the client apps 14:52:43 ahill2: it's undoubtedly true that not everyone will be satisfied by everything produced. 14:53:02 [[+1 to both of robman's points]] 14:53:14 ahill2: There is a clear distinction between the two: we're not going to propose an Amaya model as a replacement for the extent. 14:53:34 8) 14:53:40 rsingh2: We work at OGC with the Web3D Consortium, which comes from VRML and 3d gaming. 14:53:49 +1 to both of robman's points also 14:53:57 rsingh2: They started with 3d gaming and not real world coord models. Languages were closer to graphics card programming. 14:54:08 rsingh2: They don't even get into character modeling, etc. 14:54:14 rsingh2: It all comes down to LOD. 14:54:34 rsingh2: If you have a point for a POI, and then get more resolution, and create a new POI and link to the old one. 14:54:54 rsingh2: You might have different POIs that use different numbers of coords, or different standard systems to describe it. 14:55:06 rsingh2 - why not use the same POI but have content negotation for resolution based representations 14:55:12 ahill2: Isn't this effectively what something like CityGML does? It has hierarchical relationships between structures? 14:55:25 Carl: Yes it does. 14:56:06 ahill2: Are we barking up the same tree here? We want someone to be able to say "here's a POI for the mall" and someone later submits the POI for the McDonalds and references the Mall as a coord system ref, "I am 100 feet from center of the mall" -- 14:56:22 Carl: I also work on standards at OASIS. There's a group there, the Emergency Management @@something something@@. 14:56:28 rrsagent, draft minutes 14:56:28 I have made the request to generate http://www.w3.org/2011/05/26-poiwg-minutes.html matt 14:56:33 Carl: They've had almost identical discussions. 14:56:39 rrsagent, make logs public 14:56:56 Carl: They're trying to keep the base model as simple as possible, and have extensions. 14:57:07 Carl: They're basic POI is a point, line, or circle. 14:57:17 Carl: If there's a relationship, they do it by URI. 14:57:30 [[+1 to linking such relationships!]] 14:57:42 +1 to that too 14:58:02 kseiler: We're micromapping all of the shopping malls and airports, and there are POIs in there. The shoe store points to the map of the mall. I don't think we can do much beyond reference out to those constructs. 14:58:27 ahill2: Does our current proposed data model accommodate this? It seems to via our relationship primitive. 14:58:29 a combination of relationships and geometries/features should support that 14:58:35 ahill2: Does it allow us to point to a URI of a mall? 14:58:53 [[I wonder about setting the crs to reference the mall, rather than using relationship]] 14:59:08 ahill2: The relationship primitive, we can say "contained within" and point to another URI. 14:59:45 matt: Can't we use the srs stuff? 14:59:57 Carl: That's a spatial reference system. e.g. WGS-84. 15:00:10 ahill2: Sounds like a no. 15:00:21 sorry have to run, good topics 15:00:25 -Karl 15:00:33 matt: OK. How do we represent that it's 100 feet from the center of the mall? 15:00:41 ahill2: I think this a good stopping point and a good beginning point for next week. 15:00:59 +1 to wrapping up - run out of time 15:01:00 ahill2: Definitely we have had a lot of discussion about relative positioning, and now that we have the FPWD out, we need to go back and make sure we've accommodated that. 15:01:27 ahill2: Those of us at the f2f agreed that there are probably many potential descriptions of the point and we wanted to accommodate that. 15:01:36 ahill2: So, you could have a location 100ft from somewhere else. 15:01:51 see ya all next week 15:02:00 -robman 15:02:04 zakim, drop me 15:02:04 Matt is being disconnected 15:02:07 rrsagent, draft minutes 15:02:07 I have made the request to generate http://www.w3.org/2011/05/26-poiwg-minutes.html matt 15:02:07 -Matt 15:02:09 -Raj 15:02:11 -Carl_Reed 15:02:13 -fons 15:02:14 fons has left #poiwg 15:02:27 -Luca 15:02:30 ahill2 has left #poiwg 15:02:35 robman has left #poiwg 15:02:44 zakim, who is on the phone? 15:03:11 On the phone I see ahill2 15:04:01 zakim, drop ahill2 15:04:39 ahill2 is being disconnected 15:04:41 UW_POI(POIWG)10:00AM has ended 15:04:43 Attendees were Matt, ahill2, +1.312.894.aaaa, Karl, robman, fons, cperey, Carl_Reed, Raj, Luca 15:07:58 rrsagent, draft minutes 15:07:58 I have made the request to generate http://www.w3.org/2011/05/26-poiwg-minutes.html matt 15:17:27 Chair: Alex 15:17:57 s|Topic: Actions/Issues clean up|Topic: map georeference type| 15:17:59 rrsagent, draft minutes 15:17:59 I have made the request to generate http://www.w3.org/2011/05/26-poiwg-minutes.html matt 15:19:20 i/So we need to accommodate/Topic: Role of the relationship primitve| 15:19:22 rrsagent, draft minutes 15:19:22 I have made the request to generate http://www.w3.org/2011/05/26-poiwg-minutes.html matt 15:19:54 s/primitve|/primitive/ 15:19:56 rrsagent, draft minutes 15:19:56 I have made the request to generate http://www.w3.org/2011/05/26-poiwg-minutes.html matt 15:22:56 danbri has joined #poiwg 17:29:02 Zakim has left #poiwg