ApplicationProfiles/ProfileReviewCriteria

Review of Application Profiles

Workflow for creating new Application Profiles

1. Identify Functional Requirements
2. Depict Domain model
3. Use or creation of vocabularies
4. Build Description Set Profile
5. Make syntax
6. Explain everything

Introduction

The mission of the Usage Board is to ensure an orderly evolution of the metadata terms maintained by the Dublin Core Metadata Initiative. The Usage Board evaluates proposals for new terms (or changes to existing terms) in light of grammatical principle, semantic clarity, usefulness, and overlap with existing terms. To proposals that are accepted, it assigns a specific status. The Usage Board also evaluates constructs that use DCMI terms, such as Application Profiles. In order to do this the Usage Board must review proposals.

Below is a set of guidelines for reviewing application profiles. There are six areas of evaluation and six criteria that can be applied to each area.

Areas of evaluation (four required; two optional):

• Application Functional Requirements
• Application Domain Model
• Determine Terms
• Description Set Profile
• [optional: User Guidelines and Syntax Guidelines]

All of these areas must be well documented.

Six criteria:

• Conform to the DCMI Abstract Model
• Designed in non-conflict with grammatical principles (now DCMI description set profile)
• Internally consistent
• Presented with semantic clarity
• Useful to the community it serves
• Does not introduce terms or other constructs that overlap with existing ones.

Areas of evaluation

Organizational context (required)

(... somehow this area is not mentioned in the introduction)

• The documentation packet should describe the context in which the application profile will be used (or can be used).
• The documentation should identify the organizations and individuals who participated in the development of the profile, along with any agreements, guidelines, or intentions regarding the future development and maintenance of the profile.

Functional Requirements (required)

An Application profile MUST specify functional requirements in order to outline which kind of functionalities the AP is expected to support.

• Are the purpose and scope of a profile described clearly?
• Are the functional requirements of the profile described?
• Are the limitations described (things out of scope)
• Target group that will use the profile
• Resources that will be described with the profile

Application Domain Model (required)

An Application profile MUST provide a Domain Model, if only a simple one, which describes the entities and relationships amongst entities. The data model can be depicted in graphic form (e.g., as an UML class diagram) or in text.

• Are the entities in the world and the relationships among them described?
• Are the entities and relations consistent with the functional requirements?
• If the application domain model is based on a Community Domain Model (e.g., FRBR), the Community Domain Model must be identified and used clearly and consistently.
• If the Application Domain Model deviates from the Standard Domain Model, the deviations must be well documented.

Determine terms (required)

• Properties
• Classes
• Syntax Encoding Schemes
• Vocabulary Encoding Schemes
• For each of these: existing and new ???

Description Set Profile (required)

(Need to say what is an DSP)

• Is the DSP a faithful representation of the Domain Model?
• Does it have Description Templates that correspond to model entities?
• Does the Description Set Profile detail how to create a set of one or more descriptions, each of which describes a single [entity?} resource as set out in the Application Domain Model? [Redundant? And is this description set faithful to the Functional Requirements and Domain Model?]
• Are newly declared terms documented?
• Are vocabularies used in this AP clearly documented?

User Guidelines (optional)

(Need to say what we mean by user guidelines)

The Application Profile SHOULD be accompanied by a set of recommendations and best practices on how to provide the information requested by the AP.

• Are there user guidelines (optional)
• Consistency with way intended to be used

Syntax Guidelines and Data Formats (optional)

• Does the application profile clearly demonstrate what syntax encoding is to be used?

Criteria for evaluating the areas of evaluation

Overarching criteria

• Clarity
• Consistency
• Well-documented

Conform to DCMI Abstract Model

• Follows conventions of terminology.
• Builds concepts of this model into the AP and its proposed use.

Designed in non-conflict with Grammatical Principles

• One-to-one?, Dumb-down?
• Does the term usage in the AP represent a refinement and not a re-definition of the term used?

Terms used in an AP should refine and not re-define the semantics of the term used.

• Are the decisions in the AP to declare a new term as opposed to refining an existing term sensible? In creating an AP, developers are faced with the decision whether to refine an existing term through narrowed usage or to declare a new term that refines the original term. Where the AP-specific term usage solely restraints the term's value space, preference should be given to refining the original term through narrowed usage. Where the AP-specific term usage narrows the range of resources to which the term applies, the decision to create a new refining term or to use the original term restrained through a usage statement should be made based on the best interest of the community served.

• Are the AP-specific encoding schemes appropriate? {SAS NOTE: I am not sure what we mean by "appropriate" or how we operationalize it.}

• Are the terms in the AP-specific encoding schemes adequately defined, sensible and conformant? {SAS NOTE: I am not sure what "conformant" means in this context or how to operationalize it.} [2]

Internal Consistency (is the Application Profile internally consistent?)

• Does not contradict itself.
• Does not leave concepts or constructs ambiguous.
• Consistently cites outside sources where necessary, using their terminology if not purposefully and clearly changing it in the AP.

Presented with semantic clarity

• Terms, concepts, constructs, and citations are presented clearly and meaningfully.
• Are the terms used in the profile well described? The elements used to describe the terms in the AP should conform to the CEN Guidelines in substance and labeling. The AP should use all appropriate descriptive elements to identify a term's definitional attributes, identifying attributes, relational attributes, and constraints.

• Are constraints used consistently across the AP terms? The AP should use obligation, condition, data type, and occurrence in a manner consistent with the functional requirements of the AP.

Useful to the community it serves

• Well documented record of community and how this profile will be useful to it. Demonstrated feedback and vetting.

References

• [1] http://www.ukoln.ac.uk/repositories/digirep/index/Functional_Requirements
• [2] http://dublincore.org/usageboardwiki/ProfileReviewCriteria

Dublin Core Metadata Initiative

Application Profile

Unified Modeling Language

Functional Requirements for Bibliographic Records

Description Set Profile

Serial Attached SCSI

Comitée européen de normalisation