Back to the resolver.

lid: URI scheme

A lid: URI has the following structure:

lid: [ // host / ] ( [ ' ] name / )* [ $ ] value [ @ type ] [ ? context ] [ # fragment ]
The hostname of the server storing the target dataset. The server is queried, usually with the HTTP or HTTPS protocol, for the entity represented by the remainder of the URI.
A URI name, as an absolute URI reference or a prefix (may be empty) and a local name, separated with :.
the compared value of the property chain. If preceded by the $, it is treated as a name and expanded accordingly. May be empty.
Specifies the type of the literal value. Could be a language code, a language range, a name, or empty. If it is omitted altogether, the literal is simply compared by its string value, without a type comparison. A valid language code or language range with an additional hyphen (-) at the end is always interpreted as a language range stripped of it. Special names listed below are not applicable here, as they already match a language code.
Additional key-value pairs. If the key starts on _, it is an option, otherwise it is a prefix (re)definition (without the :) and the value is treated as a name. The prefixes are processed in order, that is the second prefix definition uses the context created by the first prefix definition, and so on. Assigning an empty literal value to a prefix name undefines the prefix.
Used to find the target entity within the resource specified by the URI by the navigator. If the location of the resource already contains a fragment, it is replaced.

All of special characters may be escaped with % per standard URI rules to be interpreted literally, without a special meaning. Inside a name, characters !, &, (, ), *, +, ,, and ; are reserved for future possible use and must be percent-encoded.

The path portion of the URI consists of a property path, followed by an identifier. Each property corresponds to a step in the corresponding property chain with the identifier at its end and the identified entity at its beginning. ' before a property represents its inverse. The initial node in the property path is considered the queried entity, while the final node is the identifier (final component of the URI path).

When a name is expected, a special identifier may be used instead, which doesn't match its usual structure. These are:

This is synonymous to the URI with no additional meaning.
This links a URI node to its actual string representation, and has to be used when looking for an entity by its URI, as only literal nodes are compared with the value. Blank nodes and literal nodes do not have this property. When this property is to be materialized, it is represented by, but it is not synonymous with it in any other case.

Every occurence of a name with a prefix is interpreted according to the defined prefixes in the current context. Definitions in the query portion are processed first and they specify the context for the path.

Every variable portion of the URI is eventually percent-decoded exactly once, even absolute URIs stored as a name. International characters (valid in IRI but not URI) are left unchanged.

There are several prefixes known initially. They are divided into three categories:

Common prefixes
PREFIX rdf: <>
PREFIX rdfs: <>
PREFIX owl: <>
PREFIX skos: <>
PREFIX xsd: <>

These prefixes are always available and commonly used in the constructed queries. Redefining them will only affect their specific usage in the URI, not their generated usage in the query.

Common URI schemes
PREFIX http: <http:>
PREFIX https: <https:>
PREFIX urn: <urn:>
PREFIX tag: <tag:>
PREFIX mailto: <mailto:>
PREFIX data: <data:>
PREFIX file: <file:>
PREFIX ftp: <ftp:>
PREFIX lid: <lid:>

These prefixes are defined in order to make it possible to write : instead of %3A in a name without relying on the target endpoint to support these prefixes.

Supplemental prefixes
PREFIX base: <>

Relative URIs are not allowed by the syntax, thus they have to be represented via base:. . and .. are not handled in any special manner.

This prefix would make it possible to express an absolute URI, like in base:urn:something. Producing absolute URIs this way is therefore explicitly disallowed: a prefix that denotes a relative URI cannot be used to produce an absolute URI (the converse is already true by definition for absolute URIs).

The empty prefix is always undefined initially, as well as any prefix that starts on x.. Any undefined prefix may still be used in any name, but it is up to the target to recognize it.

In addition to the prefixes declared above, a particular resolver may define additional prefixes.

Examples of valid syntax

All of the URIs below are valid, with or without a host portion (// after lid:).

The path may be omitted completely, in which case the URI refers to any empty literal value.
This refers to the literal value "1"^^xsd:integer itself.
This refers to the literal value "1", which is treated as a plain untagged literal in RDF 1.0 and an xsd:string-typed literal in RDF 1.1, which may be considered distinct entities by the target.
This refers to the string example in the English language.
This refers to the literal (with any datatype).
This refers to the entity identified by the URI Only in the last case, the mailto: part is treated as an actual prefix (defined as itself) and other vocabulary prefixes may be used.
This refers to any entity that is defined by the FOAF vocabulary.
This refers to an entity that has a textual label (as xsd:anyURI) which can be interpreted as the URI of an entity with value x.


A lid: URI on its own usually refers to entities described by a particular dataset. The purpose of creating such a URI is to produce a persistent identifier when one is unavailable (such as for a blank node) which is easy to read and interpret, and serves as a link into the dataset.

lid: URIs do not have a single possible resolution mechanism, but they are designed for use with SPARQL endpoints (located at /sparql under a particular host) and a particular resolver may use parts of the URI to construct a SPARQL query which retrieves the identified resource, in some form specific to the resolver.

The basic translation to a SPARQL query is simple and only uses a single property path, coupled with a check on the identifier. More advanced resolvers, such as the one hosted here, may however offer additional features, for example basic inference from subproperties, or unification based on standard properties like owl:sameAs, in which case the query may become more complex, while still resembling the simple one.

The SPARQL query generated by a resolver should generally be valid, but there is one exception: unbound prefixes may be used. These are not part of the standard SPARQL syntax, but they are commonly understood by SPARQL endpoint implementations. Using an unbound prefix means using whichever namespace is understood by the endpoint for that prefix, if some at all.


A lid: URI can be constructed to point to specific resources which can be thought of as synonymous under the RDF semantics. Here are some examples of possible entailment that may arise automatically from the use of a lid: URI.

<lid:example@en> owl:sameAs "example"@en . # a property-less lid: URI is a way to identify a literal value
<lid:uri/urn:something> owl:sameAs <urn:something> . # a way to encode a normal URI if needed, or to shorten it via a known prefix
<lid:15> skos:narrower "15", 15, "15"^^xsd:double . # the concept of a literal value with unspecified type is broader than any of the concrete literals
<lid:hello@en-*> skos:narrower "hello"@en-us, "hello"@en-gb . # likewise for language ranges

Additionally, the presence of a hostname in the URI might change its meaning in these ways: