W3C home > Mailing lists > Public > public-poiwg@w3.org > June 2011

Minutes 2 June, 2011 POIWG Teleconference

From: Matt Womer <mdw@w3.org>
Date: Thu, 2 Jun 2011 11:26:05 -0400
Message-Id: <3FC6573C-0BEB-4EC7-AA27-98BACCBF933B@w3.org>
To: public-poiwg W3C <public-poiwg@w3.org>
Hi all,

The minutes from today's meetings are available here:
	http://www.w3.org/2011/06/02-poiwg-minutes.html

And as text below.

It was an administrative issue heavy call today, but we resolved to poll about dates in July for a f2f at MIT, and reviewed our chartered goals.  We agreed to publish a working draft before the July f2f, with the goal of turning out a Last Call doc shortly after our f2f.

On the technical front, we discussed namespaces and have come to an agreement that for the core elements, we will likely adopt into our namespace elements from other specifications.  For example, if we adopted GML point instead of having "<gml:point>" we would have just "<point>" and the specification would explain that the semantics of the point element are identical to a particular version of GML.

The actions are as follows:
	Matt to put poll for 12-13th or the 26-27th of July at MIT
	Matt to update homepage with co-chair announcement, FPWD link
	Rob to make a map of specs/stds/wgs that are related to our work

Thanks to all those who attended,

-Matt


   [1]W3C

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

                               - DRAFT -

            Points of Interest Working Group Teleconference

02 Jun 2011

   [2]Agenda

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

   See also: [3]IRC log

      [3] http://www.w3.org/2011/06/02-poiwg-irc

Attendees

   Present
          Matt, Karl, robman, Alex, Ronald, Raj

   Regrets
          Andy

   Chair
          Alex

   Scribe
          matt

Contents

     * [4]Topics
         1. [5]Next F2F
         2. [6]WG Timeline
         3. [7]Namespacing
     * [8]Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 02 June 2011

   <robman> evening all

   <scribe> ACTION: matt to update homepage with co-chair announcement,
   FPWD link [recorded in
   [9]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:
   [10]http://lists.w3.org/Archives/Member/member-poiwg/2011Jun/0000

     [10] 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
   [11]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

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

     [12] http://www.w3.org/2010/POI/charter/#milestones

   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?

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

     [13] http://www.w3.org/TR/poi-core/

   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?

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

     [14] 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
   [15]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

   ->
   [16]http://lists.w3.org/Archives/Public/public-poiwg/2011May/0056.ht
   ml Rob's email

     [16] http://lists.w3.org/Archives/Public/public-poiwg/2011May/0056.html

   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.

   ->
   [17]http://lists.w3.org/Archives/Public/public-poiwg/2011May/0058.ht
   ml RDFa's compromise

     [17] http://lists.w3.org/Archives/Public/public-poiwg/2011May/0058.html

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

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

     [18] 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> [19]http://www.w3.org/2010/POI/track/issues/20

     [19] 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: [20]http://www.georss.org/gml

     [20] 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> [21]http://www.georss.org/gml

     [21] 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.

   -> [22]http://www.georss.org/simple

     [22] 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
   [23]http://www.w3.org/TR/xml-names/#defaulting

     [23] http://www.w3.org/TR/xml-names/#defaulting

   <robman> bye

Summary of Action Items

   [NEW] ACTION: matt to put poll for 12-13th or the 26-27th of July at
   MIT [recorded in
   [24]http://www.w3.org/2011/06/02-poiwg-minutes.html#action02]
   [NEW] ACTION: matt to update homepage with co-chair announcement,
   FPWD link [recorded in
   [25]http://www.w3.org/2011/06/02-poiwg-minutes.html#action01]
   [NEW] ACTION: Rob t make a map of specs/stds/wgs that are related to
   our work [recorded in
   [26]http://www.w3.org/2011/06/02-poiwg-minutes.html#action03]

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [27]scribe.perl version 1.136
    ([28]CVS log)
    $Date: 2011/06/02 15:04:47 $
     _________________________________________________________

     [27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [28] 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 [29]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s|[30]http://www.georss.org/simple|-> [31]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: [32]http://lists.w3.org/Archives/Member/member-poiwg/2011Jun/00
00
Found Date: 02 Jun 2011
Guessing minutes URL: [33]http://www.w3.org/2011/06/02-poiwg-minutes.ht
ml
People with action items: matt rob

     [30] http://www.georss.org/simple
     [31] http://www.georss.org/simple
     [32] http://lists.w3.org/Archives/Member/member-poiwg/2011Jun/0000
     [33] http://www.w3.org/2011/06/02-poiwg-minutes.html

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


   End of [34]scribe.perl diagnostic output]

     [34] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 2 June 2011 15:26:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:30 UTC