Issue 204: Clarification on scope notes of P50, P52, P55 and explanatory note for temporal validity and "current" properties
Posted by Vladimir Alexiev 1/3/2012
I think that P55 should have the same domain as P53 (E18 Physical Thing), and not a more specific class.
- Currently you can say "E18 Physical Thing. P53 has former or current location" but not "E18 Physical Thing. P55 has current location".
- Looking at the class diagram, P55 excludes: Physical Feature, Site, Man-Made Feature, Man-Made Thing, Collection.
What is the justification?
Posted by Martin Doerr 3/3/2012
The idea is that features cannot change location, therefore there is no current location. Collections, if they comprise only movable objects, would qualify as one Physical Object, which can change location.
Posted by Vladimir Alexiev 5/03/2012
To me this is a bit counter-intuitive: a permanent location is not current? I'd say it's current for eternity!! If that's the reasoning, it should be documented in the scope note of P55.
Speaking of the scope note of P55, I think "at the time the property was recorded" should be changed to "at present".
- Since we don't know the time the property was recorded, this makes P55 kind of useless &hellip
- Whereas "at present" makes P55 quite useful and important.
Posted by Martin Doerr 5/03/2012
P53 is not a "permanent" location, it is any location the thing ever had, in particular the current one.
Therefore, the place of a feature, which in the museum world does not change location (in contrast to the Red Spot on Jupiter) is completely documented with P53. We know by inference that any location is also current.
The scope note of P55 is not by chance: If you have a database or an inventory record saying "current location", it can only be at the time the record was created. It is absolutely impossible to conclude from such a statement in a museum record what holds "at present". How would you do that? I am curious if you have a better use case &hellip
A "permanent location" is a location where a thing should normally be. In museum practice, this is an administrational-intentional notion, rather than an observational fact.
Please do not confuse "former OR current" with "former AND current"!
The fact, that a thing may have never changed location ("permanent"), would be another property. In CRM, we discourage from such statements, because this is extremely difficult to be observed and typically non-monotonous under additional knowledge.
Posted by Vladimir Alexiev 9/03/2012
I have not confused OR and AND ever since mommy told me "you can't have an icecream and a coke, but you may pick one" at age 8.!!
I am speaking about P55, not P53.
For me the inability to state that an immovable thing "P55 has current location" is counter-intuitive.
If CIDOC considers it an appropriate limitation, then the reason should be stated in the scope note of P55 to avoid confusion.
Not if the DB has a "business date" field. Then the date of recording becomes irrelevant.
You convert all records to P53, but the last one to P55.
If a new record comes in later, you replace the previous P55 with P53 and create a new P53.
This embodies a closed world assumption and is non-monotonic, but P55 has a closed-world flavor anyway,because normally there can be only ONE current location.
Under your interpretation, you'd convert all records to P55 because they were current at the time they were made.
But that makes P55 the same as P53, therefore useless.
The current scope note refers to an UNKNOWN past moment ("the time the property was recorded"), which I think is useless.
I propose to change it to a known and important although moving moment ("at present"), and let data migrators worry how they will fulfill that.
Posted by Martin Doerr 9/03/2012
Well, of course a permanent location is also current. P53 is any location in time, hence it entails current locations, and current locations entail permanent locations.
I wanted to say that there is no point in stating as an additional observation that a feature has a "current location". I do not understand, what the utility would be in a database. P55 is there in order to be able to distinguish the current from other different locations.
What is you use case? You can add to your query a rule, that retrieves together with P55 all P53 to features.
How would allowing to explicitly state P55 for features ncrease your knowledge?
You know it anyhow by inference from P53. (By the way, this is a non-exclusive or: icecream, coke or both).
Which curator would appreciate to invest time for such statements?
Actually we mean exactly the same. The question is how you interpret the term "recorded". We have not encountered your interpretation so far. The present can never be a reference, only the validity date of the containing record or database.
Indeed, P55 has a closed-world flavor and we generally discourage using it. The idea is of course to turn all P55 into P53 when you have no validity information any more.
I propose to change the scope notes of P50, P52, P55,
from:
"at the time the property was recorded"
to
"at the time of validity of the containing record or database".
May be the issue deserves an explanation in the introduction about temporal validity of properties.
Posted by Martin
Dear All,
Following Vladimir's remarks, I suggest to add to the section Modelling Principles, possibly under monotonicity, a paragraph about temporal validity and "current" properties.
To change the scope notes of P50, P52, P55
from:
"at the time the property was recorded"
to
"at the time of validity of the containing record or database".
And to add to the section Modelling Principles, possibly under monotonicity, a paragraph about temporal validity and "current" properties
SIG accepted the proposed change "at the time of validity of the record or database containing the statement that uses this property" in properties P50, P52, P55 and the text to be written
Heraklion, Crete, 3/5/2012
On 12/11/2012, Martin wrote:
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.
Mathew Stiff wrote on 13/11/2012
"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 the time-span of its existence. If more temporal details are required, the CRM recommends explicitly describing the events of acquiring or losing such property instances, such as by 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."
The CRM-SIG accepted the proposal
Amersfoort 20/11/2012