[ICA-EGAD-RiC] Relationships in RiC

[Chris Hurley]

Resending this because it doesn't seem to have got through the first time.

I have no problem with a long list that illustrates a concept.  The RiC 1.0
list of relationships could easily stretch from 792 instances to 7,920 and
beyond.  Thinking up new instances could become a parlour game for
archivists.  My interest is in what principle(s) the instances illustrate.
My suggested categorisation was derived from what is there is RiC 1.0 and
is not what I would have come up with if I'd started with a blank page, so
"something to live with" would indeed be most welcome.  What I mean by
implementation is that, w/o further explanation, one has to infer what the
terms mean and how they might be used.  Taking "creates", for example, and
ignoring for the moment its diverse and often contested meanings (simply
taking it as an unproblematic idea) it can be applied as a relationship
thus:
 [ACTOR A]<creates>[RECORD X]
and this seems to be the how RiC 1.0 means it to be understood.

But all recordkeeping is based on describing action and circumstance and
"creates" is an action which can, therefore, be rendered as a FUNCTION
rather than a relationship (as well as, not instead of).  The descriptive
statement "A creates X" can then be rendered differently within the RiC 1.0
framework, where FUNCTION M = creates, as:
  [ACTOR A]<performs>[FUNCTION M]<to produce>[RECORD X].
It may be that somewhere in the list of possible relations in RiC 1.0 the
option of using this second formulation is already provided for but, if so,
only the diligent will find it and, absent more explanation, some of them
may not understand that these are two allowable ways of achieving the same
result.  I agree, therefore, with those who have argued that it is
important to draw out statements about how relationships are formed from
the list of enumerated possibilities.

In the first formulation, according to RiC 1.0, Date & Place could be
formulated as properties of a relation and also as instances of
Entity-Types in their own right (instead of rather than as well as in any
particular instance, I suppose).  In the second formulation, it would be
easy to link an instance of a Date-Entity and an instance of a Place-Entity
to an instance of Function M.  For those working a formed archive, the
second formulation may seem unnecessarily complex but those involved in
active record-making may encounter '000s of create transactions every day
and a developer might find it a more effective way of reaching the same
outcome (viz. a statement to the effect that "A creates X").  Developers
are clever people and could, no doubt, come up with lots more ways of
achieving the same outcome for every rule, taking account of the differing
needs of their client populations, so long as we provide them with a robust
conceptual framework.

All the best

Chris Hurley
www.descriptionguy.com