Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Fragment identifiers within URIs are specified as being interpreted based on the media type of a representation. Media type definitions therefore have to provide details about how fragment identifiers are interpreted for that media type. This document recommends best practices for the authors of media type definitions, for the authors of structured syntax suffix definitions (such as +xml), for the authors of specifications that define syntax for fragment identifiers, and for authors that publish documents that are intended to be used with fragment identifiers or who refer to URIs using fragment identifiers.
Media type registrations should avoid "inheriting" generic fragment identifier rules from both the top-level type and any structured syntax suffix that they use if the fragment identifier syntaxes defined for these overlap. Where fragment identifier syntax does overlap, media type registrations should specify how conflicts between them are resolved. Media type registrations should also reserve the use of plain name fragment identifiers for content named by authors, and specify any restrictions on the interpretation of fragment identifiers by scripts. They should avoid defining media-type specific fragment identifiers within the registration document itself, and should specify error behaviour when fragment identifiers are unrecognised or fail to identify a fragment.
Structured syntax suffix registrations are based on a structured syntax which usually will have its own media type registration. The structured syntax suffix registration should define the same fragment identifier rules as are used in that media type registration, with two exceptions. First, they should enable applications that recognise specific media types that use the structured syntax to process fragment identifiers specific to that media type. Second, they should not specify how plain name fragment identifiers are processed.
The designers of fragment identifier structures (such as XPointer) should avoid syntactic overlaps with existing fragment identifier structures and ensure that fragment identifiers can be used across formats with similar semantics.
Publishers should ensure that any addressable structures within documents that are served through content negotiation are consistent across content-negotiated variants. They should also ensure that scripts handle fragment identifiers consistently with the fragment identifier rules for the relevant media type. Authors referring to URIs with fragment identifiers should avoid using fragment identifiers that are specific to a particular syntax (such as XPointer) unless the base URI targets a specific document in that syntax.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document was published by the Technical Architecture Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to www-tag@w3.org (subscribe, archives). All feedback is welcome.
Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Fragment identifiers within URIs are used in three main ways:
When URIs contain fragment identifiers, they are interpreted based on the media type of the representation that is retrieved when the URI is requested. The Generic Syntax for URIs [URI] states:
The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications.
Individual media types may define their own restrictions on or structures within the fragment identifier syntax for specifying different types of subsets, views, or external references that are identifiable as secondary resources by that media type. If the primary resource has multiple representations, as is often the case for resources whose representation is selected based on attributes of the retrieval request (a.k.a., content negotiation), then whatever is identified by the fragment should be consistent across all of those representations. Each representation should either define the fragment so that it corresponds to the same secondary resource, regardless of how it is represented, or should leave the fragment undefined (i.e., not found).
Media Type Specifications and Registration Procedures includes a "Fragment identifier considerations" section within the template for registering media types and says:
Media type registrations can specify how applications should interpret fragment identifiers [RFC3986] associated with the media type.
Media types are encouraged to adopt fragment identifier schemes that are used with semantically similar media types. In particular, media types that use a named structured syntax with a registered "+suffix" must follow whatever fragment identifier rules are given in the structured syntax suffix registration.
Problems arise when a media type wishes to adopt several sets of fragment identifier semantics because of its similarity with other media types and its use of a structured syntax. For example, as well as defining its own method of interpreting fragment identifiers, SVG [SVG11] has the media type image/svg+xml and therefore must follow the rules for fragment identifiers that are common to all XML documents (XML Media Types Draft). As an image format, it should also use the common fragment identifier semantics for images (Media Fragments URI 1.0 [MEDIA-FRAGMENTS]). If RDF is embedded within the SVG through RDF/XML or RDFa, fragment identifiers might have RDF semantics and be used to refer to real-world things pictured within the SVG. Finally, if fragment identifiers are interpreted by scripts embedded within the SVG, they may have yet another purpose: to encode local application state.
SVG is only one example of a media type in which conflicts between different uses of fragment identifiers occur. XHTML, which also uses the +xml structured syntax suffix, contains scripts that may interpret fragment identifiers and may be used to carry data interpreted according to RDF semantics.
This document recommends some Best Practices for those registering media types, those registering structured syntax suffixes, the authors of fragment identifier schemes and individual document authors.
Individual media type registrations define how fragment identifiers should be interpreted when found in documents of that media type. These registrations must balance the following goals:
Generic applications may process documents of a particular media type without knowing about the specific rules that apply to that media type as specified in its registration. For example, a browser might always attempt to display any text/* document as text, or any application/*+xml document using XML syntax highlighting. The interpretation of fragment identifiers by media-type-aware applications should match the behaviour of these generic applications, so that the same fragment is identified whether or not the application has built-in knowledge of the media type.
As specified in Media Type Specifications and Registration Procedures [RFCXXXX], media type registrations that adopt a named structured syntax with a registered suffix, such as XML or JSON, must follow whatever fragment identifier rules are specified in the structured syntax suffix registration. This ensures that there is consistency in processing between generic applications that understand the structured syntax and those that are aware of the specific media type. Similar considerations also apply, however, to other fragment identifier structures that may be used by generic processors, for example those that perform generic processing based on the top-level media type (text, image and so on).
Another source of constraints on fragment identifier structures supported by a media type is support for content negotiation. When multiple representations with different media types are served for the same URL, fragment identifiers should be used consistently across those documents, either identifying content with the same semantic content in each representation, or giving an error.
For example, it might be anticipated that documents in ABC Music Notation with a media type of text/vnd.abc would frequently be served up through content negotiation alongside documents in MusicXML with a media type of application/vnd.recordare.musicxml+xml. People referring to music may want to reference particular bars within the musical score using fragment identifiers. To enable this to happen, both media types would need to support the same fragment structure, so that the same bar could be identified regardless of which content negotiated representation was served up. In this example, the two formats do not share the same structured syntax and are not within the same top-level media type: the need for consistency arises because the two formats have the same semantic content.
With multiple potential fragment identifier structures to comply with, there's the potential for the syntaxes of those structures to conflict with each other. When the conflicts occur due to a requirement to support different types of generic processing (based on top-level media type and a structured syntax suffix), the media type should ensure that any fragment that uses syntax that is valid for both sets of generic processing identifies the same fragment in each; if that is not possible, the media type should not use the structured syntax suffix.
Best Practice 1: Ensure Consistent Generic Processing of Overlapping Fragment Identifier Structures
If the fragment identifier structures used by different generic processors applicable to the media type overlap, they should have consistent semantics. If this is not possible, the media type should not adopt the structure syntax suffix.
When conflicts occur due to the adoption of fragment identifier structures that address application-specific fragments as in the music notation example above, the media type should prioritise the interpretations of fragment identifiers used by generic processors, and specify explicitly within the media type registration how other syntactic conflicts are resolved.
Best Practice 2: Specify Resolution of Overlapping Fragment Identifier Structures
If there are syntactic conflicts between fragment identifier structures used by the media type, the registration should specify how these are resolved.
Plain names are a common type of fragment identifier structures. A plain name fragment identifier is a fragment identifier that does not include any special internal syntax. Usually plain name fragment identifiers match the NCName or QName production from XML. Media type registrations should reserve plain names for fragments of content that are named by the author of the document.
Best Practice 3: Use Plain Names for Fragments Named by Authors
If the media type includes structures that are named by authors, plain name fragment identifiers should be used to address those structures.
Some media types support active content, whereby scripts are used to manipulate the document while it is being viewed. Depending on the scripting support in the media type, such scripts may use the fragment identifier to encode application state (see Identifying Application State for details). As described in section 5. Best Practices for Document Authors, the developers of scripts should ensure that any fragment identifiers whose behaviour is defined by the media type are handled consistently with that definition. Media type registrations may additionally specify particular fragment identifier structures that are reserved for script-based processing (for example, hash-bang URIs in which the fragment identifier starts with #!).
Best Practice 4: Define Active Content Processing of Fragment Identifiers
If the media type supports active content, the registration should specify any constraints on which fragment identifier structures scripts may process and how they are processed.
Aside from specifying support for plain name fragment identifiers and any fragment identifier syntax reserved for use by scripts, individual media type registrations should avoid specifying media-type-specific fragment identifier structures themselves. Instead, registrants should consider specifying a separate fragment identifier structure, following the guidelines in section 4. Best Practices for Fragment Identifier Structures, and referencing that specification from the media type registration. This ensures that other media types with similar contnet can easily adopt the fragment identifier structure.
Best Practice 5: Avoid Specifying Fragment Identifier Structures within Media Type Registrations
Media type registrations should reference external fragment identifier structures specifications rather than embedding such definitions within the media type registration.
Media type registrations should specify error behaviour, both when a fragment identifier is used on a document and the fragment identifier either doesn't match the syntax of fragment identifiers specified for the media type, and when the fragment identifier results in no fragment being identified (for example because there is no structure with a given plain name identifier). Fragment identifiers, particularly plain name fragments, are sometimes used within URIs to identify things described by the document, without that fragment existing within the document. In addition, active content may interpret otherwise unrecognised fragment identifiers, and users will generally get more utility from seeing the entirety of the document than from an error message. For these reasons, media types should usually specify that the result of an invalid or unrecognised fragment identifier is as if no fragment identifier were given.
Best Practice 6: Define Error Processing of Fragment Identifiers
Media type registrations should define behaviour when a fragment identifier either does not match the defined fragment identifier syntax for the media type or results in no fragment being identified within the document.
Structured syntax suffix registrations are designed to enable generic processing of media types that share a structured syntax such as XML and JSON. With respect to fragment identifiers, registrations should describe the limits of such generic processing on documents that use the structured syntax.
As described in section 2. Best Practices for Media Type Registrations, individual media types are required by Media Type Specifications and Registration Procedures [RFCXXXX] to follow the fragment identifier rules given in any structured syntax suffixes that they adopt, but may need to adopt several fragment identifier structures to support other generic processing or for consistency with other types with which they share semantics.
Structured syntax suffix registrations should therefore be fairly forgiving in the fragment identifier rules that they specify, so that it is possible for media types to adopt a variety of fragment identifier structures aside from those specified by the structured syntax suffix registration. It is only necessary for structured syntax suffix registrations to constrain the syntax and processing of fragment identifiers in so far as it enables generic processing of fragment identifier with media types that adopt the suffix.
Best Practice 7: Define Error Processing of Fragment Identifiers
Structured syntax suffix registrations should define behaviour when a fragment identifier either does not match the defined fragment identifier syntax for media types that use the suffix or results in no fragment being identified within a document. In both cases, processing should fall back to that defined within the individual media type registration.
Plain name fragment identifiers are commonly used within individual media types to address structures that are named by document authors. The ways in which these structures are named is usually not specified at the structured syntax level and even where it is, media types that adopt the structured syntax may use a different convention. For example, although XML defines both xml:id attributes and the ID attribute type, individual XML-based markup languages may adopt different conventions for naming structures. Structured syntax suffix registrations should therefore avoid defining generic processing of such fragment identifiers.
Best Practice 8: Do Not Specify Use of Plain Name Fragment Identifiers
Structured syntax suffix registrations should not define processor behaviour for plain name fragment identifiers.
Aside from the exceptions described above, the processing of fragment identifiers for media types that adopt the structured syntax suffix and the media type for the structured syntax itself should be identical. For example, fragment identifiers for application/*+xml media types should be processed in the same way as fragment identifiers for the application/xml media type. This ensures that generic processors designed for the generic media type can be used with the media types that adopt the suffix.
Best Practice 9: Process Fragment Identifiers in the Same Way as for the Generic Media Type
Structured syntax suffix registrations should define processor behaviour for fragment identifiers that is consistent with the relevant associated generic media type.
A fragment identifier structure is a defined set of fragment identifier syntax, semantics and processing requirements. A fragment identifier structure may be specific to a particular media type but is often shared across a range of media types. Examples of cross-media type fragment identifier structures are XPointer [XPTR-FRAMEWORK] and Media URI Fragments [MEDIA-FRAGMENTS].
As described in section 2. Best Practices for Media Type Registrations, a media type may adopt multiple fragment identifier structures, and it can be a problem specifying processing if these have overlapping syntaxes. Generally, fragment identifier structures fall into two categories:
If the syntax of a syntax-based fragment identifier structure overlaps with that of a semantic fragment identifier structure, they cannot be used together, which constrains how they might be used. Similarly, if the syntax of two semantic fragment identifier structures that could both apply to a given media type overlap, the media type will have to specify which takes precedence during fragment identifier processing. The designers of fragment identifier structures should therefore be careful to avoid clashing with any existing fragment identifier structures that could feasibly be used in combination.
Best Practice 10: Avoid Conflicting with Existing Fragment Identifier Structures
New fragment identifier structures should avoid overlapping with the syntax used by existing fragment identifier structures that could be used in combination.
Fragment identifier structures are most useful when they can be adopted by a range of media types. This enables them to be used by generic processors and helps authors to reference structures common across representations of content negotiated resources. Fragment identifier structures should therefore be targetted towards common use across media types rather than being media type specific.
Best Practice 11: Define Fragment Identifier Structures for General Use
New fragment identifier structures should be defined such that they can be used across media types that share the same syntax or semantics rather than being specific to a single media type.
Many thanks to Larry Masinter and Chris Lilley for their comments, and to Robin Berjon for ReSpec.js.
This appendix looks at various fragment identifier structures that apply to SVG and uses as an example a simple bar chart at http://example.org/potter, which has an SVG representation:
<svg xmlns="http://www.w3.org/2000/svg" width="150" height="120" viewBox="0 0 300 225">
<g stroke="grey" stroke-width="40">
<line id="harry" x1="50" x2="50" y1="300" y2="50" />
<line id="hermione" x1="100" x2="100" y1="300" y2="0" />
<line id="ron" x1="150" x2="150" y1="300" y2="100" />
<line id="hagrid" x1="200" x2="200" y1="300" y2="50" />
<line id="dumbledore" x1="250" x2="250" y1="300" y2="150" />
</g>
</svg>
which appears as:
The Media Fragment URIs specification [MEDIA-FRAGMENTS] defines a fragment identifier structure for images, videos and audio. They cover identification of spatial areas, time segments, tracks or named segments.
Under that specification, the area covering the first two lines within the example bar chart can be addressed using a URI like:
http://example.org/potter#xywh=25,0,100,225
which would identify the area highlighted here:
The syntax for fragment identifiers defined as part of that specification is:
namevalues = namevalue *( "&" namevalue )
namevalue = name [ "=" value ]
name = fragment - "&" - "="
value = fragment - "&"
; defined in RFC 3986
fragment = *( pchar / "/" / "?" )
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
; defined in RFC 5234
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
This syntax essentially allows anything within a fragment identifier, although applications that follow the specification will attempt to interpret any fragment identifier on an image, audio or video representation as a set of name[=value] pairs separated by ampersands.
Named segments under this specification are addressable with the syntax id=id. Thus, the URI:
http://example.org/potter#id=hermione
could (assuming an application that recognises id attributes in SVG as naming segments addressable through fragment identifier structures defined in the Media Fragment URI specifications) identify the second bar within the bar chart, which has been labelled as hermione.
The XML Media Types Draft defines (among other things) syntax and processing for fragment identifiers for */*+xml media types. It states (emphasis added):
A family of specifications define fragment identifiers for XML media types. A modular syntax and semantics of fragment identifiers for the XML media types is as defined by the [XPointerFramework] W3C Recommendation. It allows simple names, and more complex constructions based on named schemes. The syntax of a fragment identifier part of any URI or IRI with a retrieved media type governed by the specification must conform to the syntax specified in [XPointerFramework]. Conformant applications must interpret such fragment identifiers as designating that part of the retrieved representation specified by [XPointerFramework] and whatever other specifications define any XPointer schemes used. Conformant applications must support the 'element' scheme as defined in [XPointerElement].
A registry of XPointer schemes [XPtrReg] is maintained at the W3C. Unregistered schemes should not be used.
When an XML-based MIME media type follows the naming convention '+xml', the fragment identifier syntax for this media type may restrict the syntax to a specified subset of schemes, but must support barenames and 'element' scheme pointers. It may further allow other registered schemes such as the xmlns scheme and other schemes.
If [XPointerFramework] and [XPointerElement] are inappropriate for some XML-based media type, it should not follow the naming convention '+xml'.
The XML Media Types draft thus defers the interpretation for fragment identifiers for */*+xml media types to XPointer. XPointer specifies the syntax:
[1] Pointer ::= Shorthand | SchemeBased
[2] Shorthand ::= NCName
[3] SchemeBased ::= PointerPart (S? PointerPart)*
[4] PointerPart ::= SchemeName '(' SchemeData ')'
[5] SchemeName ::= QName
[6] SchemeData ::= EscapedData*
[7] EscapedData ::= NormalChar | '^(' | '^)' | '^^' | '(' SchemeData ')'
[8] NormalChar ::= UnicodeChar - [()^]
[9] UnicodeChar ::= [#x0-#x10FFFF]
For example, because SVG is XML, the second of the line elements in the SVG bar chart can be addressed using:
http://example.org/potter#element(/1/1/2)
This is highlighted in the following XML:
<svg xmlns="http://www.w3.org/2000/svg" width="150" height="120" viewBox="0 0 300 225">
<g stroke="grey" stroke-width="40">
<line id="harry" x1="50" x2="50" y1="300" y2="50" />
<line id="hermione" x1="100" x2="100" y1="300" y2="0" />
<line id="ron" x1="150" x2="150" y1="300" y2="100" />
<line id="hagrid" x1="200" x2="200" y1="300" y2="50" />
<line id="dumbledore" x1="250" x2="250" y1="300" y2="150" />
</g>
</svg>
The scheme used within a scheme-based XPointer determines what it identifies; the element() XPointer scheme used above is used to identify element nodes for example. The XPointer Framework specification also states:
A shorthand pointer, formerly known as a barename, consists of an NCName alone. It identifies at most one element in the resource's information set; specifically, the first one (if any) in document order that has a matching NCName as an identifier.
This defines the semantics of a simple fragment identifier, such that a URI such as:
http://example.org/potter#hermione
means an element within the XML information set, in this case the second line element node.
SVG itself describes how fragment identifiers can be used to identify views on SVG content. It says:
An SVG fragment identifier can come in two forms:
- Shorthand bare name form of addressing (e.g., MyDrawing.svg#MyView). This form of addressing, which allows addressing an SVG element by its ID, is compatible with the fragment addressing mechanism for older versions of HTML.
- SVG view specification (e.g., MyDrawing.svg#svgView(viewBox(0,200,1000,1000))). This form of addressing specifies the desired view of the document (e.g., the region of the document to view, the initial zoom level) completely within the SVG fragment specification. The contents of the SVG view specification are the five parameter specifications, viewBox(...), preserveAspectRatio(...), transform(...), zoomAndPan(...) and viewTarget(...), whose parameters have the same meaning as the corresponding attributes on a ‘view’ element, or, in the case of transform(...), the same meaning as the corresponding attribute has on a ‘g’ element).
SVG's fragment identifiers are conformant with XPointer: they follow the same syntax and are defined in the terms given in XPointer. For example, the URI:
http://example.org/potter#hermione
in this case will address the element with the ID hermione, highlighted here:
<svg xmlns="http://www.w3.org/2000/svg" width="150" height="120" viewBox="0 0 300 225">
<g stroke="grey" stroke-width="40">
<line id="harry" x1="50" x2="50" y1="300" y2="50" />
<line id="hermione" x1="100" x2="100" y1="300" y2="0" />
<line id="ron" x1="150" x2="150" y1="300" y2="100" />
<line id="hagrid" x1="200" x2="200" y1="300" y2="50" />
<line id="dumbledore" x1="250" x2="250" y1="300" y2="150" />
</g>
</svg>
When fragment identifiers of this kind are used, SVG uses CSS's :target pseudo-class which enables the identified element to be highlighted. For example, the SVG:
<svg xmlns="http://www.w3.org/2000/svg" width="150" height="120" viewBox="0 0 300 225">
<style type="text/css">
line:target { stroke: red; }
</style>
<g stroke="grey" stroke-width="40">
<line id="harry" x1="50" x2="50" y1="300" y2="50" />
<line id="hermione" x1="100" x2="100" y1="300" y2="0" />
<line id="ron" x1="150" x2="150" y1="300" y2="100" />
<line id="hagrid" x1="200" x2="200" y1="300" y2="50" />
<line id="dumbledore" x1="250" x2="250" y1="300" y2="150" />
</g>
</svg>
means that the URI
http://example.org/potter#hermione
is displayed with the second line (identified as hermione) stroked in red:
SVG introduces a svgView() XPointer scheme that is used to describe views onto SVG images; one possible argument is viewBox(), which selects a particular area of an image in the same way as the xywh parameter defined for Media Fragment URIs described above. Thus the URI:
http://example.org/potter#svgView(viewBox(25,0,100,225))
identifies the area of the chart that covers the first two bars.
SVG, like HTML, enables scripts to be embedded within documents and to respond to events such as clicks on particular parts of the content. Active content can read the document location and base the behaviour of the script on the fragment identifier.
For example, the following SVG parses the fragment identifier that's used to access the bar chart and uses it to highlight one of the bars:
<svg xmlns="http://www.w3.org/2000/svg" width="150" height="120" viewBox="0 0 300 225" onload="highlight()">
<script type="application/ecmascript">
function highlight () {
var id = document.location.hash.substring(1);
if (id) {
var element = document.getElementsByTagName('line')[id];
if (element) {
element.setAttribute('stroke', 'red');
}
}
}
</script>
<g stroke="grey" stroke-width="40">
<line id="harry" x1="50" x2="50" y1="300" y2="50" />
<line id="hermione" x1="100" x2="100" y1="300" y2="0" />
<line id="ron" x1="150" x2="150" y1="300" y2="100" />
<line id="hagrid" x1="200" x2="200" y1="300" y2="50" />
<line id="dumbledore" x1="250" x2="250" y1="300" y2="150" />
</g>
</svg>
The URI:
http://example.org/potter#2
thus highlights the second bar within the bar chart.
In this case, the recognised syntax of the fragment identifier is determined by the script, which recognises any numeric fragment identifier between one and five. The fragment identifier has no declarative semantics -- there is no specification that says what it means -- but in effect this script supports the identification of a bar of the bar chart through a fragment identifier.
SVG allows extensions; any element in a different namespace will be ignored by SVG processors. This facility can be used to embed semantic content through RDF/XML.
The following example contains some RDF/XML which makes some basic assertions about the resource
http://example.org/potter#hermione
This resource has been identified with a fragment identifier within an SVG document like this:
<svg xmlns="http://www.w3.org/2000/svg" width="150" height="120" viewBox="0 0 300 225">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foaf="http://xmlns.com/foaf/0.1/">
<foaf:Person rdf:about="#hermione">
<foaf:name>Hermione Granger</foaf:name>
</foaf:Person>
</rdf:RDF>
<g stroke="grey" stroke-width="40">
<line x1="50" x2="50" y1="300" y2="50" />
<line x1="100" x2="100" y1="300" y2="0" />
<line x1="150" x2="150" y1="300" y2="100" />
<line x1="200" x2="200" y1="300" y2="50" />
<line x1="250" x2="250" y1="300" y2="150" />
</g>
</svg>
In semantic content, fragment identifiers can mean anything. In this particular example, we can tell from the RDF that the above URI means the person named Hermione Granger. It is common practice when using RDF for URIs that include fragment identifiers to be used to refer to things that are described by the document retrieved at the base URI, as this makes it easy to serve RDF content.