The information after the slash is important if it indicates a different
DXCC entity than the one indicated by the station call (for example,
KP2/W3WN). It is not important, for DXCC purposes, if it indicates
mobile/portable/rover (W3WN/3, W3WN/M), or if it indicates the county of
operation for a QSO Party (W3WN/ALL), as these can be handled via the
Station Location information on upload.
The problem is that while a human being can, most of the time, process this
correctly in view of overall context, a computer can not. So someone would
need to (re-)design the software to handle these situations. Which means
someone would have to define to the software all of the possibilities, such
as when /M means Mobile, but M/W3WN means the UK; or when /MM means maritime
mobile but MM/ means Scotland; and so on and so forth ad infinitum ad
nauseum.
Would I like to see Logbook of the World handle (or better handle) these
nuances? Of course. But... someone is going to have to do the work or pay
a professional non-volunteer programmer to do it. Who does the work, or who
pays the freight? Until I have an answer, I'm not going to put in a formal
request that these changes be made... to put it another way, if I can't help
pay the piper, I'm not putting in a request on the tune.
73
-----Original Message-----
From: cq-contest-bounces@contesting.com
[mailto:cq-contest-bounces@contesting.com] On Behalf Of Michael Coslo
Sent: Thursday, May 07, 2009 8:30 AM
To: CQ Contesting Reflector
Subject: Re: [CQ-Contest] Mobile operation uploads to LOTW
On May 6, 2009, at 7:18 PM, Ed K1EP wrote:
> At 5/6/2009 11:07 AM, Michael Coslo wrote:
>
>> On May 4, 2009, at 7:40 PM, Robert Chudek - K0RC wrote:
>>
>> > Someone reported on this list (probably last year) when they
>> > questioned the
>> > LoTW desk about this, their suggestion was to upload the log twice,
>> > once as
>> > the root CALLSIGN and then as CALLSIGN/M in order to increase the
>> > likelihood
>> > of a qso match.
>>
>> I'm speechless! Entering double logs may be the worst workaround I've
>> ever seen.
>
> I have done this and it has been recommended by the LoTW people (at
> least to me). I have logs with callsign/# and callsign. Some log
> the /# and some don't. If I upload the same log signed both ways,
> then more will get a match. I have a lot of logs with callsign/M
> or callsign/CTY also. I have uploaded both. I don't see why it is
> "the worst workaround".
A matter of temperament, I guess. It's the reason I don't order two
steak dinners in case one isn't to my liking. 8^)
I deal to a fair degree in databases. Duplicate data in a database is
not a good thing. Almost the same data that is kinda duplicated but
not really sorta is even worse. Are both correct? Is only one correct?
If the database rationale is such that a "/m" is mandatory between
both, or the lack of "/m", depending on what the other station
copied, it is really messy. Besides if the rationale is that strict,
then the callsign had better be exactly as you sent it to the other
OP, or he didn't copy it correctly, therefore it is a busted QSO.
Thats a little verbose, but strict begets strict, and it isn't a good
idea to have a database so strict that you have to enter multiple and
different entries (therefore going from strict to two entries per QSO
- talk about going from one end the the other!) to get a match. That's
a big indicator that something is wrong.
We're dealing with humans, and evolving modes of logging and operating
over time, so we need a rationale that takes that into account. People
are going to append things to their callsign, we aren't going to stop
it, and we'll probably get a resolution to that about the same time
we settle the argument of 73 versus 73's. 8^)
A better rationale is to
1. insist that the callsign be correct, that is to say if W1AZX is in
a log, we should have that part right.
2. Due to human nature, and the differences in how callsigns are often
done now and that /'s were once a bigger part of the picture, and are
still required in some cases, (upgrade period between testing and
getting the wallpaper), the slash should indicate that what comes next
might be ambiguous, so it should be ignored or included without
judgement.
3. search queries should be made with the callsign, and not the data
to the right of a slash. I suspect that the log that did not have the /
m would pull up a match if it was searched first, not not the other
way around.
This is a function very much like dupe searching in logging software,
except we want the duplicate. If say counties are included to the
right of the slash, most software that checks dupes will show all the
counties, as long as just the callsign is entered.
And that is why it is a bad workaround. There shouldn't be a
workaround, there should be a bit of rewrite.
-73 de Mike N3LI -
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|