Issue 185: Missing property declaring the pattern of an identifier assignment

Perhaps we need an additional property, which would follow the same pattern as P136 (E83 Type CreationP136 was based on (supported type creation) E1 CRM Entity). This additional property could be declared as follows: E15 Identifier Assignment P was based on (supported identifier assignment) E1 CRM Entity. In library practice, librarians record in their authority files the sources that motivated them to assign a controlled form of name or title to a given actor or work.

Besides, the constituents used in instances of E15 Identifier Assignment include numerical values. Since E60 Number is not a subclass of E1 CRM Entity, an instance of E60 Number cannot be P1 identified by an instance of E41 Appellation. This difficulty can be solved by either: a) declaring E60 Number as a subclass of E1 CRM Entity (which I guess will not be deemed acceptable), or: b) declaring an additional property: E15 Identifier Assignment P... used constituent (was used in) E60 Number. The first solution, although presumably unacceptable, would nevertheless present the advantage of making it possible to use the P139 property for notational symbols for numbers: "XIV" P139 has alternative form "014" P139.1 has type "Arabic notation with three digits". For instance, the National Library of France creates such identifiers for popes: "$a Jean $u 23 $h XXIII $e pape $d 1881-1963". Such an E15 Identifier Assignment makes use (P142) of three instances of E41 Appellation ("Jean", "pape", and "1881-1963"), and two alternative notational symbols for one instance of E60 Number ("23" in Arabic notation with two digits, "XXIII" in Roman notation). Subfield $u is used for filing purposes, subfield $h for displaying purposes.

Patrick Le Boeuf 

Helsinki 28/1/2010