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

[minutes] POIWG telecon minutes 26 Jan 2011

From: Matt Womer <mdw@w3.org>
Date: Wed, 26 Jan 2011 12:29:02 -0500
Message-Id: <34DA04FB-345B-47E1-9069-B5B217AE3BAC@w3.org>
To: public-poiwg W3C <public-poiwg@w3.org>
Hi all,

The minutes from today's meeting are available here:

And as text below.

We spent most of our time discussing Karl's contributions (http://lists.w3.org/Archives/Public/public-poiwg/2011Jan/0017 ) for a location primitive.

The actions were as follows:
	Christine to contact Connected Environments to give a presentation. 
	Karl to try to determine what is optional, required, or one of in location primitve
	Karl to work on making map-reference as part of relative

Thanks all,



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

                               - DRAFT -

            Points of Interest Working Group Teleconference

26 Jan 2011


      [2] http://lists.w3.org/Archives/Member/member-poiwg/2011Jan/0019.html

   See also: [3]IRC log

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


          Matt, +1.919.439.aaaa, Andy, +3539149aabb, +1.312.894.aacc,
          Vinod, Karl, Jens, +1.617.848.aadd, Alex, Christine




     * [4]Topics
         1. [5]Administrative
         2. [6]Review Karl's materials
         3. [7]Face to Face
     * [8]Summary of Action Items

   <trackbot> Date: 26 January 2011

   <andy> hi

   <Ronald> hi

   <scribe> scribe: Matt

   <scribe> Chair: Andy

   <andy> Meeting Starts Promptly at 9 Roll call Selection of scribe
   Any objections/corrections to previous meeting minutes
   [9]http://www.w3.org/2011/01/19-poiwg-minutes Discussion of Location
   Primitive contribution Is an ID required…Continued from last week.
   Discussion of Categorization Primitive Face-to-Face Date finalize
   Announcements AOB

      [9] http://www.w3.org/2011/01/19-poiwg-minutes

   <cperey> +1


   andy: No objections to last week's minutes.

Review Karl's materials

   ml Karl's email

     [10] http://lists.w3.org/Archives/Public/public-poiwg/2011Jan/0017.html

   Karl: I went with overkill for this, figuring it's easier to cut

   kseiler: Trying to abstract the where from the what
   ... Tried to decouple description from geospatial location

   <cperey> last week we had quite a detailed discussion about ID

   kseiler: Within the location primitive there is an identification
   portion that has IDs, associated IDs, temporal information, update
   information, how it's used, it's status, and how trustworthy the
   information is.
   ... There's a geo-reference portion that can contain a point, which
   has a type with precision information: high/low, or interpolated.
   ... Within the point there can be a center point, which has
   coordinates/height and geodetic system.
   ... Another portion of the geo-reference can be an address, which
   has the expected components of an address, e.g. country code and
   language code, street, but also some things like floor, suite, area,
   postal code.
   ... There's also a line portion and 2D polygon, these are
   collections of points. 3D is left TBD.
   ... Area, not sure what the best way to do this is, as it could be
   just a polygon with a center point. Not sure we need a separate
   ... There's a portion for unknown, it's a POI where we don't know
   where it is yet.
   ... Relative, we've done some looking at that elsewhere, we can use
   that. There's a distance, and bearing, and also an optional
   reference to one of the other constructs in a POI.
   ... And a map reference, which lets people not have to provide their
   own geocoding function. If you have a high fidelity system, you can
   reference it. e.g. this point is 10% off what OSM has.

   andy: Is this overly heavy-weight?
   ... This is probably the first thing we've had at this level of

   <cperey> Alex is saying EXACTLY what I was thinking!

   Alex: Thanks for the work Karl. I don't feel like I'm in a position
   to argue against many of these things based on experience. This
   seems like a good start.

   <cperey> how could you possibly make it more detailed?

   <cperey> +q

   <jens> more detailed? you could add more indoor directions for

   kseiler: I'd love to hear if this is supportive of those domain of

   <cperey> haha!!

   <cperey> good one Alex!

   Alex: Knowing where something is, is certainly a good start.
   ... I don't see anything about orientation. Is anything added
   assumed to be N/E/W oriented?

   cperey: I see at the top that you're trying to isolate the location.
   Can we say that this information is accurate for this second, or
   ... Someone running say, this could be true for just the instant
   that the object is there.
   ... I was working on something the same, but on an object primitive.
   I like the structure.

   <kseiler> +q

   cperey: So, I was thinking about how to describe this object with
   this scheme. An object has an area, a volume, just like what you're
   saying here.

   <andy> +q

   Alex: The identification here has this last updated on, etc. You're
   asking for more information in this area.

   kseiler: This description is primarily for locations that don't
   move. I think it's important to also describe mobile objects that
   have additional attribution.

   cperey: So I think we've agreed that we want something that works
   for an object as well as a stationary point.
   ... If you want it for split seconds of time this isn't scalable, we
   know that. Maybe we could change it to the object primitive and have
   a timestamp on it and just have it change.

   Alex: It doesn't seem to me that we can't accommodate that. Not all
   of the information is required here, I could imagine it being very
   lightweight and having just a location, time and a point.

   <jens> +1 for alex

   <jens> good remark about the optionality on fields

   Alex: You could have the location be in flux, while the POI remains
   the same.
   ... We could add how long we think it's valid for too.

   <kseiler> i think we need to exercise the location primitive via a
   few XML, JSON examples, from light to heavy

   cperey: Then we have the user's position relative to that stationary

   +1 to exercising it!

   Alex: I think that's got less to do with the data model. As long as
   there's some frame of reference, whether it's WGS-84 or in another
   one, if I and the object are in the same frame of reference, we're
   ... I think we'll want orientation, but don't need it right now, as
   it's implicit in the frame of reference.

   kseiler: I ran out of time and bandwidth, but what I'd like to see
   happen is trying to render out a few use cases with both XML and
   JSON formatted examples. Lightweight and heavyweight examples. That
   gives it a better sense of if it's working.
   ... Do the dog walking through the park.

   cperey: Or the coffee cup. We talked about two identical objects
   that are differentiated by their location at a time.

   kseiler: College campuses, or when the coffee shop closes and moves
   across the street. Big constructs that if there is a problem it's a
   big problem.

   andy: I'm concerned about the direction of the conversation. I think
   there probably is an object primitive, but I don't think it's the
   same as this location primitive.

   Alex: The identification stuff here is troubling me. What does the
   owner update? What if the address hasn't changed since 1971, but
   some new georeferencing came up with new lat/lng

   <cperey> muted myself

   kseiler: There's an address primitive and a point. The points are
   getting increasingly refined as GPSes are getting out there.
   Everyone is standing in their door front with a GPS and getting
   lat/lng. So, the date changed bit lets you know it's been updated.

   Alex: Shouldn't the time go on each piece?

   <cperey> what about a machine updating the data?

   kseiler: I thought about that, but pulled it out.

   <cperey> would machines not be the predominant source of updated

   Alex: It's not clear to me what protocols people are going to use in
   general for people to state what information they want.
   ... We could keep going on and on with heaviness.
   ... Matt wanted to put timestamps on every field. It sounds
   valuable, but I don't know the protocol we'll be using for these
   things to determine what information you get and what is

   <vinod> +1 to cperey. Periodicity is probably required for a poi in
   active state. Ex: A hotel poi is active everyday from 10 am till 12
   pm. Also the time of existence has to be there Ex: An object in a
   museum which is active from 8 am till 4 pm and it existed from
   1901-1943. Hence I see two more fields in 'Identification'
   1.Periodicity for active state 2.Period of existence

   <andy> yes

   <cperey> and the time stamp which you are referencing

   kseiler: We want to be able to turn the dial up and down for how
   much information you get. Sometimes you want excruciating detail.

   <cperey> +q

   kseiler: Getting into the area of heavy vs light, will be difficult.
   Putting things in the spec that give us variability would be good.

   <andy> sounds like we have an issue to be opened

   Alex: Air on the side of atomiticity. Any element can have any
   number of attributes attached to it, just they are optional.
   ... if we have a time atom, we don't really have to care where it
   goes, it could go up to the POI, or down to the details.
   ... Instead of us deciding whether it's appropriate for everything
   to have time info, we just come up with a primitive that allows it
   to be reused anywhere we want.
   ... Come up with some basic building blocks that we can tack on to
   just about everything.
   ... They don't have to littered throughout the spec everywhere, but
   just defined once.

   cperey: A good way to get an idea of the depth we might want is the
   Internet of Things. The person I know that would be best for this is
   Connected Environments. I would take an action item to try to get
   him involved in this conversation. I'd like to have him come give us
   a presentation that Pachube uses. They have years of experience in
   exactly these problems.

   <kseiler> good idea

   <jens> +1

   <cperey> Connected Environments

   <andy> +1

   <Ronald> +1

   andy: Sounds like we have consensus that it's a good idea. Assuming
   there are no issues with IPR, let's create an action for Christine.

   <cperey> absolutely

   <scribe> ACTION: cperey to contact Connected Environments to give a
   presentation. [recorded in

   <trackbot> Created ACTION-26 - Contact Connected Environments to
   give a presentation. [on Christine Perey - due 2011-02-02].

   <cperey> I don't know how !

   <cperey> Pachube

   <cperey> pronouced PatchBay

   <cperey> I'lll looking!


     [12] http://www.pachube.com/

   andy: One thing I noticed is that the location primitive appears to
   be entirely optional. Can you comment for me?

   kseiler: I think we should sweep through this and figure out what we
   consider optional, etc.

   <cperey> Is there anyone who will collaborate with me to develop the
   Object Primitive which is similar in structure to this?

   kseiler: We need to define carefully what is the bare minimum for
   the location primitive to exist.
   ... Could be as thin and lean as "unknown".

   Alex: Sounds like we're barking up the tree of "at least one of the

   Keene +

   kseiler: I can make a first pass stab at it I can and send it back
   out for review.

   <cperey> yes, deveinitly wiki

   <scribe> ACTION: kseiler to try to determine what is optional,
   required, or one of in location primitive [recorded in

   <trackbot> Created ACTION-27 - Try to determine what is optional,
   required, or one of in location primitive [on Karl Seiler - due

   andy: I think it'd be good to get into the wiki at this point.

   Alex: I'd like to get more clarification about the map reference and
   where it fits in better.
   ... If you had a point, a line, and an area, does the map reference
   apply to all of them equally?

   kseiler: Certainly a point. Addresses typically don't exist in maps,
   they're reverse engineered out of maps.

   <jens> +q

   kseiler: The address is a linkage to a map.

   Alex: Is map reference something inherently useful to show something
   on a map.

   kseiler: It's primarily for navigation and rendering. If you want to
   know where something is, coordinates will probably tell you. If it's
   coordinates on a one way street, you need a map reference.

   Alex: So if there's something on OSM that indicates a street, then
   that would be a map reference.
   ... For instance in navigation there's a way for it to determine
   that I'm on a street and not in the bushes.

   kseiler: Yes, what it's doing is real time perpendicular snap-tos.
   ... It's a leap forward to "if you know where you are on the map,
   why keep re-rendering that?"
   ... What happens in POI listings that are lightly coupled is that
   they're constantly re-geocoding.
   ... It's 5-15% error in geocoding. You can squeeze that out by
   carrying it with you.

   Alex: Maybe this could be a form of relative? It's further
   information like a street address and a 2d point that we care about
   but it's one of these other constituents like 2d and point.

   kseiler: Yes, I like that.

   Alex: Find a way to shoe-horn it into relative.

   kseiler: I'll work on it.

   <scribe> ACTION: kseiler to work on making map-reference as part of
   relative [recorded in

   <trackbot> Created ACTION-28 - Work on making map-reference as part
   of relative [on Karl Seiler - due 2011-02-02].

   jens: Something I noticed missing is that there's no way to specify
   relative altitude.
   ... !!
   ... So you could say that "this is relative to that other location"

   Alex: To me, relative is a little bit of a frame of reference
   ... I may want to define points with a lat/lng, but I may want that
   frame of reference to be relative to another point. So I think Jens
   is saying we may want the same flexibility in defining something
   relative as we do absolute.

   <cperey> yes, like, relative to something which could be stationary
   or moving

   jens: I think relative might not be relevant to everything but to

   Alex: In KHARML, we had a notion of relative to some location. Still
   use the same fields, but now we interpret it differently.
   ... One way to accommodate that would be if each of these terms
   could have an optional attribute that specifies what is really the
   coordinate system.
   ... So you might say "Yeah, it's WGS-84, it's meters relative to
   some other point".

   +1 to relative to other points.

   kseiler: Is it relative to another point that could be relative, or
   relative to a point location.

   Alex: In general people are going to want to do multi. Basically a
   scene graph.

   <cperey> +1 on scenes/scene graph

   <kseiler> ok

   <Ronald> +1

   Alex: May end up resolving to an unrelative location.

   <cperey> Also, I would like to ask what is going to be submitted (if
   anything) for the meeting on Feb 17

   andy: Let's take it up on the mailing list or a call.

Face to Face

   andy: The poll says the best time is March 29-31st.
   ... It will be in the Layar offices in Amsterdam

   <kseiler> sorry dates of next f2f?

   andy: We're trying to drive down on hotels now. We can arrange for
   the hotel that's across the Layar offices or look for hotels near
   the city center.
   ... I want to confirm that the f2f is March 29-31st at the Layar
   offices in Amsterdam.

   Ronald: Some more information: we have public transport so it is
   quite easy to get to the city center and back. It's a question of
   whether you want to be at the meeting early in the morning without
   the hassle of traveling.

   <cperey> sorry that's my battery

   Ronald: The hotels have a variety of different rooms with price

   Alex: Is this a three day meeting?

   andy: Yes, thought three days would be better this time. Start later
   maybe on the first day. Exact hours, I'll send out later in the

   <kseiler> have to go, adios

   Alex: I would say that those of us traveling internationally it's
   not going to matter if it starts at noon, 1 or 8am. Maybe we hedge
   towards the idea of the last day being a short day.

   andy: My experience the morning in Europe is best to arrive.

   cperey: Andy, send me mail on position paper for AR workshop?

   andy: Yep.
   ... I'll send out a note on the f2f soon.

   Alex: I don't know about where.

   Ronald: It's close to the water, basically just 5-10 minute train
   ride to central station.

   <ahill2> close to Layer sounds fine, we can always travel in the

   Ronald: We can decide which hotel later this week is my proposal.

   <ahill2> in the evenings

   Ronald: Can try to get some discount deals for us.

   andy: Think we should wrap up. Thanks everyone!

Summary of Action Items

   [NEW] ACTION: cperey to contact Connected Environments to give a
   presentation. [recorded in
   [NEW] ACTION: kseiler to try to determine what is optional,
   required, or one of in location primitive [recorded in
   [NEW] ACTION: kseiler to work on making map-reference as part of
   relative [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [18]scribe.perl version 1.135
    ([19]CVS log)
    $Date: 2011/01/26 17:25:49 $

     [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.135  of Date: 2009/03/02 03:52:20
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/??/Connected Environments/
Succeeded: s/kseiler/ahill2/
Succeeded: s/ahill2:/Alex:/g
Found Scribe: Matt
Inferring ScribeNick: matt
Default Present: Matt, +1.919.439.aaaa, Andy, +3539149aabb, +1.312.894.
aacc, Vinod, Karl, Jens, +1.617.848.aadd, Alex, Christine
Present: Matt +1.919.439.aaaa Andy +3539149aabb +1.312.894.aacc Vinod K
arl Jens +1.617.848.aadd Alex Christine
Agenda: [21]http://lists.w3.org/Archives/Member/member-poiwg/2011Jan/00
Found Date: 26 Jan 2011
Guessing minutes URL: [22]http://www.w3.org/2011/01/26-poiwg-minutes.ht
People with action items: cperey kseiler

     [21] http://lists.w3.org/Archives/Member/member-poiwg/2011Jan/0019.html
     [22] http://www.w3.org/2011/01/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 Wednesday, 26 January 2011 17:29:13 UTC

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