Dear Rob, Martin

A Comment:

Dimension is defined as a measurable extent of any kind. This could be the
distance between two points on an object. I think this is the way it is
also described in the CRM reference, e.g. "This class comprises
quantifiable properties that can be measured by some calibrated means and
can be approximated by values, i.e. points or regions in a mathematical or
conceptual space..."

Skyscrapers tend to have different types of height dimension. For example,
height to tip (where there is a spire or needle), height to architectural
top, height to highest occupied floor. These are all different dimension
types measuring from one point to another on a building.

However, on the specific example, do I want to describe a state of
'openess' or am I just opening the lid to make it more convenient to
measure the different dimensions of the same box which really hasn't
changed  - height to top of closed lid, height to top of open lid. As
Martin mentions the box is specifically opened in order to take a
particular type of dimension measurement. The example of measuring these
dimensions without opening the lid at all e.g taking two measurements in a
closed position and adding them together) is also an important indicator
that we don't really need to get into a state and I expect for many fragile
items the measurement is done in this way - practically indicating that
this is simply a type of dimension.

I measured my tea caddy this morning. I measured with the "lid on" to the
point where the lid starts and then again to the top of the lid. I then
took the lid off and measured the main body of the caddy again. It was the
same measurement as when the lid was on! It is the same caddy and the
measurement was not affected. When I took the lid off it didn't really
change the properties particularly.  The two measurements, one to the top
of the main caddy body and one to the top of the lid are two different
dimensions of the same thing, like the skyscraper. If the caddy was made of
wood then these measurements might change in different conditions like, for
example, heat and humidity compared to freezing conditions. In this case
the same dimensions might have a different result but that would be a
different situation.

If I could only measure a dimension on the bottom of the box by turning the
box over, is this a dimension of a particular state (i.e. upside down
state)? - perhaps in common usage but this isn't the same as the context we
talk about.

I agree that the world is constantly changing (and our understanding of it
changes). However, taking a slightly different line, it is not necessary,
in my opinion, to be exhaustive in order to describe a valid and useful
type of totality. Some things are more useful than others. I would
therefore agree that we need to be careful about the use of states as this
could have quite problematic implications for which, as Martin says, we are
not equipped to deal with and technology hasn't really helped with (perhaps
made worse), but in any event we don't need.

I think we should update the definition of S16 - its a bit thin but I think
it could be updated to a better state. :-)

D


































orcid.org/0000-0002-5539-3126

On Tue, Apr 11, 2017 at 6:37 PM, Robert Sanderson <rsander...@getty.edu>
wrote:

>
> As in physics, you can know either the state of objects in the universe or
> the forces that act upon them, but never both (  The proposal takes the
> former as more valuable for the work that we are attempting to do –
> describe the state of objects in our care either for conservation purposes
> or for simple descriptive purposes. The CRM seems to try to model the
> ephemeral forces, to the exclusion of the things being acted upon.
>
> By which I mean that E11 Modification enables the description of the
> transforming force (the opening of the lid) but does not allow the
> identification of the resulting state.
>
> _:LidOpening a Modification ;
>     has_type <lid-opening> ;
>     has_modified <box> ;
>     carried_out_by <conservator> ;
>     had_specific_purpose _:measurement1, _:measurement2 ;
>     has_timespan <time> .
>
> _:measurement1 a Measurement ;
>     measured <box> ;
>     observed_dimension _:height .
>
> _:height a Dimension ;
>     has_type <height> ;
>     has_value 20 ;
>     has_unit <inches> .
>
> _:measurement2 a Measurement ;
>     measured <box> ;
>     observed_dimension _:width .
>
> _:width a Dimension ;
>     has_type <width> ;
>     has_value 15 ;
>     has_unit <inches> .
>
> We have described the forces … the actions … of lid-opening and measuring,
> and linked the observed dimensions … but nowhere is there an entity that IS
> the box with its lid open.  We need to understand the LidOpening action’s
> purpose in order to deduce that the measurements, although they are of the
> box, pertain to some un-identified state of that object. We do not have
> anywhere to associate even a label “Box with Lid Open” with those
> measurements.
>
> We would not want to say that the opening of the lid somehow destroyed
> Box-with-Lid-Closed and created Box-with-Lid-Open (e.g. E81 Transformation
> is not appropriate)
>
> Rob
>
> On 4/11/17, 7:13 AM, "martin" <mar...@ics.forth.gr> wrote:
>
>     Dear Robert,
>
>     The point I try to make is that we are easily confusing reality with
>     description, and partial knowledge with reconstruction of what is in
>     between:
>     To my understanding, the very existence of a state is an intellectual
>     working back from the parameters of the observation.
>     Whereas the reality does not change, things evolve, move, interact as
>     they do, the definition of state thereupon changes with the definition
>     of the properties we apply to describe these things. The objective
> thing
>     is the observation, the "state" an extrapolation of the latter. To
> start
>     constructing a state, which in the sequence is observed, turns to my
>     opinion things upside down. The lid is removed in the course of the
>     measurement in order to measure thedimension without lid, and it was
> not
>     observed that the lid was removed before the observation. The latter
> has
>     a completely different status, a "criminalistic one": Who put down the
> lid?
>
>     Once the state is produced by the activity to measure, it does not have
>     an ontological identity of its own.
>     Further, all the positions the lid can have wrt the container are
>     continuous in space. The is nothing to mark
>     a specific position which everybody would recognize as being distinct
>     from all others. Only by specifying artificially a position range as
>     "lid open", it can be described and observed. Any definition of
>     "lid-open-ness" produces another state on the very same unambiguous
>     reality. Measuring the container without the lid may not even require
>     removing the lid at all.
>
>     Therefore, I'd say your solution is not as effective or necessary to
>     describe the respective measurement.
>     "States" are a "treacherous" concept in a world which we all very well
>     know is never anywhere at rest. The art of ontology engineering is
> using
>     the concepts that produce the most robust identities as reference under
>     change of context and purpose, and not what we regard as the most
>     analytical ones. We are all tempted in this culture to try to describe
>     the world exhaustively by atomic elements, but no one has ever
> succeeded
>     to do so ;-).
>
>     Comments?
>
>     Best,
>
>     Martin
>
>     On 11/4/2017 2:18 πμ, Robert Sanderson wrote:
>     > A clearer example, reversing the for_state predicate, demonstrating
> it follows the same pattern as parts:
>     >
>     > X a ManMadeObject ;
>     >    label “Chest” ;
>     >    was_in_state S ;
>     >    composed_of P .
>     >
>     > S a State ;
>     >    label “A particular state of X”
>     >    has_type <lid-open-ness> ;
>     >    has_timespan T ;  // when X was in this State
>     >    has_dimension D ;
>     >
>     > D a Dimension ;
>     >    label “Height of X with lid open” ;
>     >    has_value V ;
>     >    has_unit U .
>     >
>     > P a PhysicalObject ;
>     >    label “Lid of X”
>     >    has_dimension D2 .
>     >
>     > D2 a Dimension ;
>     >    label “Height of Lid of X”
>     >    has_value V2 ;
>     >    has_unit U2 .
>     >
>     >
>     > On 4/5/17, 6:08 PM, "Robert Sanderson" <rsander...@getty.edu> wrote:
>     >
>     >
>     >      Thanks Martin, as always :)
>     >
>     >      So I agree completely, but we seem to have come to different
> conclusions?
>     >
>     >      The way I think about the procedure is as follows:
>     >
>     >      X is an object.
>     >      At time T, X was in a state S.
>     >      When in state S, object X was measured.
>     >      The measurement activity M, performed by actor A, resulted in a
> dimension D, with value V and unit U.
>     >
>     >      And for the majority of these capital letters I can trivially
> assign CRM classes … other than state S.
>     >
>     >      X:  the box    (Man Made Object)
>     >      T:  2015-09-10 (TimeSpan)
>     >      S: upright, lid open (?????)
>     >      M: the activity (Measurement)
>     >      A: curator ( Person)
>     >      D: the Dimension with P2 of height (Dimension)
>     >      V: 14 (Number)
>     >      U: inches (Unit)
>     >
>     >      Or something like …
>     >
>     >      X a ManMadeObject ;
>     >        has_state S ;
>     >        has_dimension D .
>     >
>     >      S a State ;
>     >        label “Lid Open” ;
>     >        has_type (external Type for lid-open) ;
>     >        timespan T .
>     >
>     >      D a Dimension ;
>     >        has_type <height> ;
>     >        for_state S ;
>     >        has_value 14 ;
>     >        has_unit U .
>     >
>     >      (and add in the Measurement activity in the obvious way, if
> desired)
>     >
>     >      I agree that we should not try to catalog the vocabulary level
> of all possible states of all possible types of object (!!) but it seems to
> me (and I believe to others) like a valid concern with practical use cases
> and requirements, that a simple P2_has_type on the Dimension would not be
> sufficient to solve.
>     >
>     >      Rob
>     >
>     >      On 4/5/17, 11:41 AM, "martin" <mar...@ics.forth.gr> wrote:
>     >
>     >          Deasr Robert,
>     >
>     >          No, the issue is very serious. The Dimension is ultimately
> determined by
>     >          the procedure.
>     >          "Height with box open" is not a label, but the very type of
> dimension.
>     >          This is not a work around.
>     >          It is a substantial understanding of what a dimension is.
> "height" is
>     >          not a dimension. It has not verifiable identity condition.
>     >
>     >          Using P2 has type must never be interpreted as "little
> regard", but as a
>     >          need for further standardization.
>     >          But I am sorry I do not see a way to formalize in another
> way the
>     >          potential complexity of measurement procedures. When they
> become
>     >          comparable, they must be categorical, and then they form a
> type. If you
>     >          cannot agree on standard measurement procedures, you cannot
> compare
>     >          results, isn't it? At least my understanding as an
> experimental
>     >          physicist by education;-)
>     >
>     >          All the best,
>     >
>     >          martin
>     >
>     >
>     >          On 3/4/2017 10:35 μμ, Robert Sanderson wrote:
>     >          > Thanks Martin :)
>     >          >
>     >          > If I understand correctly, both the type of dimension
> (height vs width) and the state of the object being measured (lid-open vs
> lid-closed) would both end up as external P2_has_type URIs?
>     >          >
>     >          > _:h a Dimension ;
>     >          >    label “Height of the box with the lid open” ;
>     >          >    has_type <height> , <lid-open> ;
>     >          >    has_value 14 ;
>     >          >    has_unit <inches> .
>     >          >
>     >          > And as the width doesn’t change depending on <lid-open>
> or <lid-closed> ness:
>     >          >
>     >          > _:w a Dimension ;
>     >          >    label “Height of the box with the lid open” ;
>     >          >    has_type <width> , <lid-open>, <lid-closed> ;
>     >          >    has_value 8 ;
>     >          >    has_unit <inches> .
>     >          >
>     >          > It seems a little jarring to have a core museum activity
> being treated with (from my perspective) little regard, compared to some of
> the existing distinctions made between classes with very little practical
> value. When the <height> and <lid-open> URIs are not understood, let alone
> the unit URI, the only thing the ontology actually captures is the value…
> and as E60 can be a string, there’s not all that much value (ha!) there
> either.
>     >          >
>     >          > When the answer to all questions is “Just put it in P2”,
> doesn’t that give one pause that P2 is so broad as to be meaningless?
>     >          >
>     >          > Rob
>     >          >
>     >          >
>     >          > On 4/3/17, 12:16 PM, "martin" <mar...@ics.forth.gr>
> wrote:
>     >          >
>     >          >      Dear Robert,
>     >          >
>     >          >      The standard way to describe this in the CRM is to
> type the Dimension
>     >          >      with the procedure:
>     >          >      a) Lid-open
>     >          >      b) Lid-closed
>     >          >
>     >          >      The Measurement procedure type can be documented by
> a detailed text.
>     >          >
>     >          >      In biology, one would measure "wingspan at life" and
> "winspan dead" of a
>     >          >      bird, etc.
>     >          >
>     >          >      Best,
>     >          >
>     >          >      martin
>     >          >
>     >          >      On 3/4/2017 7:13 μμ, Robert Sanderson wrote:
>     >          >      > Dear all,
>     >          >      >
>     >          >      > One of our use cases which we are having trouble
> modeling with just the core CRM ontology is measurements of an object in a
> particular state.  For example, we would like to record the measurements of
> a chest with the lid open, rather than those with the lid closed.  It is
> the same object, just in two different states, resulting in different
> measurements.
>     >          >      >
>     >          >      > The proposed scope note does certainly clarify
> more than the rather terse original, but if there is any feedback or
> guidance as to the above situation, we would be greatly appreciative.
>     >          >      >
>     >          >      > Many thanks,
>     >          >      >
>     >          >      > Rob
>     >          >      >
>     >          >
>     >          >      --
>     >          >
>     >          >      ------------------------------
> --------------------------------
>     >          >        Dr. Martin Doerr              |  Vox:
> +30(2810)391625        |
>     >          >        Research Director             |  Fax:
> +30(2810)391638        |
>     >          >                                      |  Email:
> mar...@ics.forth.gr |
>     >          >
>           |
>     >          >                      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
>          |
>     >          >      ------------------------------
> --------------------------------
>     >          >
>     >          >
>     >          >
>     >
>     >
>     >          --
>     >
>     >          ------------------------------
> --------------------------------
>     >            Dr. Martin Doerr              |  Vox:+30(2810)391625
>     |
>     >            Research Director             |  Fax:+30(2810)391638
>     |
>     >                                          |  Email:
> mar...@ics.forth.gr |
>     >
>   |
>     >                          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
>    |
>     >          ------------------------------
> --------------------------------
>     >
>     >
>     >
>     >
>     >
>
>
>     --
>
>     --------------------------------------------------------------
>       Dr. Martin Doerr              |  Vox:+30(2810)391625        |
>       Research Director             |  Fax:+30(2810)391638        |
>                                     |  Email: mar...@ics.forth.gr |
>                                                                   |
>                     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           |
>     --------------------------------------------------------------
>
>
>
>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>

Reply via email to