TAG Feedback: of all the potential metadata...?

[travisleithead]

[Filed in response to the request for TAG feedback]

@xxyzzzq @mounirlamouri

There's lots of potential metadata to include, how/why did you pick this particular subset? e.g., why not genre, year, etc.? (Not sure if you saw this 2014 Recommendation "Metadata API for Media Resources 1.0"? http://www.w3.org/TR/2014/REC-mediaont-api-1.0-20140313/. It's part of the Semantic-web line of documents, but does have some specific metadata fields that might be thoughtfully considered.)

[xxyzzzq]

Other fields are supported by platforms such as Android and iOS and the MediaMetadata interface should be flexible to include them.

The reason why we only include title, artist and album is that the are the most common properties. We are prioritizing mobile platforms at the moment. Other fields such as year and genre are rarely shown as mobile platforms usually have limited space.

[xxyzzzq]

Regarding "Metadata API for Media Resources 1.0", is it implemented by any major browser vendor? If it is implemented someday and we want to make the Media Session API with the Metadata API, we could use an adaptor to accept the metadata from the Metadata API.

[beccahughes]

Since there hasn't been any discussion on this issue for a couple of years I am going to close it, but feel free to re-open if necessary.

[chrisn]

I'd like to re-open this, to note that the current artist, title, album fields are music track specific, and aren't necessarily a good fit for certain kinds of content, such as podcasts or TV or radio programmes.

Is the purpose of these fields mainly for display, in which case we may want to prefer display oriented fields, such as primary title, secondary title, etc? Or do platforms want to add features that make use of the data more semantically, so that knowing the artist name, radio station name, TV series name, etc, is necessary?

[chrisn]

This was discussed at TPAC 2019 (minutes). Some interest was expressed in having a more general set of metadata fields. Could be useful to investigate schema.org, e.g., CreativeWork etc.