W3C home > Mailing lists > Public > public-media-fragment@w3.org > September 2008

Re: Identifying vs Describing media URI fragments

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 24 Sep 2008 19:12:30 +1000
Message-ID: <2c0e02830809240212h573e21c7u3e9cdbe5c880195b@mail.gmail.com>
To: "RaphaŽl Troncy" <Raphael.Troncy@cwi.nl>
Cc: "Media Fragment" <public-media-fragment@w3.org>

Hi Raphael,

On Wed, Sep 24, 2008 at 6:38 PM, RaphaŽl Troncy <Raphael.Troncy@cwi.nl> wrote:
> 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'.

I think you misunderstand me a bit. When I talk about fragment
specification, I just talk about the sheer definition of the fragment:
through time start/end points, or through spatial coordinates. That
specifies a fragment. It doesn't give it a name yet, i.e. it doesn't
give it an ID yet.

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

Again, I think you misunderstand me slightly. When I talk about
linking, I am talking about URIs. This can be done either by unnamed
reference of a fragment through its specification (e.g. time start/end
points in a URI) or by named and therefore identified fragments, i.e.
fragments with an ID.

If I understand you correctly, you are fundamentally assuming that a
fragment that hasn't received an ID cannot be referenced. I think
that's a very restrictive view.

> 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?

I am confused with this definition. When you give a xml element an id
tag, e.g. id="asdfxyz", then you are naming that element. However,
there is not necessarily semantics involved. It just means that the
thing has a name. Like you are called Raphael - I still cannot assume
what kind of a character you are.

I believe semantics are far outside what we want to achieve in this
WG. However, we should be able to reference a fragment by its name,
which does not imply semantics, but provides means to attach semantics
through some other means.

>> 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?

Again, I do not understand your point. The strings "id-3454645" and
"kiss-scene" are just simple identifier of a segment and do not
provide any semantics other than the ones that happen in the human
mind by reading the name. However, defining a referencing scheme where
we can use the name to identify a fragment is a different thing and
has nothing to do with semantics. We can still say: this is a URI to
the fragment called "id-3454645" or the fragment called "kiss-scene".
Just like class attributes of HTML elements bear no semantics, neither
do these.

>> * 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?

You misunderstood me again and I think we are actually on the same
page, just with different words. :-)
I don't care what the thing is called. either string will be a named
reference. However, a reference to region (5.3sec,7.2sec) is a
reference to a fragment without a name. I was simply distinguishing
between these unnamed fragments and the named fragments.

> 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 :-)

Totally agree.

>> * 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.

The thing is: as MPEG-21 or as Ogg we were only able to propose that
for a particular encoding of the content. That's how URI queries work
- they are content type specific. If however we as W3C define a
standard specification for addressing temporal and spatial fragments
of media resources, we can recommend these to be used on all container
formats. That would be a big step forward for standardisation and in
my opinion the reason we exist as a WG.

>> * 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?

I was not suggesting in any way to specify semantics. If you read that
out of my contributions, I will have to clarify the contributions.

>> 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.

OK, that's good to know. We don't have to worry about providing a
reference scheme for named fragments then, unless we can think of
another use.

>> 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.

Talk later. :-)

Received on Wednesday, 24 September 2008 09:13:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:41 UTC