Re: Identifying vs Describing media URI fragments

Hi Silvia,

Thanks for your feedback. I understand better what you say, but we use a 
different terminology / semantics. Let me clarify:

> I think our problem is that we have to do one (fragment specification)
> to allow for the other (fragment linking). A further problem is
> whether we just do fragment specification or go all the way to
> fragment identification (through naming).

What you call "fragment specification" is actually specifying the ID of 
the fragment. In my terminology, this is what I call the 
'identification' although I'm fine with the term 'specification'.

What you call "fragment linking" is actually specifying the IDREF, or 
better said, reference with its ID a fragment previously 
specified/identified.

What you call "fragment identification" (through naming) is what I call 
the 'description' of the fragment, i.e. define the semantics of the 
fragment. I assume that the process of giving a label/name to a fragment 
is something that goes beyond the syntax, i.e. you do not consider the 
characters of the label/name as a random string, but rather as a 
meaningful one that makes sense for a human/agent. I would strongly 
prefer use the term 'description' for such a process. And my point is 
exactly: does this step fall into the scope of this WG?

> For some things, the fragment specification & naming are obvious or
> already available - not so for others.

Giving a name with a well-defined semantics to an object is always 
subjective. Assuming I have specified a temporal fragment of a video, 
and I need to give a name to this fragment: for the machines, both the 
strings "id-3454645" and "kiss-scene" are equivalent. In both case, the 
machine will not understand what this fragment is about. Similarly, with 
only the fragment identifier, the machine will not know that this 
fragment points to a video encoded in the compression format x, under 
the resolution y, content which is also available on another media 
server with a different resolution/encoding, etc. This information is 
what I consider being part of the semantics of the fragment. The questio 
again is: does this fall into the scope of the WG?

> * image fragments can already be specificed through image maps and
> giving the map an id, so we have both, a region specification, and a
> naming mechanism to refer the region fragment with.

When you say: "giving the map an id, so we have both, a region 
specification, and a naming mechanism to refer the region fragment 
with", you seem to make a difference between giving a human readable 
name (e.g. map_of_my_workplace) versus an arbitrary string (e.g. 
map-6756753635). Is it the case? There is no difference for me as soon 
as the name/label has not been formally defined. This tends to be a 
Semantic Web point of view :-)

> * temporal fragments for audio or video can also easily be specified
> through a <start,duration> or <start,end> tuple, even though the Web
> currently has no such thing; naming such fragments OTOH hasn't been
> defined yet from a format POV.

Well, TemporalURI or MPEG-21 does that, right? But just for a particular 
encoding of the content.

> * spatio-temporal fragments for video are more complicated and haven't
> got a specificaiton yet. A suggestion could be a image map at the
> start, a image map at the end, and a function to move from one to the
> other. How to give this a name is another matter.

I agree. We have planned to address this more complex issue in the 2nd 
phase of this WG, if the 1st is successful.

> I think part of the mandate of this group is to solve the fragment
> specification issue. If we cannot specify it, we cannot link to it.

Agree. The question is also: Do we limit ourself to specify the syntax 
of how a fragment should be specified? Do we also define the formal 
semantics of such a fragment and how?

> Whether the naming is part of our mandate is a different issue and I
> only added it to the wiki because somebody else had already spoken
> about global identifiers for RDF purposes. I think this problem will
> have to be solved at some point. Whether we decide that it is close
> enough to our problem to take it on as well or leave it to another
> time to solve, I'm fairly indifferent.

OK. Just a note: RDF is flexible as it requires only resources 
identified by URI, the model does not care about having human readable 
labels/names for these resources.

> My suggestion would be to define the URI mechanism for linking to such
> named fragments, because it's fairly simple. But to leave the actual
> problem of how a media container translates the name to a segment of
> media data to the media container controlling entities (Apple for
> QuickTime, Xiph for Ogg, MS for wmv etc).
> 
> In fact, this is the only thing we can do for temporal and spatial
> fragments, too. But let's have that discussion later.

Yep, we will certainly discuss these issues more.

   Raphaël

-- 
Raphaël Troncy
CWI (Centre for Mathematics and Computer Science),
Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
e-mail: raphael.troncy@cwi.nl & raphael.troncy@gmail.com
Tel: +31 (0)20 - 592 4093
Fax: +31 (0)20 - 592 4312
Web: http://www.cwi.nl/~troncy/

Received on Wednesday, 24 September 2008 08:42:07 UTC