See also: IRC log
<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
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].
-> 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.
+1
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.
+1
<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].
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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s|http://www.georss.org/simple|-> http://www.georss.org/simple| No ScribeNick specified. Guessing ScribeNick: matt Inferring Scribes: matt Default Present: Matt, Karl, robman, Alex, Ronald, Raj Present: Matt Karl robman Alex Ronald Raj Regrets: Andy Agenda: http://lists.w3.org/Archives/Member/member-poiwg/2011Jun/0000 Found Date: 02 Jun 2011 Guessing minutes URL: http://www.w3.org/2011/06/02-poiwg-minutes.html People with action items: matt rob WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]