# Profiles

## Introduction
Interest group & link (see W3C for header)

### definition
cite Rachel Heery

### Functions
Profiles have a number of different functions, none of which exclude the others. Here are some of the things that profiles are used for:
1. creating data
2. ingesting data from others
3. analyzing and validating data
4. mixing/selecting data from different sources
5. documenting community consensus
1. ingesting data from others
1. retrieval or display of different views

## Elements of profiles
### Entity
An entity is ... If entity-to-entity relationships are desired, the entity must have some kind of identity, either a name or some other type of identifier.

### Property
Another common term for property is "data element." To be usable in programs there must be a unique name or identifier for each property. Because profiles generally use properties that have been defined elsewhere, the property should alredy have an identifying name.

### Value type
In the case where properties have defined value types, the value type should be included in the profile. There are many ways to define value types, some coming from existing programming standards, but they may also be community-defined. The important thing is to use the value types consistently. Some examples of value types are:

string (any characters)
date (a formatted date, such as 9999-yy-mm)
URI (an http identifier for a thing)
profile entity (the identifier for an entity in the current profile, for linking between entities)

### Cardinality
Often applied to properties, cardinality describes whether a property is required or not and whether it is repeatable or not. Cardinality is commonly coded in programming languages with a shorthand using 0 for "no" and 1 for "yes". Here are some examples of common formats for this data:

0..n (not mandatory, repeatable without upper limit)
1..3 (mandatory, repeatable up to 3 times)
0,-1 (not mandatory, repeatable without upper limit)
1,1 (mandatory, not repeatable)

Terms like "mandatory", "required", "repeatable" can be equivalent to these more terse formats.

## The profile "stack"

From the simplest to the more complex, these are possible profile structures. (Cardinality and annotations can be used throughout.)

### Overall profile structure view

A complete profile has this conceptual model.

* for each entity
* one or more properties
* cardinality of the property
* annotations or instructions for use of the property
* for each property, one value type

### 1. properties (data elements)
A simple list of the properties or data elements that will be used to describe some data can be a profile. There are no value types defined so this profile is very loose. There is no entity named so it is assumed that all properties refer to a single entity. Properties in profiles are generally taken from existing vocabularies like Dublin Core Metadata Terms, Schema (schema.org), etc.

title
creator
date

Properties are often further refined with _cardinality_.

| title | 0,1|

### 2. properties plus value types
In this, each property has a value type. This further constrains the properties.

### 3. Entity plus properties
Some profiles define more than one entity, such as a journal article and an author. Each entity is described with one or more properties.

### 4. Entity plus properties plus value types
The inclusion of value types in this model means that there is additional provision. There is also the capability to use a value to link one entity to another.

## Design considerations
In your design you need to think about a number of things. Your first instinct may be to think only about your immediate application, but casting your thoughts more broadly may be advantageous in your work.

### Tolerant or strict
"Be conservative in what you do, be liberal in what you accept from others".

Ideally, the data creation phase should provide strict rules so that the data that results is very uniform in nature. However, a highly defined data profile is not easily shared with others. For practical usability, different functions, such as ingest of data from others, may need to be less strict unless absolutely perfect data is needed.

OWA - ignore additional properties but don't reject.

### Minimum semantic commitment

Consider creating a cascade of constraints
(use DCAT as an example here? There's DCAT, DCAT-AP, then DCAT-AP-country code. Each becomes more strict. However, it's not an ideal example so maybe we should make up a similar example.)

people have trouble reusing because too strict

pay attention not just to your immediate application but think about those you want to share data with, and future modifications to your applications and needs. (caution about being too narrow)

## Profiles in DCMI
History, Singapore Framework, etc.