Raum is not a random string of letters: it's what you would find in ALL
other data that referred to the interior spaces. You would not find "Room"
on any other data.
In order to go from Raum, which what is on all the other documents, to Room,
you need a mapping. That in turn needs some kind of machine readable
document, which doesn't exist. It's not possible to write a program that
deals with "Room", because you don't know the relationship between the fixed
tags and all the other documentation.
Of course, you can make assumptions, but assumptions are dangerous. The
only thing that really works is to make the data in a PIDF match the other
documentation, which is what INT does.
The point of INT is to duplicate the signage (and the CAD database). If the
doors have xk17 435 on them, then you want the INT name to be xk17 and the
value to be 435.
You actually have the opposite problem, if the PIDF says "Room" and the door
says "xk17" you have to guess that xk17 means "Room" and not "Unit"
On your points:
a) What you want is to have the INT tags match the other documentation (CAD
drawings or signage). If they vary, that's okay. What matters is that they
match. You can't do that with fixed tags unless it happens that the tags
match the documentation. There is no downside to having some buildings use
Room and others use huone if that is what the other documentation does.
b) It also doesn't matter if in one building they use "Room" and in another
one they use "space". If the only signage and documentation they have is
the value, then the name of the tag doesn't matter. There aren't any use
cases I know of where you need to compare the names of the tags in one
building to those in another.
c) The INT proposal has hierarchy: order of the INTs matters. The problem
with the tags is that the hierarchy doesn't always work. A common problem
is where "UNIT" goes: in some places, UNIT goes before floors. In others, it
goes after floors. In some places, UNIT goes before Building.
Let's try to stick with use cases.
What is the use case where INT doesn't work, and fixed tags do?
I've given several where INT works, and fixed tags don't.
Brian
> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Thursday, July 16, 2009 5:40 PM
> To: Brian Rosen
> Cc: 'Thomson, Martin'; 'Marc Linsner'; geopriv@ietf.org
> Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
>
> Brian,
>
> I think you're missing the point - if I have an INT with the name
> "Raum" (to pick the German translation of "room"), all parties have to
> know what this means - otherwise, it's just a random string of
> letters. This is sufficient if the goal is to do label matching - the
> fireman needs to be able to recognize the label he saw on the map when
> entering the building.
>
> In many cases, that's probably all that's needed and it wouldn't
> matter if the sub-division was called "xk17" instead, as long as the
> door signs all had "xk17" on them. You can imagine the confusion,
> however, if the INT label was just "xk17", and the fireman had to
> guess that this corresponded to the thing labeled 435 on the sign next
> to the door.
>
> You are, however, assuming that the labels are meaningful to all the
> participants and parties. This isn't a given:
>
> - Language: Many international companies use English internally, even
> if they are, say, located in Finland. Do you use "huone" or "room"? If
> location information is entered in a decentralized fashion, you
> probably get both, in addition to "Rm" and several other variations.
> This isn't a problem for the existing tags - a user interface can
> trivially render them in any suitable language. With INT, even if
> Nokia decided to use the English designation throughout their
> buildings, this would still be rather confusing to the local fire
> department.
>
> - Convention: In many cases, things aren't tagged, they just have
> numbers or letter-number combinations on them. I suspect if you asked
> somebody in the building other than the building manager, you'd get
> three different descriptions or labels. Not a problem if location is
> entered centrally, a pain if every sys admin in every department does
> something slightly different, let alone if you leave that to users.
>
> - Hierarchy: There doesn't appear to be a hierarchy implied. At least
> with the existing labels, I can guess that if I get "Kerros 3, Huone
> 25" on a business card, that this is likely a floor and room. (These
> are on-line dictionary translations; my Finnish is too limited...)
> With no hierarchy in INT, I could get any permutation.
>
> I don't thing anyone is disagreeing that you sometimes have things
> that aren't rooms in a traditional sense. However, it is unclear that
> adding tags helps much, beyond adopting the conventions that we
> already do today. (We would use 3L and 3U for the floors, if that's
> what's on the elevator button.)
>
> Thus, for these reasons, I see only a limited applicability for INT.
> The "standard" terms will likely work in the vast majority of cases we
> care to identify for location purposes, possibly with the kind of
> simple local conventions that FLR = elevator button label.
>
> Thus, I remain strongly opposed to deprecating the old terms.
>
>
> Henning
>
> On Jul 15, 2009, at 10:19 PM, Brian Rosen wrote:
>
> > No, specifically, INT is always interoperable and the fixed tags
> > aren't.
> >
> > I can build any number of applications that can use INT exactly the
> > way the
> > building documentation names spaces. I can't build any interoperable
> > implementations where the interior spaces are not completely
> obviously
> > mapped into the fixed tags.
> >
> > The point of INT is that the way the spaces are named is self
> > defined in the
> > structure. All applications can understand the naming conventions,
> > and they
> > can relate those conventions to the PIDF as well as the other
> > available
> > documentation.
> >
> > With fixed tags, there is no way to do that. Unless you create the
> > documentation to show the mapping, or create a document that maps
> > what is
> > essentially the INT representation into fixed tags, you can't create
> > interoperable implementations of anything.
> >
> > Lots and lots of examples
> >
> > A lawyers office is Suite 202, but has two floors, they are called
> > "Upper"
> > and "Lower". If you looked outside, these are actually floors 2 and
> > 3, but
> > you can't get to room 27 on the upper floor by getting off the
> > elevator at
> > floor 3. You have to go to Suite 202 on floor 2 and go to the Upper
> > floor
> > using an interior staircase.
> >
> > What is the content of "FLR"? "3" or "upper"?
> >
> > Both might be appropriate. The fundamental problem is that in this
> > particular space, there are actually two things that equate to
> > "FLR": the
> > floor the Suite is on, and the interior floor. You want to say
> > "Building 2,
> > Suite 202, Upper Floor, Room 27" You may even want to say "Building
> > 2,
> > Floor 2, Suite 202, Upper Floor, Room 27.
> >
> > The warehouse examples: Aisles, Racks, shelves. Are they UNIT/ROOM/
> > FLR or
> > UNIT/ROOM/SEAT or FLOOR/UNIT/ROOM or BLD/ROOM/UNIT?
> >
> > The fundamental problem with the fixed tags is that no other
> > documentation
> > uses them in many buildings. You have to map the existing naming
> > convention
> > into the tags. There is no way to document how you do that, no way
> to
> > pretty print or parse unambiguously into them.
> >
> > INTs use the conventions of the existing documentation, and
> > trivially extend
> > to any convention.
> >
> > Brian
> >
> >> -----Original Message-----
> >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> >> Behalf Of Thomson, Martin
> >> Sent: Wednesday, July 15, 2009 9:43 PM
> >> To: Marc Linsner; geopriv@ietf.org
> >> Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
> >>
> >> The point that has been made is that INT would not be interoperable.
> >> Interoperability requires a shared understanding of semantics.
> >>
> >> I have no objection to providing better localization support, but
> >> let's
> >> not destroy what is there to create something that is not usable by
> >> automated systems.
> >>
> >> --Martin
> >>
> >>> -----Original Message-----
> >>> From: Marc Linsner [mailto:mlinsner@cisco.com]
> >>> Sent: Wednesday, 15 July 2009 11:15 PM
> >>> To: Thomson, Martin; geopriv@ietf.org
> >>> Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
> >>>
> >>> Martin,
> >>>
> >>> So you are suggesting to utilize "LOC" vs. "INT"?
> >>>
> >>> We must remember that PIDF-LO is used by many to fulfill many
> >> different
> >>> use
> >>> cases. I would guess the opponents of expanding PIDF-LO find it
> >>> complete
> >>> for their use case(s). The proponents of expanding PIDF-LO would
> >> like
> >>> to
> >>> create an interoperable mechanism for expanded use cases.
> >>>
> >>> Afterall, "LO" means "Location Object" not "Location Outdoors".
> ;^)
> >>>
> >>> We need an standard mechanism to express various location
> attributes
> >>> used
> >>> inside a building/campus. The use cases include both physical and
> >>> 'cyber'
> >>> locations.
> >>>
> >>> -Marc-
> >>>
> >>>
> >>>
> >>> On 7/14/09 7:51 PM, "Thomson, Martin" <Martin.Thomson@andrew.com>
> >>> wrote:
> >>>
> >>>> a) no
> >>>> b) mu, but mostly no
> >>>> c) no
> >>>>
> >>>> This document is symptomatic of an inclination to solve any
> >>> addressing problem
> >>>> by adding elements, without regard to cost and complexity.
> >>>>
> >>>> There are already 30+ elements; and we're experiencing difficulty
> >>> selling
> >>>> folks on the need for numbers larger than 5. By adding
> complexity,
> >>> we only
> >>>> continue to alienate those people and decrease the relevance of
> the
> >>> existing
> >>>> product.
> >>>>
> >>>> The civic address considerations document describes a number of
> >>> techniques
> >>>> that can be used to deal with each of the specific problems that
> >>> you've
> >>>> raised. The semantics of the existing types are flexible enough
> to
> >>>> accommodate most, if not all of your use cases.
> >>>>
> >>>> The document does not adequately describe how this might be
> >> conveyed
> >>> in DHCP.
> >>>>
> >>>> --Martin
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
> >> On
> >>>>> Behalf Of Rosen, Brian
> >>>>> Sent: Wednesday, 15 July 2009 7:07 AM
> >>>>> To: geopriv@ietf.org
> >>>>> Subject: [Geopriv] draft-rosen-geopriv-pidf-interior
> >>>>>
> >>>>> I would appreciate some comments on this draft:
> >>>>> a) Does it makes sense to you to do it this way instead of how we
> >>>>> currently support "interior" location?
> >>>>> b) Do the specifics look right (basically, it's an ordered list
> of
> >>>>> name/value pairs with no registry and a flag that suggests how to
> >>>>> pretty
> >>>>> print the result)
> >>>>> c) Should we deprecate the existing mechanism in favor of this,
> or
> >>> just
> >>>>> let the old one lie there?
> >>>>>
> >>>>> Several groups that tried to do interior addressing ran into the
> >>> kind
> >>>>> of
> >>>>> problems the existing mechanism couldn't handle and went for the
> >>> open
> >>>>> ended name/value pair idea.
> >>>>>
> >>>>> Brian
> >>>>> _______________________________________________
> >>>>> Geopriv mailing list
> >>>>> Geopriv@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/geopriv
> >>>>
> >>>> ------------------------------------------------------------------
> -
> >> --
> >>> ---------
> >>>> ------------------
> >>>> This message is for the designated recipient only and may
> >>>> contain privileged, proprietary, or otherwise private information.
> >>>> If you have received it in error, please notify the sender
> >>>> immediately and delete the original. Any unauthorized use of
> >>>> this email is prohibited.
> >>>> ------------------------------------------------------------------
> -
> >> --
> >>> ---------
> >>>> ------------------
> >>>> [mf2]
> >>>> _______________________________________________
> >>>> Geopriv mailing list
> >>>> Geopriv@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/geopriv
> >>>
> >>>
> >>
> >> --------------------------------------------------------------------
> ---
> >> -------------------------
> >> This message is for the designated recipient only and may
> >> contain privileged, proprietary, or otherwise private information.
> >> If you have received it in error, please notify the sender
> >> immediately and delete the original. Any unauthorized use of
> >> this email is prohibited.
> >> --------------------------------------------------------------------
> ---
> >> -------------------------
> >> [mf2]
> >> _______________________________________________
> >> Geopriv mailing list
> >> Geopriv@ietf.org
> >> https://www.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
> >
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
