Thanks, Mark. These are interesting, but as I read them they mainly
argue *against* using Signatory in this way. (Which makes more sense
to me -- to treat Treaties like any other resource with a title and
related creators/actors.)
At least I now kind of get the issue, although this exception is going
to be difficult to handle in systems because it will not follow the
normal pattern for associating a Group 2 entity with a Group 1 entity.
It will be the only place where a Group 2 entity (authority
controlled) becomes input to a Group 1 data element. It will translate
to $$ in systems development.
*sigh*
kc
Quoting "Mark K. Ehlert" <[email protected]>:
Karen Coyle wrote:
Can anyone explain, or point me to an explanation, for how
"Signatory to a treaty, etc." became defined as an attribute of a
Work, rather than a corporate body with a relationship to a work?
It's the only potential Group 2 entity that has ended up in Group 1
space, so I assume there is something particular about it.
It's too late for me to dig any deeper, but signatories appear to play
two roles, one as creators of treaties (19.2) and another as a Work
attribute (6.22) to characterize like preferred titles for treaties
("Treaties, etc." being the most common, it seems).
Here are some clues to the background behind "Signatory to a treaty, etc.":
<http://www.rda-jsc.org/docs/5m129-169.pdf>: see point 150,
especially under 150.3
<http://www.rda-jsc.org/docs/5ccc1-lcresp-lcfolup-alafolup.pdf>:
pretty much the whole thing
<http://www.rda-jsc.org/docs/5m170-215.pdf>: points 189.2-189.4, then
179.4 and environs
--
Mark K. Ehlert
Coordinator
Minitex
--
Karen Coyle
[email protected] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
