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. Note: Since describing both options in a single scenario may result in text that is too vague, it may be better to have multiple sets of scenarios - a set of scenarios for providers that do not allow version skew in a single configuration, and a set of scenarios for those that do.
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. Not all systems support explicit creation and management of change sets. The use cases and scenarios defined by this work group require change set resources as an intermediate resource between OSLC change requests and configuration items when using the defined link predicate oslc_cm:tracksChangeSet, and as part of the representation of baseline comparisons, but a provider may construct these change set resources implicitly, dynamically, or in other manners as required. Note that OSLC change requests may also have other links pointing directly to configuration items.
Context: A context is the description or specification of a configuration; that configuration might or might not yet exist (since we need a way to specify a configuration to be created). One way to identify a context is to use the URI of a configuration resource. Some providers may allow other mechanisms for specifying context.
Other possible terms: merge, variant, option, dimension, view, effectivity, recipe
