Subject: [Geopriv] INT labels

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Mar 2010 21:35:12 -0400

To continue the discussion in the meeting:

One of the assumptions is that things are commonly labeled, but that's rather rare in practice. Naming is typically implicit and by context, i.e., your hotel room doesn't have a label "Room 742", but rather just a carved label with the digits 7-4-2 on it. The same is generally true for airport gates, airport terminals and a whole bunch of other sub-building labels. Naturally, the building model may have some set of labels, but they are not visible to visitors and other consumers of location information.

Thus, if you want to support I18N, you want to have as many generally-understood labels, so that my German indoor location client can render "(Room) 742" as "Zimmer 742". More dramatically, in a Chinese hotel, that rendering is much more meaningful to the non-Chinese visitor than the Chinese symbol for room, which is likely nowhere to be seen on a wall or door sign. The Chinese LIS likely won't know German, even if it could do some translation (which is unlikely, given the multiple delivery steps between the source of location and the final consumer).

It is clear that there are less-common sub-building units where we simply can't define CA types or XML tags for all of them. For those, I have no objection to use the IN tag. However, for the very common ones (the current ones), the current explicit labels provide a much better user experience as long as they indeed map to their real meaning. In other words, it's a bad idea to label an airport "gate" as a "room".

Thus, the combination of using FLR etc. for the 80% of common buildings (office, hotels, residences), while dealing with the special cases with IN labels seems to give the best compromise between semantic tagging and flexibility to deal with the other 20%.

Otherwise, you'll have to define a registry of well-known IN XML attributes. In that model, the Chinese hotel would have to use the English literal "Room" for the IN label, even though it uses Chinese-language labels for all the other attributes.

Henning

---

From: [email-masked]
Date: Wed, 24 Mar 2010 16:30:12 -0400 (EDT)

Anyone in the group familiar with Omniclass? The OmniClass Construction
Classification System (known as OmniClass™ or OCCS) is a classification
system for the construction industry. Omniclass has been defined and is
used by hundreds of AEC software, design, and construction organizations.
Perhaps there may be something useful?

Omniclass and BIM are related - the IFC (Industry Foundation Classes) use
Omniclass in the Properties Table.

So, if anyone is looking for a taxonomy of building elements, this may be
the place to look.

Carl

> One of the assumptions is that things are commonly labeled, but that's
> rather rare in practice. Naming is typically implicit and by context,
> i.e., your hotel room doesn't have a label "Room 742", but rather just a
> carved label with the digits 7-4-2 on it. The same is generally true for
> airport gates, airport terminals and a whole bunch of other sub-building
> labels. Naturally, the building model may have some set of labels, but
> they are not visible to visitors and other consumers of location
> information.
>
> Thus, if you want to support I18N, you want to have as many
> generally-understood labels, so that my German indoor location client can
> render "(Room) 742" as "Zimmer 742". More dramatically, in a Chinese
> hotel, that rendering is much more meaningful to the non-Chinese visitor
> than the Chinese symbol for room, which is likely nowhere to be seen on a
> wall or door sign. The Chinese LIS likely won't know German, even if it
> could do some translation (which is unlikely, given the multiple delivery
> steps between the source of location and the final consumer).
>
> It is clear that there are less-common sub-building units where we simply
> can't define CA types or XML tags for all of them. For those, I have no
> objection to use the IN tag. However, for the very common ones (the
> current ones), the current explicit labels provide a much better user
> experience as long as they indeed map to their real meaning. In other
> words, it's a bad idea to label an airport "gate" as a "room".
>
> Thus, the combination of using FLR etc. for the 80% of common buildings
> (office, hotels, residences), while dealing with the special cases with IN
> labels seems to give the best compromise between semantic tagging and
> flexibility to deal with the other 20%.
>
> Otherwise, you'll have to define a registry of well-known IN XML
> attributes. In that model, the Chinese hotel would have to use the English
> literal "Room" for the IN label, even though it uses Chinese-language
> labels for all the other attributes.
>
> Henning
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2010 16:41:50 -0400

Can you describe the related elements? Do they describe things like "airport gate" as a separate, named entity?

Henning