For works about an Event, add the ability to specify the time described

[vickitardif]

In many cases, Articles, VideoObjects, etc are about a particular moment within an Event. Currently, there is no way to specify the time of the moment being discussed.

We should add a new property contentReferenceTime to CreativeWork to for this purpose. The property would expect the wall clock datetime of the moment as calculating the time elapsed within an event can be difficult. As an example:

{
  "@context": "http://schema.org/",
  "@type": "Article",
  "name": "Apple announces iPhone SE",
  "description": "New iPhone announced at 11:30 in California.",
  "about": {
    "@type": "Event",
    "name": "Apple's March 21 Announcements"
  },
  "contentReferenceTime": "2016-03-21T11:30:00-07:00"
}

[betehess]

What if the article mentions two events, happening at different times?

[Dataliberate]

Two events would be an issue, but I think that is just symptomatic of separating what is effectively information about an event out into a non-event type.

Would this not be better handled by more effectively describing part of an event with a type designed for the job.

Intangible > EventPart
   startTime   DateTime
   endTime    DateTime
   duration     Duration
   partOfEvent   Event

Then for the use described:

{
  "@context": "http://schema.org/",
  "@type": "Article",
  "name": "Apple announces iPhone SE",
  "description": "New iPhone announced at 11:30 in California.",
  "about": {
    "@type": "EventPart",
    "startTime": "2016-03-21T11:30:00-07:00",
    "partOfEvent" {
        "@type": "Event",
        "name": "Apple's March 21 Announcements"
    }
  }
}

Potentially this more generic solution could also help some other Event based discussions that are underway at the moment, such as presentations within a conference; sessions/innings in a sports event; acts within a theatre event. In which case Event would benefit from a hasEventPart property.

[vickitardif]

@betehess I don't think we will be able to get into such detail that an Article can be about multiple events and also be able to pinpoint exact sub-parts of each event.

@Dataliberate I considered that, but it seemed like a lot of complexity with an additional type to pinpoint a time for the focus of the Article.

[Dataliberate]

@vholland I see an Article about a specific part of an Event as a very narrow use case. If we imagined that only Article would want to reference part of an Event I would agree with your proposal, and your analysis of what I suggested. However there are many potential needs to reference such.

I get the feeling that this could easily become one of those odd-ball very specific constructs that we will soon regret later.

[vickitardif]

@Dataliberate It is increasingly common on sites like nytimes.com and washingtonpost.com to have articles or updates about specific moments. For example, for the bombings in Brussels, the nytimes had http://www.nytimes.com/live/brussels-airport-explosions-live-coverage/ with updates all around the bombings. Some sites do not bother giving the updates headlines as the NY Times does. Instead, it is a list of timestamps.

[Dataliberate]

@vholland I recognise the need you describe, although in the specific nytimes case you reference the time used is the time of the [update] article not necessarily the time of the event [part].

I do not see however, how that should cause us to implement a one-off simple single case solution that does not add any generic value to other similar cases.

As to Articles not potentially being about be about multiple events and be able to pinpoint exact sub-parts of each event. That may well be true when you are thinking about articles in daily newspapers etc. Broaden your scope to more scholarly articles or detailed analysis articles in a journal or Sunday Newspaper Supplement, it could be very possible.

Yes creating a new EventPart Type is a little more complex than just adding a property to CreativeWork; whilst adding little extra complexity to markup usage. However it makes more modelling sense in associating parts of an event with the event itself instead on one specific non-event type that might reference it. It also delivers generic benefit for all areas of the vocabulary that reference events, and potentially parts thereof.

[danbri]

Events can already have parts (subEvent / superEvent). But that doesn't give the useful hint from @vholland 's design which is that the document is specifically talking about moment(s) within the larger event.

You couldn't use CreativeWork + about + subEvent to distinguish between a post being about a battle that was part of WW-1, from being about a particular moment during an eventful day.

@betehess 's point is worth considering. If the constraint is being made that we're taking the primary or main topic, that ought to be reflected in the property's description. Alternatively, if the property is repeatable that ought to be made clear as well.

BTW I am floating a new workflow idea: I've made an experimental 'pending' extension for proposed terms, and am testing it on this issue, hence http://pending.webschemas.org/contentReferenceTime

[danbri]

OK this is "fixed" by virtue of being published in "pending", but I suggest we adopt the convention of leaving such issues open since we're soliciting feedback, discussion and deployment experience.

[danbri]

Here is some feedback from Google based on our experience with this property so far:

Regarding http://pending.schema.org/contentReferenceTime

Our feedback on this proposed property is that 1.) it adds useful expressivity into schema.org and has a reasonably clear meaning. 2.) we saw relatively low uptake in our use of the property so far in trials with publishers. We think this is partly because it was not essential to our usecase or required by our application-level validation 2.) it is was often difficult to identify the specific correct time to use in the markup. In conclusion we believe it is worth including the property in schema.org but that it will likely remain at a relatively low adoption level.

Our use case is basically mapping pieces of content (e.g. sports highlight videos) to the time point in a game during which the events actually occurred. Since content may have a variable publish latency, the contentReferenceTime property would help us understand the actual time the content maps back to.

[danbri]

My suggestion is that we keep this parked in Pending until it has a good accompanying example, at least capturing a 'breaking news' and/or sports usecase.