Points of Interest Working Group Teleconference -- 02 Jun 2011

<trackbot> Date: 02 June 2011

<robman> evening all

<scribe> ACTION: matt to update homepage with co-chair announcement, FPWD link [recorded in http://www.w3.org/2011/06/02-poiwg-minutes.html#action01]

<trackbot> Created ACTION-84 - Update homepage with co-chair announcement, FPWD link [on Matt Womer - due 2011-06-09].

<robman> yep

<scribe> Agenda: http://lists.w3.org/Archives/Member/member-poiwg/2011Jun/0000

Next F2F

ahill2: We've got a date for the next F2F at MIT in July, exact dates are still up.
... Before or after the week of the 19th-20th.
... We've tended to do Tuesday-Thursday because people can travel on Monday, but Andy's commitment was on the 20th, we could do Thursday and Friday, which might be undesirable. The week of the 11th -- 12th-13th -- or the 25-27th.

<rsingh2> all those dates are fine for me

Ronald: Most of July I am free, that's fine.

karls: I cannot do the week of July 25th.

<robman> sorry but I won't be able to make any f2f's in july

ahill2: Let's construct a poll

<scribe> ACTION: matt to put poll for 12-13th or the 26-27th of July at MIT [recorded in http://www.w3.org/2011/06/02-poiwg-minutes.html#action02]

<trackbot> Created ACTION-85 - Put poll for 12-13th or the 26-27th of July at MIT [on Matt Womer - due 2011-06-09].

WG Timeline

-> http://www.w3.org/2010/POI/charter/#milestones Chartered timeline

ahill2: The charter has our timeline.
... We got our FPWD out the door in April.
... Our next milestone is lc

matt: <explains rec process>

ahill2: That means we want to be in the PR state in November.
... There's likely to be changes to the FPWD. It's possible we would be ready for Last Call after the f2f, but given the constraints around LC that we may have a tight schedule.

karls: My impression is that the FPWD was just that: a first attempt.
... It is incomplete.
... We have to produce a relatively complete WD before we can get to last call.

<Ronald> +1

ahill2: Right.

ahill2: Having that at the next f2f is a goal. I think f2f could be about tying a bow on the wd.

matt: Maybe I could get another draft out before the f2f and we can use that at the f2f.

rsingh2: I agree.

ahill2: We've been talking about another f2f in September in Denver.

rsingh2: It's the middle of September, I thought we were taking that off the table and shooting for another meeting in Brussels.

<robman> what about Basel in Oct? assuming most people will be there

ahill2: How many more times do we want to meet before we have a rec? One more time?
... 2 more meetings before Rec.

rsingh2: Sounds reasonable.

<karls> +1

matt: Plus there are these AR deliverables, maybe it's a topic for another time.

ahill2: It's been a challenge because we've got two distinctly different constituencies who have intermittently participated in the WG and it feels as though we really need to focus on the POI Rec.
... Given our resources and participation. That's not a way of saying I don't think the AR notes are important, but I'm leery of say, two meetings a week, one on POI and one on AR Notes. That makes me nervous.
... Part of me feels if we get over the hump with the POI Rec, then it'll be a lot easier to put together an AR note.
... I'm not sure what the vocabulary is. Is that Jonathan's landscape?

matt: The vocabulary was about metadata added to POIs that could be sprinkled into a POI that enables AR apps. The landscape doc was the gap analysis sort of stuff around the Web and AR standards.
... I'm sure he would appreciate the help, we could put out a call for volunteers.

ahill2: That's our milestones and timeline. My general opinion is that we stay on course with the POI Rec for the time being and get over the hump through July before focusing our attention on the other notes.

karls: I'm concerned that we may not have enough people to get this to closure. We can bulldog through the next WD and then get people in the review loop? It may be difficult to bring someone in at this point. We've got a small working team, but sometimes I feel like we don't have enough people. There's a lot of investigation to do and we're feeling thin.

ahill2: I agree. If I wasn't used to the situation I'd be more flabbergasted.
... The more I get into this, the more I realize there's a vast depth of knowledge required.
... It makes me wonder if we need to pick our battles more. Sharpen our focus to some very core things.
... I feel like we're getting into the situation that Rob suggested, that we're redoing a significant amount of work or re-incorporating a significant amount of work. We've talked in the past about inviting outside experts on a more frequent basis.
... We need more of that.

matt: Publishing gets us comments and help. Then there's things like the blog. And identifying things that are too complex and maybe are at risk.

ahill2: I think you hit the nail on the head, generating another WD, publish it in July and hope to attract more serious attention.
... Try to attract serious people to take a look at us.

<karls> +1

<Ronald> +1

karls: A review cycle where we identify where we should apply energy towards completing.

matt: Yeah, I'll do an editor's draft.

ahill2: There was a suggestion on the blog that it's not in TR?

-> http://www.w3.org/TR/poi-core/ TR

karls: I think self promotion is a good way to get more attention. Another way is to approach other communities that we overlap with or incorporate.
... e.g. everywhere we rely on another specification we reach out to those groups.

matt: Does someone want to take a pass through and try to figure out who to coordinate with?

-> http://www.w3.org/TR/#tr_Geospatial

<robman> +1 to karls suggestion - I'm happy to make a map of related specs/stds/wgs

<robman> second 8)

<scribe> ACTION: Rob t make a map of specs/stds/wgs that are related to our work [recorded in http://www.w3.org/2011/06/02-poiwg-minutes.html#action03]

<trackbot> Created ACTION-86 - T make a map of specs/stds/wgs that are related to our work [on Rob Manson - due 2011-06-09].

Namespacing

ahill2: We need to come to a resolution on namespaces as it informs a number of things. Looking through CityGML and it's replete with namespacing.
... Significantly takes advantage of namespacing. I think we've always had in mind somewhat light POI descriptions.
... Rob suggested three basic approaches: 1. no namespacing 2. namespacing 3. reappropriating namespaced terms

-> http://lists.w3.org/Archives/Public/public-poiwg/2011May/0056.html Rob's email

ahill2: I don't know which way to go on this. Any advice on what's appropriate?
... What are other groups doing with this kind of problem?

robman: I think namespaces give you the best extensibility, and it lets you reuse the work that is created by specialist groups.

ahill2: If that's the case, what are the arguments for -- I don't think reinventing terms or redoing things is what we're looking for. What's the argument for dropping namespaces?
... Simplification seems the most obvious. People can easily construct JSON without having to worry about namespacing.

robman: Raj has an aesthetic case. In geoJSON there's a good example of it, but it's quite contentious in the JSON community.

matt: I couldn't find an example, I looked in the spec and the mailing list.

robman: It's in the wiki.

-> http://lists.w3.org/Archives/Public/public-poiwg/2011May/0058.html RDFa's compromise

robman: From Raj's blog post about namespaces too.

<robman> matt - see this page an /namespace -> http://wiki.geojson.org/GeoJSON_1.0_RC_1

rsingh2: I think aesthetics are important. And a technical argument: we've had trouble with GML, people's validators end up complicated. When people are new it takes days to get going with namespace validation. I think we'd be happy in the specification narratively saying how these things are adopted from the OGC spatial model, etc, rather than a namespace.

ahill2: Is this a practical matter for validation?

rsingh2: In the narrative it's more about having confidence that the way geography is handled is good and thorough and conforms with OGC/ISO and their ways of looking at geospatial.

ahill2: You would like to create a situation where people feel more comfortable with GML into their XML without feeling the need to validate it?

rsingh2: Well, through official OGC schemas. Look at issue-20.

issue-20?

<trackbot> ISSUE-20 -- How should we represent lines? -- raised

<trackbot> http://www.w3.org/2010/POI/track/issues/20

rsingh2: I suggested we represent lines the way GML does it.
... I used namespaces, but I think it would be fine to drop the GML namespace stuff and make it W3C namespace. Put it in the spec that they come from GML, but for technical reasons we chose to drop the namespace.

robman: I think that's fine for the core elements.
... For extensibility items though, we need more.

<Ronald> +1 to robman's comment

<robman> +1 to politely and transparently stealing 8)

ahill2: What I'm hearing is that we cut and paste schema content into our schema, keep it in our namespace, and in the narrative make it clear that we've taken it from another schema.
... That sounds reasonable and good for people who want to make it JSON and those who think namespaces are unwieldly. What practical problems? What if GML changes?

robman: That's my concern.

rsingh2: It's no fun when you have the namespaces either though.
... It's much better this way.

ahill2: We don't have to worry about things changing out from under the spec.

<robman> =1

karls: I like what's being said, but it does imply there is some kind of monitor and maintenance activity.

matt: I'd suggest we peg our version of the spec to a version of theirs, and rev our version if we need to update to a new GML spec or something and have that point at the latest.

ahill2: Is there any relationship to profiles in what we're talking about?

rsingh2: You could create a profile of GML for the POI work. Profiles work like this: there's a GML application schema and a profile. The App schema subsets the GML schema, taking out only the elements you need -- that's a whole new schema. We did that for GeoRSS.
... GeoRSS is in a GeoRSS namespace. The profile --

ahill2: That has the same problems we have, right? If GML changes underneath it then they need to announce to their community that things have changed?

rsingh2: There was no explicit reference to the version, since it didn't do the namespacing.
... Profiles take the schema, references it, and builds in additional elements that aren't in GML. I think CityGML does this, takes all the elements needed from GML in a schema, then adds new things that CityGML needed to the profile.
... For POI we could take point, line and polygon out of GML.
... GeoRSS only added the where element. It took point, line, polygon and box, and added where.

ahill2: Take something like Atom. Does GeoRSS reference Atom namespace or is it baked into the profile?

rsingh2: Nope, it goes the other way, it doesn't reference Atom, but Atom references it.
... GeoRSS doesn't know it's being used in an RSS feed in any particular way.

<rsingh2> georss examples: http://www.georss.org/gml

ahill2: Is there multiple inheritance cases here or is it ad hoc?
... We're going to need more than one standard for our eventual schema.
... We've established that we can profile off of GML and add our own elements, but what if we're profiling off of multiple namespaces?
... Is there a terminology for that or do what you want?

rsingh2: When you subset a schema, it's kind of do what you want.
... We've got some tools to do it, but it's just doing what you want to get rid of all that extra stuff.

<ahill2> http://www.georss.org/gml

ahill2: I'm looking at the above link. They're referencing GML.
... The point is that we still end up with namespaces.

rsingh2: Yes, but I'm not suggesting we do it this way.

ahill2: GeoRSS Simple seems much more like what we want.

-> http://www.georss.org/simple

<robman> or even simpler

rsingh2: Simple still has the GeoRSS namespace, so once you add it to an Atom feed, you'd probably keep the GeoRSS namespace. I'm thinking something even simpler and lighter-weight.
... Something where we have no namespace on the core elements.

ahill2: Right. I can imagine we take this and have it be a POI, have an Atom based schema and they are all under the POI namespace.

<robman> +1 to rsingh2's suggestion for core elements

rsingh2: Yes, so even if you adopt something like Atom's category, then you just call it category.
... I like that as long as we don't have a name collision.

ahill2: Avoiding these name collisions, is that a serious problem?

rsingh2: We have control over the Core, so we can make sure it's not a problem. If we use say, Atom author element, then we just don't use it any other way.
... Updated is maybe a better example. If we want a timestamp on the artifact, rather than the POI data itself, we would need different names that we could cover in the narrative.
... We should use the atom updated element, but it won't be completely clear without a namespace. The semantics won't be clear, but the narrative can explain.

<karls> all good

ahill2: I like this, and am happy to hear you bless this. We're not hearing any dissent. I'd say let's take this approach.

matt: I just want to make it clear that this namespace approach is just for the core elements and that we haven't got a story yet for metadata extensibility.

ahill2: A question for rsingh2, your UML document, was it your intention that the POI can only have a single location?

rsingh2: Yes, that's what I thought we wanted there.
... Well, not single, there was the idea of a center point and a navigation point, but my model doesn't show that. I have one single georeference required.

ahill2: I think we should get on the same page about this next week.
... A lot of the f2f discussions were around having multiple hints as to POI location in multiple different ways. e.g. "blue house down the street from the colosseum" and a civil address and a geographic point on the earth and some sort of other relationship to other POIs through which you could infer other locations.

<karls> got to go, bye

rsingh2: The relationship primitive is in there for some of that.
... For location we can change the 1 to a 1..* on georeference.

ahill2: I think that would be fine, I don't think we'll talk ourselves out of it.
... I haven't heard you or Rob weigh in on it much, let's have that be a discussion for next week or over email.
... There will be a poll forthcoming. Talk to you next week!

<robman> btw here's a link on default namespace usage http://www.w3.org/TR/xml-names/#defaulting

<robman> bye

- DRAFT -

Points of Interest Working Group Teleconference

02 Jun 2011

Attendees

Contents

Next F2F

WG Timeline

Namespacing

Summary of Action Items

Scribe.perl diagnostic output