- From: Matt Womer <mdw@w3.org>
- Date: Thu, 2 Jun 2011 10:00:28 -0400
- To: public-poiwg W3C <public-poiwg@w3.org>
Hi all,
The minutes from last week's meeting are here:
http://www.w3.org/2011/05/26-poiwg-minutes.html
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!
-M
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Points of Interest Working Group Teleconference
26 May 2011
[2]Agenda
[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
Attendees
Present
Matt, ahill2, +1.312.894.aaaa, Karl, robman, fons, cperey,
Carl_Reed, Raj, Luca
Regrets
Chair
Alex
Scribe
Matt
Contents
* [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
ISSUE-33?
<trackbot> ISSUE-33 -- Is the map georeference type needed? --
raised
<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
MIT.
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
decision.
... 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
Agenda
[11] http://lists.w3.org/Archives/Member/member-poiwg/2011May/0055
map georeference type
ISSUE-33?
<trackbot> ISSUE-33 -- Is the map georeference type needed? --
raised
<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
[13]http://www.w3.org/2011/05/26-poiwg-minutes.html#action01]
<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
georeference.
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
specific.
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.
issue-32?
<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
relationships.
... Talking about POIs that aren't specifically geographic areas
[[3.3 Relationship Primitives
These section should perhaps simply reference the OGC/ISO Simple
Features
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
"contains".
... 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
model?
... 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.
<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
flux.
... 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
them.
... 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.
ISSUE-12?
<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
kinematics.
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
imagery.
... 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
apps
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
constructs.
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
that.
... 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
[17]http://www.w3.org/2011/05/26-poiwg-minutes.html#action01]
[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
/scribe/
[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
e|
Succeeded: i/So we need to accommodate/Topic: Role of the relationship
primitve|
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
55
Found Date: 26 May 2011
Guessing minutes URL: [22]http://www.w3.org/2011/05/26-poiwg-minutes.ht
ml
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