| |
On Fri, 8 Feb 2002, Kevin Loch wrote:
> > Is that a request to actually solicit 1999 set scans?
> Yes!
> The FTP service is still offline, so the only way to submit
> right now is via email.
Okay, now I really have to propose this idea that's been banging around in
my head for the past few weeks. The motivations come, in part, from my
work organizing and grading my EQMM collection[1] and from reading the
LUGNET Plan[2].
I think that the LUGNET set database (and similar databases) could be
greatly enhanced by adding fields for *quality* of volunteer information,
and then using that information to ease information submission to the
database[3]
Specifically, I'm imagining a way of recording quality of information in
the database. Currently, data quality (or validity) is almost
binary---there is a known MSRP or there isn't, there is a picture or there
isn't. I propose that there be some way of evaluating what information is
correct and verified by others, and what information fans could help with.
As a simple example, each set has a piece count (if known). It would be
really nice if (say) Lugnet members who own the set could easily push a
button to verify that yes, that is what the box says, and then have their
names recorded as having verified that information (giving responsibility
and credit).
As a more important example, consider the picture that each set in the
LUGNET database has (I think there's just one picture, automatically
resized to standard, thumbnail, and supersize). The database admins do a
great job of getting a picture in the db as soon as possible. It would be
even better, however, if there were a way to say "The db has a picture,
but could use a better one." For example, consider
http://guide.lugnet.com/set/1349
This has a good picture (probably grabbed
from shop.lego.com), but the
supersize picture
http://guide.lugnet.com/set/?q=1349_1&v=z
really isn't as large as it could be to show detail. A scan of the first
page of the instructions, as here:
http://guide.lugnet.com/set/8480
would be better (IMHO).
This idea of keeping track of the quality of data is especially
interesting when considering the related sites to
which the Guide links---Peeron.com and BrickShelf.com. If the Guide had
some way of keeping track of the quality of the information to which it
linked on those sites[4], it could tell LUGNET users if they could help,
e.g., "BrickShelf has scans of the instructions for this set, but they're
not of the best quality Kevin would like to host" or "Peeron has an
inventory, but it's only from instructions, unverified, so if you have one
MISB you could really help"[5].
The special attraction I see (bringing me back to the message to which
this post is, technically, a reply) is a publically viewable database of
information collected. In particular, as sets came out and LUGNET members
updated their ownership information, they could see whether or not
BrickShelf had instruction scans of optimal quality (even though those
scans themselves might not be publically viewable for a few years). Thus,
Kevin Loch could get scans while sets are new and exciting, and not have
to count on people holding on to old instruction scans or worry about
multiple submissions and sudden high workloads when he asks for lots
of scans at once[6].
Additionally, data quality could really help with the two big holes in
Lego databases right now: the Brictionary and a sticker guide. If and
when the Brictionary actually gets off the ground[7], many elements are
going to need pictures. Any picture is better than no picture, but
Peeron-quality pictures are better than "I'm selling this part and I need
a thumbnail" pictures. The latter could make it into the Brictionary,
provided there were a mechanism in place (data quality tracking) so people
would know what could use improvement. Similarly, the Guide entry
for every set with sticker sheets really should link to a high quality
scan of that sheet (with a ruler for scale), but if only a partial sheet
or a non-optimal scan is available, it's still better than nothing. When
a database of these very important parts ever gets going[8],
tracking the quality of the contents would help.
In short: I think it would help the LUGNET Guide to keep track of the
quality (or perceived validity) of its data, to make the Guide better and
to give members of the community direction in how they can help improve
this wonderful resource.
I'm sure the forgoing is incomplete and probably incoherent so I welcome
questions, comments, response from the admins about whether I should stop
trying to make more work for them, etc.
Please FUT as appropriate.
-------------------------------------------------------------------------
TWS Garrison
tgarriso@math.purdue.edu
http://www.math.purdue.edu/~tgarriso/
[1] http://www.math.purdue.edu/~tgarriso/eqmm/database.html
[2] http://www.lugnet.com/admin/plan/5.html
[3] The discussion here:
http://news.lugnet.com/admin/database/?n=1280
would be a useful and related implementation, as would automatically
generated versions of
http://www.peeron.com/inv/request/
[4] Which unfortunately would probably mean more work for the
administrators of those sites. . .
[5] Of course, a practical implementation of this would be more like
"Good--no more work required" "Fair--additional help useful" "No
data--please help" than the detailed examples I gave :-)
[6] I suppose BrickShelf might have some list of scans that Kevin has but
hasn't made publicly viewable, to prevent duplication of effort, but I
haven't found such a list.
[7] A project which I would dearly love to help and participate,
although I lack the time, tools, and talent to actually get the project
going.
[8] Am I the only one who ever worries about an AFOL buying, say, an MISB
544 and gleefully putting on the stickers, without realizing that he may
be in the process destroying a potential resource for many others because
there is no established pattern of scanning before using stickers?
|
|
Message has 2 Replies:
 | | Sticker Scans [was Newish Idea for LUGNET]
|
| Hello TWS, hello everybody, let me say that I think your data quality tracking idea makes a lot of sense to me. Of course, you are also right when you say that its implementation will take a dedicated team, lead by someone with the right set of (...) (23 years ago, 21-Feb-02, to lugnet.admin.database)
|
6 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Database
|
|
|
|
|
|
