Issue 341: Aggregates of features and counting
Posted by martin on 18/4/2017
On 16/4/2017 3:11 πμ, Robert Sanderson wrote:
> Thanks Christian-Emil :)
> I’m fine with E78 not being an E22 … but I do wonder why it can’t be. Are there sets of objects that are curated by humans but not made by humans? I would have expected that curation includes the activities of adding and removing objects from the E78, by which I would expect one to consider them “made”.
Aggregates such as curated holdings are functionally considered and treated as a whole.
They can contain physical features, and physical things that may not unambiguously be described as either feature or object. In particular landscapes, archaeological sites, caves etc. are in the intended scope of curated holdings, i.e., Sites and Monuments administrations.
As such, their being a whole as a unit and identity should be seen as man-made I believe, even if all parts are not man-made. Therefore I believe E78 should be brought under E24 Physical Man-Made Thing.
The unity criterion of physical things extends from physical coherence into the treating of aggregates as a functional whole, because for many things physical coherence is only a temporary condition, as for instance a car or a military weapon which at any time can be disassembled and reassembled without changing identity or integrity. Therefore we early decided in CRM that "set" is a bad concept for a core standard, and does not introduce useful basic properties.
The scope note of E19 says: " The class also includes all aggregates of objects", meaning physical objects, not features. Aggregates including features are not meant here and not excluded by the "all". Simply all aggregates of E19s are an E19. The scope note of E18 mentions aggregates, but not specifically aggregates of non-objects (with complete natural physical boundaries). We can improve that scope note.
> The goal is to have E78s be a descendant of E19, such that it can have a number of parts, and so that E19 (as the primary class for modeling aggregations) is an ancestor of E78, which is a specific sort of aggregation…
This is a misunderstanding of the Open World modelling principle the CRM commits to. If your collection is made of objects, such that a number of parts is well-defined, then you can declare your curated collection to be E78 and E19. This is called "multiple instantiation", a logical "AND" of both classifications. In that case however, you exclude things that do not qualify as E19. You cannot simply reuse "P57 has number of parts: E60 Number" without commiting to its domain.
The "number of parts" property is only meant for cases in which you do not list the parts themselves in your primary documentation. If, on the other side, you can describe the parts of your collection, then you can count them in your application.
In the CRM we do not describe purely deductive properties per principle. You can declare them in your own system. The question for the CRM is, what is the primary knowledge. If it is the particular things, then these have priority to be described. If we would declare all deductions we would find no end for the standard. Note that the CRM IS NOT RESTRICTIVE. It only standardizes positive statements.
You can pose anyway the issue on the list to count features. Just mark it as "ISSUE", but I will do it here for you. It will be discussed and documented in the next meeting. This is not easy, because features can overlap. The scope note of P57 clearly says: "Normally, the parts documented in this way would not be considered as worthy of individual attention" and " What constitutes a part or component depends on the context and requirements of the documentation. ". Number of parts is a statistical statement, and as such has no clear semantics across applications.
As a standards working group, we discourage an unreflected use of this property. Better define your own, if you have unambiguous rules. We found however, that even in current museum practice there is no objective item count. Rather, museums count the units defined individually in the documentation. You could also use Dimension for describing the "size" of a collection.
> the sort that is curated, with a collection management plan, etc. Just add E19 as a parent class for E78, and the hierarchy problem is solved.
> That solves the “all aggregations [of whatever function] are E19s” but E78s not being E19s.
That is not necessary, see above, and it is actually logically wrong, because it forbids the superclass. I'd like to mention that these discussions had been all done in the past. As CRM-SIG we are very aware of the urgent need to make the modelling principles explicit, to avoid a repetition of arguments.
Newcomers are VERY MUCH encouraged to join our meetings physically and help with the documentation of the principles they didn't find obvious before, because we are all volunteers, and have a notorious lack of man-power, and/or to convince us where we were wrong, which is also most welcome. We normally use e-mail discussions to state the issues, but not to resolve them. There are too many aspects to be discussed and taken into account, and often a fast answer by e-mail is misunderstood or may even make a bad impression, which is the least thing we want to happen. I and other members of this Group never want to appear arrogant, simply time to write up all arguments in e-mail is quite limited. Decisions following thorough considerations of all arguments are done in physical meetings. My dream is to have a documentation of all principles so concise that e-mail would be enough to point to them...