One problem with PVD (and probably others) is that the original source of the metadata isn't theirs. It's a gray area.
If you consider this as a means of providing your customers an automatic feed for video metadata, then it's a grey area—as in approaching the legal "dark side." But the suggestion here is to simply facilitate the importation of data users have collected on their own. There is no grey in the personal use of information publicly available on the web. Users may not only read it, they may copy it, save it in a file, or collect it in a database—as long as it's all for personal use.
As its name implies, this is what PVD is for. It's not for users who have no other interest but to "make metadata appear" in their media manager. It's for users who want to collect video information. It does automate the process—and some sources may object to that—but there is nothing "improper" about a user employing these techniques to maintain their
personal database. If the source doesn't feel this fits the intended purpose of their site and/or doesn't want to support the resulting traffic, they may (and some do) block this kind of bot use.
So, integration for purpose of making information in a
personal database available to MC is fine. As a MC and PVD user, I would very much like to see this happen. Integration for the purpose of using PVD as an indirect means to provide MC users with an automatic feed of metadata is not. I'm not at all concerned about this possibility, because I know it's not going to work. While PVD does a good job of managing the process of collecting information from a variety of sources, it's too complicated to expect the process to be managed directly from MC through any form of integration. The only viable option is to use PVD to collect and manage video information, and restrict "integration" to the mapping of PVD fields to MC fields and the importing of the data. I expect the latter could be done by connecting directly to PVD's Firebird database and could be handled in a manner similar to MC's other "auto-import" functions.
Avoiding that "grey area" leaves J River with two approaches to facilitating video metadata. One is to simply provide the information using a commercial service like AMG. This would have a cost, but it would provide good coverage, consistency and quality of information. Many users would be very happy with such a hassle-free solution. Unfortunately, it would not satisfy those of us who have made a hobby out of collecting video data, who need data for non-mainstream video, who are not English-speaking, or who simply prefer a different source. Integration with other applications like PVD is a solution for all of these needs. I think J River should consider providing both. If necessary, an additional fee could be charged for the "data feed" solution. Those for whom that doesn't work—because of cost, content, coverage, flexibility or language—should have some sort of "do-it-yourself" option.
My significant commitment to PVD makes me hopelessly biased, but it's still easy for me to say this: It would not be wise for J River to associated itself too closely with any one such application. PVD is a one-man operation, so development and support could end at any time (although in today's economic environment, this is probably a meaningless distinction). Supporting one may appear to exclude others. Although PVD is clearly the best choice for me, there are valid reasons for others to choose differently.
Perhaps the best approach would be to take the lead in establishing a generalized approach to integration with other applications for the purpose of importing metadata. While the nature of the integration required depends on the source, there is much that is or should be common to all. For example: a configuration interface for the mapping of the external source fields to compatible MC fields (and the ability to create custom fields on-the-fly); conversion of data to the format required by MC (e.g., dates, times, ratings); the actual writing of the data to the MC database. I'm not a technical person, so I don't know exactly what form the solution would take. I suppose it could be a base of code a user/programmer would complete for the creation of a plugin for connecting to a specific source. Or it might be an integral part of MC that relies on configuration data provided by a user, user/programmer or third-party developer to define how it connects to an external database or data file exported by the other application. It might even be a framework that incorporates the commercial source (e.g. AMG) solution.
Author
Topic: Movie Metadata Directions (Read 7397 times)