Minutes 26 May 2011 POI WG Teleconference

Hi all,

The minutes from last week's meeting are here:

A text version is below.  Sorry for the delay in sending them out!

Our main points of discussion were around the map georeference type and the relationship primitive.  We also resolved to meet at MIT in July for our next f2f.

See you on the call in a moment!



      [1] http://www.w3.org/

                               - DRAFT -

            Points of Interest Working Group Teleconference

26 May 2011


      [2] http://lists.w3.org/Archives/Member/member-poiwg/2011May/0055

   See also: [3]IRC log

      [3] http://www.w3.org/2011/05/26-poiwg-irc


          Matt, ahill2, +1.312.894.aaaa, Karl, robman, fons, cperey,
          Carl_Reed, Raj, Luca




     * [4]Topics
         1. [5]Next F2F
         2. [6]map georeference type
         3. [7]Role of the relationship primitive
     * [8]Summary of Action Items

   <trackbot> Date: 26 May 2011


   <trackbot> ISSUE-33 -- Is the map georeference type needed? --

   <trackbot> [9]http://www.w3.org/2010/POI/track/issues/33

      [9] http://www.w3.org/2010/POI/track/issues/33

   <robman> i've muted my phone

   -> [10]http://www.w3.org/TR/2011/WD-poi-core-20110512/ POI Core FPWD

     [10] http://www.w3.org/TR/2011/WD-poi-core-20110512/

   <scribe> scribe: Matt

   <cperey> hi

   <robman> hi

Next F2F

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

   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.

   matt: I'll take the hit for the miscommunication and write to him
   after this call.

   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.
   ... That leaves us with MIT.

   cperey: Clarification: how sure are you about September in Denver?
   is that 100% nailed in?

   ahill2: Logistics and coordination? No.

   cperey: In all senses of the question.

   ahill2: It was the top vote getter in the poll, followed by OMA and

   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.

   cperey: True, but the next one will impact the following one.
   ... Late July is also close to mid-September.
   ... The benefit of Denver is co-locating with other SDOs. Plus,
   there's less cost, for the meeting itself.

   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.
   ... As far as Denver vs TPAC goes, that should be group-wide
   ... I resolve that we will meet at MIT in July. Date is TBD, as I
   need Andy to chime in. He'll be chairing.
   ... Objections?
   ... None.

   -> [11]http://lists.w3.org/Archives/Member/member-poiwg/2011May/0055

     [11] http://lists.w3.org/Archives/Member/member-poiwg/2011May/0055

map georeference type


   <trackbot> ISSUE-33 -- Is the map georeference type needed? --

   <trackbot> [12]http://www.w3.org/2010/POI/track/issues/33

     [12] http://www.w3.org/2010/POI/track/issues/33

   kseiler: Do we need to go back in one of these meetings and adjust
   the timeline? It's starting to feel open-ended.

   ahill2: let's put that in the agenda for the next meeting.

   <cperey> +1

   <scribe> ACTION: ahill2 to put time-line on next week's agenda
   [recorded in

   <trackbot> Created ACTION-83 - Put time-line on next week's agenda
   [on Alex Hill - due 2011-06-02].

   ahill2: It seems to me the consensus is that we don't need a map

   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.
   ... 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.
   ... So in the spec, being able to hard bind to a point on the map
   would relieve ambiguity.

   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.

   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.

   <ahill2> Hard to argue with the need for a map reference, but hard
   to incorporate it cleanly

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

   ahill2: Is there value in talking about how to approach that?

   kseiler: I don't know if it's part of the core spec, or a
   recommended model, or a soft advisory or something.

   ahill2: Can a map reference be as simple as a URI?

   kseiler: Yes.

   ahill2: The way it's going to be implemented is going to be vendor

   kseiler: Make it optional, and a URI and then it could go in the
   core spec.

   ahill2: So, is it important enough to add to the core spec?
   Obviously, it'd be optional.
   ... Sounds like the issue remains open.


   <trackbot> ISSUE-32 -- Does map georeference side definition need
   additional info? -- raised

   <trackbot> [14]http://www.w3.org/2010/POI/track/issues/32

     [14] http://www.w3.org/2010/POI/track/issues/32

   ahill2: Anything else to say about map georeference?
   ... OK, moving on.
   ... Move on to namespaces.

   kseiler: Going back a bit. I'm not necessarily current. Have you
   talked about locations that are a little bit ambiguous?
   ... 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?

   ahill2: What kind of information do we have about where a hamlet is?

   kseiler: Typically, it's X/Y is the intersection of a main
   thoroughfare. It's usually got some administrative naming associated
   with it.
   ... Name neighborhoods too.
   ... Is this type of thing handled by map reference, or is there an
   open ended construct?

   <Luca> Sorry I'm late

   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.

   <robman> things like hamlets seems more like a combination of
   "define as an area geometry" and an open ended discussion about
   international address formats 8)

   ahill2: There has been a lot of confusion about this, but that is
   the plan.
   ... For instance, we have the relationship primitive which I believe
   facilitates that kind of thing.
   ... Somebody just recently posted an OGC thing about the kinds of
   ... Talking about POIs that aren't specifically geographic areas

   [[3.3 Relationship Primitives

   These section should perhaps simply reference the OGC/ISO Simple

   Interface standard, section 6.1.15  Relational Operators.]]

   -> [15]http://lists.w3.org/Archives/Public/public-poiwg/2011May/0028
   OGC comments, relationships

     [15] http://lists.w3.org/Archives/Public/public-poiwg/2011May/0028

   carl: A series of POIs?

   ahill2: At one point we had discussion about having a whole bunch of
   POIs that could have relationships like "contains" that establishes
   ... The example was Silicon Valley. It's not a part of a city
   necessarily, but is a region within it.
   ... We wanted to capture that kind of relationship.

   carl: There's a group in ISO called @@??@@
   ... In our terminology that's known as a feature collection, or a
   multi-point/polygon geometry.
   ... 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
   ... 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.
   ... The question is, do you want all of that complexity in the data
   ... 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

   <robman> +1 for a simple point based data model with a feature
   collection relationship extension

   kseiler: I agree with simple data model.

   ahill2: How do you represent these POIs at navteq?

   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.
   ... We also know the administrative hierarchy.
   ... That suffices for consumption.

   ahill2: This also deals with LOD?
   ... As you zoom, you don't see all of the boundaries.

   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.

Role of the relationship primitive

   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?

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

   kseiler: I think civic addresses are hierarchical.

   <cperey> cperey waves to matt

   <robman> bye cperey

   kseiler: The administrative hierarchy varies from country to
   country, culture to culture. That's very expensive.
   ... I'd recommend that you have a construct for addresses, or
   reference out to something, but keep it light.

   [[+1 to keeping address light, or even non-existent]]

   ahill2: Where in the spec do we put these administrative
   relationships? Carl, Raj?

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

   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.

   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"

   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?
   ... e.g. going out of the data model to define the relationship.
   ... If he says "administrative area, Manitoba" he's not referring to
   another POI. Is that a problem?

   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?
   ... And then, who maintains the admin data? Those things are all in
   ... 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.

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

   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.
   ... 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
   ... The WD has "contained-within" and "adjacent-to".

   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.
   ... What we don't have is a real hierarchical taxonomy.

   <ahill2> so perhaps we need is "an instance of"

   rsingh2: e.g. "all cities are children of states"
   ... That taxonomy is a big part of a gazetteer.

   kseiler: What you just said lets one build out that hierarchy. Our
   spec lets someone else build it.
   ... We kind of did the same thing with civil addresses.
   ... It sounds like in the POI spec we've got the ability to build
   these hierarchical constructs.
   ... I think the tinker-toy blocks are there if someone wanted to
   build it out.

   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?

   kseiler: I think that works.

   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.

   kseiler: These things are constantly in flux at navteq.

   rsingh2: Not good for an international standard.

   ahill2: It might be nice if the spec could also be used in that way.
   ... 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.

   <robman> category queries

   ahill2: About tangents, I don't want this call to be about topics
   that no one cares about, so tangents can be good.


   <trackbot> ISSUE-12 -- Should object be a georeference? -- raised

   <trackbot> [16]http://www.w3.org/2010/POI/track/issues/12

     [16] http://www.w3.org/2010/POI/track/issues/12

   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.

   <robman> theoretically all features and extents could be
   externalised and just linked to a POI

   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.

   robman: Inline or external?

   ahill2: That's a separate discussion.

   rsingh2: You're talking 3d for the physical surface vs say

   ahill2: One is representation -- I think we're getting to a future
   where a centroid will not suffice anymore.
   ... Something like CityGML that has a detailed hierarchical info on
   the area.

   <robman> ahill2 I think you're right - one is a description and one
   is a representation

   <robman> description is geometry - representation is how it should
   look visually

   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.

   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
   ... I couldn't draw a clean line. Why does it end at a 2d polygon?

   <robman> i think that's just a choice made by the POI publisher

   ahill2: It is a touchy subject. You need rendering experts and
   animators to comment on it.

   <robman> and possibly supported by content negotiation in the client

   ahill2: it's undoubtedly true that not everyone will be satisfied by
   everything produced.

   [[+1 to both of robman's points]]

   ahill2: There is a clear distinction between the two: we're not
   going to propose an Amaya model as a replacement for the extent.

   <robman> 8)

   rsingh2: We work at OGC with the Web3D Consortium, which comes from
   VRML and 3d gaming.

   <fons> +1 to both of robman's points also

   rsingh2: They started with 3d gaming and not real world coord
   models. Languages were closer to graphics card programming.
   ... They don't even get into character modeling, etc.
   ... It all comes down to LOD.
   ... If you have a point for a POI, and then get more resolution, and
   create a new POI and link to the old one.
   ... You might have different POIs that use different numbers of
   coords, or different standard systems to describe it.

   <robman> rsingh2 - why not use the same POI but have content
   negotation for resolution based representations

   ahill2: Isn't this effectively what something like CityGML does? It
   has hierarchical relationships between structures?

   Carl: Yes it does.

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

   Carl: I also work on standards at OASIS. There's a group there, the
   Emergency Management @@something something@@.
   ... They've had almost identical discussions.
   ... They're trying to keep the base model as simple as possible, and
   have extensions.
   ... They're basic POI is a point, line, or circle.
   ... If there's a relationship, they do it by URI.

   [[+1 to linking such relationships!]]

   <robman> +1 to that too

   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

   ahill2: Does our current proposed data model accommodate this? It
   seems to via our relationship primitive.

   <robman> a combination of relationships and geometries/features
   should support that

   ahill2: Does it allow us to point to a URI of a mall?

   [[I wonder about setting the crs to reference the mall, rather than
   using relationship]]

   ahill2: The relationship primitive, we can say "contained within"
   and point to another URI.

   matt: Can't we use the srs stuff?

   Carl: That's a spatial reference system. e.g. WGS-84.

   ahill2: Sounds like a no.

   <kseiler> sorry have to run, good topics

   matt: OK. How do we represent that it's 100 feet from the center of
   the mall?

   ahill2: I think this a good stopping point and a good beginning
   point for next week.

   <robman> +1 to wrapping up - run out of time

   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.
   ... Those of us at the f2f agreed that there are probably many
   potential descriptions of the point and we wanted to accommodate
   ... So, you could have a location 100ft from somewhere else.

   <robman> see ya all next week

Summary of Action Items

   [NEW] ACTION: ahill2 to put time-line on next week's agenda
   [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [18]scribe.perl version 1.136
    ([19]CVS log)
    $Date: 2011/05/26 15:20:02 $

     [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [19] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at [20]http://dev.w3.org/cvsweb/~checkout~/2002

     [20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/./?/
Succeeded: s/./?/
Succeeded: s|Topic: Actions/Issues clean up|Topic: map georeference typ
Succeeded: i/So we need to accommodate/Topic: Role of the relationship
Succeeded: s/primitve|/primitive/
Found Scribe: Matt
Inferring ScribeNick: matt
Default Present: Matt, ahill2, +1.312.894.aaaa, Karl, robman, fons, cpe
rey, Carl_Reed, Raj, Luca
Present: Matt ahill2 +1.312.894.aaaa Karl robman fons cperey Carl_Reed
Raj Luca
Agenda: [21]http://lists.w3.org/Archives/Member/member-poiwg/2011May/00
Found Date: 26 May 2011
Guessing minutes URL: [22]http://www.w3.org/2011/05/26-poiwg-minutes.ht
People with action items: ahill2

     [21] http://lists.w3.org/Archives/Member/member-poiwg/2011May/0055
     [22] http://www.w3.org/2011/05/26-poiwg-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

   End of [23]scribe.perl diagnostic output]

     [23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Thursday, 2 June 2011 14:00:31 UTC