This looks like a large scale domain modelling problem for the movie production process. This is the last place I was expecting an overlap between computer engineering and film-making.
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.
Ontology is part of philosophy, and concerns itself with what exists; domain modelling is ontology applied to systems (typically software and/or bureaucratic systems).
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.
Between ISO, UN CEFACT/OASIS, the now irrelevant/repivoted OMG, etc it isn’t like the idea is a new one or that anything isn’t written down - there are formal standards (insert xkcd here). The incentives for widespread adoption are just not there.
And cost - most standards organizations charge money for implementations and for training. I find it no coincidence that the most widely implemented standards are the ones that you can learn about and implement for free.
The movie and film production process currently involves a large web of organizations, including both traditional movie production studios and software development firms. These firms have to be able to communicate effectively and work together, so they need a common language that they can use to describe concepts.
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.
An ontology describes the things in a system and the relationships between them.
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.
Are there any real success stories for "ontolgies" like this? It seems like a lot of them are made, but they're ultimately not that useful.
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.
Modern production pipelines have a lot of dynamic human fueled workflows with orchestration - having a common syntax definitely helps those in the control room and operating systems and tools have a common way to exchange - especially in a remote setup. The netflix production team also has done a great job of standardizing the vocabulary across their production systems.
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.
Disparate ontologies are ripe in the medical field (SNOMED, ICD 9/10, etc) and there are companies[1] trying to map between them for better interopt between healthcare networks.
Medical ontologies are different because there are two enormous economic incentives for their adoption: billing, in the US or any private healthcare - and medical research much of which is highly incentivized by the pharma, device, and diagnostic industries.
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.
Yes. In the early 2000s Endeca made use of several public ontologies to enhance its information access and summarization products for clients.
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.
> Are there any real success stories for "ontolgies" like this? It seems like a lot of them are made, but they're ultimately not that useful.
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.
Sometimes it's hard to know if a business failed because the idea was bad, the market wasn't ready, they didn't execute well, they didn't advertise themselves effectively to let clients that could benefit know what they could offer, or some combination of multiple of those.
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.
> 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.
Complex ontologies (including logical constraints, etc.) have mostly been a failure, but lightweight shared vocabularies/taxonomies can be very useful. See schema.org for a typical example of what these are like.
BTW, XML has fallen out of use for this stuff. JSON-LD can be very convenient, though.
Music metadata (Musicbrainz, AllMusic, etc...) comes to mind. The data is usually more important than the ontology itself, and the ontology is not really consistent across the entire industry, but it's a somewhat relevant example.
The scope of those is pretty limited (i.e., helping people categorize their discogs with a dozen or so common fields) and isn't really a "musical ontology" where you're hooking it up to a first order logic solver and reasoning about music or whatever mythical use case drives most of that work.
Sort of... They are used at scale to share and ingest data between services, for things like recommendations, etc. But it is messy, a lot of the ontology is more or less the same but every company/database does things slightly differently.
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).
Unfortunately the music field never had such collaborative effort to build a unified ontology, so each big player have its own ontology, and they are not very compatible. From personal experience, building software that consumes data from multiple sources in music is a nightmare, it is impossible to design a data model that fits all the incompatible ontologies.
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.
In the US there are guilds that have rules that decide who can claim what production and who is qualified to do what job. That is one of the main reasons why while film is really specialized ("gaffers", "grips") you can on a US production know you have people who know how to do what they are supposed. It lets huge movies staff up or staff down really fast.
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".
32 comments
[ 6.6 ms ] story [ 87.6 ms ] threadBut 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.
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.
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.
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.
[1] https://clinicalarchitecture.com
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.
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".