[Crm-sig] Financial transactions (was CRM Right and Time-Span: ISSUE)

Nicholas Crofts nickcrofts at yahoo.com
Tue Mar 9 15:39:29 EET 2010

Dear all,

I recently used the CRM as the basis for a data migration for a client changing their software platform. Since all the data had to be moved, including all the records of commercial transactions that are currently out of scope for the CRM, we made the ad hoc extensions described below. I should point out that the scope of these extensions was limited to the cases we had to deal with. It isn't intended as a complete model for all financial transactions. However, it might serve to set the ball rolling...   
Monetary quantity features in the CRM as an example of E56 Dimension and currency units are given as examples of E58 Measurement Unit.
However, the CRM gives no explicit indications concerning the way financial
transactions such as purchases should be represented. The properties of E8 Acquisition, for example, allow the
object being acquired, the previous owner, and the new owner to be specified,
but not, in the case of a purchase, the amount paid.

In order to
represent financial transactions adequately, we defined Purchaseand other
operations involving payments as subtypes of E8 Acquisition (specified using
the P2 has type property). We also
defined a new specialization of the CRM property P24 transferred title of: P24 transferred payment. The domain
of this subproperty remains E8 Acquisition, but the range is defined as E72 Legal Object. This class seems to be
ideally suited for instantiating sums of money exchanged in financial
transactions. As a subclass of E70 Thing it inherits the property P43 has
dimension, allowing monetary quantity and units to be specified. The
properties defined for Legal Object concern the definition of rights, notably
the right of ownership, which clearly apply to sums of money. E72 Legal Object
makes no assumptions about the physical manifestation of the legal object being referred to, which seems entirely
appropriate for monetary payments since these may be made using a variety of
monetary instruments, both physical and virtual, whose precise nature is
largely irrelevant to the act of payment. 
Thus we define
purchase as the P24 transfer of title of a E18 Physical Thing, (transferred from Actor A to Actor B) in exchange for a E72 Legal Object, (transferred from
Actor B to Actor A). Since the two parties involved in the transaction are
already defined by the properties P22 and P23, and since the reciprocal
direction of the exchange of payment is inherent in the idea of purchase, we
thought it unnecessary to define supplementary properties to make explicit the
actors making and receiving the payment. This would be required for complex
transactions, for example where payment is made on behalf of the institution by
a third party.
this extended model highlights a possible incoherence in the CRM, already discussed by Christian-Emil and Georg. The range of P24 transferred title of is defined
as E18 Physical Thing, but the definition of E72 Legal
Object clearly indicates that ownership and title are not limited to physical
items but can also apply to intellectual property. It would therefore seem
logical to modify the range of P24 to apply to E72. In its current state, the
CRM does not allow the acquisition of intellectual property to be
documented.   Best wishes


nicholas crofts consulting
cultural information management
gestion de l'information culturelle
av. miremont 23c 
ch-1206 genève 
+41 22 557 90 92 
nicholas at crofts.ch 

From: Christian-Emil Ore <c.e.s.ore at iln.uio.no>
To: martin <martin at ics.forth.gr>
Cc: crm-sig <crm-sig at ics.forth.gr>
Sent: Sun, 28 February, 2010 21:46:02
Subject: Re: [Crm-sig] CRM Right and Time-Span: ISSUE

Dear Martin,
I will really like to give it a try

On 28.02.2010 21:19, martin wrote:
> Dear Christian-Emil, Georg,
> Indeed I would appreciate an initiative to model business transactions and
> a model of everything that can be acquired in a wider sense, as an 
> (external)
> extension of the CRM.
> Would someone like to invest more time into that? If we come up with a 
> satisfactory
> model, we can still decide in the future, if it should be part of the 
> CRM. I am currently
> hesitating to add anything of this kind to the CRM, before having 
> understood the whole
> complex completely. I'd start with a model of a simple exchange 
> transaction of material
> objects, and then go into details of what money is, what a payment is, 
> what an acquired right is.
> What do you think?
> Best,
> Martin
> Christian-Emil Ore wrote:
>> That's right, Martin.
>> I am not very overly enthusiastic of using to many states, cf. ABC model.
>> It is correct that commercial activities and business is not in the 
>> scope of the CRM.
>> Some rights can be transferred completely others are created as a part 
>> of the transaction. If I buy a piece of music (an inaccurate term) 
>> from Itune, my right to play this music (that is the content of the 
>> file) on my device did not exist earlier and is created in the 
>> transfer of title process.
>> Chr-E
>> On 18.02.2010 21:15, martin wrote:
>>> Dear Christian-Emil, Georg,
>>> I believe we have two issues here. The temporality of Right has two 
>>> explanations:
>>> a) Right is a Conceptual Object, which is created at some time.
>>>    It has a validity, which is a temporal entity, with distinct dates
>>> b) The "right" someone holds is in itself a state, i.e. a subclass of 
>>> Temporal Entity.
>>> Both models can be used to report the history of rights.
>>> The issue of bying rights is another one.
>>> If someone acquires a copyright, this does not necessarily imply that 
>>> someone else
>>> looses it, i.e., that there is only one holder of a Right of type 
>>> "copyright". If this
>>> is the case, my copyright and your copyright on the same text is two 
>>> different instances.
>>> In this sense, it is not "sold", but I can be paid for resigning from 
>>> my right and granting
>>> you a right.
>>> The question is, if the CRM should deal in such detail with rights 
>>> and business, or if this would
>>> be a compatible extension. In particular, we have no model for 
>>> exchange businesses of any kind,
>>> this was not in the practical scope. But, of course, this is very 
>>> interesting!
>>> To be discussed.
>>> Martin
>>> Christian-Emil Ore wrote:
>>>> Dear Georg,
>>>> I got your eamil when I came back from Helsinki and  had caught a 
>>>> cold. That is the reason I did not read it that carefully. This is 
>>>> really fun.
>>>> In CRM applications there has according my impressions been an 
>>>> increasing tendency to explain the lack of what you mention with the 
>>>> use of a (E2-E5) temporal entity to express what you mentioned.
>>>> I remember the discussion which in fact was on two different issues 
>>>> we had in the meetings and in the email list:
>>>> 1) Is ownership a right?
>>>> 2) can a right be sold or acquired?
>>>> 1) I argued that ownership to something clearly is a right. This was 
>>>> accepted and we got
>>>> ************************************************************************* 
>>>> P105 right held by (has right on)
>>>> Domain:        E72 Legal Object
>>>> Range:        E39 Actor
>>>> Superproperty of: P52 has current owner (is current owner of)
>>>> Quantification:        many to many (0,n:0,n)
>>>> Scope note:    This property identifies the E39 Actor who holds the 
>>>> instances of E30 Right to an E72 Legal Object.
>>>>     It is a superproperty of P52 has current owner (is current owner 
>>>> of) because ownership is a right that is held on the owned object.
>>>> P105 right held by (has right on) is a shortcut of the fully 
>>>> developed path from E72 Legal Object through P104 is subject to 
>>>> (applies to), E30 Right, P75 possesses (is possessed by) to E39 Actor.
>>>> Examples:       Beatles back catalogue (E73) right held by Michael 
>>>> Jackson (E21)
>>>> *************************************************************************** 
>>>> 2) Here my view has not been so successful:  I argued that some 
>>>> rights (culture dependent) can be sold and acquired, for example 
>>>> copyrights. However ideal intellectual rights cannot be transfered 
>>>> according to at least the European continental legislation. So there 
>>>> are clearly some rights that cannot be sold in an ideal world. Since 
>>>> these rights are given by the allmighty or a priori (again according 
>>>> to the given cultural  context) it is a question if these should be 
>>>> considered as rights in the CRM. The original motivation of the 
>>>> introduction of the class right is the rights complex problem in 
>>>> museums, that is ownership, copyright and other rights to do thing 
>>>> with objects. The current class has a wider scope.
>>>> My suggestion is that the range of "P24 transferred title of 
>>>> (changed ownership through): E18 Physical Thing" should be 
>>>> lifted/generalised to E72 legal object.
>>>> It is possible to express your example by the use of E5 event of 
>>>> type ownership although I don't like that solution.
>>>> I post this email to the crm sig as well to see if we can get some 
>>>> discussion.
>>>> Christian-Emil
>>>> On 29.01.2010 14:53, Hohmann, Georg wrote:
>>>>> Dear Christian-Emil,
>>>>> we are currently mapping data of our domains to the respective 
>>>>> CIDOC CRM concepts and properties for the WissKI-project. During 
>>>>> this effort we encountered a problem with the mapping of multiple 
>>>>> rights on objects and metadata-documents. We currently can't find a 
>>>>> way to express the history of former rights applied to such objects.
>>>>> As an example:
>>>>> The publishing rights on the "Allgemeine Künstlerlexikon" (AKL) ...
>>>>> ... was held by the publisher "E. A. Seemann" from 1969 to 1990.
>>>>> ... was held by the publisher "K. G. Saur" from 1991 to 2005.
>>>>> ... was held by the publisher "Walter de Gruyter" from 2006 up to now.
>>>>> In our understanding this relationship between an actor and right 
>>>>> can not be expressed using 'P51 has former or current owner' or 
>>>>> 'P52 has current owner'. However, there seems to be no other 
>>>>> solution to connect specific 'E30 Right' to a 'E52 Time-span'. With 
>>>>> the help of almighty Google we found your mail about a similar 
>>>>> issue on the SIG-Mailinglist:
>>>>> http://lists.ics.forth.gr/pipermail/crm-sig/2007-February/000991.html
>>>>> This also seems to be a valid solution for our problem. Did you get 
>>>>> any feedback according to this problem? How did you finally solve it?
>>>>> Best Regards,
>>>>> Georg
>>>> I read through a CRM mapping of the basic Norwegian photo documentation
>>>> standard where ownership and intellectual rights where mapped by P51 
>>>> and
>>>> P105 respectively:
>>>> Ownership, event oriented
>>>> Full path:
>>>> E18 Physical Thing <- P24 Transferred Title of <- E8 Acquisition Event
>>>> -> P22 Transferred title to -> E39Actor
>>>> Shortcut:
>>>> E18 Physical Thing   -> P51 has former or current owner ->  E39 Actor
>>>> *
>>>> Intellectual rights, no event
>>>>    *
>>>> Full path in CRM:
>>>> E72 Legal Object ->P104 Is subject to -> E30Right <- P75Posesses <- 
>>>> E39Actor
>>>> Shortcut:
>>>> E72 Legal Object->P105Right held by-> E39Actor
>>>> According to the CRM one can only own physical stuff (thing forgive 
>>>> me).
>>>> One can only hold rights to abstracts/conceptual objects. This is ok.
>>>> One may also hold rights to physical stuff. Is it possible to imagine
>>>> ownership without a some kind of legal system?  The scope note for E30
>>>> Right: "This class comprises legal privileges concerning material and
>>>> immaterial things or their derivatives". A fair interpretation of 
>>>> "legal
>>>> privileges" includes all types of ownership. So it not unnatural to use
>>>> P105 instead of P51. So should E8 Acquisition be replacedby /be a
>>>> subclass  an "Acquisition of right"  event or the properties adjusted?
>>>> _______________________________________________
>>>> Crm-sig mailing list
>>>> Crm-sig at ics.forth.gr
>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Crm-sig mailing list
Crm-sig at ics.forth.gr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20100309/2a829283/attachment-0001.htm 

More information about the Crm-sig mailing list