-
Starting Point
- See the Guidance Document
-
All Profile Resources
- See the Profile Resources
IDN Catalogue Profile - Specification
This is the IDN Catalogue Profile specification that defines all elements of the profile's metadata model.
Metadata
- URI
https://data.idnau.org/pid/cp/spec
↗- Is Part Of
- IDN Catalogue Profile
- Publisher(s)
- Indigenous Data Network
- Creator(s)
- Nicholas J. Car
- Dates
-
Created 2022-03-18 Issued 2022-07-19 Modified 2023-05-08 - Version
- 0.0.2
- License
- Attribution 4.0 International (CC BY 4.0)
- Copyright
- Indigenous Data Network, 2022 - 2024
Preamble ↑
Abstract ↑
This document is the formal data model specification of the IDN Catalogue Profile which is a profile of DCAT, the Data Catalog Vocabulary. Where DCAT is designed for the representation of data catalogues and their content in general, this profile of it aims to cater for the enhanced representation of indigenous data governance.
Most of the rules of this profile just implement conventions for the use of DCAT and introduce few or no new model elements.
Related parts of the IDN Profile:
- Validator - for the automated testing of data to conform to this specification
- Instructions for FAIR, CARE and other scoring
The first validator above contains tests for this profile's requirements on top of DCAT's. The second contains this profile's tests as well as those from the standards this profile, profiles: DCAT etc. The third - not available yet - contains tests for different FIAR and CARE etc scores, based on the mappings from this profile to models of those assessment systems.
For the list of all resources within this profile, see the profile definition:
Namespaces ↑
This document refers to elements of various ontologies by short codes using namespace prefixes. The prefixes and their corresponding namespaces' URIs are:
- idncp
https://data.idnau.org/pid/cp
- dcat
http://www.w3.org/ns/dcat#
- dcterms
http://purl.org/dc/terms/
- owl
http://www.w3.org/2002/07/owl#
- prof
http://www.w3.org/ns/dx/prof/
- rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
- rdfs
http://www.w3.org/2000/01/rdf-schema#
- role
http://www.w3.org/ns/dx/prof/role/
- sdo
https://schema.org/
- skos
http://www.w3.org/2004/02/skos/core#
- xsd
http://www.w3.org/2001/XMLSchema#
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. Introduction ↑
The IDN Catalogue Profile follows standard patterns of use of elements of DCAT, the Data Catalog Vocabulary, such as Catalog
, Dataset
and so on and some DCAT-recommended ways of expressing relationships from catalogue elements to Agent
instances (people & organisations) using PROV, the Provenance Ontology, and SKOS, SKOS Simple Knowledge Organization System.
To cater for Indigenous data governance concerns, this profile requires, or at least expects/promotes the use, of specific catalogues of Agent
instances and specific vocabularies of Concept
instances for to classify Dataset
instances with.
So, where using regular DCAT, you might indicate that a Dataset
is themed as being about water where water is selected from a data theming vocabulary, you would also indicate that the dataset is themed as being culturally sensitive using a particular Concept
from this profile's TK Labels vocabulary.
Where using DCAT, with PROV, you might indicate that a Dataset
is related to an Agent
by the property dcterms:contributor
(i.e. the Agent
referenced contributed to the dataset), using this profile you would use the alternate DCAT-recommended qualified agent relations pattern and say that the Dataset
is attributed to the Agent
with the role of contributor where the role referenced is taken from this profile's IDN Role Codes 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 standard DCAT.
Minimum Metadata ↑
For catalogue metadata statements of resources according to this profile, we need at least the following information for data:
Property | Notes |
---|---|
Identifier | Either you have one, or we can create one for you. See the Identifiers section below |
Title | Just plain text |
Description | A single sentence at least, up to multiple paragraphs. Just plain text though. |
Creator | The ID of a Person or an Organisation in our IDN Data Agents DB |
Custodian |
As for Creator: the ID of a Person or an Organisation in our IDN Data Agents DB. Can be the same as, or different to, Creator |
Created |
The date/year etc. the data was created. This property is recommended but optional: If you really don't know this, leave it out. See the Dating section below |
Modified |
The date/year etc. the data was last modified/updated. This property is recommended but optional: If you really don't know this, leave it out. See the Dating section below |
See the Minimal Example below for instances of each of the properties.
Format ↑
The IDN Catalogue Profile uses a particular, machine-readable, data type for all metadata: RDF.
It's critical that metadata is either supplied in one of the RDF formats or that it be able to be converted into it.
See the examples below for metadata records in RDF.
Supplying non-RDF data
Unless someone else is going to convert your metadata into RDF, you should use the:
Supplying RDF data
If you want to supply RDF metadata to the IDN, or just make your own RDF metadata generally, see what the IDN Metadata Creator tool does - it can show off RDF metadata.
You can also see the machine-readable version of the Full Example below.
Identifiers ↑
This Profile relies on web address-style identifiers for things, so you will to provide, or ask us to create, something like this:
That is the identifier for the Koori Health Research Database dataset.
It's unique ID bit is its acronym 'KHRD' and the https://data.idnau.org/pid/
bit is what the IDN uses to make unique ID's into web addresses that work - are clickable.
Existing Identifiers
If you already have a web address for your data, use that. For example, the Australian Government Indigenous Programs & Policy Locations (AGIL) dataset is already listed in the data.gov.au catalogue at https://data.gov.au/data/dataset/34b1c164-fbe8-44a0-84fd-467dba645aa7, so we continue to use that web identifier. See our listing of that dataset.
Indigeneity ↑
Roles ↑
All Agents, that is Organisations & People, associated with resources such as datasets in IDN metadata need to have their role defined.
Th 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.
Agents ↑
All Agents, that is Persons or Organisations, referred to by IDN metadata MUST be registered within the IDN Data Agents DB which is online at coming soon, Jan, 2023!
When registered, 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 Australian Data Archive:
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 fo many organisational persistent identifiers.
This identifier is present in the Full Example below.
Here is an example of an identifier for an Organisation supplied by the IDN:
https://data.idnau.org/pid/orgagilwg
- Australian Government Indigenous Locations Working Group 2007-2012
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.
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:
Type | Format | Example |
---|---|---|
Date | yyyy-mm-dd |
2021-02-28 |
Year | yyyy |
2021 |
Year/Month | yyyy-mm |
2021-02 |
Date/Time | yyyy-mm-ddTHH:MM:SS |
2021-02-28T14:02:23 |
Please do not use junk values like 00:00:00 for time: select a format that effectively conveys what you know about the data.
2. Requirements ↑
The requirements for data to conform to this profile are listed here. They are organised into the following subsections:
- Structural Requirements - specifying data "shapes" which are the patterns of classes and properties needed
- Values Requirements - specifying particular property values, i.e. classification of Resources according to specific vocabularies
Where model objects are indicated in code
and no namespace is indicated, presume the dcat
, prov
or skos
namespaces are used. There are no class/property overlaps between those models, so there can be no confusion if the object is looked up in those standards.
2.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.
2.1.2 Catalogue
Req C1: Being a Resource
, each Catalog
instance MUST also adhere to the Resource
Requirements R1, R2, R3 & R4.
Req C2: Each Catalog
instance MUST contain at least one Resource
indicated by the hasPart
property.
Example: A Catalogue instance with minimum required metadata <https://doi.org/a-doi-for-the-catalogue> a dcat:Catalog ; dcterms:title "Catalogue X" ; dcterms:description "An example catalogue"@en ; dcterms:created "2022-07-21"^^xsd:date ; dcterms:modified "2022-07-25T20:15:21"^^xsd:dateTime ; prov:qualifiedAttribution [ a prov:Attribution; prov:agent <https://linked.data.gov.au/org/idn> ; # Indigenous Data Network's PID ex:hadRole :custodian ; ] , [ a prov:Attribution; prov:agent <https://orcid.org/0000-0002-8742-7730> ; # Nicholas Car's IRI ex:hadRole :pointOfContact ; ] ; dcterms:hasPart ex:some-resource-y , ex:some-resource-z , ... .
2.1.3 Resource
Req R1: Each Resource
instance SHOULD indicate a persistent identifier to be used to gain access to its point-of-truth metadata. The PID SHOULD be used as the Dataset
instance's IRI, if it is an HTTP/HTTPS IRI, or else it SHOULD be quoted as a literal value, indicated with the property dcterms:identifier
of datatype xsd:token
.
Req R2: Each Resource
instance MUST provide basic Resource
metadata so that exactly one of each of the following properties is required with range value as per Resource
requirements: title
, description
, created
& modified
.
Req R3: Allowed Semantic Web date/time properties for created
& modified
properties are xsd:date
, xsd:dateTime
, xsd:dateTimeStamp
, time:Interval
Req R4: Each Resource
instance MUST NOT indicate Agent
roles with direct DCAT properties (e.g. publisher
) and MUST indicate them with the DCAT-recommended PROV qualified attribution pattern with each prov:Attribution
indicated with the property prov:qualifiedAttribution
.
Req R5: Each Resource
instance, if it is not a Catalog
instance MUST and if it is a Catalog
instance MAY indicate that it is within at least one Catalog
instance with an in-bound hasPart
property from a Catalog
instance.
Req R6: Each Resource
instance MAY indicate that it is a specific type of resource by use of the dcterms:type
property. Catalogued Dataset
instances are equivalent to catalogued Resource
instances of dcterms:type
Dataset
.
Example: A Resource instance with minimum required metadata <http://example.com/resource/x> a dcat:Resource ; dcterm:identifier "CAT::2-3-4::X"^^xsd:token ; # Dummy catalogue number dcterms:title "Resource X" ; dcterms:description "An example Resource"@en ; dcterms:created "2022-07-21"^^xsd:date ; dcterms:modified "2022-07-25T20:15:21"^^xsd:dateTime ; prov:qualifiedAttribution [ a prov:Attribution; prov:agent <http://example.com/org/clc> ; # Example Indigenous org PID ex:hadRole :custodian ; ] , [ a prov:Attribution; prov:agent <http://example.com/academic/person-x> ; # An academic ex:hadRole :author ; ] , [ a prov:Attribution; prov:agent <http://example.com/org/xyz-people> ; # An Indigenous group ex:hadRole :subjectAgent ; ] ; dcterms:type ex:map ; # An example specialised resource - a map - from some vocabularty of types . <https://doi.org/a-doi-for-a-catalogue> # a catalogue indicating this Resource is a part of it dcterms:hasPart <http://example.com/resource/x> ; .
2.1.3 Dataset
There are no structural requirements specifically for Dataset
instances: the requirements for Resource
also apply to Dataset
.
Note that there are values requirements for Dataset
instnaces, as per the next section.
2.1.1 Attribution
Req A1: Each Attribution
instance MUST indicate an Agent
instance with the property prov:agent
and a role for that Agent
, as a skos:Concept
, in relation to the attributing entity, with the hadRole
property.
Example: A Resource with a qualified Attribution <http://example.com/resource/x> a dcat:Resource ; ... prov:qualifiedAttribution [ a prov:Attribution; prov:agent <http://example.com/resource/central-lands-council> ; dcat:hadRole :custodian ; ] ; ... .
2.1.5 Agent
Agents are the Organisations & People that have Roles in relation to Catalogues and Resources.
Req AG1: Each Agent
instance MUST be either an sdo:Organization
or a sdo:Person
instance.
Req AG2: Each Agent
instance MUST be described with at least the sdo:name
property and, if an sdo:Organization
, also an sdo:url
property with a xsd:anyURI
value or, if a sdo:Person
, an sdo:email
property with a xsd:anyURI
value.
Req AG3: Each Agent
instance SHOULD be described with a sdo:description
property and, if the Agent
has them, identifiers for it should be indicated with sdo:identifier
with xsd:anyURI
or xsd:token
values.
Req AG4: Each Agent
MAY relate other information using schema.org properties, for example sdo:affiliation
to link a sdo:Person
to an sdo:Organization
.
Example: An Organization with an example Australian Business Number identifer and a Person affiliated with it <https://kurrawong.ai> a sdo:Organization ; sdo:identifier "31 353 542 036"^^ex:ABN ; sdo:name "KurrawongAI" ; sdo:description "KurrawongAI is a small, Artificial Intelligence, company in Australia specialising in Knowledge Graphs." ; sdo:url "https://kurrawong.ai"^^xsd:anyURI ; . <https://orcid.org/0000-0002-8742-7730> a sdo:Person ; sdo:name "Nicholas J. Car"@en ; sdo:email "nick@kurrawong.ai"^^xsd:anyURI ; sdo:affiliation <https://kurrawong.ai> ; .
2.1.5 Concept
This profile is a profile of Vocabulary Publications Profile, VocPub, among other specifications. VocPub sets requirements for Concept
and ConceptScheme
instances.
See the VocPub Concept
requirements listed in its Specification:
Example: A Concept with basic VocPub requirements met <http://example.com/concept/x> a skos:Concept ; rdfs:isDefinedBy <http://example.com/concept-scheme/y> ; # Indicating the vocabulary that defines this term skos:prefLabel "Concept X"@en ; # The Concepts preferred label skos:altLabel "Xxx"@en ; # A synonym/alias skos:definition "An example Concept"@en ; # The Concept's definition skos:narrower <http://example.com/concept/x.1> ; .
2.1.6 ConceptScheme
This profile is a profile of Vocabulary Publications Profile, VocPub, among other specifications. VocPub sets requirements for Concept
and ConceptScheme
instances.
See the VocPub ConceptScheme
requirements listed in its Specification's Vocabulary section:
2.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 ; ... dcat:theme idth:indigenous-demographics ; # Concept within the IDN Data Themes Vocabulary ... 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 :custodian ; # Role from the IDN Role Codes Vocabulary ] ; .
3. Extended Examples ↑
Minimal ↑
A dataset resource online with minimal metadata:
For this dataset we have only:
Property | Value |
---|---|
Identifier | https://data.idnau.org/pid/BSA |
Title | Briscoe-Smith Archive |
Description | Historical population data and biographical records |
Agent / Role |
Gordon Briscoe & Len Smith / Author Indigenous Australians / Subject Agent |
It has a simple title, brief description and several Agent (an organisations & people) associated with it. This item is easily understood to be Indigenous - it's about Indigenous Australians - but it's FAIR and CARE scores aren't great: a lot of simple metadata could easily be added.
The machine-readable version of this metadata record is reproduced here in the RDF Turtle format:
PREFIX dcat: <http://www.w3.org/ns/dcat#> PREFIX dcterms:<http://purl.org/dc/terms/> PREFIX droles: <https://linked.data.gov.au/def/data-roles/> PREFIX prov: <http://www.w3.org/ns/prov#> <https://data.idnau.org/pid/BSA> a dcat:Resource ; dcterms:title "Briscoe-Smith Archive" ; dcterms:description "Historical population data and biographical records" ; prov:qualifiedAttribution [ dcat:hadRole droles:author ; prov:agent <https://orcid.org/0000-0002-5477-0874> , "Gordon Briscoe" ; ] , [ dcat:hadRole droles:subjectAgent ; prov:agent <https://data.idnau.org/pid/organisation/8cfcfc08-3cec-40e1-a772-a8860c118c9d> ] , [ dcat:hadRole droles:custodian ; prov:agent <https://linked.data.gov.au/org/ada> ] ; .
Note that the reference to the custodian, the ADA, is by persistent identifier web address, https://linked.data.gov.au/org/ada
, that resolves to more information about the ADA. Also, this identifier is known in the IDN's Data Agents DB, so the IDN knows even more information about the ADA than just the simple metadata linked to by the identifier.
This metadata record will not score well on most metrics for FAIR access, governance scores and so on since it's minimal, but it's better than nothing!
Here is the same minimal metadata example as above in RDF's JSON-LD format, just to shown multiple technical formats:
{ "@context": { "dcat": "http://www.w3.org/ns/dcat#", "dcterms": "http://purl.org/dc/terms/", "iso": "http://def.isotc211.org/iso19115/-1/2018/CitationAndResponsiblePartyInformation/code/CI_RoleCode/", "prov": "http://www.w3.org/ns/prov#" }, "@graph": [ { "@id": "https://data.idnau.org/pid/BSA", "@type": "dcat:Resource", "dcterms:title": "Briscoe-Smith Archive", "dcterms:description": "Historical population data and biographical records", "prov:qualifiedAttribution": { "@id": "_:n4ed1e6643b704c4188c0e3cd15798563b1" } }, { "@id": "_:n4ed1e6643b704c4188c0e3cd15798563b1", "dcat:hadRole": { "@id": "iso:custodian" }, "prov:agent": { "@id": "https://linked.data.gov.au/org/ada" } } ] }
Snippet examples for many of the Requirements of this Specification are given in the individual Requirements' sections. This section contains a single, larger, example that makes a complete Catalog
instances with content: it is a part of the IDN's Dataset Catalogue.
The IDN Dataset Catalogue that this example is extracted from is online at:
Example: Partial content of the IDN Dataset Catalogue PREFIX dcat: <http://www.w3.org/ns/dcat#> PREFIX dcterms: <http://purl.org/dc/terms/> PREFIX idnth: <https://data.idnau.org/pid/vocab/idn-th> PREFIX idnroles: <https://data.idnau.org/pid/vocab/idn-role-codes> PREFIX isoroles: <http://def.isotc211.org/iso19115/-1/2018/CitationAndResponsiblePartyInformation/code/CI_RoleCode/> PREFIX owl: <http://www.w3.org/2002/07/owl#> PREFIX prov: <http://www.w3.org/ns/prov#> PREFIX sdo: <https://schema.org/> PREFIX skos: <http://www.w3.org/2004/02/skos/core#> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> <https://data.idnau.org/pid/democat> a dcat:Catalog ; dcterms:title "IDN Demonstration Catalogue" ; dcterms:description """The Indigenous Data Network's catalogue of datasets. This catalogue contains records of datasets in Australia, most of which have some relation to Indigenous Australia. The purpose of this catalogue is not to act as a master catalogue of Indigenous data in Australia to demonstrate improved metadata models and rating systems for data and metadata in order to improve Indigenous data governance. The content of this catalogue conforms to the Indigenous Data Network's Catalogue Profile which is a profile of the DCAT, SKOS and PROV data models."""@en ; dcterms:created "2022-07-31"^^xsd:date ; dcterms:modified "2022-11-09"^^xsd:date ; prov:qualifiedAttribution [ a prov:Attribution; prov:agent <https://linked.data.gov.au/org/idn> ; dcat:hadRole isoroles:author , isoroles:owner , isoroles:custodian ; ] ; dcterms:hasPart <http://example.com/resource/x> ; . <http://example.com/resource/x> a dcat:Dataset ; dcterms:title "Example Dataset 1" ; dcterms:description "This example dataset has a minimalist metadata record that is valid according to the Indigenous Data Network's Catalogue Profile"@en ; dcterms:created "2022-07-31"^^xsd:date ; dcterms:modified "2022-07-31"^^xsd:date ; dcat:theme idnth:indigenous-demographics ; prov:qualifiedAttribution [ a prov:Attribution ; prov:agent <https://orcid.org/0000-0002-8742-7730> ; dcat:hadRole isoroles:author ; # not being a real dataset, it has no roles other than 'author' for Agents associated with it ] ; . # From the IDN Agents Catalogue <https://linked.data.gov.au/org/idn> a sdo:Organization ; sdo:name "Indigenous Data Network" ; sdo:description "The IDN is within the University of Melbourne. It was established in 2018 to support and coordinate the governance of Indigenous data for Aboriginal and Torres Strait Islander peoples and empower Aboriginal and Torres Strait Islander communities to decide their own local data priorities." ; sdo:url "https://mspgh.unimelb.edu.au/centres-institutes/centre-for-health-equity/research-group/indigenous-data-network"^^xsd:anyURI ; . # From the IDN Agents Catalogue <https://orcid.org/0000-0002-8742-7730> a sdo:Person ; sdo:name "Nicholas J. Car"@en ; sdo:email "nick@kurrawong.ai"^^xsd:anyURI ; sdo:affiliation <https://kurrawong.ai> ; . <https://kurrawong.ai> a sdo:Organization ; sdo:name "KurrawongAI" ; sdo:description "KurrawongAI is a small, Artificial Intelligence, company in Australia specialising in Knowledge Graphs." ; sdo:url "https://kurrawong.ai"^^xsd:anyURI ; . # From the IDN Data Themes Vocabulary idnth:indigenous-demographics a skos:Concept ; skos:prefLabel "Indigenous Demographics"@en ; skos:definition "Concerned with the demographics of Indigenous people in Australia"@en ; skos:inScheme <https://data.idnau.org/pid/vocab/idn-th> ; . # From the IDN Role Codes Vocabulary isoroles:author a skos:Concept ; skos:prefLabel "Author"@en ; skos:definition "party who authored the resource"@en ; skos:inScheme <https://data.idnau.org/pid/vocab/idn-role-codes> ; . isoroles:owner a skos:Concept ; skos:prefLabel "Owner"@en ; skos:definition "party that owns the resource"@en ; skos:inScheme <https://data.idnau.org/pid/vocab/idn-role-codes> ; . isoroles:custodian a skos:Concept ; skos:prefLabel "Custodian"@en ; skos:definition "party that accepts accountability and responsibility for the resource and ensures appropriate care and maintenance of the resource"@en ; skos:inScheme <https://data.idnau.org/pid/vocab/idn-role-codes> ; .
The content for the example above can be accessed online from the IDN Dataset Catalogue's content repository:
Annex A. Mappings↑
This Annex defines mappings between this Profile and assessment models.
A.1. FAIR Mapping↑
A.2. Indigeneity Mapping↑
A.3. CARE Mapping↑
A.4. Local Context Labels Mapping↑
Annex B. Assessment Models↑
B.1. FAIR Model↑
B.2. Indigeneity Model↑
B.3. CARE Model↑
B.4. Local Context Labels Model↑
B.4.1 Introduction
"The primary objectives of Local Contexts are to enhance and legitimize locally based decision-making and Indigenous governance frameworks for determining ownership, access, and culturally appropriate conditions for sharing historical, contemporary and future collections of cultural heritage and Indigenous data"
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:
The prefix lc:
is used in this section for the namespace of this model: https://data.idnau.org/pid/vocab/lc-labels/
.
Figure B.4.1 overviews the 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.
B.4.2 Definitions
B.4.2 LocalContextLabel
class definition
Property | Value |
---|---|
IRI | https://data.idnau.org/pid/vocab/lc-labels/LocalContextLabel |
Preferred Label | Local Context Label |
Definition | A label to be applied to data that allow communities to express local and specific conditions for sharing and engaging in future research and relationships in ways that are consistent with already existing community rules, governance and protocols |
Source | https://localcontexts.org/labels/traditional-knowledge-labels/ |
Subclass Of | SKOS Concept |
Expected Properties | Standard SKOS Concept properties |
B.4.2.2 QualifiedLocalContext
class definition
Property | Value |
---|---|
IRI | https://data.idnau.org/pid/vocab/lc-labels/QualifiedLocalContext |
Preferred Label | Qualified Local Context |
Definition | An association between an RDF Resource and a Local Context Label that allows for the nature of the relationship to be defined |
Provenance | Developed for this data model, based on standard Linked Data graph patterns |
Subclass Of | SKOS Concept |
Expected Properties |
|
B.4.2.3 requirement
property definition
Property | Value |
---|---|
IRI | https://data.idnau.org/pid/vocab/lc-labels/requirement |
Preferred Label | requirement |
Definition | A description of the necessity for a Local Context Label |
Provenance | Developed for this data model, to cater for labels needed but not present |
Domain | Qualified Local Context |
Range | A textual, literal, value |
B.4.3 LocalContextLabel
instances
LocalContextLabel
instances for all defined TK & BC labels are given in two vocabularies:
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/> 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 ; .
B.4.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 ; ] ; ... .
References ↑
- RFC2119
- Bradner, S. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet Engineering Task Force. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
- PROF
- Rob Atkinson; Nicholas J. Car (eds.). The Profiles Vocabulary. 18 December 2019. W3C Working Group Note. URL: https://www.w3.org/TR/dx-prof/
- PROV
- Timothy Lebo, Satya Sahoo, Deborah McGuinness (eds.). PROV-O: The PROV Ontology. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-o/
- Semantic Web
- World Wide Web Consortium. Semantic Web 2015. Web Page. URL: https://www.w3.org/standards/semanticweb/, accessed 2020-06-14
- Turtle
- World Wide Web Consortium. RDF 1.1 Turtle Terse RDF Triple Language, W3C Recommendation (25 February 2014). URL: https://www.w3.org/standards/semanticweb/