Linking Service Glossary
The following terms are used to describe the Linking Service.
Linking Glossary
artifact
An artifact is any item of data that a tool exposes publicly so that other tools can refer to it. Each artifact must have an artifact type. Each artifact must be identified by a unique and immutable artifact identifier. For example, source file myfile.cs, work item 125, test results from build 20041205.3.artifact consumer
Informally, a tool that holds references to artifacts. More formally, a Web service that exposes references it holds to artifacts that are hosted by artifact providers. For example, a work item, that is itself an artifact, can hold references to source control changesets that were checked in when the work item was processed. In this case, Team Foundation work item tracking is the artifact consumer and Team Foundation Version Control is the artifact provider. An artifact consumer must offer certain standard behavior described in the Artifact Consumer Obligations section. By definition, a link is between two artifacts. Therefore, an artifact consumer must also be an artifact provider.artifact identifier
An objectified version of the unique, immutable identifier for a particular artifact (ArtifactUri). The properties in an artifact identifier comply with the rules for Team Foundation URIsartifact provider
Informally, a tool that hosts artifacts. More formally, a Web service that exposes artifacts. For example, Work Item Tracking exposes artifact types of defect, requirement, and task, through Web services. This makes Work Item Tracking an artifact provider. An artifact provider must offer certain standard behavior, as described in Artifact Provider Obligations. Because a link is, by definition, between two artifacts, many artifact providers are also artifact consumers.artifact type
A type of data that a tool exposes publicly. An artifact of a particular artifact type has a common set of link types with other artifacts of that type. Some examples are Source file, defect, requirement, test result, build.artifact URI
A URI that complies with Team Foundation-specific rules for well-formed URIs.external identifier
Refers to the identifier by which a tool that is not Team Foundation-enabled refers to an artifact. This is meaningful in the context of the Team Foundation Generic Artifact Provider. For example, in SharePoint, the External Identifier is the SharePoint URL.generic artifact schema
A common schema for describing a collection of artifacts. Each artifact includes its extended attributes. These are the links that the artifact holds to other artifacts.generic link schema
A common schema for describing a collection of links. Each link includes its referring and referenced artifactUris and its link type.GLS
See generic link schema.inbound link
A link from the standpoint of the referenced artifact—in other words, the artifact to which the link points. You can obtain inbound links to a referring artifact by using the standard GetReferencingArtifacts method that is required for implementation by artifact consumers.inversion query
See reference inversion.link
A link is formed when a tool (an artifact consumer) holds an artifact identifier to a different artifact. To be a well-formed link, the link must have a link type. In other words, a well-formed link is a link type between two artifacts, the referring artifact, and the referenced artifact. A pointer between an artifact and a non-artifact is not a link because there is no specified link type. For example, "bug 125 was found in build 20041205.4" is a well-formed link because "bug" and "build" are artifact types and "was found in" is a link type.link type
Describes the purpose of links of that type. It may constrain the artifact type of artifacts to which valid links can be constructed. Each link includes two readings or roles, one from each direction, outbound and inbound. For example, bug 125 was found in build 20041205.4 vs. build 20041205.4 exposed bug 125.loose coupling
In the context of linking, a quality of behavior that does not require either the artifact provider or the artifact consumer to know anything about the consumers of the other. For example, when an artifact provider issues a reference inversion query, the linking service returns a set of references according to a schema that is common to all artifacts. This is distinct from "uncoupled" and "tightly coupled" behavior. For more information, see Uncoupling and Tight Coupling.outbound link
A link from the standpoint of the referring artifact—in other words, the artifact that points to some other artifact. Outbound links to a referenced artifact are returned by the standard GetArtifacts method that is required for implementation by artifact providers.reference inversion
Generally, reference inversion is the process of discovering the items that refer to a specific item. In the Linking Service, reference inversion is the process of discovering which referring artifacts hold links to a specific referenced artifact.referenced artifact
The referenced artifact is the side of the link to which the referring artifact points. A referenced artifact is always hosted by an artifact provider. This term is always used in the context of a link.referencing artifact
The referring artifact is the side of the link that holds the reference to a referenced artifact. It is hosted by an artifact consumer. This term is always used in the context of a link.referring artifact
See Referencing Artifact.Team Foundation Server
A namespace that corresponds to the Team Foundation logical server—in other words, a server not tied to a single, specific computer. A Team Foundation refers to a collection of Team Foundation-enabled products and artifacts. A Team Foundation can be thought of as a logical server that has physical elements distributed across multiple physical servers. Tools register themselves with a Team Foundation Namespace Server at installation time. All tools can be accessed through the Team Foundation location table. Each artifact is owned by one Team Foundation.tight coupling
In the context of linking, a quality of behavior that requires the artifact consumer to have specific information about the artifact provider. For example, if the provider offers a specialized reference inversion method, perhaps the provider includes special filters or passes back specific information of particular interest to the subject consumer. The consumer takes advantage of the specialized method, in which interaction is tightly-coupled. It is distinct from loosely coupled or uncoupled behavior. For more information, see Loose Coupling and Uncoupling.tool-specific ID
The final part of a well-formed Team Foundation URI. The combination of tool instance, artifact type, and tool-specific ID must be unique in a TFS. Additionally Tool-specific ID must be immutable.TSId
See Tool-specific ID.uncoupling
In the context of linking, a quality of behavior that does not require either the artifact provider or the artifact consumer to have any information about the other. In version 1.0, the linking service does not provide uncoupled behavior because the artifact consumer must consider the existence of links it holds. In version 1.0, the linking service supports loosely coupled behavior. For more information, see Loose Coupling and Tight Coupling.VSTF URI
A URI that complies with Team Foundation-specific rules for well-formed URIs.