Dear All,
Here a better version I just received from Matthew Stiff:
"Properties, such as having a part, an owner or a location, may change
many times for a single item during its existence. Stating instances of
such properties for an item in terms of the CRM only means that these
properties existed during some particular time-span. Therefore, one
item may have multiple instances of the same property reflecting an
aggregation of these instances over its time-span of existence. If more
temporal details are required, the CRM recommends explicitly describing
the events of acquiring or losing such property instances, such as E9
Move etc. By virtue of this principle, the CRM achieves monotonicity
with respect to an increase of knowledge about the states of an item at
different times, regardless of their temporal order.
However, for some of these properties many collection databases describe
the "current" state, such as "current location" or "current owner".
Using such a "current" state means, that the database manager is able to
verify the respective reality at the latest date of validity of the
database. Obviously, this information is non-monotonic, i.e., it
requires deletion when the state changes. In order to preserve a reduced
monotonicity, these properties have time-neutral superproperties by
which respective instances can be reclassified if the validity becomes
unknown or no longer holds. Therefore the use of such properties in the
CRM is only recommended if they can be maintained consistently.
Otherwise, they should be reclassified by their time-neutral
superproperties. This holds in particular if data is exported to another
repository."
On 12/11/2012 8:56 ??, martin wrote:
Dear All,
Here my proposal for a text about temporal validity of properties for
the CRM introduction:
Properties, such as having a part, an owner or a location, may change
many times for a single item during its existence. Stating instances
of such properties for an item in terms of the CRM only means that
these properties existed at some time-span. Therefore, one item may
have multiple instances of the same property reflecting an aggregation
of these instances over its time-span of existence. If more temporal
details are required, the CRM recommends to explicitly describe the
events of acquiring or loosing such property instances explicitly,
such as E9 Move etc. By virtue of these principle, the CRM achieves
monotonicity with respect to an increase of knowledge about the states
of an item at different times regardless of their temporal order.
However, for some of these properties many collection databases
describe the "current" state, such as "current location" or "current
owner". Using such a "current" state means, that the database
maintainer is able to verify the respective reality at the latest date
of validity of the database. Obviously, this information is
non-monotonic, i.e., it requires deletion when the state changes. In
order to preserve a reduced monotonicity, these properties have
time-neutral superproperties by which respective instances can be
reclassified if the validity becomes unknown or no more holds.
Therefore the use of such properties in the CRM is only recommended if
they can be maintained consistently. Otherwise, they should be
reclassified by their time-neutral superproperties. This hold in
particular if data are exported to another repository.
--
--------------------------------------------------------------
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 |
--------------------------------------------------------------
