Issue 426: Pxxx holds or supports
Posted by Robert Sanderson on 24/6/2019
Has anyone used P54 has current permanent location in practice in an information system, where the containing Place is defined only with respect to some other physical object?
Some use cases for this pattern:
· A set of letters in a folder, or a set of paintbrushes in a box
· A set of coins in a display case
· Books on a bookshelf
This seems like a very easy use case for a shortcut between Physical Objects to avoid creating Places that exist only to be the P54 of some other object. The containing object is typically 1:1 with its container-space, as even if there are drawers in a desk, you could model the drawer as a part of the desk, which had its own space. Thus the cutlery in one drawer, the cooking utensils in a different drawer, despite being part of the same kitchen cupboard unit.
Similarly, P53 and P55 could also benefit from such a shortcut for their different temporal aspects.
Posted by Martin on 25/6/2019
The most simple solution is Physical Object IsA Place, with the respective semantics, of being itself the reference system.
The temporal aspects of P53, P55 are given by the Presence class, which requires E18 IsA STV, otherwise the paths get very long...
We will try in our team a logical definition of these things.
Posted by Robert Sanderson on 9/7/2019
Thank you Martin.
Having the same instance be both the physical thing and the place that the physical thing is the reference for is interesting. It certainly cuts out the mostly unnecessary entities.
Given that Place and Human-Made Object only intersect at E1, there doesn’t seem to be any significant confusion by having a new class that’s a sub class of both E22 and E53. It could be called a Container.
There’s some weirdness about partitioning of the physical, and how that relates to the positional, but so far nothing that produces inconsistency that wouldn’t also be inconsistent with the fully expressed path. For example, a desk with drawers is a Container, that has parts which are Containers. The place-ness of the desk and drawers are not necessarily also partitioned in the same way, which is fine – we might consider only the top of the desk as the place that it defines, which would be distinct from the drawers. Equally, if we took the drawer out of the desk and put it on top, we would not have part of the place being contained within itself.
It means that the place is destroyed along with the object … but that’s not bad either. Without the reference system of the object, the place no longer has any meaning. It does get a little strange with former_or_current_location – the former location is a thing that has been destroyed – but that’s indeed what has happened.
Could we have another RDFS join class - E22_E53_Container ?
Posted by Martin on 9/7/2019
That is one idea. The question is actually, if it is only containers that carry things around. My computer has a hard disk in it, but also the "bears feature" is nothing else than indirectly referring to the object as a place.
Another question is, why we do have "P8 took place on or within", which "...describes the location of an instance of E4 Period with respect to an E19 Physical Object. P8 took place on or within (witnessed) is a shortcut of the more fully developed path from ‘E4 Period’ through ‘P7 took place at’, ‘E53 Place’, ‘P156i is occupied by’, to ‘E18 Physical Thing’"
...and not another "Pxxx is located on or within" . One could either introduce that or give up both in favor of the IsA. We had however in CRMSci concerns if all physical things qualify to define a spatial reference frame, if they are too plastic. On the other side, their extent is always a spatial confinement, even without being able to mark relative positions within them, e.g., an Amoeba having swallowed some algae.
Following CRMgeo, instances of Place do only exist as long as their reference object exists. It cannot be otherwise. Only spacetime points are absolute in the universe, because they exist only for their instant of time, and do not cause problems of spatial reference systems moving in different directions.
Indeed, the question of being "on" is an interesting one. It should be interpreted as being adjacent to the surface. Imagine a young bock in the hunter's rucksack, limbs protruding: Is it in, or on, or in and on?
In order to avoid such ambiguities, I would rather stick to a notion of adjacency, in case of things. If we use IsA, then "bears feature' becomes superfluous, but we need to check the implications of topological relations with other places, such as places within such places.
If you just declare containers and gravity-bound storage features to be IsA place, you avoid the more general questions.
Posted by Robert Sanderson on 11/7/2019
Yes, completely agree with the problems posed!
My preference would a shortcut that was parallel to P8 – your “Pxxx is located on or within”. It has P8 as precedent, it shortcuts around an entity that exists only through the existence of the object and it works in RDF as well as in other implementations of the higher level logic.
I would be concerned about a Period+Thing class to replace P8. For that specific scenario it seems comprehensible, but it opens up a lot more confusion (as per the STV discussion) as to the nature of the entity that I think can be avoided.
Posted by Robesrt Sanderson on 12/7/2019
Following from the discussion about how to represent objects that contain or otherwise provide a location for other objects, without necessarily instantiating a Place for them to be located at, I would like to propose a new property for CRM Base, following the pattern of P8 took place on or within. Martin suggested “is located on or within” however this is the label of the inverse of P59 has section, which is used as part of the full path. To have both properties with the same label would be incredibly confusing!
As a first attempt at a definition, please see below.
Pxxx holds or supports (is held or supported by)
Domain: E18 Physical Thing
Range: E18 Physical Thing
Quantification: many to many
This property relates one E18 Physical Thing which acts as a container or support, such as a shelf, for another E18 Physical Thing. Pxxx holds or supports is a shortcut of the more fully developed path from the domain E18 Physical Thing through P59 has section, E53 Place, P53i is former or current location of, to the range E18 Physical Thing. This property is similar to P56 bears feature (is found on), except that the range resource can be any Physical Thing rather than only a Physical Feature, and it is not a sub property of P46 is composed of, as the held or supported object is not a component of the container or support.
This property can be used to avoid explicitly instantiating the E53 Place which is defined by a Physical Thing, especially when the only intended use of that Physical Thing is to act as a container or surface for the storage of other Physical Things. The place’s existence is defined by the existence of the container or surface, and will go out of existence at the same time as the Destruction of the container or surface. As such, there are very few situations in which the identity of the place needs to be distinguished from the defining physical thing.
· The archival folder (E22) “6” _holds or supports_ the piece of paper (E22) carrying the text of a letter from Alloway to Sleigh
· The artist’s materials box (E22) labeled “VG6” _holds or supports_ Van Gogh’s paintbrush 23 (E22)
· The storage box “VG” (E22) _holds or supports_ the artist’s materials box (E22) labeled “VG6”
· The bronze coin bank “72.AC.99” (E22) _holds or supports_ silver coin “72.AC.99-1” (E22)
· The bookshelf “GRI-708.1” (E22) _holds or supports_ the book (E22) “Catalog of Paintings in the J. Paul Getty Museum”
Posted by Martin on 17/7/2019
I support this issue.
My only concern is the following phrase: " This property is similar to P56 bears feature (is found on),". To my opinion, there must not be "similar" properties in the CRM. Whatever the distinction, it must be explicit and decidable.
I suggest two different interpretations: The new property being superproperty of P56 (preferred) or
definitely distinct. In the latter case, the range should be Physical Object.
A confusion with P46 should not occur, because this is about location. I would not exclude components from the new property, such as a chessman being in a box, whereas a set of chessman without a box would be not within anything.
Posted by Robert Sanderson on 17/7/2019
Very happy to remove the fuzzy “similar to”, good catch!
I also prefer it being a super-property of P56. It’s more general than just the bearing of features. Also, the range being limited to Physical Object, rather than Physical Thing would rule out not only Features (E25, E26, E27 and below), but also the other subclass of E24 Physical Human-Made which includes at least E78 Curated Holding. While I don’t use E78, I think it would be difficult to explain why an E78 can’t be held in the space provided by a room in a building. And definitely we should not exclude components – chessmen can clearly be in a box!
Posted by Christian Emil on 20/7/2019
As I understand CRM, the basic idea is that a physical thing (E18 Physical Thing)
has a location (E53 Place) and this location is on (identified relative to) a larger physical thing (E18 Physical Thing): A book has a location at a shelf located in a bookshelf located somwhere in a room etc.
The new property, Pxx, is a shortcut used when there is no/there is no need for information about the locations (E53 Place). This is fine and I support the proposal.
P56 bears feature (is found on) is a similar shortcut restricted to E19 Physical Object and E19 Physical Object:
"P56 bears feature (is found on) is a shortcut. A more detailed representation can make use of the fully developed (i.e. indirect) path ‘E19 Physical Object’,through, ‘P59 has section’, ‘E53 Place’, ‘P53i is former or current location of’, to, ‘E26 Physical Feature’."
The new Pxx restricted to E19 Physical Object and E19 Physical Object is exactly E56 bears feature (is found on).
E56 bears feature (is found on) should be a subproperty of the new Pxx.
In the 45th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 38th FRBR – CIDOC CRM Harmonization meeting, the sig discussed RS’s proposal agreed with the scope note definition provided by RS and proposed that Pxxx holds or supports should best be declared a superproperty of P56 bears feature. HW assigned to RS & MD to investigate the superproperty.
Heraklion, October 2019