RE: schema.org Series generalized, VideoGameSeries added for sdo-venkman release

Thanks for the changes and responses. They all look good to me.

From: Dan Brickley [mailto:danbri@google.com]
Sent: Thursday, November 20, 2014 6:32 AM
To: Tom Marsh
Cc: W3C Web Schemas Task Force; Dan Scott; Vicki Tardif Holland
Subject: Re: schema.org Series generalized, VideoGameSeries added for sdo-venkman release

On 19 November 2014 22:41, Tom Marsh <tmarsh@exchange.microsoft.com<mailto:tmarsh@exchange.microsoft.com>> wrote:
A few questions/comments:

For Series, what are startDate and endDate referring to? Is this the time when the series was published/aired? If so, how would we model a TV series that is rebroadcast or similar cases?

There's a limit to how much nuance we can overload a single pair of properties with for Series in general, or even down at the level of TVSeries. As you say there are rebroadcasts, in different geographies, not to mention the rise of video on demand availability. We might add something like "the main or most obvious" to the general definition of "startDate", "endDate", although appealing to commonsense isn't the most helpful of techniques. My intuition says that for TV series it would be the broad period from when it was first broadcast, until the last episode was made and broadcast. Repeats, on-demand, etc. would need modeling explicitly elsewhere.

http://blog.schema.org/2013/12/schemaorg-for-tv-and-radio-markup.html is the overview blog post for this, and it leans on the earlier Programmes Ontology. There is a http://schema.org/BroadcastEvent construct that could be used to directly carry such dates for an entire (TV etc) series, or else derrived from aggregate BroadcastEvent data for various episodes. This is an area where more (and realistic) examples are super important since there are so many types/properties that need to be used well together.

Also we don't currently link our handful of explanatory blog posts from the site, which is a great shame as they say more than the schema.org<http://schema.org> site. I'll work on implementing that before the upcoming release (for Action and Role too).

TVSeries still has endDate. We don’t need this now that Series has endDate, do we?

Thanks for catching that one :) As anticipated yesterday when I cleaned most of these, it was easy to miss.

Suspecting that there might be more of these (and indeed there were several, mostly media-related), I've:

1. opened an issue on github, https://github.com/rvguha/schemaorg/issues/174

"No subtype need redeclare domainIncludes, rangeIncludes of its parents"

2. wrote a couple of SPARQL-based tests, marking them as "@unittest.expectedFailure"

3. updated the RDFS to remove such redundant type/property associations.

4. marked the test as passing

This is probably a good habit to get into. SPARQL is much better at spotting these things than me :)

I have left the issue open since it needs more work to deal with pairs of types that aren't neighbours in the hierarchy. The underlying toolkit rdflib should handle this but I didn't have much luck with rdfs:subClassOf+ notation today. It did catch a good number of other redundancies though.

BTW to encourage more use of our unit test machinery I've also just rigged up an option ("./run_tests.py --skipbasics") that bypasses the most basic tests for frequent use. It only shaves 0.5 seconds of the time to run the data-oriented tests but every little counts I guess.

The tests are at https://github.com/danbri/schemaorg/blob/sdo-videogameseries/tests/test_graphs.py#L79


Similarly, there are a bunch of properties that seem redundant with hasPart and isPartOf (assuming I can use these to link from series to both episodes and seasons). Should we deprecate these? Examples are episode and season on the various Series subtypes, partOfSeason and partOfSeries on Episode, and partOfSeries on Season.

That is a good idea, and consistent with our usage of subproperties elsewhere. I think we ought to do this.

I don't believe we *need* to do this for the imminent release but I'd entirely support doing so if others are enthusiastic. I've dug out all the relevant partOf* properties and filed an issue for now:

https://github.com/rvguha/schemaorg/issues/175


cheers,

Dan


Tom

From: Dan Brickley [mailto:danbri@google.com<mailto:danbri@google.com>]
Sent: Wednesday, November 19, 2014 10:24 AM
To: W3C Web Schemas Task Force; Dan Scott; Vicki Tardif Holland
Subject: Re: schema.org<http://schema.org> Series generalized, VideoGameSeries added for sdo-venkman release


Please take another look. http://sdo-venkman.appspot.com/Series


This is a larger attempt at a general Series type, following the direction of this thread and github discussions.

There are subtypes for TVSeries, RadioSeries, as before; however we also add minimalistic MovieSeries, BookSeries, as well as bringing in Periodical and the new VideoGameSeries type. Media-specific
properties have been pushed down into the movie-tv-games-radio areas.

There are probably some rough edges, but feedback on the general direction would be useful. The intent is for Series' definition not to seem too weird for either written or media content. This means it has to be general, so we balance that by linking very explicitly to the subtypes for detail...

Does this work? Does it seem too hasty to include MovieSeries, BookSeries here or does that help in rounding out the picture and general approach? We could comment them out and discuss them at more leisure later if they do seem too tricky to get right...

Dan

ps. full implementation details are in this branch, https://github.com/danbri/schemaorg/tree/sdo-videogameseries


On 18 November 2014 20:43, Dan Brickley <danbri@google.com<mailto:danbri@google.com>> wrote:
[snip]

Ok, so it appears I tried to implement the rough consensus in
https://github.com/rvguha/schemaorg/issues/148 too hastily, and also
ran into some legacy baggage in our schema structures. In particular I
missed out the idea that we would introduce subtypes of Series such as
(initially) VideoGameSeries, so that the less generic Series
properties (episodes, actor, director etc.) *could* migrate down to
the subtypes. I would like the wording of Series to be open to its use
with books, periodicals etc even if the presence of 'director',
'actor' is (perhaps temporarily) awkward. If there are sites today
publishing TV and radio Series data using the top class Series, rather
than specific subtypes, it seems awkward to remove properties from
Series. I'll dig around to see how many such cases I can find.

In favour of the present wording, Dan Scott in the github issue did
say "@danbri @Dataliberate Actually, I don't have a problem with the
wording; books, comic books, pamplets, etc are all forms of media
(print media).". But "A media series, e.g. TV, radio or video game."
needn't be the final word on Series. It surely won't be.

There is also the question of how many of the VideoGame properties to
also attach to VideoGameSeries. I went with the simple approach of
saying "all of them", even if some of them will be unlikely. We could
prune a few perhaps.

Anyway I'll take another pass through this tomorrow and hope to return
here with something more polished. The legacy baggage that needed
tidying is that (for old implementation reasons that have gone away
since we moved to appengine/github) there were various properties that
listed domains including both e.g. Series and TVSeries, RadioSeries.
That was a hack needed to make the TV/Radio improvements last year
work with the existing site codebase. I'm removing the redundant
subtypes and tidying some old text...

Dan