Semantics

This page discussed the semantics for representing Media Fragments URI.

Basics

When we talk about semantics of fragment identifiers in URIs, we need to start with RFC3986, section 3.5:

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.

We note that, wherever fragments are not defined in the respective media type registration, the general rule from RFC3986, as stated above, applies. For the current IETF/IANA registration process and requirements see RFC4288. Note that regarding fragments, as stated in sec 4.11 of RFC4288, there is only a SHOULD-requirement. Most media types are expected not to specify fragments and their semantics, see also review of media types regarding fragment identifiers.

Proposed Wording for WD

The Media Fragment WG has no authority to update registries of all targeted media types. To the best of our knowledge there are only few media types that actually have a registered fragment specification, including Ogg, MPEG-4, and MPEG-21. For all others, the semantics of the fragment are considered to be unknown. The media fragment specification to be defined through the Media Fragment WG will be a recommendation to media type owners. We recommend to update or add the fragment semantics specification to their media type registration once a generic scheme has been determined. At minimum, those schemes that have an existing, diverging fragment specification should be harmonized. To achieve uptake of the scheme, updates to the server and client software for the different media types will be required.

Discussion

• Discussion with TimBL on swig chat: see http://chatlogs.planetrdf.com/swig/2009-02-01#T11-52-02
  • TBL Quotes: "I think that it would be good to have a general rule for video/* that there is a common fragment identifier syntax and semantics. I think that the specification should claim all video/*. The W3C specification itself can be a media type specification... I think it can be registered in the registry as the spec for a MIME type."
• Investigation regarding the feasibility of registering video/*, audio/*, image/*:
  • MPEG-21 Part 17 have already considered audio/mpeg, video/mpeg, video/mp4, audio/mp4, application/mp4, video/MPEG4-visual, application/mp21
  • Have these been added in RFC? See discussion on the MF list in 07/2009

Resources

• 3.2.1. Representation types and fragment identifier semantics in Architecture of the World Wide Web, Volume One
• ISSUE-3: Does our MF URI syntax imply that we need to update MIME Type registrations?
• IANA media type registry
• review of audio/*, image/*, video/* media types regarding fragment semantics