Martin wrote in particular: Reduce in CRMbase Mesaurement , P40 observed dimension, to E18 Physical Thing. Add 3 different properties “has dimension” in CRMBase to E70 Thing, E53 Place, E4 Period (or E2 Temp Entity).
I agree with your argumentation, and believe that the changes in CRM Base would be: P39 measured: Range changes from E1 CRM Entity to E18 Physical Thing PXX1_has_dimension Domain: E53 Place Range: E54 Dimension PXX2_has_dimension Domain: E4 Period Range: E54 Dimension to be cognate with P43 has dimension for E70s. The question would remain about the measuring of Non-physical Things, such as the number of symbols in a E90 symbolic object... but I don't have that use case, so am happy to leave the discussion to someone that does :) Rob On Tue, Mar 2, 2021 at 4:31 PM Martin Doerr <mar...@ics.forth.gr> wrote: > > > *Posted by Robert Sanderson on 9/9/2020* > > I believe that there is an inconsistency in the model for measurements and > dimensions. > > E54 Dimensions are associated directly with E70 Things using P43 has > dimension. So not every class can have dimensions, only those that are > descendents of E70. > > However E16 Measurement's property P39 measured has a range of E1 CRM > Entity, meaning that while (for example) an E53 Place cannot have a > dimension, it can be measured to have a dimension. This seems inconsistent > that an entity that cannot have dimensions can still be measured. > > I propose that the range of P39 measured be changed to E70 Thing to > resolve this inconsistency. > > > > We have to distinguish measurement from dimension. In order to measure > something in a narrower sense, I need an observation of something material. > Dimensions can also be result of computation, evaluation and estimation > (forms of Attribute Assignment). > > If we look at measuring in the narrower sense, we can count the characters > of a text on paper, but not the abstract text. The logical representation > of a text can be evaluated for its dimensions. > > We cannot measure a place, but features at a place. See also Issue 388. > But clearly, we can measure duration and extent of processes, and comparing > a clock, which provides a duration from the last sync event, with some > other transient situation or microevent, in order to calculate absolute > time. > > So, we may assign the ability to be observed to E18 physical things and E4 > Period, or more narrowly to E5 Event. The ability to be observed appears > to need some common ontological nature, a certain materiality interacting > with measurable signals. Even the lightning creates a plasma hose lasting > some milliseconds. That would need a new class “Observable Entity” as range. > > Otherwise, we may regard measuring physical things and measuring processes *as > independent*. Then, we would need *another measurement class*, such as > “static measurement” versus “dynamic measurement”. > > Dimensions of other things, such as places in the abstract geometric sense > of the CRM, need not be based on a common property. The place can only have > diameters and areas as dimentions, and may be some more exotic ones. The > dimension in the phenomenal timespan is of course that of the respective > period etc. So, my argument being that E53 Place, E52 Time-Span have their > own properties with range Dimension, without being regarded as observable > (rather results of observation). > > I’d propose the following: > > Reduce in CRMbase Mesaurement , P40 observed dimension, to E18 Physical > Thing. Add 3 different properties “has dimension” in CRMBase to E70 Thing, > E53 Place, E4 Period (or E2 Temp Entity). > > Extent CRMSci by E18, E4 IsA Observable Entity, and extend Mesaurement P40 > observed dimension, from E18 to Observable Entity. > > Alternatively, introduce “Dynamic Measurement” in CRMSci. > Best, > > Martin > -- Rob Sanderson Director for Cultural Heritage Metadata Yale University
_______________________________________________ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
