Issue 426: Pxxx holds or supports
Posted by Robert Sanderson on 24/6/2019
Dear all,
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.
Thoughts?
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.
Thoughts?
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
Dear Robert,
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
Dear all,
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.
Rob
Pxxx holds or supports (is held or supported by)
Domain: E18 Physical Thing
Range: E18 Physical Thing
Quantification: many to many
Scope Note:
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.
Examples:
· 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
Dear All,
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!
Thanks Martin!
Posted by Christian Emil on 20/7/2019
Dear all,
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
Posted by Richard Sanderson on 17/1/2020
All,
In this homework http://www.cidoc-crm.org/Issue/ID-426-pxxx-holds-or-supports there is the question of whether holds or supports should be a super-property of p56 bears feature, or whether it should be distinct.
The proposed scope note included:
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.
Which Martin rightly pointed out is not helpful – either properties are related formally or they’re distinct.
The scope note for “holds or supports”:
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 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.
And the scope note for “bears feature”:
This property links an instance of E19 Physical Object to an instance of E26 Physical Feature that it bears.
An E26 Physical Feature can only exist on one object. One object may bear more than one E26 Physical Feature. An E27 Site should be considered as an E26 Physical Feature on the surface of the Earth.
An instance B of E26 Physical Feature being a detail of the structure of another instance A of E26 Physical Feature can be linked to B by use of the property P46 is composed of (forms part of). This implies that the subfeature B is P56i found on the same E19 Physical Object as A.
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’.
Note that both have the same expanded path through P59 /E53 / P53i. The only difference is that P56 is more limited in range to only Features.
Features are E18 Physical Things, so there’s no discrepancy there.
So all in all, I believe that P56 bears feature is a good sub-property of the new property and would like to propose that change in addition to the creation of the new property.
Posted by Martin on 30/1/2020
Dear Robert,
I believe the range should be Physical Object. It should not be integral to the support, as a feature would be, and not regarded part of it. It is a shortcut, but no superproperty.
Comments?
Posted by Robert Sanderson on 25/6/2020
Scope Note
This property relates one instance of E18 Physical Thing which acts as a container or support for another instance of E18 Physical Thing. Typical examples of E18 Physical Things which are intended to function as a container or support include shelves, folders or boxes. These containers or supports provide a stable surface which is intended for other physical objects to be placed upon for storage, display, transport or other similar functions. 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. 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 an instance of E18 Physical Thing, especially when the only intended use of that instance of E18 Physical Thing is to act as a container or surface for the storage of other instances of E18 Physical Thing. 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.
Examples
-
Archival folder “6” (E22) _holds or supports_ the piece of paper (E22) carrying the text of a letter from Alloway to Sleigh
-
Artist’s materials box “VG6” (E22) _holds or supports_ Van Gogh’s paint brush 23 (E22)
-
Storage box “VG” (E22) _holds or supports_ the artist’s materials box “VG6” (E22)
-
Bookshelf “GRI-708.1” (E22) _holds or supports_ the book “Catalog of Paintings in the J. Paul Getty Museum” (E22)
And Christian-Emil kindly provided the first order logic:
Pxx(x,y) ⊃ E18(x)
Pxx(x,y)⊃ E18(y)
Pxx(x,y) ⊂ (∃z) [E53(z) ˄ P59(x,z) ˄ P53i(z,y)]
In the 47th joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 40th FRBR - CIDOC CRM Harmonization meeting; the sig discussed and reviewed the revised by RS scope note of Pxx holds or supports and decided to introduce this property to CRMbase with name P198 holds or supports. Also the SIG went over, the examples, edited them and accepted them –and RS was asked to provide references to them. Harvard style references –if in a catalog, refer to it. The definition of P198 can be found here.
Even though the sig accepted the examples to be appreared in the official release of the CIDOC CRM, decided that these should be gradually replaced by actual, well-referenced ones. This would be done in a separate issue, not the current one.
The issue closed.
June 2020