Issue 341: 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 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 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 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 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 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.

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