The simple answer to this is yes you can curate features and that is why E78 is where it is.
Stephen Stead Tel +44 20 8668 3075 Mob +44 7802 755 013 E-mail [email protected] LinkedIn Profile http://uk.linkedin.com/in/steads -----Original Message----- From: Crm-sig [mailto:[email protected]] On Behalf Of Christian-Emil Smith Ore Sent: 16 April 2017 07:34 To: Robert Sanderson <[email protected]>; 'crm-sig' <[email protected]> Subject: Re: [Crm-sig] E78 Collection vs E19 Physical Object 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." Best Christian-Emil ________________________________________ From: Robert Sanderson <[email protected]> Sent: 16 April 2017 02:11 To: Christian-Emil Smith Ore; 'crm-sig' Subject: Re: [Crm-sig] E78 Collection vs E19 Physical Object 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. Rob On 4/15/17, 8:02 AM, "Crm-sig on behalf of Christian-Emil Smith Ore" <[email protected] on behalf of [email protected]> wrote: 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. Best, Christian-Emil Multiple Instantiation is the term that describes the case that an instance of class A is also regarded as an instance of one or more other classes B1...n at the same time. When multiple instantiation is used, it has the effect that the properties of all these classes become available to describe this instance. For instance, some particular cases of destruction may also be activities (e.g.,Herostratos' deed), but not all destructions are activities (e.g., destruction of Herculaneum). In comparison, multiple inheritance describes the case that all instances of a class A are implicitly instances of all superclasses of A, by virtue of the definition of the class A, whereas the combination of classes used for multiple instantiation is a characteristic of particular instances only. It is important to note that multiple instantiation is not allowed using combinations of disjoint classes. From: Robert Sanderson <[email protected]> Sent: 15 April 2017 02:43 To: [email protected]; Christian-Emil Smith Ore; 'crm-sig' Subject: Re: [Crm-sig] E78 Collection vs E19 Physical Object On 4/14/17, 4:53 PM, "Stephen Stead" <[email protected]> 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 . _______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig _______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
