Remove occupiesGeographically and occupiesGeographicallyPermanently?

[dylan-sa]

During the inverse working group meeting, we noticed a potential redundancy with the following predicates.

• Currently, we have isGeographicallyOccupiedBy and its inverse, occupiesGeographically. We also have isGeographicallyPermanentlyOccupiedBy and its inverse, occupiesGeographicallyPermanently.
• While not formally specified, these predicates are likely intended to relate objects to spatial regions. (isGeographicallyContainedIn, a further property not on the list above, is likely intended to relate spatial regions to spatial regions.)
• Arguably, hasPhysicalLocation could do the work that occupiesGeographically does, and for this reason we may want to remove occupiesGeographically and its inverse to avoid redundancy.
• If we were to remove occupiesGeographicallyPermanently and its inverse, there is a question as to whether we would want to add an analogous hasPermanentPhysicalLocation.

[rjyounes]

We're going to remove the inverses in any case, based on #506.

[rjyounes]

See also #812 for a renaming proposal if we decide to keep them.

[rjyounes]

Proposal: remove these predicates and define hasPermanentPhysicalLocation to cover the sense of permanent location.

Jamie: Difference between occupying an entire building, a floor, a room, etc. and being located there.

Another proposal: change to occupiesPhysically so that it doesn't suggest a geo location.

Would be useful to have Dan in the discussion.

[uscholdm]

define hasPermanentPhysicalLocation to cover the sense of permanent location

I am in favor of this. The restriction on Landmark can be easily updated to say:

			[
				a owl:Restriction ;
				owl:onProperty gist:hasPermanentPhysicalLocation ;
				owl:someValuesFrom [
					a owl:Class ;
					owl:unionOf (
						gist:GeoRegion
						gist:GeoVolume
					) ;
				] ;
			]

There are subtle distinctions between this and to 'occupy' that one can make, but I don't think we need that for gist.

[dylan-sa]

Granting the distinction between something occupying an entire space and merely being located within it, I wonder if we can rely on a single predicate like hasPhysicalLocation for both cases. In cases where it's more useful to know the precise chunk of space that something is occupying, you can dial up the specificity of the location.

[rjyounes]

We have to loosen the SVF restriction to gist:Place, since (1) presumably this will be a subproperty of gist:hasPhysicalLocation and (2) we want to include things like a sock being in a drawer, which I suppose is literally a geo region of some sort but not the sense in which gist uses geo regions.

[uscholdm]

Granting the distinction between something occupying an entire space and merely being located within it, I wonder if we can rely on a single predicate like hasPhysicalLocation for both cases. In cases where it's more useful to know the precise chunk of space that something is occupying, you can dial up the specificity of the location.

I agree that this could be important on some occasions. But is it universal enough to go in gist?

[rjyounes]

Peter: Permanence depends on time-frame. Need to define what we mean by permanent.
Dave: The permanent idea was to distinguish between, e.g., houses and cars. Now I think we should use a temporal relation if we want to time-delimit it, rather than two distinct predicates.
Boris: Agrees with Dave.
Mark: Agrees with removal of occupies predicates and dropping the permanent predicate
Michael: No way to distinguish Landmark.
Mark: Use annotations to make the permanent/impermanent distinction.
Rebecca: Do we need a subclass of TemporalRelation for locations?
Mark: (1) The temporal relation model is for gist extension, not gistCore. (2) Don't limit the usage of hasPhysicalLocation in annotations - let people use it the way they want.

DECISION:

• Remove the occupies predicates
• Add an annotation to hasPhysicalLocation that this could include either permanent or temporal relations, and to time-delimit it you should use an temporal relation (the last half is my addition, use it if you want).
• Maybe change restriction on Landmark that it's a subclass of a SVF restriction on hasPhysicalLocation. [ NOTE: I no longer think this is a good idea, because it's already a subclass of Place. All places are located in places (with the exception of the universe, I suppose) so there's no need to add this to Landmark in particular.

UPDATED DECISION (updated 2023-07-28) based on new deprecation policy:

• Deprecate the occupies predicates by adding owl:deprecated true
• Add an annotation to hasPhysicalLocation that this could include either permanent or temporal relations, and to time-delimit it you should use an temporal relation (the last half is my addition, use it if you want).
• Restriction will not be changed until the next major release, when the properties are removed.

[uscholdm]

See also #757