Media resources with various encodings

elf-pavlik commented 4 years ago

If we take an example of photograph or a video recording. I think for each we would have an RDFSource describing it as creative work. It may include information about who took photo / video, geolocaiton, what it depicts, who appears in the creative work (aka 'tagged in' social feature). Also if someone would like or comment, the would reference that 'crative work' which I would consider RDFSource.

At the same time, each one of those creative works would have multiple encodings. For photos, it could have image/jpeg version or image/png. Also having Responsive images feature, we can expect even more encodings of the same image. Similar for videos we can expect multiple encodings of the same creative work with different codecs and qualities and frame rates (720p60 etc.)

I'd like to clearly define difference between the conceptual creative work and multiple encodings of it each denoted by distinct URI. I think we also should notice that in some cases we want to have meta data for each of the encodings with information like codec used, encoding software which produced it etc.

EDIT: See also:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source

TallTed commented 4 years ago

Sure. Something like http://example.com/movie#this could be the URI for the work, with http://example.com/movie.mov, http://example.com/movie.mp4, http://example.com/movie.avi, http://example.com/movie.720p60.mp4, http://example.com/movie.1080i60.mp4, etc., for different encodings, resolutions, etc.

Each of these should have its own description, including details for how derivative encodings are related to the original (and which that is), etc.

The basic description of the creative work (photographer/camera-person, director, scriptwriter, composer, etc.) should be inherited by all the encoding/derivatives, which could happen by various means.

I think most of this is reasonably well covered by previous work (though refinements and improvements are almost certainly possible), significantly within BIBO and PROV.

elf-pavlik commented 4 years ago

Each of these should have its own description, including details for how derivative encodings are related to the original (and which that is), etc.

I understand that each of those encoding resources (Non-RDF Source) would have it's own encoding specific metadata resource (RDF Source) (rel=describedby?). Then each of that description of MediaObject would reference the same CreativeWork resource (RDF Source) with something like schema:endoding (used as inverse property).

A media object that encodes this CreativeWork. This property is a synonym for associatedMedia.

elf-pavlik commented 4 years ago

In https://www.w3.org/TR/cooluris/#linking I notice

The HTML document at http://www.example.com/people/alice should contain in its header a <link> element that points to the corresponding RDF document:

<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
  <head>
    <title>Alice's Homepage</title>
    <link rel="alternate" type="application/rdf+xml"
          title="RDF Representation"
          href="http://www.example.com/data/alice" />
  </head> ...

This allows RDF-aware Web clients to discover the RDF information. The approach is recommended in the RDF/XML specification ([RDFXML], section 9). If the RDF data is about the Web page, rather than an expression of the information in it, then we recommend using rel="meta" instead of rel="alternate".

Above doesn't even mention rel="describedby", I think it would help if we provide guidance on when to use:

describedby
meta
alternate

ericprud commented 4 years ago

Here's what I dug up:

describedby: RFC5988 turfs the definition of describedBy to POWDER, which says:

The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.

meta: microformats loosely defines meta as:

The meta link relationship is used to link to a resource containing external metadata about the HTML page. The metadata is often assumed to be in RDF format, as indicated by the type attribute.

As far as I can see, there's no relationship to the HTML meta element. Also, the heritage of meta may go back to a W3C QA doc with text from before 2000.

alternate: This does come from the HTML spec and has some special cases:

rel attribute also contains the keyword stylesheet ... type attribute set to the value application/rss+xml ...

and the fall-through applies to our case:

Otherwise The keyword creates a hyperlink referencing an alternate representation of the current document

The IANA Link Relations Registry has no entry for meta. (Beware, the results of an IETF search for link are almost all related to routing and OSPF.)

I'm guessing we want describedby unless we want to write a (badly-needed) RFC for meta (analogous RFC, source).

elf-pavlik commented 4 years ago

I'm guessing we want describedby

Makes sense for 'resource description', unless we find advantage in using URIs for all the relations and have a clear way to express them in RDF (eg. when exporting all the metadata).

I think alternate could be used in cases which require independent operations on different representations, like in https://github.com/solid/specification/issues/69#issuecomment-573129043

TallTed commented 4 years ago

solid / data-interoperability-panel

Media resources with various encodings #33