Skip to content
This repository was archived by the owner on Jul 31, 2025. It is now read-only.

Class Activity: Application Profiles

Nic edited this page Apr 27, 2017 · 1 revision

Overall goal: Looking at the relevant examples from our metadata folder, and the use cases you developed last week, begin to develop an application profile for your project.

To complete this exercise, you will need to answer the following questions:

  • What elements are necessary to meet your stakeholders' expectations?
  • Will an existing schema meet all of these requirements?
  • If not what extensions or modifications are needed?
  • How does this align with the repository software (CKAN) that you have chosen.

How do I evaluate metadata standards useful for my project? Dian Hillman offers these criteria:

  • Look at what others in the domain are using (done!) – Stability/volatility of the standard (and whether it really IS a standard) (i.e. How often is the standard changed?) – How well does the community for the standard integrates new needs and ideas – Startup and maintenance costs for use in an individual project (higher for more complex formats and implementations)

What is (at most basic level) required for an application profile?

For each element in your application profile you should (eventually) provide the following:

  • Namespace, and namespace definition
  • Status: Mandatory or optional
  • Permitted encoding scheme for values
  • Any rules for content
  • An example

You should also choose an encoding scheme for your examples (JSON or XML for our sake).

Remember:

"If an implementor wishes to create 'new' elements that do not exist elsewhere then (under this model) they must create their own namespace schema, and take responsibility for 'declaring' and maintaining that schema."

You don't want to create new elements, do you?

Clone this wiki locally