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 underE24 <#_E24_Physical_Man-Made_Thing>
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
<#_P57_has_number_of%20parts> has number of parts: E60 <#_E60_Number>
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...
All the best,
Martin
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
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email:[email protected] |
|
Center for Cultural Informatics |
Information Systems Laboratory |
Institute of Computer Science |
Foundation for Research and Technology - Hellas (FORTH) |
|
N.Plastira 100, Vassilika Vouton, |
GR70013 Heraklion,Crete,Greece |
|
Web-site:http://www.ics.forth.gr/isl |
--------------------------------------------------------------
