Difference between revisions of "ApplicationProfiles/ProfileReviewCriteria"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 1: Line 1:
= Summary and open questions =
== Review of Application Profiles ==
* Four parts
** Work flow
** Introduction
** Areas of Evaluation
** Criteria for Evaluating those Areas
* These are all listed with
** Titles
** Requirements and or Questions
== Open Questions for Discussion ==
* In: Criteria -> Designed in non-conflict with Grammatical Principles
** '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]'
* Do Grammatical Principles and Other Guidelines Matter?  Are they included?  e.g., One-to-one?, Dumb-down?
* Are we right in stating what is required and what is recommended or optional?  Does this affect the way we declare an AP conformant?  Any parts conflict with Singapore Framework?  Any parts of Singapore Framework left out that need to be here?
= Review of Application Profiles =
= Review of Application Profiles =


# Workflow
== Workflow ==


1. Identify Functional Requirements
1. Identify Functional Requirements
Line 34: Line 10:
6. Explain everything
6. Explain everything


# Introduction
== 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 four areas of evaluation and six criteria that can be applied to each area.
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 four areas of evaluation and six criteria that can be applied to each area.
Line 44: Line 20:
All of these areas must be well documented.
All of these areas must be well documented.


# Areas of evaluation:
== Areas of evaluation ==


Organizational context (required).
Organizational context (required).
Line 52: Line 28:
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.
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.


## C.1  Functional Requirements (required)
=== C.1  Functional Requirements (required) ===


* Are the purpose and scope of a profile described clearly?
* Are the purpose and scope of a profile described clearly?
Line 59: Line 35:
the resources that will be described with the profile, and
the resources that will be described with the profile, and


## C.2  Application Domain Model (required)
=== C.2  Application Domain Model (required) ===


An Application profile MUST provide an 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.
An Application profile MUST provide an 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.
Line 71: Line 47:
If the Application Domain Model deviates from the Standard Domain Model, the deviations must be well documented.
If the Application Domain Model deviates from the Standard Domain Model, the deviations must be well documented.


## C.3  Determine terms (required)
=== C.3  Determine terms (required) ===
Properties
Properties
Classes
Classes
Line 78: Line 54:
For each of these: existing and new
For each of these: existing and new


## C.4  Description Set Profile (required)
=== C.4  Description Set Profile (required) ===
 
Is the DSP a faithful representation of the Domain Model?
Is the DSP a faithful representation of the Domain Model?
Does it have Description Templates that correspond to model entities?
Does it have Description Templates that correspond to model entities?
Line 88: Line 65:
Questions: are vocabularies used in this AP clearly documented?
Questions: are vocabularies used in this AP clearly documented?


## C.5  User Guidelines (optional)
=== C.5  User Guidelines (optional) ===
(Need to say what we mean by user guidelines)
(Need to say what we mean by user guidelines)
Are there user guidelines (optional)
Are there user guidelines (optional)
Consistency with way intended to be used
Consistency with way intended to be used


## C.6  Syntax Guidelines and Data Formats (optional)
=== C.6  Syntax Guidelines and Data Formats (optional) ===
Question: Does the application profile clearly demonstrate what syntax enco=
Question: Does the application profile clearly demonstrate what syntax enco=
ding is to be used?
ding is to be used?


# Criteria for evaluating the areas of evaluation
== Criteria for evaluating the areas of evaluation ==


Overarching criteria: Clarity, consistency, and well-documented.
Overarching criteria: Clarity, consistency, and well-documented.


## Conform to DCMI Abstract Model
== Conform to DCMI Abstract Model ==


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


## Designed in non-conflict with Grammatical Principles
== Designed in non-conflict with Grammatical Principles ==


One-to-one?, Dumb-down?
One-to-one?, Dumb-down?
Line 115: Line 92:
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]
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?)
== Internal Consistency (is the Application Profile internally consistent?) ==


Does not contradict itself.
Does not contradict itself.
Line 121: Line 98:
Consistently cites outside sources where necessary, using their terminology if not purposefully and clearly changing it in the AP.
Consistently cites outside sources where necessary, using their terminology if not purposefully and clearly changing it in the AP.


## Presented with semantic clarity.
* Presented with semantic clarity.


Terms, concepts, constructs, and citations are presented clearly and meaningfully.
Terms, concepts, constructs, and citations are presented clearly and meaningfully.
Line 128: Line 105:
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.
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.
* 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 DCMI Usage Board
* Does not overlap with terms or constructs approved by the DCMI Usage Board


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

Revision as of 20:34, 26 February 2008

Review of Application Profiles[edit]

Workflow[edit]

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

Introduction[edit]

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 four areas of evaluation and six criteria that can be applied to each area.

Four areas of evaluation required (two optional): Application Functional Requirements, Application Domain Model, Determine Terms, and Description Set Profile [optional: User Guidelines and Syntax Guidelines]

Six criteria are: 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.

All of these areas must be well documented.

Areas of evaluation[edit]

Organizational context (required).

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.

C.1 Functional Requirements (required)[edit]

  • 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) the target group that will use the profile;

the resources that will be described with the profile, and

C.2 Application Domain Model (required)[edit]

An Application profile MUST provide an 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.

C.3 Determine terms (required)[edit]

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

C.4 Description Set Profile (required)[edit]

Is the DSP a faithful representation of the Domain Model? Does it have Description Templates that correspond to model entities? Question: Does the Description Set Profile detail how to create a set of on= e or more descriptions, each of which describes a single [entity?} resource=

as set out in the Application Domain Model? [Redundant? And is this descri=

ption set faithful to the Functional Requirements and Domain Model?] Question: Are newly declared terms documented? Questions: are vocabularies used in this AP clearly documented?

C.5 User Guidelines (optional)[edit]

(Need to say what we mean by user guidelines) Are there user guidelines (optional) Consistency with way intended to be used

C.6 Syntax Guidelines and Data Formats (optional)[edit]

Question: Does the application profile clearly demonstrate what syntax enco= ding is to be used?

Criteria for evaluating the areas of evaluation[edit]

Overarching criteria: Clarity, consistency, and well-documented.

Conform to DCMI Abstract Model[edit]

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

Designed in non-conflict with Grammatical Principles[edit]

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?)[edit]

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.
  • Does not overlap with terms or constructs approved by the DCMI Usage Board

References[edit]