Ken:

I think it's time to turn our attention to a problem which once upon a time was a realtively minor annoyance but is becoming increasingly problematic. I have not done anty research on it yet myself to try and figure out the best attack on the problem but...Multiple covers for the same UPC# is becoming a larger problem almost by the hour, it doesn't usually impact me because I nearly always buy first releases, but ther are plenty of users it does affect, I wouldn't be at all surprised to see 3, 4 or even 5 different covers for some UPCs over time, I have even noted some titles get special new slip covers and i don't believe they have changed the UPC#.

I don't think thispresents an issue relative to data, typically, it does happen that the data can change, typically I think removing a WS presentation from a WS/FF title and simply leaving a FF at a much reduced price. But I think this is probably a rare enough issue to not be concerned with it to a large extent, and if it's not I have NO idea how we would be able to accomodate multiple datasets for one UPC#.

Skip

There are some movie released with variant covers aand the same UPC on the same date. Mulholland Dr comes to mind.

Rom:

Unless data deviations are more significant that what you described and a lot more numerous, I would say keep the data locally, it would get very complex to try and establish two separate datasets for a single UPC and for that work I would, were I the developer, be looking for a lot more significant changes than case type.

Skip

I would love to see this myself. There is many titles that I have an alternate cover for. Yes some has alternate data as well. But far from all of them.

We would of course need a way to tell Invelos when it is an alternate cover instead of a better version of what is already there. And when there is already more then one online which cover you are trying to improve.

Quoting Woola:

Quote:
Rom:

Unless data deviations are more significant that what you described and a lot more numerous, I would say keep the data locally, it would get very complex to try and establish two separate datasets for a single UPC and for that work I would, were I the developer, be looking for a lot more significant changes than case type.

Skip

We already have "separate databases for a single UPC", as long as the locality is different. It looks as if the only requirement would be the ability to split not only on basis of locality but also on basis of one other selector (could be just a number, or release date, or whatever works for the programmer).

If the cover is different, the overview can be different to. It could be as subtle as a correction of typos, but it could be a completely new overview. It could also be that the overview was in English on the original cover, and that it has been translated to the locality's language in the new version.

And if it's a re-release, not only will the release date be different, but it's likely that the MSRP has been lowered as well.

But - I think the most common situation where UPC and locality is not enough to separate releases, is when an old movie is released in a box-set, and you have to use disc id as the UPC. If the same disc is used in two different box sets, with two different covers (or one box set is a slip case and the other is a digipak), one of the box sets will have to use the profile from the other. This can be particularly problematic if the movie was first released as a two-disc special edition, and both discs are used in the first box-set, then when its included in a different box set, only the first disc is included. In this case it's impossible to represent that second box set correctly.

I believe some of this could be solved by changing the data model, and letting features, audio&subtitles, cast and crew be a property of a disc instead of the profile itself. This would have the added benefit of getting rid of a lot of redundant data, and making sure that every profile that include a particular disc will have the latest information, no matter which profile a correction is submitted for. This would also mean that the only difference between a TV-set with individual child profiles and one without, will be that the individual profiles will have a cover (which may be identical to the parent profile's cover).

Quoting Staid S Barr:

Quote:
It looks as if the only requirement would be the ability to split not only on basis of locality but also on basis of one other selector (could be just a number, or release date, or whatever works for the programmer).

Basicly, yes. But as for "release date" as this distinguisher I want to quote myself from an earlier thread on this subject:

Quote:
...that would mean that the release date has to become mandatory. If I can't find a release date, what then?
And what happens if the release date has to be changed? Would that change the profile or spawn another copy? Both ways can lead to trouble.

And we should clarify what exactly we are talking about: one profile distinguished by UPC/EAN and Locality with 'just' multiple covers or going for broke and UPC/EAN, Locality and $Third_Key?

And to play devils advocate: what if the $Third_Key isn't as good as we thought and such a disc will still be send out with different covers or even with/without slip-cover?

Maybe the 3rd key should be a simple number, call it Variant_Counter or something. Handling in Profiler could be similar to UPC/EAN and Locality: if you want to change the variant, you change the number to an existing or delete the number and then submit the profile for allocation of a new variant number. On the database-end such a submission should be handled like a new submission, with a very good documentation from the submitter as to why this is a new variant and not an update.

cya, Mithi

Quoting Woola:

Quote:
Rom:

Unless data deviations are more significant that what you described and a lot more numerous, I would say keep the data locally, it would get very complex to try and establish two separate datasets for a single UPC and for that work I would, were I the developer, be looking for a lot more significant changes than case type.

Skip

Ya I agree, it just the case type and the titles that changed.