Record set definition
96 views
Skip to first unread message
Sophie cote
May 5, 2025, 11:06:55 AMMay 5
to Records_in_Contexts_users
Richard Williamson
May 6, 2025, 4:01:11 PMMay 6
to Records_in_C...@googlegroups.com
Dear Sophie,
Thank you for your question! I will try to offer a few thoughts on how
I think about this; I am sure that the other members of EGAD will
chime in if they see aspects of it differently or have other
perspectives :-).
I tend to think of a Record Set as an 'intellectual aggregation' of
Records. In particular, I think that the following in the RiC-CM Scope
Notes for Record Set is the key to the question about instantiation:
"The member Records in a Record Set may physically reside together,
though physical proximity is not essential". There is a little more
along similar lines in the introductory remarks to section 2.2.2. I
will try to give a few examples.
For one that was in the news recently...
https://www.bbc.com/news/articles/c8x89kw0vg4o
...the Darwin Archive could certainly be considered intellectually as
a single entity (the output of Darwin), i.e. as a Record Set, but, as
is not atypical for personal archives, it is held across numerous
institutions, thus does not really exist as a physical aggregation. As
an aside, one can make very free use of RiC-R024 'includes or
included' with Record Set, i.e. one could regard the part of the
Darwin Archive that is at Cambridge as a Record Set which does have an
Instantiation, and then could say that the Record Set which is the
overall Darwin Archive 'includes or included' the one at Cambridge
(and similarly for all the other parts of it in other places).
For another example (which will be elaborated greatly upon in the
forthcoming 'Application Guidelines'!), the 'records of the Council of
Castile' certainly intellectually makes sense, i.e. could be
considered as a Record Set, but there is no single archival
institution which holds them all; some are at the Archivo General de
Simancas, and others at the Archivo Histórico Nacional in Madrid, for
example.
For a third example, suppose that one wished to express that all
records in a certain collection which had suffered mould damage had
been digitised and destroyed. These records might occur randomly
within the collection, i.e. there may be no sense in which they are in
physical proximity or reflect the aggregating principles of the
original record set. The software which makes the digitisations
available might list all of the records of the original collection in
their original order, with a little icon where a digitisation is
available or something. In this case, there is not really an
Instantiation of the aggregration of exactly those Records which were
digitised, but it may be very useful to refer to this precise
aggregation, i.e. regard 'those records in collection X with mould
damage' as a Record Set. E.g. one might wish to give the date when the
digitisation and destruction took place, record who made the
evaluation of mould damage, etc. All of this could be metadata
attached to this bespoke Record Set.
This third kind of example could be very useful in a record management
context (RiC definitely wishes to make sense and be able to be used
for record management by the way; we are actively working on ways in
which we can tweak things to better facilitate this, some small ones
of which will make it into the next release of RiC-O!). Indeed, I am
very fond of use of 'Activity' in RiC, it can be used for any kind of
record management or archival handling. And when I use Activity like
that, I then tend to make very free use of Record Set, as in the third
example, to denote the result or scope of such activity, without
worrying about whether there is an Instantiation. Even if there is
something which could be regarded as an Instantiation, one does not
have to give metadata for it or refer to it explicitly if one has no
need for that (this goes in fact for Records as well, even though it
is required there that an Instantiation does exist).
I hope this is a little helpful. Just let me know if anything is
unclear or you'd like me to elaborate upon anything. And of course, if
anyone else has thoughts or examples to share, please do chime in!
Best wishes,
Richard
On Mon, May 5, 2025 at 5:06 PM 'Sophie cote' via
Records_in_Contexts_users <Records_in_C...@googlegroups.com>
wrote:
> You received this message because you are subscribed to the Google Groups "Records_in_Contexts_users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to Records_in_Context...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/398e5b3e-2703-4d74-974b-e5dab0fb053fn%40googlegroups.com.
Thank you for your question! I will try to offer a few thoughts on how
I think about this; I am sure that the other members of EGAD will
chime in if they see aspects of it differently or have other
perspectives :-).
I tend to think of a Record Set as an 'intellectual aggregation' of
Records. In particular, I think that the following in the RiC-CM Scope
Notes for Record Set is the key to the question about instantiation:
"The member Records in a Record Set may physically reside together,
though physical proximity is not essential". There is a little more
along similar lines in the introductory remarks to section 2.2.2. I
will try to give a few examples.
For one that was in the news recently...
https://www.bbc.com/news/articles/c8x89kw0vg4o
...the Darwin Archive could certainly be considered intellectually as
a single entity (the output of Darwin), i.e. as a Record Set, but, as
is not atypical for personal archives, it is held across numerous
institutions, thus does not really exist as a physical aggregation. As
an aside, one can make very free use of RiC-R024 'includes or
included' with Record Set, i.e. one could regard the part of the
Darwin Archive that is at Cambridge as a Record Set which does have an
Instantiation, and then could say that the Record Set which is the
overall Darwin Archive 'includes or included' the one at Cambridge
(and similarly for all the other parts of it in other places).
For another example (which will be elaborated greatly upon in the
forthcoming 'Application Guidelines'!), the 'records of the Council of
Castile' certainly intellectually makes sense, i.e. could be
considered as a Record Set, but there is no single archival
institution which holds them all; some are at the Archivo General de
Simancas, and others at the Archivo Histórico Nacional in Madrid, for
example.
For a third example, suppose that one wished to express that all
records in a certain collection which had suffered mould damage had
been digitised and destroyed. These records might occur randomly
within the collection, i.e. there may be no sense in which they are in
physical proximity or reflect the aggregating principles of the
original record set. The software which makes the digitisations
available might list all of the records of the original collection in
their original order, with a little icon where a digitisation is
available or something. In this case, there is not really an
Instantiation of the aggregration of exactly those Records which were
digitised, but it may be very useful to refer to this precise
aggregation, i.e. regard 'those records in collection X with mould
damage' as a Record Set. E.g. one might wish to give the date when the
digitisation and destruction took place, record who made the
evaluation of mould damage, etc. All of this could be metadata
attached to this bespoke Record Set.
This third kind of example could be very useful in a record management
context (RiC definitely wishes to make sense and be able to be used
for record management by the way; we are actively working on ways in
which we can tweak things to better facilitate this, some small ones
of which will make it into the next release of RiC-O!). Indeed, I am
very fond of use of 'Activity' in RiC, it can be used for any kind of
record management or archival handling. And when I use Activity like
that, I then tend to make very free use of Record Set, as in the third
example, to denote the result or scope of such activity, without
worrying about whether there is an Instantiation. Even if there is
something which could be regarded as an Instantiation, one does not
have to give metadata for it or refer to it explicitly if one has no
need for that (this goes in fact for Records as well, even though it
is required there that an Instantiation does exist).
I hope this is a little helpful. Just let me know if anything is
unclear or you'd like me to elaborate upon anything. And of course, if
anyone else has thoughts or examples to share, please do chime in!
Best wishes,
Richard
On Mon, May 5, 2025 at 5:06 PM 'Sophie cote' via
Records_in_Contexts_users <Records_in_C...@googlegroups.com>
wrote:
>
> Hello everyone! I don't know if anyone here could help us... I'm trying to better understand the concept of a Record Set. Has anyone further explained the definition of this concept when implementing the standard? Can anyone give me examples of Record Sets that aren't instantiated? I know that RIC is more focused on describing historical records, but we want to use and adapt it for a Record Management context. Any help is welcome. Thank you for your attention to this request.
>
> --
> Hello everyone! I don't know if anyone here could help us... I'm trying to better understand the concept of a Record Set. Has anyone further explained the definition of this concept when implementing the standard? Can anyone give me examples of Record Sets that aren't instantiated? I know that RIC is more focused on describing historical records, but we want to use and adapt it for a Record Management context. Any help is welcome. Thank you for your attention to this request.
>
> You received this message because you are subscribed to the Google Groups "Records_in_Contexts_users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to Records_in_Context...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/398e5b3e-2703-4d74-974b-e5dab0fb053fn%40googlegroups.com.
Arian Rajh
May 7, 2025, 5:38:00 AMMay 7
to Records_in_Contexts_users
Hm, this invokes a broader question of gradually defining terminology (classes of ontology or description logic concepts). The record set may be a record-centric concept in today's data-centric reality (surveillance capitalism, data gaze - to mention a few terms from the literature), and (potential) archival materials is a broader term. My suggestion, which I presume is not a popular one :), would be to build terminology from atomic concepts to the top (signs, data, information, and so on) because the record is just one of many information forms. Record managers and archival heritage professionals are also focused on databases and other non-documentary forms of information. In our contemporaneity I would say we rely more on data then on records...
Andrew Warland
May 7, 2025, 5:38:04 AMMay 7
to Records_in_C...@googlegroups.com
Hello Sophie
I wanted to wait for someone from the RiC group to respond, thanks Richard.
I would like to provide a response in the context of 'in-place' records management, especially using Microsoft 365. As you know, the traditional model for recordkeeping was to store all related records in a single aggregation, for example a box or a file (or set of files), that 'mapped' to a business function and activity, or terms in a file plan. A simple example would be the function of Financial Management and the activity of 'Budgeting'. Everything about that subject would, in the past, be stored in a logical and accessible aggregation.
In practice, and especially since the introduction of digital records, it has not always been possible to aggregate all the records as it relies on end users to do this. Consequently, not everything relating to a given subject might be stored in the same aggregation; it may remain 'in place', in the Outlook mailbox for example. The widespread adoption of Microsoft 365 with Outlook/Exchange, SharePoint/OneDrive, Teams, Office, Windows, File Explorer and more has resulted in a much more complex environment in which records are likely to remain stored in the storage linked with the application - for Outlook, this is the Exchange Online mailbox. This is where 'in-place' management arises and where, I think, the concepts behind RiC will eventually lead the way.
Most records in Microsoft 365 will be stored in either (a) Exchange Online mailboxes (emails, as well as copies of Teams chats and posts, copies of Viva Engage posts, Copilot engagements etc that are stored in hidden folders), or (b) SharePoint, which includes OneDrive. End users may be unaware that the content they are storing via File Explorer is being synced automatically to their OneDrive. Saving 'files' via Teams chats or channels is actually storing that content in OneDrive or SharePoint.
So, in the digital world, records relating to a given subject may remain 'hidden away' in multiple locations and may not be physically aggregated together in the traditional sense of a single accessible aggregation. Microsoft 365 provides three broad ways to find information that remains 'in-place'.
- End users can search from the main landing page https://m365.cloud.microsoft/ previously https://office.com. Searches from here will retrieve any sites, files, emails, chats, images (with readable text), videos (with transcripts) they have already access to. It's not recordkeeping, but it's a very handy thing to know, to find related information.
- Global admins, or a user assigned to the Compliance Admin role or the eDiscovery Manager role in Purview can conduct either a Content Search or create an eDiscovery case. These will find anything across the workloads, regardless of permissions, that meets the search criteria. eDiscovery allows you to create 'Review sets' which are in some ways not dissimilar to a Record Set, without the RiC elements.
- Microsoft 365 also has its own Graph. The Graph is not designed to do what RiC does; it only works with the (very extensive) back-end metadata contained in the digital content stored in Microsoft 365. This metadata doesn't map exactly to the RiC entities but some of it is the same or similar. The Graph is also not designed for recordkeeping (or RiC) purposes but to support how Microsoft 365 brings things (signals) together, just like the Google, Facebook and many other graphs. Graphs make connections between things via signals and metadata.
I've exchanged messages with Richard on this subject already, and I'm interested to see if and when someone develops a RiC tool that could link with the underlying Microsoft 365 Graph (or use the same signals) to produce details and links about records that are stored 'in-place'. I am confident this is coming, but it might not be until 2030 or afterwards.
Kind regards
Andrew Warland
Melbourne, Australia
On Tue, May 6, 2025 at 1:06 AM 'Sophie cote' via Records_in_Contexts_users <Records_in_C...@googlegroups.com> wrote:
--
Jochen Deprez
May 7, 2025, 6:43:56 AMMay 7
to Records_in_C...@googlegroups.com
Hi Sophie,
Simply put, a Record Set is any "level" of aggregation of records, when comparing it to ISAD(G) descriptions. So, for example, an"archive" level description in ISAD(G) is a Record Set, but so does a "file" level, or a "series" level, or any of its subparts.
A Record Resource is the collection of all records, record parts and records set. You can define and describe this hierarchically like in ISAD(G), or not. That is up to you and this needs to be defined for each separate Record Set (for example with the RiC-R024 'includes or included' relation. You can recreate the hierarchy with relations contained within the RiC-CM and RiC-O standards. Both your descriptions of the Record Sets and relations between them are totally dependent on your desired level of detail and their context. The more detailed the descriptions and relations the better, but sometimes, as information and context is lacking, we are forced to use more general descriptions and more generally defined relations. RiC allows us to specify and describe this granularity, which to me, is one of the biggest evolutions in archival description the standard offers.
Also keep in mind that control notes and authority notes (as established in AtoM, EAD and EAC) are records (and thus Record Types in RiC) in their own right. You can (and should) relate them to the records and instantiations they describe. But it's possible to interpret the collection of all these authority and control notes as a Record Set, with the Record Set Type being a "series", "file" or a type of its own. For me, these types of records come close to a record that isn't necessarily directly related to an instantiation.
My experience with studying RiC is that you can make your implementation of it as simple or complex as you want it or need it to be. It's extensible, so you can expand it at will using Protégé to safeguard its "logic" and "reasoning". My advice is: keep it as simple as possible and gradually expand according to your needs. EGAD is currently working on the RiC-AG documentation, which will hopefully provide us with the "how-to's" and best practices for implementing it in our organisations.
Greetings,
Jochen Deprez - Archival-, Records- and Information manager at DVV Midwest (Belgium)
Op ma 5 mei 2025 om 17:06 schreef 'Sophie cote' via Records_in_Contexts_users <Records_in_C...@googlegroups.com>:
--
Richard Williamson
May 14, 2025, 4:47:25 AMMay 14
to Records_in_C...@googlegroups.com
Thank you very much Arian, Andrew, and Jochen, for a lot of great
points that were missing from my initial reply! Just to emphasise
something that Jochen wrote, if coming from ISAD-G, one can just use
Record Set for Series, File, etc, using the Record Set Type attribute
(RiC-A36) to indicate which it is. But Jochen expresses it much more
nicely :-).
It was great also to discuss a digital example, thank you Andrew! I
just wished to pick up on something Andrew mentioned, that following
his initiative in getting in touch and with guidance from him, I wrote
a working proof-of-concept parser last year which can communicate with
Microsoft 365's Graph API to obtain a RiC description of a Sharepoint
drive (with author data and so on). I have not yet made it public
because I wished to add a few more examples such as email and chat
threads in Microsoft Teams, and alas have been a terrible
correspondent and not had time to properly follow up on it. But if
somebody wishes to actually create an archive with a description in
RiC from something falling under the umbrella of Microsoft 365
(Sharepoint, Teams, ...), it would not be that much work to build upon
the proof-of-concept to do it, and I would be happy to share the code
that I have; feel free to get in touch! This would not be as
comprehensive a piece of software as Andrew envisions, but it would be
usable I think without very much work for relatively simple archiving.
Best wishes,
Richard
> To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/CAE3fQCx7A9j3aW5tQ-qcq41EeM2rEZejb732Z6-u9x76SLTQqQ%40mail.gmail.com.
points that were missing from my initial reply! Just to emphasise
something that Jochen wrote, if coming from ISAD-G, one can just use
Record Set for Series, File, etc, using the Record Set Type attribute
(RiC-A36) to indicate which it is. But Jochen expresses it much more
nicely :-).
It was great also to discuss a digital example, thank you Andrew! I
just wished to pick up on something Andrew mentioned, that following
his initiative in getting in touch and with guidance from him, I wrote
a working proof-of-concept parser last year which can communicate with
Microsoft 365's Graph API to obtain a RiC description of a Sharepoint
drive (with author data and so on). I have not yet made it public
because I wished to add a few more examples such as email and chat
threads in Microsoft Teams, and alas have been a terrible
correspondent and not had time to properly follow up on it. But if
somebody wishes to actually create an archive with a description in
RiC from something falling under the umbrella of Microsoft 365
(Sharepoint, Teams, ...), it would not be that much work to build upon
the proof-of-concept to do it, and I would be happy to share the code
that I have; feel free to get in touch! This would not be as
comprehensive a piece of software as Andrew envisions, but it would be
usable I think without very much work for relatively simple archiving.
Best wishes,
Richard
Sophie cote
May 14, 2025, 2:00:26 PMMay 14
to Records_in_Contexts_users
Hello!
Thank you for this very interesting discussion! I would like to learn more about the relationship between Microsoft graphs and the RIC. Along the same lines of concern related to the implementation of the standard, I was wondering if there was any documentation on updating and maintaining a RIC-based data repository over time, both in terms of management costs (IT infrastructure, human resources, etc.) and the process of keeping the data and their relationships up-to-date.
Thank you, and have a good day everyone!
Thank you for this very interesting discussion! I would like to learn more about the relationship between Microsoft graphs and the RIC. Along the same lines of concern related to the implementation of the standard, I was wondering if there was any documentation on updating and maintaining a RIC-based data repository over time, both in terms of management costs (IT infrastructure, human resources, etc.) and the process of keeping the data and their relationships up-to-date.
Thank you, and have a good day everyone!
Reply all
Reply to author
Forward
0 new messages