|
|
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: Contribution Discussion |
Page:
1 2 3 4 5 6 Previous Next
|
Parsing unknown names |
|
|
|
Author |
Message |
| T!M | Profiling since Dec. 2000 |
Registered: March 13, 2007 | Reputation: | Posts: 8,738 |
| Posted: | | | | Quoting Gadgeteer: Quote: At the risk of repeating myself, we just need a common, understandable & indisputable default starting standard, with the provision of documentation to allow for differing from the default. At the risk of repeating myself: this will NEVER be solved as long as the name of the field doesn't match - even if only in the eyes of some of us - with what we're to enter into it. It is beyond me why you would want to introduce another discrepancy between the name of the field and its usage! The "production year" issue is far from solved, too: try "correcting" to production year to 2003 when the end credits give a clear 2002 copyright date on a couple of profiles... Despite the rules, it's very hard to convince the no-voters, let me assure you. Without renaming (or removing!) the field, you can put me down for a firm "no!". | | | Last edited: by T!M |
| Registered: March 14, 2007 | Posts: 2,366 |
| Posted: | | | | I wish that the middle name would be renamed to nickname, so the endless discussions of which name should be where will end. And we shall all live happily ever after... | | | Martin Zuidervliet
DVD Profiler Nederlands |
| Registered: March 14, 2007 | Posts: 742 |
| Posted: | | | | Quoting Gadgeteer: Quote:
The simplest and easiest to follow is: First Name\Anything Inbetween\Last Name
If you replace "Name" with "Word" to describe the parsing process, I'm 100% d'accord. Using the term "Name" in the field description and in attempts to explain how to parse is the only reason for all the disagreements and endless (and - because of the absence of any rule determining how to parse - also pointless) discussion. While I agree that it is not logical to regard a name simply as a collection of words to be put in three fields regardless of the eventual meaning behind that name, as a starting point it is one of only two practical ways to collect this information. It's easy to understand (first word / anything in between / last word - this concept doesn't take a diploma in literature or linguistics to grasp) and a starting point for any local changes until further valid documentation for a different way of parsing is provided. The second - and IMO better - practical way to enter this data is to remove the three fields and set up a single name field. It was like that before, and I'm pretty sure a crosslinking feature would also work if there was only one field. But alas, this seems to be another one of those never-ending topics, a perfect fir for the occasinal summer slump in new topics on this board (using the term "silly season" kind of prohibits itself in these circles I'd say ) | | | Lutz |
| Registered: March 13, 2007 | Posts: 519 |
| Posted: | | | | Quoting T!M: Quote: Without renaming the field, you can put me down for a firm "no!". The "production year" issue is far from solved, too: try "correcting" to production year to 2003 when the end credits give a clear 2002 copyright date on a couple of profiles... Despite the rules, it's very hard to convince the no-voters, let me assure you.
Bottom line: please let's not introduce another discrepancy between the name of the field and its usage! Just a simple renaming (or removing it altogether, of course!) would solve everything. In your example the no-voters are violating the rules and I would hope that the screeners would pick up on this along with the yes voters. The rules dictate what goes where, not someone's interpretation of the name of the field. Another example: the crew credits have a number of "roles to include" that don't match the DVD Profiler role. The last word is the rules. Having said that, I'm not totally against renaming the fields, I just don't think it's necessary. | | | Stuart | | | Last edited: by Gadgeteer |
| | T!M | Profiling since Dec. 2000 |
Registered: March 13, 2007 | Reputation: | Posts: 8,738 |
| Posted: | | | | Quoting Darxon: Quote: Quoting Gadgeteer:
Quote:
The simplest and easiest to follow is: First Name\Anything Inbetween\Last Name
If you replace "Name" with "Word" to describe the parsing process, I'm 100% d'accord. Agreed! As long as we keep calling it "names", this will never end. So yes, although it doesn't make much sense, I'd be willing to support that, as long as the rules and field names are changed to refer to "words" instead of "names", or something to that effect. But like you, I'd also prefer a single name field... | | | Last edited: by T!M |
| Registered: March 13, 2007 | Posts: 519 |
| Posted: | | | | If you rename the fields to 1st Word/Anything In-between/Last word, you will have people arguing against putting anymore than 1 name in the 1st or last field (eg H//B C), even if documentation is provided, because the field name says "Last Word" (singular not plural).
I say the simplest way is to add default parsing into the rules with provision of variances when documented.
This will be indisputable and allows the flexibility for cases like H//B C | | | Stuart | | | Last edited: by Gadgeteer |
| Registered: March 13, 2007 | Posts: 519 |
| Posted: | | | | How about we suggest renaming it to simply:
First/Middle/Last
this along with something in the rules on default parsing positions should suffice. | | | Stuart | | | Last edited: by Gadgeteer |
| | T!M | Profiling since Dec. 2000 |
Registered: March 13, 2007 | Reputation: | Posts: 8,738 |
| Posted: | | | | Quoting Gadgeteer: Quote: If you rename the fields to 1st Word/Anything In-between/Last word, you will have people arguing against putting anymore than 1 name in the 1st or last field (eg H//B C), even if documentation is provided, because the field name says "Last Word" (singular not plural). Yes, and I'd like that. No different treatment for the "happy few" where documentation can be found: we could simply parse them all exactly alike. Quote: I say the simplest way is clarify default parsing in the rules with provision of variances when documented. This will be indisputable and allows the flexibility for cases like H//B C There's no need to that kind of flexibility, because parsing is one of the hardest things to document. Just because someone was able to dig up a complete family history of Helena Bonham Carter, some people think that documentation is the answer. But I'd say that over 90% (probably more like 95%) of these parsing issues are undocumentable. I hate any system that allows me to enter Helena/Bonham Carter, but would prevent me from entering Viola/Kates Stimpson, just because I couldn't supply documentation for the latter. Needless to say I feel that both should be parsed in the same way. Either we use your proposal and parse all names alike - however silly that may be - or we don't. Letting this depend on documentation is a bit of a red herring, as you well known that it's near-impossible to document "correct" parsing of names. | | | Last edited: by T!M |
| Registered: March 13, 2007 | Posts: 519 |
| Posted: | | | | When I search for H//B C, I, and I suspect many others would type in the box Helena Bonham Carter.
The name parsed as H/B/C won't show, H//B C will.
This is one reason why we need to allow for properly documented flexibility. It must be functional and as accurate as possible. | | | Stuart | | | Last edited: by Gadgeteer |
| Registered: August 22, 2007 | Reputation: | Posts: 1,807 |
| Posted: | | | | Methinx the Rules should set different standards for different nationalities. If we are talking of an American actor, we could presume that the "word(s) in between" actually is his/her Middle Name, unless proven otherwise. If the actor is from a country where the Middle Name concept does not exist, using it would be nonsense in my view, and just bring confusion, so the "standard" should be a *national* standard, according to local usage. ...Unless Ken changes the fields to "first word in the name", "words in between", "last word in the name"! | | | -- Enry |
| Registered: March 13, 2007 | Posts: 519 |
| Posted: | | | | Quoting Gadgeteer: Quote: When I search for H//B C, I, and I suspect many others would type in the box Helena Bonham Carter.
The name parsed as H/B/C won't show, H//B C will.
This is one reason why we need to allow for properly documented flexibility. It must be functional and as accurate as possible. In addition, you will never get agreement amongst the community with no provision of the flexibility. However, I think we should be able to reach a consensus on a default starting point. | | | Stuart |
| Registered: March 13, 2007 | Posts: 519 |
| Posted: | | | | Quoting EnryWiki: Quote: Methinx the Rules should set different standards for different nationalities.
If we are talking of an American actor, we could presume that the "word(s) in between" actually is his/her Middle Name, unless proven otherwise.
If the actor is from a country where the Middle Name concept does not exist, using it would be nonsense in my view, and just bring confusion, so the "standard" should be a *national* standard, according to local usage.
...Unless Ken changes the fields to "first word in the name", "words in between", "last word in the name"! Are you suggesting that we check every cast member's nationality before we parse the name. It may be possible on the 'bigger' names but impossible for most others. This won't work. | | | Stuart | | | Last edited: by Gadgeteer |
| | T!M | Profiling since Dec. 2000 |
Registered: March 13, 2007 | Reputation: | Posts: 8,738 |
| Posted: | | | | Quoting Gadgeteer: Quote: How about we suggest renaming it to simply:
First/Middle/Last
this along with something in the rules on default parsing positions should suffice. If the rules would then specify that what is actually meant here are "words" (i.e. "First Word/Middle Word(s)/Last Word"), not "names", then yes, that would work. Still no exceptions then, though: each and every name should be parsed in exactly the same way. We would no longer recognize "first names", "middle names" or "last names", we would just spread the words over the three fields based on what we see. No room for interpretation, no room for exceptions, but hey: no room for any problems, too. I still feel the result would be kind of silly, and I'd prefer going back to two or even a single name field, but it does work, and would end all these debates immediately. |
| | T!M | Profiling since Dec. 2000 |
Registered: March 13, 2007 | Reputation: | Posts: 8,738 |
| Posted: | | | | Quoting Gadgeteer: Quote: When I search for H//B C, I, and I suspect many others would type in the box Helena Bonham Carter.
The name parsed as H/B/C won't show, H//B C will. This is blatantly not true: I just re-checked to be sure... Typing Helena Bonham Carter will show you both variants. Both ways of parsing have equal problems, though: using H/B C won't show her when you just look for just "Carter", using H/B/C won't show her when you just look for just "Bonham". But search-wise, there is certainly no "better" way to parse the names. Additionally, I feel that the search feature shouldn't dictate our preferred way of parsing - it should be the other way around. The search feature should be able to handle any way we choose to parse the names... | | | Last edited: by T!M |
| Registered: March 13, 2007 | Posts: 519 |
| Posted: | | | | Quoting T!M: Quote: Quoting Gadgeteer:
Quote: When I search for H//B C, I, and I suspect many others would type in the box Helena Bonham Carter.
The name parsed as H/B/C won't show, H//B C will. This is blatantly not true: I just re-checked to be sure... Typing Helena Bonham Carter will show you both variants. Both ways of parsing have equal problems, though: using H/B C won't show her when you just look for just "Carter", using H/B/C won't show her when you just look for just "Bonham". But search-wise, there is certainly no "better" way to parse the names.
Additionally, I feel that the search feature shouldn't dictate our preferred way of parsing - it should be the other way around. The search feature should be able to handle any way we choose to parse the names... I stand corrected. You're right, both do show. | | | Stuart |
| Registered: March 13, 2007 | Posts: 21,610 |
| Posted: | | | | Quoting Addicted2DVD: Quote: Once again... I agree... we do just need a standard to start with... and as was said can always fix any that is proven wrong with documentation. And I also see no reason to rename any field. All we need to do is get a standard starting point and submit it to Ken to put in the rules. I agree, Pete And the standard I use is based on the results the last time this came up and does quite nicely. But you see us poor Americans must bow to the Euro centric users, even if it is an American born name, because they are all naming experts and know precisely how every name should be parsed without proof. They really are a brilliant lot, especially when it comes to thinking that Europe is larger than the US, I am not sure in what regard that would be true, physical size and population certainly would not work to prove that point. This thread will eventually die down, only to be reolaced the next time someone else gets out their Magic 8 Ball. Skip | | | ASSUME NOTHING!!!!!! CBE, MBE, MoA and proud of it. Outta here
Billy Video |
|
|
Invelos Forums->DVD Profiler: Contribution Discussion |
Page:
1 2 3 4 5 6 Previous Next
|
|
|
|
|
|
|
|
|