eduKateSG · Why Science?
Find the right open repository, then verify the research object at its source
Use OpenDOAR records, inclusion criteria, editorial review, repository types, subjects, policies and APIs to build trustworthy open-research routes.
Universities, research institutes and subject communities publish articles, theses, datasets, software and other scholarly outputs through repositories. OpenDOAR helps readers discover those repositories through a curated global directory.
Jisc describes OpenDOAR as a directory of quality-assured open-access repositories. Its editor reviews repositories and update requests against published inclusion criteria. The directory describes repositories; it does not become the publisher or file host for everything they contain.
Did you know? OpenDOAR inclusion requires a repository to demonstrate real open scholarly content rather than offering only abstracts, previews or external links. This makes the directory record useful evidence about the repository service, while item-level appraisal still happens at the destination.
This guide shows how to move from directory search to a repository record, policy pages and finally the exact research object. The goal is a route another learner can repeat without confusing a repository listing with a paper, dataset or quality verdict.
Chapter index
Chapters 1–9: directory scope, curation and record fields
- 1. OpenDOAR is a repository directory
- 2. Editorial review supports record trust
- 3. Inclusion criteria define scope
- 4. Repository and journal are different services
- 5. Aggregators are not repository owners
- 6. A repository record summarises identity
- 7. Repository type shapes expectations
- 8. Subject labels support browsing
- 9. Repository URLs need current checks
Chapters 10–17: inclusion, policies, APIs and source verification
- 10. Updates pass through editorial review
- 11. Metadata policies govern description reuse
- 12. Data policies govern full items
- 13. Content policies describe deposits
- 14. Submission policies explain provenance
- 15. Preservation policies explain continuity
- 16. API data needs current documentation
- 17. Repository literacy supports open-science careers
A repository directory is useful when its inclusion rules and record provenance stay visible. The service organises records about repositories that provide open academic outputs and resources. It is not a general article index and does not claim ownership of hosted items. This helps a learner distinguish a quality-assured directory from a search engine or content host.
Try this
Evidence question: Are you looking at a directory record or a repository item? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Label both pages and keep their URLs separate. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for opendoar is a repository directory, its identifier or version context, and one limit that must remain visible.
Directory metadata can point to open scholarship, but the repository remains responsible for the actual items. OpenDOAR says each listed repository is reviewed and curated by its editor. Review supports reliable directory description but cannot certify every new deposit. It also shows how repository infrastructure supports open science.
Try this
Evidence question: What did directory curation evaluate? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: State the repository-level evidence without extending it to every item. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for editorial review supports record trust, its identifier or version context, and one limit that must remain visible.
Editorial review improves trust in a listing without certifying every object held by that repository. Published criteria require free access, no mandatory login for open materials, complete content and reliable accessibility, while allowing some embargoed or metadata-only entries. The source record remains the place to verify files, rights and version details.
Try this
Evidence question: Which criterion is demonstrated by this repository? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Open several items and document what is actually accessible. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for inclusion criteria define scope, its identifier or version context, and one limit that must remain visible.
CHAPTER 4 OF 17 · Understand the directory
4. Repository and journal are different services
Policies become practical when access, reuse, deposit and preservation terms are read separately. OpenDOAR excludes electronic journals and portals that merely gather a portfolio of journals. A repository collects scholarly outputs under a deposit and preservation model. A reproducible route therefore records both the directory entry and the repository destination.
Try this
Evidence question: Does this site publish a journal or preserve deposited outputs? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Read the about and policy pages before classifying it. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for repository and journal are different services, its identifier or version context, and one limit that must remain visible.
A repository directory is useful when its inclusion rules and record provenance stay visible. A service that only links to content elsewhere does not meet the directory definition of a repository. This prevents a chain of links from being mistaken for custody. This helps a learner distinguish a quality-assured directory from a search engine or content host.
Try this
Evidence question: Where are the files actually held? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Follow one item to its download host and record the domain. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for aggregators are not repository owners, its identifier or version context, and one limit that must remain visible.
CHAPTER 6 OF 17 · Read a repository record
6. A repository record summarises identity
Directory metadata can point to open scholarship, but the repository remains responsible for the actual items. Records can show repository name, organisation, URL, country, type, subjects and policy links. Fields may change when institutions rebrand or platforms move. It also shows how repository infrastructure supports open science.
Try this
Evidence question: Which organisation currently operates this repository? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Compare the directory record with the repository’s own about page. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for a repository record summarises identity, its identifier or version context, and one limit that must remain visible.
Editorial review improves trust in a listing without certifying every object held by that repository. Institutional, disciplinary, governmental and aggregating contexts serve different communities and deposit policies. A type label guides discovery without determining the quality of an item. The source record remains the place to verify files, rights and version details.
Try this
Evidence question: What population of outputs should this repository contain? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Write a one-sentence scope based on the repository policy. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for repository type shapes expectations, its identifier or version context, and one limit that must remain visible.
Policies become practical when access, reuse, deposit and preservation terms are read separately. Broad subject categories help locate disciplinary repositories. Cross-disciplinary records and local terminology can make a single label incomplete. A reproducible route therefore records both the directory entry and the repository destination.
Try this
Evidence question: Which subjects are explicit and which are inferred? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Use the listed subject for discovery, then verify item keywords at source. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for subject labels support browsing, its identifier or version context, and one limit that must remain visible.
A repository directory is useful when its inclusion rules and record provenance stay visible. A directory link should resolve to the repository, but platforms, domains and redirects can change. OpenDOAR provides a route to report errors. This helps a learner distinguish a quality-assured directory from a search engine or content host.
Try this
Evidence question: Does the listed URL reach the current service? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Test the link and note any redirect before sharing it. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for repository urls need current checks, its identifier or version context, and one limit that must remain visible.
Directory metadata can point to open scholarship, but the repository remains responsible for the actual items. Repository managers can report changes, and OpenDOAR says its editor reviews and verifies requested updates. This creates a correction path for directory metadata. It also shows how repository infrastructure supports open science.
Try this
Evidence question: Is the inconsistency in OpenDOAR or the repository? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Capture evidence and use the appropriate correction channel. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for updates pass through editorial review, its identifier or version context, and one limit that must remain visible.
CHAPTER 11 OF 17 · Check access and policy
11. Metadata policies govern description reuse
Editorial review improves trust in a listing without certifying every object held by that repository. Repository policies can state who may access and reuse metadata and what attribution or linking is required. Metadata rights can differ from rights in full items. The source record remains the place to verify files, rights and version details.
Try this
Evidence question: What may be reused from the catalogue record? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Quote the policy category and record the original identifier. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for metadata policies govern description reuse, its identifier or version context, and one limit that must remain visible.
Policies become practical when access, reuse, deposit and preservation terms are read separately. An open-access repository policy can distinguish viewing, copying, educational use and commercial reuse. The actual item licence remains decisive where stated. A reproducible route therefore records both the directory entry and the repository destination.
Try this
Evidence question: Which permission applies to this file? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Check both repository policy and item-level licence. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for data policies govern full items, its identifier or version context, and one limit that must remain visible.
A repository directory is useful when its inclusion rules and record provenance stay visible. Policies may describe accepted document types, subjects, peer-review status and publication status. Presence in a repository does not imply formal peer review. This helps a learner distinguish a quality-assured directory from a search engine or content host.
Try this
Evidence question: What status is declared for this item? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record document type and review status rather than assuming them. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for content policies describe deposits, its identifier or version context, and one limit that must remain visible.
Directory metadata can point to open scholarship, but the repository remains responsible for the actual items. A policy can identify eligible depositors, responsibilities and checks. Repository administration may screen metadata or rights without reviewing scientific validity. It also shows how repository infrastructure supports open science.
Try this
Evidence question: Who deposited the object and what was checked? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Separate deposit validation from scholarly peer review. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for submission policies explain provenance, its identifier or version context, and one limit that must remain visible.
Editorial review improves trust in a listing without certifying every object held by that repository. Policies can address backups, file retention, withdrawal, tombstone pages and updated versions. A preserved identifier supports history when content changes or is removed. The source record remains the place to verify files, rights and version details.
Try this
Evidence question: What happens if this item is withdrawn? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Find the preservation or withdrawal statement before relying on permanence. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for preservation policies explain continuity, its identifier or version context, and one limit that must remain visible.
Policies become practical when access, reuse, deposit and preservation terms are read separately. OpenDOAR developer guidance points users to Jisc’s current API platform and authentication practices. Programmatic retrieval must record fields, pagination, update date and terms. A reproducible route therefore records both the directory entry and the repository destination.
Try this
Evidence question: Which API and schema produced this record? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Log the endpoint and request without exposing credentials. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for api data needs current documentation, its identifier or version context, and one limit that must remain visible.
CHAPTER 17 OF 17 · Follow the source
17. Repository literacy supports open-science careers
A repository directory is useful when its inclusion rules and record provenance stay visible. Librarians, repository managers, archivists, research administrators and developers maintain access, policy and preservation routes. This helps a learner distinguish a quality-assured directory from a search engine or content host.
Try this
Evidence question: Which role would fix a broken record or ambiguous licence? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Create a handover note from directory discovery to item verification. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for repository literacy supports open-science careers, its identifier or version context, and one limit that must remain visible.
Contents · Previous chapter · Continue at the Science Learning Hub
A trusted directory is the beginning of the evidence route
OpenDOAR helps learners locate repositories whose services meet published open-access inclusion criteria. Its curated records make repository discovery more dependable while leaving item-level evidence with the source repository.
Save the OpenDOAR record, repository URL, organisation, type, subjects, relevant policies, item identifier, licence, version and access date. Then inspect the actual file and method before using it in an argument.
| Reading object | What it can support | Question to keep visible |
|---|---|---|
| Directory record | Description of a repository service | Is the organisation and URL current? |
| Inclusion criteria | Repository-level eligibility rules | What do they establish and what remains untested? |
| Repository policy | Access, reuse, deposit or preservation terms | Does an item-level licence override or refine it? |
| Source item | Actual scholarly object and files | Which identifier, version and status apply? |
Sources and next reading
Substantive resource claims in this article were checked against the primary pages below. A structured record is a route into evidence; it does not by itself prove a scientific conclusion. Recheck the live record, evidence labels and release context before using it in assessed work or research.
For a classroom enquiry, save a short research receipt containing the question, search terms, selected object, exact identifier, version, access date and the evidence boundary you observed. Add the file or page that supports each statement. This small routine turns browsing into accountable science learning and gives a teacher, classmate or future analyst a route they can independently follow.
Before sharing the conclusion, ask another reader to retrace the route without verbal hints. If they reach a different version, file or interpretation, improve the receipt and narrow the claim. Reproducibility begins with this practical check. It teaches careful reading, supports fair collaboration and keeps uncertainty visible while evidence moves from an online service into notes, analysis and a final explanation.
A useful final review separates five questions. What object was found? Which organisation or repository maintains it? What exact evidence was inspected? Which statement does that evidence support? What remains uncertain? Answer each question in one sentence, then connect every answer to a visible field, file or source page. This review catches common mistakes: citing a collection when a file supplied the value, treating the newest release as the analysed release, confusing permission with scientific suitability, or turning a discovery count into a conclusion. It also gives students a calm way to improve work. A missing detail becomes a next research step instead of an invitation to guess. When the route is complete, the final explanation can stay simple because the identifiers, dates, versions, limitations and supporting evidence are already organised underneath it.
Primary sources
- About OpenDOAR — accessed 25 October 2026.
- OpenDOAR inclusion criteria — accessed 25 October 2026.
- Managing repository records — accessed 25 October 2026.
- OpenDOAR policy support — accessed 25 October 2026.
- OpenDOAR developer guidance — accessed 25 October 2026.