ApplicationProfiles/ProfileReviewCriteria
Summary and open questions[edit]
Review of Application Profiles[edit]
- 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[edit]
- 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[edit]
A. Workflow 1. Identify Functional Requirements 2. Domain model 3. Use or creation of vocabularies 4. Build Description Set Profile 5. Make syntax 6. Explain everything
B. Introduction The mission of the Usage Board is to ensure an orderly evolution of the met= adata terms maintained by the Dublin Core Metadata Initiative. The Usage Bo= ard evaluates proposals for new terms (or changes to existing terms) in lig= ht of grammatical principle, semantic clarity, usefulness, and overlap with=
existing terms. To proposals that are accepted, it assigns a specific stat=
us. 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 o= f guidelines for reviewing application profiles. There are four areas of ev= aluation and six criteria that can be applied to each area.
Four areas of evaluation required (two optional): Application Functional Re= quirements, 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-confl= ict with grammatical principles (now DCMI description set profile), Interna= lly consistent, Presented with semantic clarity, Useful to the community it=
serves, Does not introduce terms or other constructs that overlap with exi=
sting ones
All of these areas must be well documented.
C. Areas of evaluation: Organizational context (required) The documentation packet should describe the context in which the applicati= on profile will be used (or can be used). The documentation should identify the organizations and individuals who par= ticipated in the development of the profile, along with any agreements, gui= delines, or intentions regarding the future development and maintenance of = the profile.
C.1 Functional Requirements (required) 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) An Application profile MUST provide an Domain Model, if only a simple one, = which describes the entities and relationships amongst entities. The data m= odel 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, th= e deviations must be well documented.
C.3 Determine terms (required) Properties Classes Syntax Encoding Schemes Vocabulary Encoding Schemes For each of these: existing and new
C.4 Description Set Profile (required) 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?
Optional: C.5 User Guidelines (optional) (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) Question: Does the application profile clearly demonstrate what syntax enco= ding is to be used?
D. Criteria for evaluating the areas of evaluation
Overarching criteria
Clarity, consistency, and well-documented.
D.1 Conform to DCMI Abstract Model Follows conventions of terminology Builds concepts of this model into the AP and its proposed use
D.2 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-definitio= n of the term used? Terms used in an AP should refine and not re-define the semantics of the te= rm 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 d=
ecision whether to refine an existing term through narrowed usage or to dec= lare 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 d=
ecision to create a new refining term or to use the original term restraine= d through a usage statement should be made based on the best interest of th= e 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, sensi= ble and conformant? {SAS NOTE: I am not sure what "conformant" means in thi= s 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.
- Does not overlap with terms or constructs approved by the DCMI Usage Board