Problems with gist:Room

[rjyounes]

The term specification does not define a "room" in the ordinary sense: e.g., elevators, staircases, hallways, and closets are direct parts of buildings but not rooms in the ordinary sense; and they can all have IDs. Also, a room in the ordinary sense can be a direct part of a wing, where the wing is a direct part of a building. In this case the room is a part of the building but not a direct part. According to the gist definition of Room, the wing is a Room and the room within a wing is not a Room. We could rename the class, but the usefulness of a class that includes elevators, staircases, hallways, wings, and some rooms but not others, is dubious; this is confirmed by the difficulty of finding an accurate name for the class - i.e., it's not a real concept. I suggest modifying the definition of gist:Room to be a semantically and coherent reflection of the concept of "room."

[johnwcowan]

This is an instance of the directPart general problem. Is a finger a direct part of a human body, or is it part of a hand which may be (depending on the natural language) part of an arm which is part of a body?

Both ordering and hierarchy need better general approaches.

[rjyounes]

1. Remove restriction on gist:identifiedBy
2. Change directPart Building to part Building
3. Change definition. Bring back proposals to group.

[johnwcowan]

IMO directPart should be phased out completely: there is almost never a case where there cannot be an intervening object that is larger than the part and smaller than the whole.

…

On Thu, Jun 11, 2020 at 11:29 AM Rebecca Younes ***@***.***> wrote: 1. Remove restriction on gist:identifiedBy 2. Change directPart Building to part Building 3. Change definition. Bring back proposals to group. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#102 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANPPBQXBIQUT7EJ2R6MNDDRWDZ5NANCNFSM4IOA2Q5A> .

[rjyounes]

@johnwcowan I agree. Can you please add an issue?

[rjyounes]

@johnwcowan Never mind. We have an issue #115 which includes this.

[johnwcowan]

I've commented on it.

…

On Thu, Jun 11, 2020 at 1:20 PM Rebecca Younes ***@***.***> wrote: @johnwcowan <https://github.com/johnwcowan> Never mind. We have an issue #115 <#115> which includes this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#102 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANPPBUVAJON3673KSBCY53RWEG7LANCNFSM4IOA2Q5A> .

[ungricht]

Problem statement: “Room” is an ambiguous label. There are problems with polysemy, and so simply fixing the definition for “Room” isn’t going to solve the issue. If we consider the concepts that share the label “Room” we find multiple distinctions that are significant (e.g. Space vs Place, physical space vs virtual space, etc.). These may need to be accommodated in Gist.

Proposal: It seems like there’s an implicit class in between “PhysicalIdentifiableItem” and “Building.” That class is something like “Structure.” This could rely on “hasDirectPart” to refer to other structures, though “locatedIn” is more accurate. Additionally, you could create a subclass of “Structure” that is a variant of “Partition”(PartitionedSpace/BuildingPartition) to indicate that a partition might be different from the structure of which it is a part. “Partition” could be defined to have a function, and it’s instances (or types) could include some of the edge case examples we discussed: stairwell, office, section of seating in an arena, assigned desk/cubicle. If you wanted “Building” to be a “PhysicalIdentifiableItem” with all the associated properties, you could create a subclass of “Structure” that is “PhysicalStructure” or “Building” but “PhysicalStructure” might be able to include things like Mount Rushmore or Half Dome.
It doesn’t have to be a physical structure; it could be a data structure or a virtual structure (Minecraft). One example is having a Zoom meeting, or a virtual meeting where there’s a shared ID for a virtual space and several participants join. It’s less clear from the problem statement that we need to accommodate such a case with this model, but it doesn’t appear to break it.

[ungricht]

And looking back, there's also a problem with "directPart" but that is also resolved by the proposed approach, because I recommend using "locatedIn" which is a property we've used with some success with our clients.

[uscholdm]

@ungricht makes some good points. A few comments.

1. The term 'Structure' is super-ambiguous, use it at all will be difficult to get right.
2. We need to focus on what is likely to be needed in practice for the typical enterprise. Room does not come up very often. Once for Sentara for where to store medical supplies. I had a lot of detail and generality about the notion of place. It was my first SA ontology and it was way over-complicated.
3. We can stick with @rjyounes 's proposal and move on, until/unless we have use cases.

[rjyounes]

Should this be in gist at all?

PartitionedSpace is not a subclass of Structure.

Because we can't agree on a common meaning and use of Room, this suggests that it should not be defined in gist.

DECISION: Remove it.

Deprecating, moving to gistDeprecated.

[rjyounes]

@ungricht I've devoted some time to gist today, so I'll take this on since it's so quick.

[rjyounes]

DEFERRED: See comments on PR #335