My favorites | Sign in
Project Home Wiki Issues Source
Updated Apr 18, 2011 by

CoIN (The Composition of Identifier Names)


The CoIN vocabulary defines a set of classes and properties used to descibe what properties of a resource constitute components of a URI. (Who for all other purposes are supposed to be treated as opaque.)

Data described using CoIN can thus be used to control how to mint and/or check such URI:s.

With CoIN you describe schemes for URI construction. These schemes use URI templates, whose variables are mapped to literals (or resource URI:s) by matching properties of the resource.

URI:s are coined for a resource by reading the scheme and trying to match a full path (greediest match "wins"). This includes matching by type, or computing tokens for property values, either directly, from the property value of a reference, or by finding a "slug token" for the referenced resource (in a given dataset).


Namespace URI:

N3 source:

Usage example:

The CoIN Specification (draft).


This is an outline of how an algorithm for minting URI:s using CoIN should work.

A URI can minted for a resource by using a coin:CoinScheme. A scheme defines a set of Templates (via coin:template). They are defined as the combination of a coin:uriTemplate (based on the syntax of the URI template draft), and coin:component definitions.

Each component of a template defines a property (coin:property) for which a value will be used to fill in a variable in the URI template. The variable name is either given explicitly (using coin:variable), or by using the leaf part of the URI of the property (N.B.: this "leaf" usage should be considered experimental).

If there is a value for all of the components, the template "matches" and a URI can be constructed by using the URI template and the values for the variables.

A scheme can also define a base (coin:base) to be used for constructing the URI (thus the URI templates need not be full URI:s, only absolute).

Furthermore, templates can narrow the match by defining which type the resource must have for the template to match (using coin:forType).

The value is expected to be a literal (of any type), unless the component defines a second property (using coin:slugFrom). If present, the value to use is the value for a related resource (related via the object of the component's coin:property). In SPARQL:

    coin:property ?property;
    coin:slugFrom ?slugFrom .
  ?resource ?property ?related .
  ?related ?slugFrom ?value .

There is also a way to define how to mint fragment URI:s by appending resolved fragment templates to a base URI picked from a relation from or to the resource. has yet to be documented.

Finally, CoIN defines properties for describing how values must be translated before the URI is constructed (using coin:slugTranslation with e.g. type(s) coin:LowerCasedTranslation, coin:BaseCharTranslation, optionally defining a specific coin:spaceReplacement and/or matching/stripping using regexps). Once completed, remaining characters illegal in URI segments must be URI encoded (unless a complete base is presevered by prepending them with "+", according to the URI Templates draft).

Sign in to add a comment
Powered by Google Project Hosting