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
