MovieEvent type and properties for movie listings #328

Closed
vholland opened this Issue Feb 6, 2015 · 22 comments

Projects

None yet

7 participants

@vholland
Contributor
vholland commented Feb 6, 2015

Schema.org currently has a type for MovieTheater, but data required for movie showtime listings is missing. The proposal implemented in my GitHub repositiory, would add the following:

MovieTheater:

  • New property "screenCount" to describe the number of screens at a given theater

MovieEvent:

  • New type for movie screenings
  • Properties include:
    • screeningType: The type of screening (e.g. IMAX, 3D, etc)
    • subTitleLanguage: Language of subtitles
    • inLanguage: The language(s) the event is presented in.

Details at vholland@05dc056

@chaals
Contributor
chaals commented Feb 6, 2015

I support the MovieEvent, but would prefer it to be called screeningEvent, and the new / extended properties (although subtitleLanguage should IMHO be cased like that).

I'm not sure about the use case for screenCount - is this important for movie theaters?

@danbri
Contributor
danbri commented Feb 9, 2015

@chaals it's a type not property so assume you are asking for "ScreeningEvent" with an initial capital. The first thing that 'screening' makes me think of is airport security, so although bearable I wouldn't argue for that change.

@vholland - I don't see the most basic functionality here, which is indicating the particular movie that will be shown. While the workPerformed property doesn't directly apply in this use case (and I wouldn't propose stretching it) don't we need something similar to associate the event with the Movie? Could you post an example?

@danbri danbri added this to the 2015 Q1 milestone Feb 9, 2015
@vholland vholland was assigned by danbri Feb 9, 2015
@vholland
Contributor
vholland commented Feb 9, 2015

I was thinking about using workPerformed to associate the Movie with the MovieEvent. Something like:

{
"@context": "http://schema.org/",
"@type": "MovieEvent",
"name": "Blade Runner anniversary showing",
"startDate": "2015-02-09T21:00:00Z",
"workPerformed": {
"@type: "Movie",
"name": "Blade Runner"
}
}

@danbri
Contributor
danbri commented Feb 9, 2015

Seems a pity to dilute the reasonably clear 'workPerformed' property, but I guess bearable. Adding properties isn't without cost either.

If I wrote down events to describe MP3s I'm playing in my house, would workPerformed be the right relationship between the event and the work? It feels like an awkward stretch of 'performed'.

workScreened ?

@vholland
Contributor
vholland commented Feb 9, 2015

If this is a MovieEvent-only property, perhaps movieScreened?

@Aaranged

@danbri I was initially going to weigh in with essentially your same comment about a means of "indicating the particular movie that will be shown", but upon reviewing Event and its sub-types I came to the same conclusion as @vholland - that "workPerformed" fit the bill without the need to add any additional types or properties.

I still think that's the case, though it's indeed unfortunate that "perform" isn't better suited to the purpose. But not, I think, ill-suited enough to create a workScreened or movieScreened.

The conceptual provenance for an "event" seems to have been a music concert, for which "performer" and "workPerformed" work well - but obviously not as well for many other Event types. It hardly seems right that a presenter at a conference (BusinessEvent) should be referred to as a "performer", and it would certainly be odd to refer to a recipe (Recipe) for Chicken Tikka Masala made by Jamie Oliver as the "workPeformed" at a cooking demonstration (FoodEvent).

FWIW, I think "workFeatured" or "workPresented" might be generic enough to handle the majority of works associated with an event (the movie screened, the recipe demonstrated, the MP3 played, the painting displayed).

@tmarshbing

@Aaranged, I agree with your reasoning on workPerformed and also like the alternative of workPresented.

From a naming pov, the screeningType property also doesn't seem like a great name, particularly for the TelevisionStation domain. How about something like videoPresentedIn? I often hear things advertised as "presented in HD" or "presented in IMAX". Or if we want this to be specific to the resolution (seems like all of the examples are resolution-related), then we could name it something like "videoResolution".

@vholland
Contributor

How about videoFormat?

@tmarshbing

@vholland, videoFormat sounds good. How would you compare its use to videoFrameSize and videoQuality?

@Aaranged

Great points. I'd add that in addition to ""presented in HD" or "presented
in IMAX" there's also "in 3D!" This obviously transcends videoFrameSize
and videoQuality, so sort of makes the case for a separate videoFormat
property.

On Thu, Mar 12, 2015 at 9:44 AM, tmarshbing notifications@github.com
wrote:

@vholland https://github.com/vholland, videoFormat sounds good. How
would you compare its use to videoFrameSize and videoQuality?


Reply to this email directly or view it on GitHub
#328 (comment).

@tmarshbing

@Aaranged, good points. So would "in HD" go in videoQuality and/or videoFrameSize and "in 3D!" go in videoFormat? Or both in videoFormat?

@Aaranged

Gets tricky doesn't it?

"HD" should be trivial because it is a pixel dimension - 1920x1080 (well,
okay, 1280x720 is sometimes called "HD" and 1080P "full HD"), and could be
expressed with either videoFrameSize or by using media's height and width
properties. Ditto Ultra HD.

But it's also a more generic format, and also gives an implied nod to
aspect ratio which, AFAIK, no schema.org property covers or could be made
to cover. IMO "aspect ratio" (which, like "HD" can be either numeric as
"16:9" or descriptive like "letterbox") is another candidate for
"videoFormat", where I'd probably throw things like "HD" or "1080P" as well.

On Thu, Mar 12, 2015 at 3:26 PM, tmarshbing notifications@github.com
wrote:

@Aaranged https://github.com/Aaranged, good points. So would "in HD" go
in videoQuality and/or videoFrameSize and "in 3D!" go in videoFormat? Or
both in videoFormat?


Reply to this email directly or view it on GitHub
#328 (comment).

@vholland
Contributor

@Aaranged 's thinking is inline with mine. Looking at websites, people play fast and loose, mixing formats and aspect ratios interchangeably. I'll admit I am throwing up my hands a bit by giving a squishy property for people to fill in.

@tmarshbing

Sounds like we have consensus on videoFormat. @vholland, can you also add some guidance, possibly via examples, on what values publishers should put in the different properties, similar to the examples mentioned in this issue?

BTW, did we close on whether to implement the suggestion from @Aaranged on workPresented?

@romainlange

Then, which eventType would you suggest for a public screening of soccer match in a bar?
SportsEvent? ScreeningEvent?

@vholland
Contributor

@romainlange I personally would type the match itself as a SportsEvent and the public screening as a ScreeningEvent.

@vholland
Contributor

I am fine with adding workPresented to ScreeningEvent. I find it confusing to add it the Event as I would not know if I should use workPresented or workPerformed for a TheaterEvent.

@vholland
Contributor
  1. I changed MovieEvent to ScreeningEvent.
  2. I changed screeningType to videoFormat.
  3. I added workPerformed as property of ScreeningEvent with the idea we could promote the property to Event with some further discussion.
  4. I added example markup.

The changes are in pull request #387

@vholland
Contributor

I added a link to the BCP 47 standard from the subtitleLanguage description and fixed a typo in the inLanguage description.

@tmarshbing

Looks great!

@chaals
Contributor
chaals commented Mar 20, 2015

There's a relationship between subtitles, movies in general and ScreeningEvents in particular and some accessibiityFeatures like audioDescription or signLanguage.

Which makes me wonder about accessibility of the event - a venue's accessibility characteristics can vary, with specific things added for events (e.g. at a hotel used for a big accessibility conference there are some extra things they do specifically for the event). But that's future work.

For now this looks good to me - thanks.

@vholland vholland modified the milestone: sdo-gozer release, 2015 Q1 Apr 2, 2015
@rvguha
Contributor
rvguha commented Apr 7, 2015

Changes in pull request #387 look good. Closing this issue out.

@rvguha rvguha closed this Apr 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment