Usage Board review of application profiles: criteria and procedures
About this draft
This is work in progress by the Usage Board. Please do not cite or quote.
What are the boundaries of what constitutes Usage Board review? Need to distinguish between things that affect conformance and usage guidelines that may conform but with which the Usage Board may disagree. Is there a difference between semantic conformance and modeling conformance?
End product of review should be self-contained, including short description of a profile. Questions below should make reviewer assignments explicit enough to elicit such descriptions.
Usage Board Application Profile Review Guidelines (For Review: Barcelona)
General
-
The assignment of conforming status by DCMI to an application profile indicates that at the time of submission for DCMI review: (1) the profile's usage of terms conforms to the DCMI Abstract Model; (2) the profile, taken as a whole, is internally consistent; and (3) the profile is sufficiently documented to serve the needs of the community of interest.
-
General guidelines for adequate documentation are set out below.
-
See also the DCMI AP Application Profile. (outline at Architecture Wiki:
Outline of an Application Profile for an Application Profile)
-
DCMI draws a jurisdictional distinction between:
-
Matters affecting a profile's conformance to the DCMI Abstract Model--matters upon which a Usage Board judgment of conforming status depends; and
-
Matters of conformant usage with which the Usage Board disagrees--matters upon which a Usage Board may only advise and recommend.
-
While an application profile may be judged conforming by the DCMI, the assignment of conforming status does not mean that DCMI considers the conforming profile to be the only one that is useful for a particular community.
| PROFILE PURPOSE AND SCOPE | |||
| Question | Consideration | ||
| Are the purpose and scope of the AP clearly stated? | The documentation must define the goals of the profile in terms of the community of interest as well as the profile's purpose in terms of the resources to be described and the functionality it intends to support. | ||
| The documentation should describe the context in which the application profile is used or is likely to be used. | |||
| The documentation should identify the organizations or individuals involved in the profile's development as well as any arrangements, policies, or intentions regarding the future development and maintenance of the profile. | |||
| FUNCTIONAL REQUIREMENTS | |||
| Question | Consideration | ||
| Are the functional requirements of the AP stated, and does the AP conform to the stated functional requirements? | The documentation must define the functional requirements of the profile. These requirements should be framed in terms of general functions such as (but not limited to) discovery, identification, and selection as well as in a more detailed enumeration of specific functionality enabled by the profile under each of the more general functions. | ||
| The documentation must demonstrate that the application profile conforms to the stated functional requirements. | |||
| APPLICATION DATA MODEL | |||
| Question | Consideration | ||
| Does the AP provide a coherent data model? | The Application profile must provide a data model that describes the profile's entities and the relationships among those entities. The data model may be illustrated in a graphical form (e.g., as one or more UML class diagrams) or set out in text. | ||
| The application profile may be based on an externally expressed data model. In such a case, the application profile must clearly identify: (1) the external data model used; and (2) any points of divergence of the profile from that external model. Additional information deemed necessary to clarify the relationship between the profile and the external model should be provided. | |||
| DOCUMENTATION OF TERMS | |||
| Question | Consideration | ||
| Are the terms used in the profile well described? |
The elements used to describe the terms in the AP should conform to the |
||
| 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. | ||
| Do the recommended encoding schemes exist? | The recommended encoding schemes should exist and be declared in an existing namespace prior to Usage Board review. | ||
| CONFORMANCE OF INDIVIDUAL TERMS | |||
| Question | Consideration | ||
| Does the term used in the AP conform to the DCMI Abstract Model? |
Each term used in the AP should conform to the DCMI Abstract Model. Conformance should be confirmed by means of the |
||
| 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.} | ||
Previous Draft and Discussions
-
General
-
"Does the AP meet the community's needs?" I think we decided this is the wrong question...
-
Documentation - introductory material
-
Purpose and scope
-
Are the purpose and scope of the AP clearly stated?
-
What is the stated goal? Cite and paraphrase.
-
Functional requirements
-
Are the functional requirements for the AP stated, and does the AP conform to the stated functional requirements?
-
This needs to be expanded!
-
Application Model
-
Does the data model make sense?
-
This needs to be expanded!
-
When reference is made to an externally expressed model, how much additional material do we expect?
-
Documentation on terms
-
Are the terms well described - what descriptive elements are present?
-
How sensible are the labels for the descriptive elements?
-
Are the obligations consistent across the properties?
-
Do the recommended encoding schemes exist?
-
Conformance of individual terms
-
Use the term decision tree, http://dublincore.org/architecturewiki/TermDecisionTree:
-
Check that each term conforms to the Abstract Model
-
Are any AP-specific encoding schemes appropriate?
-
Are the terms in the encoding scheme defined adequately, are the terms sensible, do they conform?
-
Making sure that "Usage in this DCAP" is not a case or re-definition.
-
We used to discourage people from creating new properties; now maybe encourage?
Issues arising from the UB assessment process, Manzanillo:
-
The CEN guidelines need to be revised to follow what the UB sees as best practice in reviewing APs.
-
When is it OK to use a general property but narrow its usage v when is it appropriate to define a new property?
-
What is the convention in application profiles for displaying what comes from an external source and what is intrinsic to the specific application profile?
-
We need to describe better how functional requirements fit into the application profile description, and where that relates to the application model.
-
We should make it clear that we are not aiming to anoint particular application profiles as the only ones useful for a particular community.
-
UB review needs to recognize that there may be a relationship between an externally expressed model and the AP, and the AP documentation might need to have some additional material to assist in relating the model to the AP where dependencies exist.
-
Question about whether we are explicitly endorsing subproperty assertions when we say that usage in an AP is conforming. If so we should say that up front.
-
Issue of redefinition (or not) should be part of DCAP guidelines.
-
Usage guidelines have to leave unchanged or narrow the semantics. And if you are narrowing, then why not define new property? We have been encouraging people to re-use. Rather, we could take the view of encouraging creation of new properties.
Application model (is it enough to support functional requirements?) Need one person looking at both together: Does it, on its face, meeting the requirements as stated? "This is a conforming way to say it in this particular context". Should be enough information in a Profile.
In the spirit of having stand-alone document. Usage guidelines - content rules documented here. Stand-alone documents define what the content standard is, if there is one.
Process: http://dublincore.org/usage/meetings/2006/09/manzanillo/profile-cdap/2006-02-13.process.txt
Three essential criteria are:
-
1. conformance to the abstract model
-
2. internal consistency
-
3. relationship of terms in the application profile to existing DC terms.