W3C home > Mailing lists > Public > public-media-fragment@w3.org > March 2009

Re: Linked Media: Weaving non-textual content into the semantic web

From: Conrad Parker <conrad@metadecks.org>
Date: Mon, 9 Mar 2009 22:48:39 +0900
Message-ID: <dba6c0830903090648h1b5841e3mee125166732f4208@mail.gmail.com>
To: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Cc: Media Fragment <public-media-fragment@w3.org>
2009/3/9 RaphaŽl Troncy <Raphael.Troncy@cwi.nl>:
> Dear Conrad,
>> The use of fragments introduces a new protocol layer above HTTP. I
>> think it's a major issue, and as such #fragment offsets should only be
>> mandated in situations where it is not possible to use ?queries.
> We had already long discussion regarding the use of a hash vs query. You can
> read [1] that tentatively summarizes all the discussion we had during
> telecon and f2f. The current position of the group is that the Media
> Fragment URI spec might use both ... but for different purpose:
> †- #: to take a fragment of a media resource, the context is saved, i.e.,
> the User will see that there might be some bits before and after a video
> sequence he is playing.
> †- ?: to create a new resource, extracted from a resource, the context is
> lost.
> [1]
> http://www.w3.org/2008/WebVideo/Fragments/wiki/Issues#URI_Fragment_.2F_URI_Query

I've read that discussion; I don't mean to be difficult, I'd just like
to contribute (both now and at the next f2f).

The distinction between use of a fragment or a query introduces
different retrieval protocols. This is a technical distinction and has
little to do with semantic purpose such as user context.

Retrieval of segments by fragment lacks backwards-compability with
plain HTTP, whereas retrieval by query can fall back to a direct HTTP
download of the segment. Fragment syntax also lacks discoverability as
pointed out above.

This is a topic that's been discussed in the Annodex project since
about 2001. I'm hoping this WG can avoid some of the mistakes we made
early on in that, such as trying to use fragment syntax where it is


Received on Monday, 9 March 2009 13:49:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:42 UTC