search

XMLTV / xmltv

Utilities to obtain, generate, and post-process TV listings data in XMLTV format
GNU General Public License v2.0
283 stars 93 forks source link

DTD: Proposed change to 'actor' element #154

Closed honir closed 2 years ago

honir commented 2 years ago

Some sources provide links to headshots of the actors. It would be good to add these to the xml. This would give the option for downstream apps to display pretty pics of the actors in case you've forgotten what they look like. (As you can tell I'm not enamoured of the idea but other sites and tv guides like to do this, so what do I know ;-) )

To avoid a breaking change I suggest we add this as an attribute to the 'actor' element.

Your thoughts?...

garybuhrmaster commented 2 years ago

Your thoughts?...

I have no specific objection to the concept (although, like you, I can't understand why one typically needs such).

The obvious attribute would be an optional url (which is already defined), but thinking about use cases I do worry that a url (even as a repeatable attribute) might be too limiting, since one may have multiple reference sources of a headshot (imdb, tmdb, ttvdb, ???) and without a source reference a downstream app might choose the "wrong" one. This is, of course, the general problem of multiple sources of truth in the metadata space. Interestingly, xmltv_ns allows one to specify an arbitrary "system" that allows downstream apps to choose what system(s) they wish to prefer (if any), and since it allows arbitrary systems and extensions, has been used to feed other metadata through xmltv. A generalized metadata reference extension is probably well beyond the immediate goals.

And should the url be of the actor (i.e. the portfolio shot), or of the role (some actors are in so much makeup if could be anyone). At the least one should provide some guidance somewhere if there is some preference.

rmeden commented 2 years ago

allowing a URL makes sense, along with a "system" for the source..  I don't like the term "system", over source but if it's used for other URLs, consistency is important. Should it be "URL" or "image"?   There may be other places URL should be replaced (or augmented) with "image".  URL could be anything.

On 12/21/2021 9:55 AM, Gary Buhrmaster wrote:

Your thoughts?...

I have no specific objection to the concept (although, like you, I can't understand why one typically needs such).

The obvious attribute would be an optional url (which is already defined), but thinking about use cases I do worry that a url (even as a repeatable attribute) might be too limiting, since one may have multiple reference sources of a headshot (imdb, tmdb, ttvdb, ???) and without a source reference a downstream app might choose the "wrong" one. This is, of course, the general problem of multiple sources of truth in the metadata space. Interestingly, xmltv_ns allows one to specify an arbitrary "system" that allows downstream apps to choose what system(s) they wish to prefer (if any), and since it allows arbitrary systems and extensions, has been used to feed other metadata through xmltv. A generalized metadata reference extension is probably well beyond the immediate goals.

And should the url be of the actor (i.e. the portfolio shot), or of the role (some actors are in so much makeup if could be anyone). At the least one should provide some guidance somewhere if there is some preference.

— Reply to this email directly, view it on GitHub https://github.com/XMLTV/xmltv/issues/154#issuecomment-998895410, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBCLNTE5YE6Z7ZRY2MRIFTUSCPQNANCNFSM5KQLPX2Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

honir commented 2 years ago

Should it be "URL" or "image"? There may be other places URL should be replaced (or augmented) with "image". URL could be anything.

Yes the DTD is very loose - perhaps too loose - on what a URL is:

A URL where you can find out more about the element that contains
it (programme or channel).  This might be the official site, or a fan
page, whatever you like really.

So perhaps 'image' is better?

And should the url be of the actor (i.e. the portfolio shot), or of the role (some actors are in so much makeup if could be anyone). At the least one should provide some guidance somewhere if there is some preference.

Mmm...that opens up the potential for multiple images per actor. Which would mean we need a sub-element within the 'actor' container? That might break existing downstream apps?

garybuhrmaster commented 2 years ago

Mmm...that opens up the potential for multiple images per actor. Which would mean we need a sub-element within the 'actor' container? That might break existing downstream apps?

Well designed apps should be tolerant (the robustness principal), but attributes are probably more likely to be tolerated than new elements.

I guess a couple of important questions is what do the petitioners wish for, and what would they find acceptable, and do the (any/all/enough) upstream sources have sufficient information to meet even the acceptable part?

honir commented 2 years ago

Good questions. My proposal was based on the fact I'm currently writing a filter to augment movie listings using the TMDB API. i.e. an alternative for the existing IMDb routine (tv_imdb). TMDB offer headshots for the cast members (I don't know what percentage data fill - I haven't checked).

There are no petitioners for this data yet - it wasn't available with IMDb - but if data are there then I like to make them available. "Give them the data and they will come" - or something like that ;-)

rmeden commented 2 years ago

Geoff, What does IMDB call the fields?  Do they have different fields for different types of images?

honir commented 2 years ago

TMDB has five 'images' sub-entities : 'backdrop', 'poster', 'still', 'profile', 'logo'.

TMDB use the catchily named 'profile_path' attribute for actor image URIs.

I think I prefer 'image' - either as element or attribute name. With the benefit it's not a label we already have in the DTD.

honir commented 2 years ago

Looking again at the data, there may be benefit in adding sub-elements rather than attributes. TMDB have additional data on actors/directors: gender, popularity, original-name are probably not worth much, but they also have an 'id' tag. This might allow downstream apps to pick up an actor's other films, for example. (I think there's also an 'imdb_id' for actors which would allow a url to IMDb to be added to each credit.)

So we could have something like:

Element credits
  Element actor*     Attribute role
    Element image*   Attribute type  (e.g. 'character', 'portfolio')
                     Attribute system   (e.g. 'tmdb', 'imdb')   
    Element url*     Attribute system   (e.g. 'tmdb', 'imdb')

where 'image' is photos of the actor, and 'url' is links to their profile on TMDB/IMDB/whatever

honir commented 2 years ago

Implemented in c8640b8 and 95bf61b