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



Reply via email to