|
|
Welcome to the Invelos forums. Please read the forum
rules before posting.
Read access to our public forums is open to everyone. To post messages, a free
registration is required.
If you have an Invelos account, sign in to post.
|
|
|
|
Invelos Forums->DVD Profiler: Desktop Feature Requests |
Page:
1 2 Previous Next
|
Ignore parsing (First, last, middle name), similar to mixed cases in Cast and Crew |
|
|
|
Author |
Message |
Registered: January 1, 2009 | Reputation: | Posts: 3,087 |
| Posted: | | | | For names like Amy MacDonald since a while the program ignores the different cases: So If in a profile is Amy Macdonald, but I have her local as Amy MacDonald the name in profile gets change to the local variant. (with "D")
I would like to see it the same way for different parsings. Til now it can happen I have got (for example) Sheri Moon Zombie// Sheri/Moon/Zombie Sheri//Moon Zombie in my database, because of the different ways someone entered it in a profile. For every different variant in a profile I download, the program adds a new variant in the local database.
I would like the program would change the variant in profile to what I have in database. So if I have Sheri//Moon Zombie in database and I download a profile with Sheri/Moon/Zombie the entry should change to my local variant (Sheri//Moon Zombie) and not an adition of a new entry which doesn't link correct.
I think if the string of a three fields together would get compared from local to profile variant and based on that, the change would be made, could work.
I think the pro can everyone imagine, but as always there is also a con: For different actors that really just are different because of the parsing we would need to add a Birth Year to distinguish. (But I think we do this already) As I don't know an existing example, a fake example: Two actors with the name Hans Hermann Meier. One parsed Hans/Hermann/Meier correctly. Second parsed Hans//Hermann Meier correctly. With the new system we can't make different entries for them. (Just with BY)
Second con gets the prob of Ken: To get this new feature working some kind of Tool is needed to get the local database cleaned up of the different variants. (Not every users removes those variants always or every variant)
Because I often heard of the idea of just one name field for complete name: With my suggested option we still would be able to have the different fields (sorting, ...) and we could have it local as everyone personal thinks it is correct.
Edit: Would wonder if this would have never been suggested. | | | Last edited: by VirusPil |
| | T!M | Profiling since Dec. 2000 |
Registered: March 13, 2007 | Reputation: | Posts: 8,736 |
| Posted: | | | | Quoting VirusPil: Quote: For every different variant in a profile I download, the program adds a new variant in the local database. No, it doesn't. Instead, if you already have the person in your database, any new profile you download with that person in it will automatically use the same parsing that you had in your database already. Other than that, I would LOVE if the system would ignore parsing differences. For me, the key part of that is in the contribution system. As I just explained, newly downloaded profiles automatically adopt the parsing you had locally (for the people that were already part of your database). So far, so good. But it all goes awry as soon as you want to contribute such a profile: any parsing differences will show up as part of the contribution, even if you didn't mean or even want to, and those changes often attract no-votes. So IMHO, that's where "ignore parsing" should be applied: in the contribution system. |
| Registered: January 1, 2009 | Reputation: | Posts: 3,087 |
| Posted: | | | | Quoting T!M: Quote: Quoting VirusPil:
Quote: For every different variant in a profile I download, the program adds a new variant in the local database. No, it doesn't. Instead, if you already have the person in your database, any new profile you download with that person in it will automatically use the same parsing that you had in your database already. ... Do you say if I have got profile A with Franky G// in database and I would download a profile B made by you with a Franky//G it doesn't add a new variant and uses also Franky G// in my local database? This is what I meant and I do suggest. |
| | T!M | Profiling since Dec. 2000 |
Registered: March 13, 2007 | Reputation: | Posts: 8,736 |
| Posted: | | | | Quoting VirusPil: Quote: Do you say if I have got profile A with Franky G// in database and I would download a profile B made by you with a Franky//G it doesn't add a new variant and uses also Franky G// in my local database? That's exactly how it works, yeah. So if that's your feature request, you're in luck - it already works that way since quite a while. As I said, that doesn't eliminate the parsing problems, though. It helps for our local databases, but not for online purposes. What we need is to have the contribution system ignore parsing differences. |
| Registered: January 1, 2009 | Reputation: | Posts: 3,087 |
| Posted: | | | | Quoting T!M: Quote: Quoting VirusPil:
Quote: Do you say if I have got profile A with Franky G// in database and I would download a profile B made by you with a Franky//G it doesn't add a new variant and uses also Franky G// in my local database? That's exactly how it works, yeah. So if that's your feature request, you're in luck - it already works that way since quite a while.
As I said, that doesn't eliminate the parsing problems, though. It helps for our local databases, but not for online purposes. What we need is to have the contribution system ignore parsing differences. What would then be a big reason to do such things? Til it never will influence my local database, the voting and online prob isn't this big. (Since we will often don't know the correct way) Wow, now I see a sence in cleaning up my local database. Many thanks for the information. |
| | T!M | Profiling since Dec. 2000 |
Registered: March 13, 2007 | Reputation: | Posts: 8,736 |
| Posted: | | | | Quoting VirusPil: Quote: What would then be a big reason to do such things? Because of, again, the fact that the contribution system doesn't ignore parsing differences, and many users will vote against contributions because of parsing differences - with both parties claiming their way is "correct" and no way to actually reach an agreement. That's why. |
| Registered: January 1, 2009 | Reputation: | Posts: 3,087 |
| Posted: | | | | Quoting T!M: Quote: Quoting VirusPil:
Quote: What would then be a big reason to do such things? Because of, again, the fact that the contribution system doesn't ignore parsing differences, and many users will vote against contributions because of parsing differences - with both parties claiming their way is "correct" and no way to actually reach an agreement. That's why. I understand this, but why should this bother me if this doesn't influence my database? With a good explanation a parsing change gets also in online database and if not (Which will often happen): This doesn't influence the users local database. So why should I waste my time with argueing then? That's why I did this feature request: I wanted to have one point less of argueing. |
| Registered: January 1, 2009 | Reputation: | Posts: 3,087 |
| Posted: | | | | So as my original idea apparently is implented, I would change it to get the problem mentioned by T!M solved.
So the online database parsing does just influence our local database at the first addition of a cast/crew member.
How about this: The program should ask at an addition of a new cast/crew member if I want to take the existing online parsing, if not it should give me the possibility to change it. |
| Registered: March 13, 2007 | Reputation: | Posts: 3,197 |
| Posted: | | | | Well, I voted for Other. Because I find name parsing totally useless and a complete waste of time, I want a single name field only. | | | First registered: February 15, 2002 |
| Registered: March 29, 2007 | Reputation: | Posts: 4,479 |
| Posted: | | | | Quoting VirusPil: Quote:
So the online database parsing does just influence our local database at the first addition of a cast/crew member.
That is not exact, as I demonstrated in this post. In your local, you may have two different parsings for the same actor. In fact, I hate everything that automatically decides at my place what has to be in my database. A warning is good, an automatism is a nightmare. I would prefer rules ask us to enter just correct parsing/spelling of names than any "CLT decided" or "automatically decided by system" data. And for people thinking that correct spelling/parsing data is difficult to find, there is a site called Google which allows to find them easily in 99% of cases. | | | Images from movies |
| Registered: January 1, 2009 | Reputation: | Posts: 3,087 |
| Posted: | | | | Quoting surfeur51: Quote: Quoting VirusPil:
Quote:
So the online database parsing does just influence our local database at the first addition of a cast/crew member.
That is not exact, as I demonstrated in this post. In your local, you may have two different parsings for the same actor. ... But in your example it was a manual addition in your local database. Not the addition of an actor made by the program. Edit: If it was an addition by downloading a profile with a different parsing variant, then I have to go back to my original request. Quote: In fact, I hate everything that automatically decides at my place what has to be in my database. The program should just change to the variant you have in database. So you'll get the parsing variant which you decide is the correct. | | | Last edited: by VirusPil |
| Registered: January 1, 2009 | Reputation: | Posts: 3,087 |
| Posted: | | | | Quoting KinoNiki: Quote: Well, I voted for Other. Because I find name parsing totally useless and a complete waste of time, I want a single name field only. If the field length of the name fields would increase, you could write all names in first field, with my idea. (Don't know if this would least long in online database, but once changed local nothing else would be needed) |
| Registered: March 29, 2007 | Reputation: | Posts: 4,479 |
| Posted: | | | | Quoting VirusPil: Quote:
But in your example it was a manual addition in your local database. Not the addition of an actor made by the program.
If you have already both actors in your database, which one is chosen ? You forget that old versions of DVD profiler allowed to download differently parsed names, and, if you have not cleaned your database, you may have kept them from old profiles. | | | Images from movies | | | Last edited: by surfeur51 |
| Registered: March 14, 2007 | Reputation: | Posts: 4,667 |
| Posted: | | | | Quoting KinoNiki: Quote: Well, I voted for Other. Because I find name parsing totally useless and a complete waste of time, I want a single name field only. Me too. The only downside that I can see is that you can't sort on last name, but since we cannot seem to agree on what the last name is for many actors, this isn't very useful today either. | | | My freeware tools for DVD Profiler users. Gunnar |
| Registered: January 1, 2009 | Reputation: | Posts: 3,087 |
| Posted: | | | | Quoting surfeur51: Quote: Quoting VirusPil:
Quote:
But in your example it was a manual addition in your local database. Not the addition of an actor made by the program.
If you have already both actors in your database, which one is chosen ? You forget that old versions of DVD profiler allowed to download differently parsed names, and, if you have not cleaned your database, you may have kept them from old profiles. I know, but still thanks for the hint. I need to do a clean-up of my local database to get this working properly. (That's why I suggested in op a tool which helps me before the new system would be introduced, seems this wasn't made ) I guess if yóu have two variants in local database it links the downloaded to the exactly matching. But I have no idea what would happen with a third variant. |
| Registered: January 1, 2009 | Reputation: | Posts: 3,087 |
| Posted: | | | | Quoting surfeur51: Quote: ... I would prefer rules ask us to enter just correct parsing/spelling of names than any "CLT decided" or "automatically decided by system" data. And for people thinking that correct spelling/parsing data is difficult to find, there is a site called Google which allows to find them easily in 99% of cases. As you know and everyone can imagine from this ond other feature requests, I'm more in favor for solutions which give the user less work and not more work, but with the best possible freedom for the single user in his local database. |
|
|
Invelos Forums->DVD Profiler: Desktop Feature Requests |
Page:
1 2 Previous Next
|
|
|
|
|
|
|
|
|