Link shows to a story entity, on Camdram or external

[ajf58]

Changes to the schema to reflects plays having productions which have performances. Use something like freebase or dbpedia. Pave the way for better creation of shows (e.g. autopopulate cast list, links between previous productions, productions of shows by the same playwright, download the soundtrack (revnue stream for camdram).

[philosophicles]

I don't necessarily think we want to implement anything with revenue (but making soundtracks available somehow for free or via another organisation who charges is cool).

If Camdram had a bank account / source of income, a number of things would get more complicated ranging from 'who manages the money' to 'who's responsible if it goes wrong' to needing to pay the Information Commissioner's Office money to be in their Data Protection Register, and probably loads in between.

[ajf58]

Camdram has annual costs, we need that money to come from somewhere.

[dstansby]

Out of interest what are the costs, how much are they and how are they covered at the moment? I would hope that if approached CUADC wouldn't be too averse to covering them if needs be!

[philosophicles]

OK, @ajf58's point is a fair one (I assume referring to hosting costs mainly).

I suspect this is a longer conversation that should perhaps not happen right now (given multiple features have to be implemented before anything could happen). I suppose all I'm saying is that it will need proper consideration when the time is right - where the money should come from, how to manage it, and other ramifications of having money. Don't want to open a can of worms really.

[CHTJonas]

This issue was opened in 2013 so massive fast forward to today (I'm triaging old issues)... 🕐

The current schema supports having shows which have multiple performances at different venues etc. and it also looks like Freebase was shut down on 02/05/2016 (see here) so I am closing this issue.

The Google Knowledge Graph API might serve a similar purpose but I'll let that be opened in a separate issue. I'd also argue that most people would probably prefer to use a Google search or iTunes purchase rather than implementing this functionality directly. But happy if other disagree.

[philosophicles]

I'm re-opening at least briefly as I think the original central intent of this issue might not have been clear @CHTJonas. If after this clarification, people still want to close it, then fine - but I think this should maybe have a slightly wider "vote" before closing as it is quite an interesting idea.

The central point (I believe, @ajf58 can of course correct me!) was extending the schema in a way that definitely still hasn't been done, to create something like a play object that abstractly represents a play, independently from any specific production. This would then be used to link up all the myriad productions (identical to our current show concept) of that play.

So there'd be one row in a play table for Macbeth, by William Shakespeare, published 1606. The primary key for this row would be present on the show table for every single production of that play/script.

A separate table could list the "standard" cast list for the play (as usually included at the start of scripts), so that could be auto-generated when somebody creates a new production of the play. Users would be free to add/remove cast if their adaptation has some differences. Similarly we could have a table listing authors/playwrights, with a single PK id for William Shakespeare, so all the plays by that author can be easily listed.

The freebase part was just a potentially easy way of populating these extra tables initially, but not the only way (we could crowdsource from Camdram data entry, for example). Google Knowledge Graph might be another but these are all just means to an end, not the end itself.

I do personally think this might be interesting extra data to use within the Camdram UI, and beneficial to end-users e.g. making it easier to surface data about most/least popularly performed plays, which might help guide choices of what gets staged next.

[philosophicles]

It is worth noting that our situation re annual costs has changed since 2013, so revenue is not so much of a concern I think.

[CHTJonas]

Oh I see exactly what you mean! Yeah this sounds like a neat idea - sorry I had totally the wrong end of the stick as to what the central point was! 😰

Running with this concept a bit, why not have tables for plays/musicals and films too (relevant to #320)? Would you be rid of the acts_shows table entirely or would you retain shows and have them link to FK's of performances and FK's of plays/musicals/films?

[GKFX]

If films become a concept in Camdram (and they should!) I guess you’d have acts_shows as it is now, acts_films being similar to acts_shows, and then acts_stories (better name required). So Macbeth is a single entry in acts_stories, and there are multiple performances of Macbeth in acts_shows linking to the single acts_stories entry. Then acts_films has similar links into that acts_stories entry.

There are large number of proposed schema changes scattered about the issues list now, I’m going to pull together a wiki page and try to get a solid idea of what the new DB structure should look like.

[CHTJonas]

Pulling them together sounds like a great idea! I'd take a quick look at the GitHub 'Projects' interface - I think it's probably much more what you're after maybe? 😝

[GKFX]

The GitHub projects interface is very nice. A summary of all the database-related issues is at https://github.com/camdram/camdram/projects/1?fullscreen=true.

[philosophicles]

I like it @GKFX. At some point a visual ERD of the proposed end-result DB schema could also be useful, maybe?

I don't think I can comment on tiles in that Projects/kanban interface, so:

• Films probably needs to be multi-layer just like live shows. We have acts_shows for the production and acts_performances for the actual performance events that comprise that production. Similarly a film has the production itself and could also have multiple screenings that would be shown in our calendar.
• The proposed acts_stories (I actually really like that as a name, personally) probably would need a separate table for characters?

[GKFX]

The most significant problem here I think is where to get data, and who we allow to edit data. Options that I can see are:

• Wikipedia and Wikidata. Easy, but we can't guarantee that character data will be present, and the notability requirement will exclude a number of shows.
• CUADC Wiki. Should be vandalism-free, but Cambridge Uni only.
• Anyone can edit story data on Camdram. Accessible, but vandalism likely.
• Only specifically approved people can edit story data on Camdram. Likely to discourage people from participating.

So far I'm leaning towards Wikipedia; I imagine most shows that get performed multiple times are Wikipedia-notable. This makes acts_stories effectively just a cache of Wikipedia leads and acts_characters a cache of Wikidata entries. However character information on Wikidata does seem poor from a brief look, and editing Wikidata is not very accessible.

[hoyes]

Another approach might be to use Camdram itself... I imagine if we looked at the cast list for every show ever named "Macbeth" then we could probably determine a likely cast list for future productions.

[philosophicles]

We don't necessarily need to take the same approach to data-sourcing for character lists as for the main story attributes (title, author, etc).

@GKFX, you might be overstating the risk of vandalism a bit. It's certainly a non-zero risk, but I think it's actually quite low. We know when Person descriptions were somewhat public-editable, only one really got 'vandalised', and it was done in good taste, bit of an in-joke, no harm done etc. Looking further back, remember that the Infobase was always publicly editable and definitely a theoretical target for vandalism - but as far as I can recall, it very rarely happened. Similarly, we very rarely get any abuse of show listing submissions.

The approach the Infobase took was that any logged-in user could edit, and changes went live right away, but webteam got a notification email with the diff of the change - no action necessary if it all looked OK, but could intervene if needed. I'd suggest a similar 'manage by exception' approach could work for this. The pool of reviewers could even be wider than just webteam, if we could work out a way of giving limited powers to more people.

For bootstrapping the dataset, I agree with @hoyes that Camdram's own historic data is probably a great start. I'd expect some kind of Pareto ratio - if we were able to bootstrap 80% of commonly-needed stories from our own trusted data, with a little manual curation and editing of the dataset, then the other 20% could be built gradually on-demand as time goes by.

[philosophicles]

This has made me realize that probably not all shows should be required to link to a story. Stand-up comedy, improv, some physical theatre, would not make sense to have stories created that would realistically only ever be needed once.

Similarly, new writing or original works that in theory could be performed again but realistically probably won't be - these maybe shouldn't be encouraged to have stories created. Keeping stories to just published things, perhaps?