Define two subclasses for different types of CustodialEvents?

[rjyounes]

Originally the custodial event model distinguished aggregate from individual custodial events formally, using two different classes. We then decided that the types of resources would be profiled similarly, with properties and relationships such as activities, dates, locations, price, etc, and we collapsed them into a single class.

In working on the application profiles for VitroLib, it now appears to me that the distinction both (a) is important, perhaps defining, and (b) facilitates application functionality. In general I am not in favor of bending the ontology to suit the application, but in this case the difficulty posed for applications suggests to me a deficiency in the model.

The primary difference between the two is that the individual event attaches directly to an item, whereas the aggregate event does not, and attaches only to individual custodial events. This is a fundamental distinction in the semantics and the behavior. The difficulty in the application is that when the user wants to add a bf:partOf relationship between an individual and an aggregate event, he/she should be presented with choices of only the aggregate type - which has no definition in the model other than it is not attached directly to any items, and is attached directly to a custodial event that is attached to an item.

My current proposal is to define a CustodialEvent class, with two subclasses, IndividualCustodialEvent and AggregateCustodialEvent. This allows the common profiling of the two types of custodial events, but also models the important distinction between them.

Note also that the aggregate CustodialEvent cannot have an accession number (I believe).

@jak473 @melanieWacker @sfolsom I realize we are not going to reopen modeling questions now, and we have also decided in the first iteration of RareMat VitroLib not to model the aggregate custodial events, so the question is moot at this stage. However, I'd like to get your opinion on the modeling question with an eye to making a possible change after the release of VitroLib.

[jak473]

Can we ignore the aggregated custodial event and simplify the model for first-pass VitroLib implementation?

[jak473]

Sorry... somehow missed the last sentence... you already said that. Agreed. Let's document this as needed for future work (the write-up you did is perfect for the documentation).

[rjyounes]

Added to recommendation doc. Leaving the issue open in case it generates more discussion.