Re: Is the same video but in different encodings the owl:sameAs?

Hi Thomas,


On Wed, Dec 4, 2013 at 6:24 PM, Thomas Steiner <tomac@google.com> wrote:

> Hi again,
>
> Thanks for your reply, Kingsley.
>
> > <http://ex.org/video.mp4> denotes one entity.
> > <http://ex.org/video.ogv> denotes another.
>

well, it is actually up to the owner of the namespace to decide what those
two URIs denote,
so they might very well decide they denote the same thing.
But that, in my opinion, that would break many assumptions of the average
LOD user,
so that sounds like a bad idea.
More specifically, the presence of a file extension in the URIs somehow
implies that the (format of) the information available at those URIs is
part of the identity of the resource.

Disclaimer: I know very well that I'm not allowed to formally deduce
anything from the structure of the URI; that's why I saying that this
interpretation is not the only possible one, only the one satisfying most
people's expactation.

Note: I never was a big fan of the Information Resource / Non-information
Resource distinction, but it sounds like a good fit here.


> We agree on that. I guess my question boils down to "how to avoid
> having to make duplicate statements about each resource"? I cannot
> take your proposed <#CapturedEventNameX> as a "proxy" entity, as it is
> not a video, but an event.
>

The "depicted event" is a way to link those two entites, but it is not the
only one.
FRBR <http://en.wikipedia.org/wiki/FRBR> [1] for example, provides the
notions of Work, Expression, Manifestation and Item.

In my understanding, video.mp4 and video.ogv are two manifestations
(encoding) of the same expression (abstract video).
To avoid making dupplicate statements, you have to make them at the correct
level of abstraction. For example, the title or the depicted event are
properties of the expression, while encoding and frameHeight are properties
of the manifestation.


> My argument was more: take any random user and let them view the .ogv
> and the .mp4 versions of the video, and if they say it is the same

(which random users most probably will do, as the visual and the
> audial contents are the same), the two versions can be considered
> owl:sameAs.
>

well, that's assuming that your user is able to read both, which is often
not the case :-)
(and this is the whole point of specifying several sources)

more subtly, the sound quality, image resolution, etc... may differ between
the two videos, which some users at least will detect.

finally, some users are tech-savy enough to consider the encoding to decide
whether two videos are indeed the same (don't tell some of my friends that
a FLAC file and an MP3 file are the same!).


> One version may, e.g., have more details (say, due to the bit rate)
> than the other, just like the two entities below are considered
> owl:sameAs, even if one _may_ have more, or more accurate, facts than
> the other…
>
> <http://dbpedia.org/resource/London> owl:sameAs
> <http://rdf.freebase.com/ns/en.london>
>

This is very different as those URIs clearly denote Non-information
Resources. So the information retrieved at those URIs is not part of the
identity of the resource. The fact that I retrieve different data has
therefore no impact of the "sameness" of the resources (they are just
different account of what is true about the resource).

Again, I'm not denying that you could *decide* that video.mp4 and
video.webm really denote something more abstract that the respective
encoded data-streams, but, coming again to your "random user", are you sure
they would not be tempted to assert format-specific facts about those two
URIs? This would make your knowledge base inconsistent.

Both options are possible, but you have to chose side, and the safest
choice, I think, is to consider that those two URIs denote different things..

  pa

[1] http://en.wikipedia.org/wiki/FRBR



> Does that make sense?
>
> Thanks,
> Tom
>
> --
> Thomas Steiner, Employee, Google Inc.
> http://blog.tomayac.com, http://twitter.com/tomayac
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
>
> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtP5://xKcd.c0m/1181/
> -----END PGP SIGNATURE-----
>
>

Received on Wednesday, 4 December 2013 18:31:01 UTC