ApplicationProfiles/ProfileReviewCriteria

From MPDLMediaWiki
Jump to: navigation, search

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 DCMIDublin Core Metadata Initiative 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 DCMIDublin Core Metadata Initiative Abstract Model
  • Designed in non-conflict with grammatical principles (now DCMIDublin Core Metadata Initiative 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 APApplication Profile 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 UMLUnified Modeling Language 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., FRBRFunctional Requirements for Bibliographic Records), 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 DSPDescription Set Profile)

  • Is the DSPDescription Set Profile 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 APApplication Profile 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 APApplication Profile.

  • 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 DCMIDublin Core Metadata Initiative Abstract Model

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

Designed in non-conflict with Grammatical Principles

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

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

  • Are the decisions in the APApplication Profile to declare a new term as opposed to refining an existing term sensible? In creating an APApplication Profile, 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 APApplication Profile-specific term usage solely restraints the term's value space, preference should be given to refining the original term through narrowed usage. Where the APApplication Profile-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 APApplication Profile-specific encoding schemes appropriate? {SASSerial Attached SCSI NOTE: I am not sure what we mean by "appropriate" or how we operationalize it.}
  • Are the terms in the APApplication Profile-specific encoding schemes adequately defined, sensible and conformant? {SASSerial Attached SCSI 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 APApplication Profile.

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 APApplication Profile should conform to the CENComitée européen de normalisation Guidelines in substance and labeling. The APApplication Profile 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 APApplication Profile terms? The APApplication Profile should use obligation, condition, data type, and occurrence in a manner consistent with the functional requirements of the APApplication Profile.

Useful to the community it serves

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

Does not overlap with terms or constructs approved by the DCMIDublin Core Metadata Initiative Usage Board

References