MovieLabs publishes common ontology for production
ibc.org
ibc.org
But it is not surprising given that large parts of film-making are now supported by software, which has a tendency to direct the evolution of terminology and concepts.
After a cursory glance at the model, it starts with a fairly generic set of primitives: Task, Asset, Participant, Context and Relationship. It then creates further instances based on this idea.
I'm sure other industries could also benefit from collaborative modelling of their problem domains like this.
I am sure there are people who like the model or hate the model, but its creative success in the twentieth is hard to argue with. I think as work forces become more flexible, it is something to think about.
Years ago, I knew a B-list director who did some of the early films that combined animation and live action. What he wanted to do was make movies with a team of 20 or 30 people. What he was stuck doing was managing a factory with 100-200 people. He was hoping that automation would get the size of the team down to where he could get back to directing. Much as word processing and publishing tools vastly reduced the size of the team needed to edit and print a book.
That didn't happen. Instead, it got worse. Much worse. Look at the credits at the end of a modern action movie. There are about a thousand people involved, at maybe 50 different subcontractors. Today there's a big pre-production and pre-visualization phase just to develop the plans and tooling to make the movie. The budgets are so big that nobody can afford a failure, so efforts to reduce risk dominate. Which is why most movies are now sequels or part of some "franchise".
The product I work on ends up doing a lot of work for order processing, stock management, logistics, etc. There is no industry standard ontology for anything. All off the shelf software works in different ways. Terminology is somewhat consistent but not at all formally defined.
The idea of being able to build software (or human processes) around a well understood ontology is great. Full software interoperability is a long way off, but building integration points is rarely the challenge when integrating, the real challenge is in adapting one way of thinking about a problem to fit someone else's entirely different model.
If this is close enough to reality then it doesn't even need lots of parties on board with "supporting" it, they could already be close enough. Having it all written down is a great next step that should enable a lot more products to enter the marketplace.
An industry-specific ontology seems a lot more tractable than a general purpose ontology for all industries.
I've been forced to use some, and it seems that someone got paid a lot of money to come up with something that's incomplete and poorly models the domain. So the net change is some XML doodads that no one really wanted or needed.
A lot of these ontologies depend on adoption in the organization and enforcement and without that these efforts really are show and of low utility.
Improving healthcare interop is not something that happens unless it is subsidized or penalized. 50 years of healthcare IT with systems that are basically the same with some new window dressing have proven that.
One particularly compelling example that comes to mind was an ontology involving public companies, figures, events, and relationships that was combined with NLP (entity and concept identification) over semi-structured content on the ETL side, and faceted search and navigation on the retrieval side, to replace a research portal for a major UK newspaper in the mid 2000s. The results were mind blowing.
Back in the dot-com era I was marginally involved in a project proposal for a business spun-out of a logistics company. They had developed an ontology that supposedly captured their parent business's (admittedly extensive) knowledge of global logistics, and had then built a multi-layered process model on top of it. From what I recall, the business model was that you could buy vertical (logistics speciality) and horizontal (level of detail) slices through the model that would express a subset of the domain knowledge in a way that could be somehow implemented (or executed?). It seemed very clever, as did the people, and the one time I went to their offices the walls were pretty-much covered in diagrams and post-its defining their massive model. I heard later that they had shut-down due to lack of sales.
What you described sounds really interesting and useful if I understand it correctly, and I can think of multiple times over the past decade plus that it would have been useful to use as a consultant for companies I've worked for, if it wasn't too costly.
Yeah I think I was maybe unfair on them to end it that way. They were probably ahead of their time, and it was a hard sell. I hope the people there went on to do more good things.
BTW, XML has fallen out of use for this stuff. JSON-LD can be very convenient, though.
Most of the difficulties are with matching artists and content across different databases, which is a separate issue. The ontology itself is tangential, but one example where it's important (even if it's not a fully / cleanly solved problem).
Relevant XKCD: https://xkcd.com/927/
This is meant to be an interop for various BIM (building information modeling) applications. The first generation of technical progress in AEC had been largely about computer generated geometry, but the lagging needs now are on the information attached to the geometry. In the US autodesk's Revit is dominant (and reviled) but the IFC open source development, namely ifcOpenShell & BlenderBIM, is rapidly reaching feature parity. The first computerized cohort of architects knows only AutoCAD, the current cohort will be all Revit, and I predict right now there is a new split coming as much better tools get built. Hypar.io, testfit, speckle etc are some of those tools. Ifc is likely to be a part of that, it's a fresher, cleaner take than awful Revit and opens up the information to much wider platforms.
Since (to paraphrase) the second hardest thing about software development is naming things, and software developers/filmmakers are likely to be unfamiliar with the other field's terminology, this guide is an attempt to provide suggested names of things such that everyone understands one another.
By relationships, I don't just mean A is related in some way to B, I mean (for example) A modifies B, or A requires B, or even A eats lunch with B. In short, they relate things to each other using whatever the verbs in that domain are. Imagine a database schema, but with richer information.
In theory, if you have a good ontology, you can translate an expert human's understanding of a system to something a computer can also understand. So if, for example, you were going to write software to orchestrate the production of a massive film, or a commercial production studio, you might benefit from a common ontology for film production.
In practice, ontologies in the wild have had limited success, historically, compared to expectations in the academic world around the end of the last century.