Academic/organizational context

[osma]

Many academic documents, in particular theses but also reports, include information about the school, faculty, department, degree program etc. under which the document was created. This is not easy to represent using DC. In some cases, the organization can be seen as a Publisher; in other cases, it could be some kind of a Contributor; degree programs and academic disciplines can be seen as a kind of Subject. But many of these seem to be stretching the scope of DC fields a little bit.

The FinGreyLit metadata schema includes these fields, which are ad-hoc specializations of DC properties:

• dc.contributor.department The department that contributed to or approved the publication.
• dc.contributor.faculty The faculty that contributed to or approved the publication.
• dc.contributor.organization The organization that contributed to or approved the publication.
• dc.contributor.orgunit The organizational unit within an organization that contributed to or approved the publication.
• dc.relation.contractor The entity with which a contract or agreement is related. Used for theses commissioned by e.g. a company or public sector organization.
• dc.subject.degreeprogram The degree program associated with the document. Used for theses, including doctoral theses.
• dc.subject.discipline The academic discipline or field of study to which the resource relates.

Jan posted this to the DC-SRAP list on 2024-01-25. It's about affiliations in MODS, and affiliation is a separate issue #3 , but the structuring can also be useful when talking about organizational context:

1. I said I would look at how MODS allows for structured corporate bodies associated with theses

We had a request from the Bodleian library in the UK with a requirement for structured affiliations. After much discussion we recommended that they incorporate their own schema within a MODS affiliation. I know we are not specifically talking about affiliations but the units in the structuring of the institution may be helpful.

<!-- Affiliations  For multiple affiliations, create a separate ora:affiliation for each affiliation   -->
<affiliation>       
           <ora:affiliation xmlns:ora="http://ora.ox.ac.uk/terms/">
               <ora:affiliationComponent type="institution" institution_id="field:contributors__institution_identifier">field:contributors__institution</ora:affiliationComponent>
               <ora:affiliationComponent type="division">field:contributors__division</ora:affiliationComponent>
               <ora:affiliationComponent type="department">field:contributors__department</ora:affiliationComponent>
               <ora:affiliationComponent type="sub_department">field:contributors__sub_department</ora:affiliationComponent>
               <ora:affiliationComponent type="research_group">field:contributors__research_group</ora:affiliationComponent>
               <ora:affiliationComponent type="sub_unit">field:contributors__sub_unit</ora:affiliationComponent>
               <ora:affiliationComponent type="oxford_college">field:contributors__oxford_college</ora:affiliationComponent>
           </ora:affiliation>
<affiliation>

I think that SRAP could recommend a similar sub-structure for dct:contributor that includes organizational structure.

[kcoyle]

I see a real difference between describing a scholarly resource and describing affiliation details. Affiliation is not a quality of the resource, but of the contributor at that moment in time. Thinking about functionality, these separate components of affiliation do not appear to me to have viable processing functions, as most of them would be strings and there is no standard for how they are written.

We aren't proposing detailed information about persons - which could include birth and death dates, birth places, educational history, awards, etc etc. We just have a name and/or an identifier for the person, presumably as found on the resource. For affiliation, the question is whether you are transcribing the affiliation information from the resource or if you expect catalogers to do research. I suspect that only the former is reasonable, and that the affiliation will therefore be a string that may not be consistent across resources (just as names are not).

I do think we should look at a number of examples. I'll add some to the G-Doc.

[osma]

Alasdair: RDA Unconstrained properties don't have anything suitable for linking from a thesis to the department. There is isStudentAt but that's for linking the creator to the department, not the work.

[freddy-sumba]

Building on the insightful discussions in this thread, I propose a nuanced approach to encapsulate academic and organizational contexts within metadata. Recognizing the complexities of diverse institutional hierarchies and the challenges in standardizing such details, my suggestion is to enhance the dct:contributor schema. This entails introducing a structured yet adaptable affiliation model that leverages both Dublin Core and SPAR Ontologies, providing a comprehensive representation of affiliations.

dct:contributor
rdf:Description
rdf:valueDr. Jane Doe</rdf:value>
<dct:role rdf:resource="http://purl.org/spar/pro/Author"/>
dct:affiliation
rdf:Description
dct:titleUniversity X</dct:title>
dct:partOfScience Faculty</dct:partOf>
<vivo:AcademicDegree rdf:resource="http://example.org/Doctorate"/>
</rdf:Description>
</dct:affiliation>
</rdf:Description>
</dct:contributor>