IDN Catalogue Profile - Specification

Abstract ↑

This is the formal data model specification of the IDN Catalogue Profile which is a "profile" of schema.org, DCAT, the Data Catalog Vocabulary and PROV-O, the Provenance Ontology.

Where schema.org is a general-purpose of data elements for documenting Internet resources, DCAT is designed for the representation of data catalogues and their content in general, and PROV-O for representations of provenance in general, this profile aims to cater for the enhanced representation of Indigenous data and its governance concerns.

The rules - "Requirements" - of this profile set conventions for the use of schema.org, DCAT & PROV and some other common models, such as DCTERMS, but no new model elements are introduced.

The Requirements mandate specific values to be used for particular model predicates. The specific values are to be drawn from vocabularies that are referenced in the Vocabularies Section.

Parts

You are now reading the Specification part of the IDN Catalogue Profile which defines the metadata model, but there are other parts too, that provide model mappings, further examples, machine-readable forms of the model and so on.

See the IDN Catalogue Profile Definition for a listing of all the parts.

Namespaces ↑

This document refers to elements of various ontologies by short codes using namespace prefixes. The prefixes and their corresponding namespaces' URIs are:

Conformance ↑

The key words MAY, MUST, MUST NOT, and SHOULD are to be interpreted as described in RFC2119.

The Examples in this document are snippets of RDF data formulated according to the Turtle syntax.

1.1 Purpose ↑

What is the purpose of this Profile?

To improve the representation of Indigenous data's metadata and governance information.

Common catalogue models provide lots of possible metadata elements which can be used to describe catalogued items, to categorise them, indicate how they are managed and so on but don't specifically handle Indigenous concerns.

This profile's ultimate aim is to improve Indigenous person's agency in relation to data by or about them and Indigenous things by:

• improving the identification of data as being about Indigenous people and/or things
• explicitly linking Indigenous data to all the persons and organisations related to it
• explicitly linking Indigenous data to all the policies that affect it

This Profile is just a recommendation to use a common catalogue model - DCAT, the Data Catalog Vocabulary - in particular ways which are called patterns - see the Patterns Section below.

1.2 Basic Use ↑

What does basic use of this profile look like?

Figure 2: This profile requires basic use of the DCAT model's elements for cataloguing with model elements from several other models for classification and relating catalogued resources to people and organisations. This is all common DCAT practice.

This IDN Catalogue Profile builds on the DCAT, the Data Catalog Vocabulary, which requires Catalog instances to contain Resource instances, and some DCAT-recommended ways of expressing relationships from resources to people & organisations - Agents - using PROV, the Provenance Ontology. Resources can be categorised using vocabulary terms defined using SKOS, the Simple Knowledge Organization System and a few special relationships are recommended to link resources to policies, such as data governance policies and licenses.

To cater for Indigenous data governance concerns, this profile recommends the use of the IDN Data Agent Database when referencing Persons or Organisations. Use of specific Concept vocabularies to classify Resource instances are also recommended.

So, when using regular DCAT, you might indicate that a Resource was created by a person identified by an ORCID, an international researcher identifier, using this profile you might indicate the creator using an identifier from the Indigenous Data Network's Agents Database which stores additional Indigenous-relevant information about people and groups.

Also, when using DCAT, you might just indicate the theme of data by classifying a Resource with a Fields of Research Code. When using this profile you might still do that but might also select a more nuanced Indigenous research topic from the IDN Themes vocabulary.

In addition to requiring the use of some DCAT-promoted patterns over others and recommended use of particular reference catalogues & vocabularies, this profile also constrains the ways in which several other DCAT properties should be used. All the constraints are still normal DCAT-style constraints.

1.3 Minimum Metadata ↑

What minimum elements are required?

For the cataloguing of resources according to this profile, we need at least the following information:

A catalogued resource with minimal metadata:

• Tjukinya
  • original TROVE record at https://trove.nla.gov.au/work/10128420

For this resource we have only:

It has a simple title, brief description and a few Agents (organisations & persons) associated with it. This item is easily understood to be Indigenous as it is themed with an indigenous language - Pitjantjatjara - and controlled access is indicated.

This item will gain some form of FAIR and CARE scores, but they could be improved: see the next section.

1.4 All Elements ↑

What are all the recommended elements?

In general, all the metadata elements that can be used in accordance with this profile are those of the DCAT specification. DCAT contains lots of attributes for lots of purposes, so most resources will not sensibly use all of them.

More specifically, there are other schemes, including profiles of DCAT, that recommend specific elements for use, beyond those listed in the previous section.

Here we make two specific recommendations for particular DCAT metadata elements:

1. Australian government-aligned metadata
2. Maximal Indigenous content representation

1.5 Scoring

In addition to the metadata model constraints placed on generic data catalogue models to improve Indigenous data representation, this profile also indicates how to calculate several "scores" - metrics - for aspects of catalogued resource.

The most well-known of these is scores is the FAIR score, based on the FAIR Principles which indicate the findability, accessibility, interoperability and reusability of data. The CARE score is facilitated is the first known metric-ification of the CARE Principles for Indigenous Data Governance.

This profile also specifies a Data Governance Distance score, see the B.3. Data Governance Distance annex. for details

The purpose of including these scores in this profile is to allow profile users to calculate, or have calculated for them, metrics which can be used to measure resource Indigenous data governance improvement. For example, a catalogue of many resources might initially have an average CARE score of X and wish to improve that to Y. By reviewing how the scores are calculated, the catalogue manager might be able to implement this change.

Annex B details how scores work in general, how they are calculated from this profile's metadata, and how to record score results alongside other resource metadata.

1.6 Vocab Values

For catalogued objects, it is important to use well-defined and preferably common reference values for categorisation in metadata for maximal understanding. For example, if you are trying to ensure as many people as possible understand that a catalogued information object is about Indigenous people, you could categorise it with the concept About Indigenous People.

That concept is explicitly defined to indicate that something it is assigned to is "about Indigenous people" making understanding easy, as opposed to something related that may be ambiguous. For example, if the categorisation "Indigenous" was used for an object, it may be about Indigenous people, or Indigenous things or native Australian plants etc.

Additionally, that concept is de-referencable - when clicked the link to it above resolves to more information - and published with a set of other vocabularies all about Indigenous Australian concerns.

The Indigenous Data Network published a reference catalogue of vocabularies for metadata use:

• IDN Vocabularies

some particular vocabularies of interest there are:

• Data Indigeneity - The ways in which data may have a connection to Indigenous people
• IDN Themes - The Indigenous Data Network's general-purpose vocabulary of thematic terms for indigenous data
• IDN Role Codes - The roles that Agents - People and Organisations - play in relation to data

We recommend that IDN vocab terms be used as much as possible for metadata according to this profile. If a term you expect and need is missing from an IDN vocabulary, please contact the IDT to have it added.

1.7 Tools

There are a number of tools provided to help people use this metadata profile. In particular:

• Metadata Entry Tool - online form that can create IDN CP metadata and calculate scores
• IDN CP Validator - a SHACL RDF data validation file that can be used to check conformance of metadata to this profile

Additional tools are the IDN's demonstration, vocabularies and spatial reference data catalogues that provide examples and reference data elements that can be used in the creation of new records.

See the IDN's catalogue of catalogues to see all the catalogues that may be of help.

1.8 Format ↑

What data formats can I use for this metadata?

This uses the same machine-readable data structure used by DCAT and schema.org: Resource Description Framework (RDF).

RDF is widely supported by tools and available in multiple formats, in particular:

• Turtle - the native RDF syntax
• JSON and JSON-LD - a JSON syntax some developers prefer
• JSON and RDF/XML - an XML syntax

It's critical that metadata is supplied in one of the RDF syntaxes, or able to be converted to it, so that it can be validated with this profile's supplied validators - see the Validation Section.

Here are the contents of the Tjukinya resource shown in the Minimum Metadata section above expressed in Turtle, JSON-LD & RDF/XML.

2.1 Identifiers ↑

This Profile relies on web address-style identifiers for things, so you will need to provide, or ask us to create, something like this:

• https://data.idnau.org/pid/2975ec4e-518f-4a09-8e6d-38bad64728a3

That is the identifier for the Welcome to Country: A travel guide to Indigenous Australia dataset which, when clicked, will redirect to the catalogue entry for it on one of the Indigenous Data Network's systems.

2.1.1 Existing Identifiers

If you already have a web address identifier for your data, use that. For example, "Australian First Nations response to the pandemic: A dramatic reversal of the 'gap'" (2021) already has Digital Object Identifier https://doi.org/10.1111/jpc.15701, so we continue to use that identifier. Just note that in cases like this, the identifier will redirect somewhere else.

If you have a non web address identifier, try and use it to create a web identifier. For example, if your organisation IDs a dataset as ABC123, then you could create the IDN identifier of https://data.idnau.org/pid/ABC123 whcih preserved the original ID part but would redirect to an online catalogue entry.

It is also possible to use existing web addresses as identifiers for Organisations and Persons. See the guide to Agent Patterns for examples that use addresses from the Research Organization Registry (ROR) and the Open Researcher and Contributor Identifier (ORCID) registry.

2.2 Indigeneity ↑

Indigeneity, or "Indigenous-ness", is important to the data and people and organisations related to the data. The IDN's reference Data Indigeneity vocabulary provides values that should be used to indicate the indigeneity of data whereas the Organisations Indigeneity vocabulary and the Indigenous Status of Persons vocabulary should be used for Organisations & Persons, respectively.

2.3 Roles ↑

All Agents, that is Organisations & People, associated with resources such as datasets in IDN metadata need to have their role defined.

The roles we start with are those defined in the well-known ISO's Role Codes vocabulary.

This vocabulary contains standard roles such as:

• author
• co author
• custodian
• point of contact

To this vocabulary, we have added:

• subject agent
• subject agent representative

Some of these roles are present in the Full Example below.

In the technical versions of the examples below, you will see how pairs of Roles and Agents are grouped together in metadata so multiple Agents and Roles may be described for a single resource.

2.4 Agents ↑

Agents are persons or organisations - things with agency that can have a role to play with respect to catalogued resources.

All Agents referred to in IDN metadata MUST be identified with a persistent identifier and SHOULD be registered within the IDN Data Agents DB.

So, instead of referring to a person like this:

<http://example.com/resource/x> a dcat:Resource ; dcterms:creator "John Smith" ; # a literal string used for their name .

you must refer to them like this:

<http://example.com/resource/x> a dcat:Resource ; dcterms:creator <http://example.com/person/john-smith> ; # an identifier .

When registered in the AgentsDB, Agents are given a persistent identifier web address. Such identifiers may have been created elsewhere, or may be assigned by the Data Agents DB.

For example, here is the persistent identifier for the University of Melbourne:

• https://linked.data.gov.au/org/uom

This identifier resolves - you can click on it and go to a web page - and it has been assigned by a party other than the IDN, in this case, the Australian Government Linked Data Working Group, which is a source for many organisational persistent identifiers.

This identifier is present in the Example Appendix below.

Here is an example of an identifier for an Organisation supplied by the IDN:

• https://data.idnau.org/pid/org/agilwg - Australian Government Indigenous Locations Working Group

Note the use of the IDN's namespace, https://data.idnau.org/.

If you enter a new Organisation or Person into the Data Agents DB, you will automatically be assigned a new persistent identifier of this form unless you quote an existing one.

2.5 Dating ↑

For Created & Modified and all other dates, you are free to use any one of the following formats, but you do have to pick one and not make up your own format:

Please do not use junk values like 00:00:00 for time when you don't know it, instead select a format that effectively conveys what you do know about the data.

2.6 Theming ↑

Theming is open-ended categorisation of a resource by linking it to concepts in categorisation vocabularies or to text keywords. When using the DCAT model, the predicate dcat:theme is used and should indicate a controlled term in a vocabulary. When using the schema.org model, the predicate schema:keywords (note the 's') should be used and may indicate plain text as well as controlled terms.

While it may be tempting to just theme a resource with words such as "Aboriginal" or "Wiradjuri", and this is better than not doing so, better yet is to use terms from vocabularies, in particular the IDN's reference vocabularies, as these have definitions.

The IDN's main, general-purpose, categorisation vocabulary is the IDN Themes vocabulary. and this should be used as much as possible. Within that vocabulary are collections of concepts grouped based on sub-theme or term origin, so if you're used to, for example, APAIS terms, you can draw from that collection.

In addition to contemporary terms, this vocabulary has archaic ones no longer recommended for use, such as "Aborigine". This allows old metadata records to be understood.

Since there is hierarchy in the IDN Themes vocab, you should always categorise a resource with the most specialised term you can, knowing that the vocabulary will automatically categorise the resource with relevant more general terms.

For example, if you state that a resource is categorised as Cultural burn, it will be understood that the resource is generically also categorised as First Peoples land management.

These two terms come from different vocabularies but the IDN Themes vocabulary has placed them in relation to one another, allowing for this kind of reasoning.

Example: A fictional resource, themed with several vocabulary terms and textual keywords <http://example.com/resource/x> a dcat:Resource ; dcterms:title "Resource X" ; ... dcat:theme <https://linked.data.gov.au/def/nrm/c9f1f747-3677-5e72-aac0-b49733ea4629> , # "Cultural burn" from the IDN Themes vocab <https://linked.data.gov.au/def/policy/5cc52a34-77c0-4589-91c6-7dabb6b65761> , # "First Peoples land management" (implied) <https://vocabularyserver.com/apais/xml.php?skosTema=13> ; # "Aboriginal history" ... .

2.7 Policies ↑

The policies that affect data resources greatly impact the status of Indigenous data governance, therefore a link from a resource to each policy known to affect it should be stated explicitly when known.

For example, resources in the Indigenous Studies Unit's catalogue are known to be managed in accordance with the University of Melbourne's Collections Policy, so this is indicated for every resource in the catalogue like this:

Example: The ISU's Law: The Way of the Ancestors resource and a link to a policy <https://data.idnau.org/pid/762463a4-f8b1-4eec-a335-3689c8d86e9e> a dcat:Resource ; schema:name "Law: The Way of the Ancestors" ; ... odrl:hasPolicy <https://data.idnau.org/pid/MPF1309> , # "Collections Policy", identified with its ISU catalogue ID ... .

Some policies affecting ISU catalogued content are listed as resources in the ISU's catalogue too:

• Aboriginal and Torres Strait Islander Cultural Heritage Policy
• Collections Policy
• Human Remains and Burial Artefacts Policy
• Research Data Management Policy

Organisations should explicitly identify all policies affecting their data and catalogue them if not already done. They should then link their resources to them, as above.

NOTE: In the future, it is hoped that machine-readable versions of policies can be made available, so that the details of how policies affect Indigenous data resources can be automatically understood. While we are not there yet, identifying and linking resources to policies, as above, is the first major step to that future.

2.8 Language ↑

Where a Resource includes text or spoken Indigenous languages, the Resource metadata SHOULD indicate this with languages selected from the AustLang vocabulary

Example: A resource in an Indigenous language <https://www.youtube.com/watch?v=tEdweyPh-N8> a dcat:Resource ; dcterms:title "Mitch Tambo performs John Farnham's You're the Voice in Gamilaraay language" ; ... dcterms:language <https://data.idnau.org/pid/austlang/D23> ; # AustLang's Gamilaraay / Gamilaroi / Kamilaroi ... .

See patterns under 2.6 Theming where the Resource is about an Indigenous language. Note that a Resource may be both about Indigenous language and written / spoken in Indigenous languages.

2.9 Provenance ↑

The provenance of objects are facts about their origins. As used in this profile, provenance links resources to their sources - perhaps also catalogued resources - links resource to the agents who have roles to play with respect to them and activities, e.g. project, that created them.

Provenance information can be critical in describing the context of resource needed to understand them.

Direct metadata properties such as dcterm:creator are provenance properties, but they will not be discussed further here as they are part of basic metadata - see Basic Use.

As per DCAT (and this example), this profile requires that provenance information be formulated according to the PROV-O: The PROV Ontology.

One frequent case for the use of provenance according to PROV-O is for qualified attribution where a resource is associated with an Agent with a specified role. Some direct DCAT and schema.org catalogued resource metadata properties include roles, such as dcterms:publisher which includes the role 'publisher' but there are many possibly significant roles that do not have such properties.

See the Agents section for a listing of roles.

Here is an example of a resource's qualified attribution to Agents with role not expressible in direct DCAT / schema.org properties:

Example: Provenance of qualified attribution <https://data.idnau.org/pid/resource/debd1b90-aeb4-403e-82fc-7db7c474b2fd> a dcat:Resource ; dcterms:title "Yirrkala LPC Dataset" ; ... prov:qualifiedAttribution [ prov:agent <https://linked.data.gov.au/org/uom> ; # University of Melbourne dcat:hadRole <https://def.isotc211.org/common/RoleCode/custodian> ; # Custodian ] , [ prov:agent <https://orcid.org/0000-0002-1398-7524> ; # Kristen Smith dcat:hadRole <https://def.isotc211.org/common/RoleCode/pointOfContact> , # Point of Contact <https://def.isotc211.org/common/RoleCode/principalInvestigator> ; # Principle Investigator ] ; ... .

In the above example, the University of Melbourne has a role - custodian - for which there is no direct DCAT / schema.org property, so a PROV=O qualified attribution is used. Kristen Smith has two roles: Point of Contact and Principal Investigator.

Projects

Provenance can be used to indicate projects or other activities that generated resource. This would take the form of PROV-O's prov:wasGeneratedBy from the resource indicating a project. For this you would need a persistent identifier for the project.

3.1 Classes ↑

Class Index

• Resource
• Location
• PeriodOfTime
• Attribution
• Score
• Distribution

PREFIX ind: <https://data.idnau.org/pid/vocab/indigeneity/>

<https://data.idnau.org/pid/762463a4-f8b1-4eec-a335-3689c8d86e9e>
    a dcat:Resource ;
    dcterms:title "Law: The Way of the Ancestors" ;
    dcterms:description "The authors show how Indigenous law has enabled people to survive and thrive in Australia for more than 2000 generations. Nurturing people and places, law is the foundation of all Indigenous societies in Australia, giving them the tools to respond and adapt to major environmental and social changes." ;
    dcterms:type <http://id.loc.gov/vocabulary/marcgt/boo> ;  # Book
    dcat:theme
        ind:by-indigenous-people ;
        ind:about-indigenous-people ,
.
							

3.2 Predicates ↑

• dcterms:title
• dcterms:description
• dcterms:spatial
• dctems:temporal
• dcterms:language
• links to agents:
  • dcterms:contributor
  • dcterms:creator
  • dcterms:publisher
  • dcterms:rightsHolder
  • prov:qualifiedAttribution
• dcat:theme
• odrl:hasPolicy
• dcterms:license
• score:hasScore
• dcat:distribution

3.3 Axioms ↑

TODO

5.1 Structural Requirements

The following sub-subsections are per object class, where 'class' is one of the classes in this profile's structural overview (see Figure 2 above).

The general idea is that objects of the various class types in the overview diagram are needed for IDN metadata and this section describes their required properties and relations. For example, all Resource instances must be related to at least one Catalog instance.

5.2 Values Requirements

IDN metadata must be represented according to certain classes with certain properties, including relations between classes, as defined in the section above. This section defines the requirements for particular properties to indicate particular values. These values are mostly items in particular vocabularies and catalogues managed by the IDN itself and the result of these requirements is to ensure that IDN metadata is related to values understood by the IDN.

Req V1: Each Resource instance MUST be categorised with at least one value from the IDN Data Themes vocabulary, indicated with a theme property.

Req V2: The roles of Agent instances with relation to a Resource MUST be indicated with the hadRole property and selected from the IDN Role Codes Vocabulary.

Req V3: Each Agent instance referenced by an Attribution instance, if the Agent is Indigenous SHOULD be registered within the IDN Agents Catalogue.

Example: A Resource with a qualified Attribution <http://example.com/resource/x> a dcat:Resource ; ... # Concept within the IDN Data Themes Vocabulary dcat:theme idth:indigenous-demographics ; ... prov:qualifiedAttribution [ a prov:Attribution; # Example Agent that could be registered in the IDN Agents Catalogue prov:agent <http://example.com/resource/central-lands-council> ; dcat:hadRole droles:custodian ; # Role from the IDN Role Codes Vocabulary ] ; .

A.1. Local Context Labels Mapping↑

TODO

A.2. RO Crate↑

TODO

B.1. FAIR↑

FAIR scores are metrics according to the FAIR Principles (see the scoring section, above calculable from catalogued resource metadata.

B.2. CARE↑

CARE scores are metrics according to the CARE Principles (see the scoring section, above) calculable from catalogued resource metadata.

B.3. Data Governance Distance↑

DGD scores are metrics according to the DGD calculations described here calculable from catalogued resource metadata.

C.1 Introduction

This Local Context model is a small ontology providing just a few classes and properties to indicate how to attach LC labels to objects catalogued according to this profile.

The machine-readable version of this model is available at:

TODO

• https://data.idnau.org/pid/vocab/lc-labels

The prefix lc: is used in this section for the namespace of this model: https://data.idnau.org/pid/vocab/lc-labels/.

Figure C.1 overviews the model.

Figure C.1: Overview of elements of the Local Context Model.

This model requires that a LocalContextLabel, which is a specialised skos:Concept, is assigned to a catalogued dcat:Resource via an intermediate node of type QualifiedLocalContext. This use of the "Qualified Relations" graph modelling pattern allows for the nature of the Resource/LocalContextLabel relationship to be defined.

C.2 Definitions

The following subsections contain definitions for the classes identified in Figure C1, above.

C.3 LocalContextLabel instances

LocalContextLabel instances for all defined TK & BC labels are given in two vocabularies:

TODO

1. BC Labels Vocabulary
2. TK Labels Vocabulary

The vocabularies above, while they have been created by the IDN, are not available publicly.

An example of RDF data for one of these labels is:

PREFIX tk: <https://data.idnau.org/pid/vocab/tk-labels/> PREFIX lc: <https://data.idnau.org/pid/vocab/lc-labels/> tk:women-restricted a skos:Concept , lc:TKLabel ; dcterms:identifier "women-restricted"^^xsd:token ; dcterms:source "https://localcontexts.org/label/tk-women-restricted/"^^xsd:anyURI ; rdfs:isDefinedBy cs: ; skos:definition "This Label should be used when you want to let external users know that the material circulating freely is actually of a highly restricted nature. This is a Women’s Highly Restricted Label and indicates that there are restrictions of access and use based on customary law. This Label can be used to help external users recognize that with this material there are very specific protocols and conditions of use. This Label is designed to recognize that some knowledge is gendered, and that certain knowledge expressions can only be shared among specific members of the community. Only authorized [and/or initiated] women within the community should be using this material."@en ; skos:inScheme cs: ; skos:notation "TK WR" ; skos:prefLabel "Women Restricted"@en ; .

C.4 Examples of a Resource with LC labels

Example: A Dataset that does have a label applied to it but requires one <https://www.atsida.edu.au/archive/datasets/au.edu.anu.ada.ddi.20002-aus> a dcat:Dataset; dcterms:title "Annual Aboriginal Census,1921-1944 - Australia"@en ; ... dcat:theme [ a lc:QualifiedLocalContext ; dcterms:type tk:culturally-sensitive ; lc:requirement "This dataset contains information collected in ways no longer thought to be best practice. The data may, if used unwarily, put Indigenous people in an un-due negative light."@en ; ] ; ... .

Example: A Dataset that does have a label applied to it but requires one <http://dx.doi.org/10.26193/V93KUP> a dcat:Dataset; dcterms:title "Aboriginal radio broadcasting in Alice Springs, 1981"@en ; ... dcat:theme [ a lc:QualifiedLocalContext ; dcterms:type tk:multiple-communities ; rdf:value "Responsibility and ownership over this material is spread across several distinct communities. Use will be dependent upon discussion and negotiation with the multiple communities named herein Central Lands Council, Waltja Tjutangku Palyapayi Aboriginal Corporation, Akeyulerre Healing Centre. Decisions about use will need to be decided collectively. As an external user of this material you are asked to recognize and respect cultural protocols in relation to the use of this material and clear your intended use with the relevant communities."@en ; ] ; ... .