Back to the resolver.
lid: URI has the following structure:
lid:[//host/] ( ['] name/)* [$] value [@type ] [?context ] [#fragment ]
$, it is treated as a
nameand expanded accordingly. May be empty.
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.
_, 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.
All of special characters may be escaped with
% per standard URI rules to be interpreted literally, without a special meaning. Inside a
; 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).
name is expected, a special identifier may be used instead, which doesn't match its usual structure. These are:
http://www.w3.org/1999/02/22-rdf-syntax-ns#typewith no additional meaning.
value. Blank nodes and literal nodes do not have this property. When this property is to be materialized, it is represented by
http://www.w3.org/2000/10/swap/log#uri, 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:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX owl: <http://www.w3.org/2002/07/owl#> PREFIX skos: <http://www.w3.org/2004/02/skos/core#> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
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.
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.
PREFIX base: <>
Relative URIs are not allowed by the syntax, thus they have to be represented via
.. 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.
All of the URIs below are valid, with or without a host portion (
"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.
examplein the English language.
http://www.w3.org/1999/02/22-rdf-syntax-ns#type(with any datatype).
mailto:email@example.com. Only in the last case, the
mailto:part is treated as an actual prefix (defined as itself) and other vocabulary prefixes may be used.
xsd:anyURI) which can be interpreted as the URI of an entity with value
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.
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: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:
owl:sameAs, but other properties may warrant weaker links.