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]> 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]> 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]> 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: [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 |
> --------------------------------------------------------------
>
>
>
--
--------------------------------------------------------------
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 |
--------------------------------------------------------------
