Dublin Core
Dublin Core
About DCMI Themes Members Governing Board Usage Board Directorate
Bluesky Twitter YouTube GitHub RSS Feed

DCMI Government Working Group - Application Profile

DCMI-Government Working Group

DC-GOV APPLICATION PROFILE

Introduction

Questions

Comments on all aspects of this document are invited. Questions about particular elements and refinements, for which answers are desperately needed, are included throughout the document in bold italics.

Namespaces

At least one new namespace is needed from where the proposed new elements and refinements can be stored and accessed. The DC-Gov Application Profile uses all existing namespaces and requires the creation a new DC-GOV one, which will be accessible from the DC site. This means using a combination of namespaces for our application profile, including DC, DC, DC-gov and DC-terms. This allows flexibility and maintains the closest links with the international DC initiative.

SUMMARY OF PROPOSALS

  1. Application profile to include Audience element, with accompanying qualifiers. These will be taken from the DC-ed namespace

  2. A new refinement for the DC.Date element;

acquired

  1. Two new refinements of the DC.Relation element, from the AGLS namespace;

isBasedOn and isBasisFor

3a. A revised definition of the DC.Relation element refinements isVersionOf and hasVersion, to enable easy differentiation from isBasedOn and isBasisFor

  1. Additional refinements to the DC.Rights element;

securityClassification
previousSecurityClassification
accessRights
copyright

  1. Additional refinements to the DC.Subject element;

category
keyword

  1. Additional refinement to the DC.Type element;

aggregation level

1 Audience element, with accompanying refinements.

The government domain covers many other domains, such as education, health, finance and transport. The capacity to designate various aspects of the intended users of, or audience for, the resources being described is an important function for networked information discovery and retrieval.

Name: audience
Label: Audience
Namespace: Use DC-Ed if the final version of this element is rendered non-domain specific.
Definition: A category of user for whom the resource is intended.
Comment: Frequently, creators and publishers of government resources explicitly state the category of user for whom the resource is intended. In like fashion, end-users frequently use audience characteristics as search terms.

Qualifier that Refines dc-ed:audience: [1]
Name: mediator
Label: Mediator
Definition: An entity that mediates access to the resource.
Comment: The audience for a resource may be one of two basic classes: (1) an ultimate beneficiary of the resource (such as a student or trainee), or (2) an entity that mediates access to the resource (such as a teacher or trainer). The mediator element refinement represents the second of these two classes.

It will be used by Departments of Education, and may have value to other sectors, such as health and social services. For example, if the resource is information on social security benefits, the ultimate audience is the person who receives benefits but access to this is often mediated by a social worker or citizens advice bureau worker.

Encoding schemes will be needed if the real value is to be gained from this refinement. Various educational encoding schemes are available and there are no doubt others for different domains, e.g. health. We need to list these and decide which are the most useful, and if necessary develop a government scheme.

  1. A new refinement for the DC.Date element: acquired

Name: date.acquired
Label: Acquired
Namespace:
Definition: Date on which the resource was received into the organisation.
Comment: The nature of a resource can change when it is submitted by one authority to another ( e.g. in legislative procedures) without necessarily any change being made to the content of that resource. Includes date of receipt of an e-mail.
Example: The date that a legislative text is tabled for consideration (=date of acquisition by the House) is not the same as the date the resource is adopted (by the submitting or receiving authority).
DC-Gov Best Practice:

We need a specific example or two of this, preferably along the lines of "A person searching for……."

3. Two new refinements of the DC.Relation element: isBasedOn and isBasisFor

3a. A revised definition of the DC.Relation element refinements isVersionOf and hasVersion, to enable easy differentiation from isBasedOn and isBasisFor

Name: isBasedOn
Label: Is Based On
Namespace: http://www.naa.gov.au/recordkeeping/gov_online/agls/1.2
Definition: The resource is a performance, production, derivation, translation, adaptation or interpretation of another resource
Comment:
DC-Gov Best Practice:

Name: isBasisOf
Label: Is Basis Of
Namespace: http://www.naa.gov.au/recordkeeping/gov_online/agls/1.2
Definition: The resource has a performance, production, derivation, translation, adaptation or interpretation, namely, the referenced resource.
Comment:
DC-Gov Best Practice:

DC definitions
isVersionOf: The described resource is a version, edition or adaptation of the referenced resource. Changes in version imply substantive changes in content rather than differences in format.
hasVersion: The described resource has a version, edition, or adaptation, namely, the referenced resource.

AGLS definitions:
isVersionOf / HasVersion: One resource is a historical state or edition of another resource by the same creator
isBasedOn/isBasisFor: One resource is a performance, production, derivation, translation, adaptation or interpretation of another resource

I have yet to find real support for this, and am seriously thinking of dropping it if nobody comes forward to 'champion' it. Do we really need it, or can we get by with IsVersion?

Specific examples would be very useful. Can anyone supply some?

4. Additional refinements to the DC.Rights element;

securityClassification

previousSecurityClassification
accessRights
copyright

Name: securityClassification
Label: Security Classification
Definition: The classification allocated to the resource indicating its official security status
Comment: Will be needed on intranets where resources with a variety of classifications will be stored but also on metadatabases designed to indicate that an information resource exists even if it is not actually available to the public. This is often needed to meet access to information legislation requirements.
DC-Gov Best Practice: It is envisaged that all users will use their administration's official classification list as an encoding scheme. Ideally a link should be given to further explanation of the scheme, though in some administrations, e.g. UK, this scheme is itself classified.

Name: previousSecurityClassification
Label: Previous Security Classification
Definition: The classification allocated to the resource indicating its official security status prior to its current status
Comment: Many official documents have their security classification reduced over time. The ability to search on current and previous markings allows a user to locate resources that have changed their classification.
DC-Gov Best Practice: It is envisaged that all users will use their administration's official classification list as an encoding scheme. Ideally a link should be given to further explanation of the scheme, though in some administrations, e.g. UK, this information is itself classified.
By repeating this element refinement it will be possible to record all of a resource's security classification changes.
Example: A political analyst wishes to study the rate at which education policy resources are reduced from 'Secret' to 'Open'. In addition to Subject (education policy) he needs to search on rights.securityClassification (open) as well as rights.previousSecurityClassification (secret) to find suitable resources to study. (In this case the change date would also be essential - any opinions? SecurityClassificationChangeDate as a refinement of Date?)

Name: accessRights
Label: Access Rights
Definition: Legal or other rights an individual has to access the resource or that regulate the administration's right to release or provide access to the resource
Comment: Contains information on the resource's status under any information access or privacy laws or regulation.
Note that this differs from, and may even conflict with, the official security marking given in the 'security classification'; refinement. For example an individual government officer may classify a document as 'secret' where the relevant 'access to information' legislation may regard the same document as one that should be made available to the public.
DC-Gov Best Practice: Use one or more encoding schemes. Different schemes will be needed depending on the nature of the legislation or regulation covering access, these schemes will need to be developed and implemented by the relevant administrations.
Example:

Name: copyright
Label: Copyright
Definition: Statement and identifier indicating the legal ownership and rights regarding use and re-use of all or part of the resource
Comment: Administrations may publish resources under a variety of copyright regimes.
DC-Gov Best Practice: a statement is needed to allow searching by copyright type. The link is useful for providing more information about how the form of copyright works.
Example: Crown copyright http://www.hmso.gov.uk/docs/copynote.htm

More (non-UK) examples would be useful.
DC Usage board thinks that an encoding scheme would suffice here but I don't know if one would, or even if one exists. Any ideas?

5. Additional refinements to the DC.Subject element;

classification

keyword

Name: classification
Label: Classification
Definition: Term from a controlled vocabulary designed to aid browsing by subject matter
Comment: Typically taken from a high-level subject scheme or encoded classification system
Differs from Subject¦Keyword in that it requires a broad heading not a specific subject descriptor. This will be used for browsing systems (Yahoo-type categories) and other circumstances where only a broad heading is needed. It should be possible to use Keyword and Category in conjunction, e.g. to search all items in a given category with given keywords.
Data in this refinement can also be used as the basis of a 'push' system, to classify documents for current awareness services.
DC-Gov Best Practice:
Example:

Does this coincide with the proposed DC-Lib Subject¦Classification refinement? I prefer 'Category', as 'Classification' implies an alphanumeric code, but would appreciate comments.

Name: keyword
Label: Keyword
Definition: Term describing the specific subject of the resource
Comment: Will be used, in conjunction with subject.category, to aid the mapping of multiple thesauri.
DC-Gov Best Practice: Entry would contain the subject to be found at the lowest level of granularity available in a controlled vocabulary or thesaurus and descriptive of the subject matter of the resource.
Example:

6. Additional refinement to the DC.Type element

Originally we requested three refinements for Type; aggregation level, dossier type and item type. These were all rejected outright by the Usage Board, mainly on the basis that encoding schemes would suffice. I am happy to leave this for now and see what the Collection Level Group comes up with. Is everyone happy with this?