Dear Vladimir,
I am not sure if merging these classes is a good idea, and provides much
help. We should
not forget that the CRM is an ontology and not a database schema. If you
declare in ResearchSpace
a class "Part Transfer" , you are completely CRM compatible. (See also
definition of CRM compatibility!) If a class instance is instance of one
or two classes is a concern of local optimization, not of the conceptual
logic.
The case is not so analogous to Acquisition of Move as it may seem.
Business transactions are by nature
agreements between parties, but taking something from an object does not
mean integrating it into another one per default, nor is the combination
of part removal and addition something that would require a particular
unity of activity, as buying/selling.
In general, Part Removal can be taking a sample from a mummy, cutting
the nose of the Sphinx and
whatever. So, I do not see which "meaningless" situation you refer to.
For instance, I may have a
part of an ancient Greek temple, I know when it was stolen, and by whom,
but not from which temple.
I may have a reference of things being stolen from a particular temple,
but don't know what has been removed. I may have reference of some
things being stolen from from temples. I may remove a stone of the
common wall of two(!!) buildings.
"Meaningful Situations" are typically bound to extremely special
contexts relative to the wide scope of the CRM. It is the power of the
CRM to foresee such "exceptions". Please not, that the CRM foresees
quantifications for P112. So, some of the situations you describe are
situations of lack of knowledge, not situations of the reality the CRM
refers to. For instance, E80 Part Removal requires that something is
diminished, but this may be unknown.
At information integration time, restrictions to "force you to express
only meaningful situations" are
a very bad idea. Data have to come in correct already, or providers must
change the source,
which is rarely in a CRM form. Consistency constraints have to be
enforced at data entry time, where
possible situations are better known.
Best,
Martin
On 6/12/2012 4:48 μμ, Joshan Mahmud wrote:
In addition to Vladimir's question we use these classes always together and I'm
not sure when they would be separated.
What would be really helpful is in addition to the comments in the ontology
CIDOC provided a range of examples of each predicate and class from a real
world 'meaningful' situation to a set of RDF triples. This would demystify how
CRM and should be used.
Thanks
Josh
On 6 Dec 2012, at 14:23, "Vladimir Alexiev" <[email protected]>
wrote:
What would the generic case mean? For example:
removed=<object1>, diminished=<collectionA>, added=<object2>,
augmented=<collectionB>
And what do these cases mean?
Part Removal: removed=<object1>, diminished=<collectionA>,
diminished=<collectionB>
Part Removal: removed=<object1>
Part Removal: diminished=<collectionA>
Part Removal:
CRM allows you to express situations, but it doesn't force you to express only
meaningful situations.
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
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 |
--------------------------------------------------------------
