[ICA-EGAD-RiC] Entities in RiC

[Chris Hurley]

Confusion between Recordkeeping Entities and Authority Records began with
ISAAR.  This seems an apposite moment to correct the misunderstanding.
Four of the 14 proposed Entities (Documentary Form, Date, Place,
Concept/Thing) could be represented as properties of the ten remaining.
There is no harm in having those four as entities if that is useful (though
the utility eludes me) and many more besides.  In some metadata schemas,
Relationships are nominated as entities, for example.  But, if you’re going
to name four, you should make it clear that many other kinds of entity are
possible and, if you’re going to name those four, you should make it clear
that they can (optionally) be treated as properties.



Alternatively, true Authority Records, like EAC-CPF and SNAC, could be
built for Documentary Form, Date, Place, Concept/Thing, etc., etc. to
control data content of the properties of Recordkeeping Entities.  This
leads on to the question whether we need to stipulate the properties of
Authority Records used in recordkeeping.  The other ten Entities proposed
in RiC 1.0 are true Recordkeeping Entities whose properties can be
controlled by Authority Records of one kind or another (or not, as the user
decides).  These ten entities can be conceptualised as instances (not the
only possible ones) of three basic Entity-Types that are particular to
recordkeeping :

·         DEEDS: events or circumstances that give rise to recordkeeping –
e.g. functions, functions (abstract), activities, mandates, processes,
responsibilities, products, etc.;

·         DOERS: actors who undertake the Deeds - e.g. agents, occupations,
positions, corporations, agencies, processes, persons, families, etc.;

·         DOCUMENTS: memories of Deeds undertaken - e.g. records, record
components, record sets, series*, fonds*, documentary objects, processes,
artefacts, legends, myths, etc.

I deliberately include “process” under all three types to illustrate the
point that the same thing can be described in more than one way, using
different Entity-Types as appropriate.  I have already suggested the use of
Relationship Types and I think using Entity Types is a better way also.



Four properties are common to all Recordkeeping Entity-Types in RiC 1.0
(Global Persistent Id, Local Id, Name, and General Note) and to those I
would wish to add Date (either as a relationship or a property).  Within
the framework of an entity-relationship model, that would satisfy what I
see as the mandatory requirements for all Recordkeeping Entities - viz.
that they possess :

·         IDENTITY: because every record is unique;

·         DATES: because every record is time-bound;

·         RELATIONSHIPS: because no record stands alone.

Other common properties, such as name, are useful but not essential in
recordkeeping.  If I were modelling RiC, I would represent the common
properties as belonging to a Super-Type of the kind I have sometimes called
the URO (Universal Recordkeeping Object), and more facetiously the HERO
(Hurley’s Enduring Recordkeeping Object).  I think a good many more
properties (e.g. Description) could be remodelled as common to all
Recordkeeping Entities and brought into the URO either because they are
already common to all Recordkeeping Entities in RiC or should be.


Other properties might be better handled in other ways, at least as
alternative options.  Some of these are trifling but “Accruals” (P24 & P25)
should be given further thought.  Accruals are part of a Process (viz.
accessioning) and some people might want to document accessions as Record
Sets (or Sub-Sets for incorporation into Sets).  I would.  That suggests
that an option needs to be provided allowing accruals to be treated as
Record Sub-Sets with relationships to Record Sets as part of the history of
the formation of the Set and not merely as a property forecasting future
possibilities.  In the physical world, it was sometimes necessary to manage
Transfers or Deposits as entities (Record Sub-Sets) separately from
Accessions because they comprised one of more Accessions, formed before,
during, or after relocation, and I imagine that similar entities might be
useful during data migrations.

All the best

Chris Hurley
www.descriptionguy.com