Aggregates of features and counting

posted by Robert Sanderson on 14/4/2017

Dear all,

A question completely unrelated to states, I promise (

E78 Collection is described as:  “This class comprises aggregations of instances of E18 Physical Thing that are assembled and maintained …”
And E19 Physical Object’s scope note says:  “The class also includes *all* aggregates of objects made for functional purposes of *whatever kind*, …”
(emphasis added)

However E78 is not a descendant of E19 … they are both independent descendants of E18.

So every E78 Collection must also be, explicitly, an E19 Physical Object?  This seems like a bug in the class hierarchy?

And regardless of the hierarchy, if there is a set of objects that are not “physically bound together or […] kept together for their functionality” (hence not E19), but do not have a “particular collection development plan” (hence not E78 either) … how should they be modeled?  Examples include auction lots, the set of objects that are looked after by an art dealer (but without a development plan), and similar.

Posted by Christian Emil on 14/4/2017

Hi Robert,

The E78  Collection changed name (which of course does not mean anything since the name of a class is just a label and the definition is given by the scope note.) to E78 Curated Holding a year ago (issue 270 resolved in Prato February 2016). The CRM 6.2.2 is not completely updated - unfortunately.

The crucial point is: Can an instance of E78 Curated Holding consist of stuff (to use the old term) that is not moved and cannot be moved.  The first sentence of the scope note indicates that a curated holding consists of things that are assembled and thus moved (demonstrating that they are physical objects).

"This class comprises aggregations of instances of E18 Physical Thing that are assembled..."

If this is the case, one may argue that any assembly of physical objects is in itself a physical object. On the other hand there may well be a open air museum where the collection consists of log houses placed in different locations (say, 1 kilometer apart) but curated collectively. It may be somewhat artificial to model such a collection as a single physical object.

However, I agree that the word 'assembled' may cause confusions.  If you agree that my collection of log houses should not be modeled as a single physical object, could you suggest a better formulation in the scope note?

Best
Christian-Emil

********************************************
E78 Curated Holding
Subclass of:  E24 Physical Man-Made Thing

Scope note: This class comprises aggregations of instances of E18 Physical Thing that are assembled and maintained (“curated” and “preserved,” in museological terminology) by one or more instances of E39 Actor over time for a specific purpose and audience, and according to a particular collection development plan.  Typical instances of curated holdings are museum collections, archives, library holdings and digital libraries. A digital library is regarded as an instance of E18 Physical Thing because it requires keeping physical carriers of the electronic content.

Items may be added or removed from an E78 Curated Holding in pursuit of this plan. This class should not be confused with the E39 Actor maintaining the E78 Curated Holding often referred to with the name of the E78 Curated Holding (e.g. “The Wallace Collection decided…”).

Collective objects in the general sense, like a tomb full of gifts, a folder with stamps or a set of chessmen, should be documented as instances of E19 Physical Object, and not as instances of E78 Curated Holding. This is because they form wholes either because they are physically bound together or because they are kept together for their functionality.

Examples: 
 the John Clayton Herbarium
 the Wallace Collection
 Mikael Heggelund Foslie’s coralline red algae Herbarium at Museum of Natural History and Archaeology, Trondheim, Norway

**********************************************

E19 Physical Object
Subclass of:    E18 Physical Thing
Superclass of:  E20 Biological Object
E22 Man-Made Object

Scope note: This class comprises items of a material nature that are units for documentation and have physical boundaries that separate them completely in an objective way from other objects.

The class also includes all aggregates of objects made for functional purposes of whatever kind, independent of physical coherence, such as a set of chessmen. Typically, instances of E19 Physical Object can be moved (if not too heavy).

In some contexts, such objects, except for aggregates, are also called “bona fide objects” (Smith & Varzi, 2000, pp.401-420), i.e. naturally defined objects.

The decision as to what is documented as a complete item, rather than by its parts or components, may be a purely administrative decision or may be a result of the order in which the item was acquired.
Examples:
 John Smith
 Aphrodite of Milos
 the Palace of Knossos
 the Cullinan Diamond
 Apollo 13 at the time of launch
*****************************************************

Posted by Robert Sanderson on 14/4/2017

Dear Christian-Emil, all,

Yes – I’ve followed 270 over its evolution.  To me, there are still two issues not addressed in 270:

1. E78 curated aggregation is not a descendant of the class used for general aggregations E19.
2. There are a lot of aggregations that do not fit into the scope notes.

For 1, if it’s accepted as an issue to be solved, then I propose that E78 become a sub-class of E22 Man Made Object

Currently E78 is a sub-class of only E24.
E22 is a sub-class of both E19 and E24.
Thus the simplest change to have E78 descend also from E19 is to move E78 to be a child of the existing E22.

Or, more comprehensively, introduce a new class below E19 for Sets, and move P57 to it, then make E78 a child of the new class and of E24.
If P57 is intended to be used for more than membership, then it should instead be on E18 along with P46.

For 2, I would propose to remove the following text from E78’s scope note:

“over time for a specific purpose and audience, and according to a particular collection development plan.”

An art dealer’s stock is assembled for a specific purpose, I think curated is appropriate, arguably for the audience of art buyers (which seems a bit meaningless), but unless you count “buy low, sell high” as a collection development plan, it does not fit under E78.  Ditto Auction lots, consignments, personal collections, and so forth.  Personal collections probably fail the specific purpose clause, unless “my amusement” counts as a purpose.

That said, if issue 1 is solved, I would also be happy with simply changing the reference to E19 in the E78 note:

From:   This is because they form wholes either because they are physically bound together or because they are kept together for their functionality.
To:  This is because they do not have collection plans that are followed over time.

A Collection could be physically bound together. A Collection could be kept together for its functionality. The importance is the management of it, not the physical composition or subjective reason for the particular grouping.

Posted by Steve on 14/4/2017

E78 is intended to allow a curated collection of features not just of objects and so does not belong as a sub-class of E22.
I am unclear what the Identity, Unity, Existence and Substance criteria for a "Set" would be and thus find it difficult to conceive of it being a class.
The long list of things that do not fit under E78 suggests that criteria are actually a "real" partition of the world that is in our scope. Many of the things that do not fit are either out-of-scope or are not curated collections or both.
In the case that there is something that is both an instance of E19 and E78 then multiple instantiation is the solution not tinkering with the class definitions.

CEO's desire to replace 'assembled' might be tackled with "grouped" instead. Not sure, still thinking about it.

posted by Robert on 14/4/2017

Hi Stephen,

I don’t follow why the class of the collection affects what can be collected?  A curated collection of features is not itself a feature, and hence could be an E22. Could you explain your objection further please? Features are a sub-class of E18, which can be included into either an E78 or E19, as the predicate is defined with E18 as the domain which is the ancestor of both.

It would be helpful to clarify the distinction between the two classes:

“This class comprises aggregations of instances of E18 Physical Thing” … as P46 comes from E18, that’s no problem, as E19 is a sub-class of E18.
“The class also includes *all* aggregates of objects” … in all practicality, this is exactly the same as E78 as P46’s domain and range are E18.

The documentation says:

All aggregations of objects are E19s.
E78s are aggregations of objects.
E78s are not E19s.

I contend there is a logical inconsistency.

Posted by Robert on 15/4/2017

Robert
1] Of course the superclass constrains the contents of a subclass.
2] I disagree with your contention that E19 contains all aggregates. It contains a subset of all aggregates; that is those that are "made for functional purposes".
3] E78s are not just aggregations of objects they are aggregations of instances of E18 Physical Thing which includes things other than objects like features.
4] The distinctions are Very clear and it would be a logical inconsistency to move E78 so that it was a sub-class either directly or indirectly of only E22 because then you could not have features in a collection. Which would be strange.

Posted by Robert Sanderson on 15/4/2017

On 4/14/17, 4:53 PM, "Stephen Stead" <steads@paveprime.com> wrote:

    Robert
    1] Of course the superclass constrains the contents of a subclass.
    4] The distinctions are Very clear and it would be a logical inconsistency to move E78 so that it was a sub-class either directly or indirectly of only E22 because then you could not have features in a collection. Which would be strange.

The superclass constrains the functionality and semantics of the subclass, but not its related resources.

It’s perfectly possible to say:

_:collection a E78_Curated_Holding ;
  P46_is_composed_of _:1, _:2, _:3 .

_:1 a ManMadeObject .
_:2 a Feature .
_:3 a PhysicalObject .

Those statements would hold regardless of the super-classes of E78, so long as E18 is an ancestor (to get P46).
(And even then you could still do that outside of OWL, as the use of P46 would simply imply that the E78 is an E18 as well)

So I’m afraid that I still disagree. The change that would make features not able to be part of a Collection would be to change _its_ superclass to not be E18.

    2] I disagree with your contention that E19 contains all aggregates. It contains a subset of all aggregates; that is those that are "made for functional purposes".

Okay, I elided “for functional purposes” but unless collections are not “made for functional purposes” then the point stands.
And if there are aggregations of things that are made for no functional purpose at all, I question whether Issue 270 is even remotely valid.  A Hoard has no *function* in and of itself. It’s just an aggregation of objects. It’s not a Collection, so if it’s not a E19 … what is it? Ditto an Art Dealer’s stock. Ditto the set of objects in an Auction Lot. Ditto the set of objects in an archive. Ditto …

If it is impossible to describe these extremely common things in the cultural heritage sector using CRM, there is a very simple solution that involves not using CRM, but I would like to be 110% certain of that before invoking that nuclear option.

    3] E78s are not just aggregations of objects they are aggregations of instances of E18 Physical Thing which includes things other than objects like features.

Sure. But so are E19s according to the ontology.  This is completely legitimate as E25, E26 and E27 are all descendants of E18:

_:SetOfFeatures a E19_PhysicalObject ;
  P46_is_composed_of _:1, _:2, _:3 .

_:1 a E26_Physical_Feature .
_:2 a E27_Site .
_:3 a E25_Man-Made_Feature .

Posted by Christian Emil on 15/4/2017

Dear all,

E78 Curated holding is a subclass of E18 Physical Thing, thus all instances of E78 Curated holding are instances of E18 Physical Thing. That seems to be unproblematic. 

The first question is whether _all_ instances of E78 Curated holding can be seen as instances of E19_Physical Object. If this is the case, then E78 Curated holding could be a subclass of E19_Physical Object.

At least to me it is clear that not all instances of E22 Man Made Objects are instances of E78 Curated Holding (which would have been the ultimate goal of the Hemulens (https://en.wikipedia.org/wiki/List_of_Moomin_characters) . Thus E22 Man Made Objects cannot be a subclass of E78 Curated Holding
The ultimate question is whether all instances of E78 Curated Holding are (should be analysed as) instances of E22 Man Made Objects.  Only if this is the case, then E78 Curated Holding could be a subclass of E22 Man Made Objects.

Robert mentions that a curated collection (instance of E78 Curated Holding) can be composed of objects and features (P46 is composed of (forms part of): E18 Physical Thing). From a model technical/formalistic point of view all instances of all the subclasses of E18 Physical Thing can be a part of a curated holding.   It is also important to remember that the CRM describes how you may organize the information resulting from your documentation, not how the universe is organized.  The scope note of E46 states this clearly “This property allows instances of E18 Physical Thing to be analysed into component elements.”

For me it seems to be too restrictive to insist that all curated holdings (instances of E78 Curated Holding) should be modeled as physical man-made object (E22 Man Made Objects). 

In an early stage of the development of CRM one concluded that in many cases it is necessary to model things as instances of more than one class, so called “multiple  instantiation” (see below). This can be used if a curated holding also needs to be seen as a physical man-made object.
This will may solve the issue Robert raised.

Finally: The crm-sig list should always be open for discussions about any aspect of the CRM family of ontologies. I personally appreciate the reviewing done by Robert. If Robert still find E78/E22 problematic I will challenge him to raise a new issue in which the class hierarchy is satisfactory and logically consistent and also write drafts for new scope notes.
 

Posted by Robert on 16/4/2017

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”.

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… 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.

Posted by Christian Emil on 16/4/2017

I see your point. It all depends on how one want to delimit the extention of 'currated holding'. Can rock art preserved in situ be a currated holding? If so, then a currated holding cannot be a physical object in the E19 Physical Object sense:

"This class comprises items of a material nature that are units for documentation and have physical boundaries that separate them completely in an objective way from other objects." 

Posted by Steve on 16/4/2017

The simple answer to this is yes you can curate features and that is why E78
is where it is.

Posated by Robert Sanderson on 16/4/2017

Okay!
So, although the class hierarchy allows you to aggregate features into an E19, you actually shouldn’t be able to do that?
And thus the bug is not the disjointness of E78 and E19, it’s that E19 allows the P46 inclusion of E26 Features which it shouldn’t.

Further, as Collections are E24s which are E18s but by your definition can aggregate features … E19 can currently aggregate Collections of Features, but should not be able to aggregate Features. If P46 is intended to be transitive, then E19s would once again aggregate Features via Collections.  Therefore P46 must not be transitive. That should be made explicit in the scope notes.

Further, you think that there should be no way to have a set of features that are not curated according to a collection plan. That such an aggregation is outside of the scope of CRM.
To quote 270:
>>> This is not what we have made the CRM for. You SHOULD not make such a distinction

The scope note for E19 should also be clearer that the first paragraph further limits the second paragraph. And the “independent of physical coherence” should be removed, as clearly there is a physical separability requirement on the _aggregated resources_, not just the aggregation itself. 
 

Posted by martin on 18/4/2017

Dear Robert,

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...

Posted by Martin on 18/4/2017

Dear Robert,

If the CRM would describe the world, we would be gods . Seriously now, since this is impossible,
the CRM follows an Open World and Bottom Up development. We model only, what we have understood.
The Open World principle states that what is not said may be true or not.

So, an auction lot, which is not an E78, but is kept functionaly together for the purpose of the auction, is just an E19. If it contains real estate, it is an E18.

Hoards by the way, have of course a clear functionality, to safeguard a treasure, and are therefore together. They are E19s. That the owner may have lost control over them, does not change their raison d'etre.

The set of objects on a photo are different, they form an accidental whole and do not have an identity condition without the photo. The CRM did not have these so far in its scope, so you are free to add such things, without violating CRM compatibility. The CRM does not say, that these things do not exist, nor that you cannot talk about them when you use the CRM. The CRM is NOT a data format!!

May I take it as compliment that "It is certainly arguable that CRM is too complicated where it doesn’t matter, and not complicated enough where it does."?

All constructs in the CRM have been driven by community demands. We normally require evidence that you already have a database with such fields, and that the information is relevant across specialized disciplines. This has exactly the effect you describe for any specialist , but it has allowed for relating information across domains that could never before talk to each other, and that in the end provide important information to both specialists and those trying to understand the larger pictures of the past.
If we would standardize all specialist needs, we would never have arrived where we are now.