The potential for ambiguity comes in when the pattern is adopted more generally
for resources other than Dimension. Consider this scenario:
As a conservator, I measure the [now wearing thin] chest with the lid closed,
and I take a photograph of it in that state. I then open the chest’s lid,
measure the chest with the lid open and take a photograph in that state.
Without an entity to represent the state of the chest, as a data modeler, I
have to use the Type as the integration point between the dimensions and the
photograph. Thus I associate the lid-open type with the Dimension (meaning
that the Dimension is of the Object in the state Lid-Open), and with the
Photograph (meaning that the Image depicts the Object in the state Lid-Open) so
I can cross-reference with the Dimension). If there is a type that applies to
both Image and Object, it would be ambiguous which it applied to… and the same
for any other resource that should be associated such as a Title, Description,
etc.
How about … the ambiguity of the dimensions of a Framed Painting (Dimension P2
Framed), with a Framed photograph (Photograph P2 Framed -- meaning the
photograph) of the Unframed Painting (Photograph P2 Unframed -- meaning the
painting)?
{
"@type": "ManMadeObject",
"dimension": {
"@type": "Dimension",
"has_type": "x:Framed" // meaning the MMO measured in “framed” state
},
"has_representation": {
"@type": "Image",
"has_type": "x:Framed" // ambiguous whether the Image is framed or the MMO
depicted is framed
}
}
This sort of ambiguity is typically solved by having a new entity which can
have dimensions and representations (and titles, and…) associated with it,
which is my “State” … I don’t care about the name, and am happy to change the
definition to philosophically aligned … but the current “just use P2 to tag
everything” seems to either result in an infinity of interrelated Types (making
them no longer usable) or likely ambiguity when applied to real world use cases.
Rob
On 4/12/17, 12:41 PM, "martin" <[email protected]> wrote:
Dear Robert,
As we said, each measurement procedure defines a new Dimension type. In
modern physics it became very clear that measurements in general do interact
with the object itself. Therefore, do not separate the "state" from the
procedure. E.g., if you measure the
voltage of a battery with a Voltmeter, each Voltmeter with a different
inner Ohm resistance will give you another value with very different diagnostic
utility (a personal experience by the way, that puzzled me once for days!).
Putting an object in a rectangular
adjustable box gives you another height than the maximum spatial extent,
and depending on the softness and elasticity, you may be quite puzzled by what
you measure.
Therefore, we really do recommend that "lid-open" and "lid-closed" are two
different types of Dimension, and that you describe with sufficient text and
graphics or photos what that each type means ("is documented in"). Then, you
simply measure the Dimension
"lid-open" etc. I believe that defining artificial states are not of any
help to do that better, but if you give me a query that you regard as relevant
that can be answered
only your way, can make clear how the state itself would be defined in an
unambiguous way, and that this is possible for all kinds of measurements, I'll
be glad to be convinced:-)!
All the best,
Martin
On 12/4/2017 6:49 μμ, Robert Sanderson wrote:
Hi Dominic, Martin,
Here’s two concrete use cases … how do you suggest that they be described
in CRM?
1. The object is a manuscript and for storage reasons I want to know the
dimensions of it when closed (also this is the typical set of dimensions), and
for exhibition planning reasons I want to know the dimensions of it when open,
so I can lay it out in a display case.
2. The object is a chest with hinged lid that sits, at rest, either
completely open or completely closed. Same reasons as above – I want to display
it open, but store it closed, so need to know the total height of the chest
with the lid closed versus open.
Clearly there are many possible states for these objects that would result
in different measurements – the height of the manuscript would depend on the
number of pages turned, and the lid could be propped open to just about any
height.
The difference with the skyscraper heights is that the skyscraper is not
being manipulated to produce the different dimensions, they’re just heights of
different parts. You could measure and record them separately and calculate the
different totals. The wooden tea caddy is also interesting regarding state …
let me propose a simpler case though:
3. An umbrella can be folded into a cylinder needing length and radius
dimensions, or open into (err…) an umbrella shape probably needing height,
width and depth dimensions.
This case requires two _sets_ of dimensions to go together. Say that it’s a
very carefully constructed umbrella where the appearance when folded is black,
but the appearance when open is multi-colored. Same umbrella in two states,
each of which has multiple properties beyond just dimensions.
If the P2 is the approach for the Dimension … is it also that we’d
associate the same Type with a descriptive text for the color?
(And for all other features we want to describe about the same state?)
Rob
On 4/12/17, 8:18 AM, "Dominic Oldman" <[email protected]>
<mailto:[email protected]> wrote:
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 <http://orcid.org/0000-0002-5539-3126>
<http://orcid.org/0000-0002-5539-3126>
On Tue, Apr 11, 2017 at 6:37 PM, Robert Sanderson
<[email protected]> <mailto:[email protected]> 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" <[email protected]>
<mailto:[email protected]> 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" <[email protected]>
<mailto:[email protected]> 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" <[email protected]>
<mailto:[email protected]> 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" <[email protected]>
<mailto:[email protected]> 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 <tel:%2B30%282810%29391625> <tel:%2B30%282810%29391625>
|
> > Research Director |
Fax:+30(2810)391638 <tel:%2B30%282810%29391638> <tel:%2B30%282810%29391638>
|
> > | Email:
[email protected] <mailto:[email protected]>
<mailto:[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 <http://www.ics.forth.gr/isl>
<http://www.ics.forth.gr/isl> |
> >
--------------------------------------------------------------
> >
> >
> >
>
>
> --
>
>
--------------------------------------------------------------
> Dr. Martin Doerr | Vox:+30(2810)391625
<tel:%2B30%282810%29391625> <tel:%2B30%282810%29391625> |
> Research Director | Fax:+30(2810)391638
<tel:%2B30%282810%29391638> <tel:%2B30%282810%29391638> |
> | Email:
[email protected] <mailto:[email protected]>
<mailto:[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 <http://www.ics.forth.gr/isl>
<http://www.ics.forth.gr/isl> |
>
--------------------------------------------------------------
>
>
>
>
>
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625
<tel:%2B30%282810%29391625> <tel:%2B30%282810%29391625> |
Research Director | Fax:+30(2810)391638
<tel:%2B30%282810%29391638> <tel:%2B30%282810%29391638> |
| Email:
[email protected] <mailto:[email protected]>
<mailto:[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 <http://www.ics.forth.gr/isl>
<http://www.ics.forth.gr/isl> |
--------------------------------------------------------------
_______________________________________________
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 |
--------------------------------------------------------------
