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

On 19 November 2014 22:41, Tom Marsh <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 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]
> *Sent:* Wednesday, November 19, 2014 10:24 AM
> *To:* W3C Web Schemas Task Force; Dan Scott; Vicki Tardif Holland
> *Subject:* Re: 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> 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
>
>
>