Resource: in this context, we refer to an information resource - data that resides on a computer, not an actual physical entity.
Concept resource: All the major “Artifacts” or “Entities” in OSLC domains and equivalent linked data providers are concept resources. Examples are defects, tasks, products, projects, users, tests cases, designs, requirements, plans, and so on. Like all resources, concept resources have URLs. In most cases, URLs of concept resources are used throughout a system. “Entities” are addressed in HTTP messages via their concept resource URLs. Again in most cases, links are established by using the URL of a concept resource.
Version resource: A version resource defines a particular version of the state of a concept resource. A version resource is a version of one and only one concept resource - though note that through redirection or some other form of mapping, a GET on a concept resource URI might resolve to a different concept resource, or a version of a different concept resource. There are use cases for links that always identify a specific version resource.
Configuration: a resource that identifies a set of revisions, versions, and/or states of some other resources (the workgroup is to determine if configuration can contain other configurations). In some systems, a configuration identifies an exact set of resources selected by the entity that created the configuration, as well as their versions; in other systems, a configuration may identify the state of a fixed set of resources, not limited to a client-determined set. The implication is that a client cannot rely on being able to create a configuration that ‘contains’ only a client-specified set of resources. There are use cases for links to a version of a resource identified by a given configuration. The issue of enumerability is usually important for baselines, but is less certain for configurations. We have not yet discussed use cases that require that configurations are themselves versioned.
Configuration item: this is a common term in configuration management, referenced in ISO9001-1003, MIL-STD-498 and elsewhere. It encompasses any type of resource whose state may be recorded by a configuration - that is, a type of resource that may be ‘in’ a configuration. The wg has yet to determine if configuration resources are themselves configuration items for phase 1.
Configuration management: the practices of managing configurations, their contents, their lifecycles - in particular, identifying and controlling changes to configurations.
Baseline: a common term for a configuration that identifies an immutable set of resources with immutable states. Baselines often have other identifying properties, such as particular workflow or approval states. A baseline resource might be mutable. In some domains and tools, it may take time to construct the baseline during which the set of member resources might be changeable, but the remember resources are immutable. At some lifecycle stage, the baseline might undergo validation and approval at which point the collection becomes immutable. It is possible that a baseline is simply a specialization of a configuration such that its members are always immutable and enumerable, and at some stage in its lifecycle it becomes immutable. It’s not clear whether we need a different resource type between a baseline and a configuration.
Version skew: the situation where two different versions of the same concept resource are used in different places in some context or related set of contexts. The group has agreed that for some providers, a single configuration by itself cannot support version skew, while some providers might be able to do so. Since many providers cannot represent version skew in a single configuration, but version skew does exist in the real world, the detailed scenarios developed by this workgroup must explain how that real world version skew could be represented using multiple configurations (including the possibility of allowing configurations to be members of other configurations, or allowing configurations to reference or depend on other configurations). The scenarios should also describe how single configurations may be used for providers that can support version skew in a single configuration.
Revision: a revision is a synonym for a version resource
Branch: a branch identifies a set of version resources that form a parallel variant of a concept resource - for example, a set of versions of a product for a particular geography or market. The term is also used to identify the point in the version history at which that new branch was created, and the parent version from which the new branch was derived. Finally, as a verb, branch is also used to describe the action of creating the initial parallel version.
Change set: a resource that identifies a set of related changes to one or more other resources. TBD - not all systems support explicit creation and management of change sets, so we need to define these as potentionally system-created or implicit resources.
Other possible terms: merge, variant, option, dimension, view, effectivity, recipe
