  
| Author: | Teup  | | Posted: | Feb 17, 2024 03:08 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 79 times | | Topic: | Catalog | |
|
| In Catalog, Admin_Russell writes:
| | Hello again everyone,
This is my official response to the video from R.R. Slugger concerning the merging
of part variants in the BrickLink catalog:
https://www.youtube.com/watch?v=aGRxNX8Cg_o&t=1s
Here is an initial response to the video, specifically regarding the set inventory
for the Core Magnetizer:
https://www.bricklink.com/message.asp?ID=1450164
Here is today's response:
*************************************
I’ll start with a couple points I actually agree with Slugger on:
1) BrickLink certainly is an invaluable tool, and one of the things that has
motivated me to invest in the catalog over the years, long before I became a
community admin or started working in the BrickLink office, was knowing that
whatever corrections or additions I would make would instantly circle the globe
and potentially benefit thousands of fans everywhere.
2) Regarding the suggestion to double down on accuracy – that is actually what
we’re doing, if you look at the big picture. I remember discussing with one of
the authors of the LEGO Collector books that came out a few years ago:
and one of the points we discussed was why certain things weren’t included in
a publication that was so comprehensive. The answer was that if a particular
data field didn’t have at least 80% of the data, then there were questions raised
as to how useful that field would be.
Of course this case does not cover all of the changes being made to the BrickLink
catalog, but it does pertain to some of them. The smooth slopes and frosted bricks,
even after 20 years of accepting data from the community, have a very weak connection
to our inventory system. Many of the parts are not represented even a single
time, and of those that are represented, there are serious questions as to the
accuracy of the inventory change requests.
The biggest obstacle in separating variants on BrickLink, especially the older
ones, is lack of real data. So the question comes up, should we have entries
on BrickLink that can’t or never will be represented sufficiently in the inventory
system?
Being orphaned or partially orphaned from the system is a bad thing, and our
stance on that is one of the things that has really changed since Dan built the
inventory system in the early 2000s. It used to be acceptable to have entries
floating around just for buying and selling, but over time we have realized the
power of our inventory system, to the extent that we now use artificial inventories
to represent certain parts (like BAM parts):
By removing some of these variants, the accuracy and inclusiveness of the inventory
system goes up, and that is the primary driving force behind these current changes.
Why not just fill out the data instead of consolidating entries? Because we simply
do not have the data, and if we did, we couldn’t handle it all anyway. There
is no way we can add thousands of new minifigure inventories to the system simply
to accommodate different types of studs.
Next I’d like to give an actual example or something that WILL be lost in
the transition.
Slugger is right – just because the example he gave may not have been the perfect
example, it doesn’t negate the point that something will be lost. So here goes:
Set 7171 from 1999 (Mos Espa Podrace):
is one of the celebrated early Star Wars sets and as such we may consider it
to be at the pinnacle of collector interest. In that set is a yellow dome with
a “blocked open stud” which is part no. 30151a:
[p=30151a,3]
The next version of that part by all accounts was introduced around 2010,
[p=30151b]
and by that time, the Mos Espa Podrace had long been retired. So we can say with
reasonable certainty that this set came originally with domes with blocked open
studs. If you see a copy of the set sitting on someone’s shelf and the domes
on Anakin’s podracer have hollow studs (no little Mercedes symbol), that is a
sure sign that the parts, and maybe even the whole set, is not original.
So if the BrickLink catalog stops distinguishing the “a” from the “b” version,
someone might build it wrong and wouldn’t even know it! However, as a quiz question
for savvy readers, why would this scenario never actually happen in the real
world? What do we know about these the 30151 variants that puts this problem
completely into the realm of the hypothetical?
Next example, set 4778-1 from 2005 (Desert Biplane):
This is not Star Wars buts it’s still a classic in my book. There is a different
kind of dome on the front of this plane (553), but it has the same issues as
the previously mentioned dome part.
[p=553b,5]
This set is from 2005, so it’s not likely that it ever came with the “c” variant.
The 2008 appearance is in the first UCS Death Star which had a really long production
run and has over 50 lines of variants in the BrickLink inventory:
But if this little set were produced up through 2010, there might be a real possibility
of seeing one with a “c” variant.
[p=553c,5]
So with the current merges, this is data that would be lost. People wouldn’t
know about the stud variants, and someone could get any of 3 different stud types
– blocked open, hollow, or even vented. All three exist in red.
[p=3262,5]
Next up is set 6745-1 from 2009 (Propeller Power).
This also has a red 533 on the nose of the plane, but here the inventory system
says it could have either the “b” or “c” variant. Check the change log to see
if you recognize any of the people who added these variants to the set:
https://www.bricklink.com/catalogInvChangeItem.asp?itemType=S&itemNo=6745-1&viewDate=Y&viewStatus=1
We’re pretty sure this came with both “b” and “c” types. It didn’t come with
a vented stud, and someone might mistakenly put one on this model if BrickLink
doesn’t educate them about it, right? That is the premise on why we need these
variants in the catalog, correct?
The thing is, how can we tolerate the difference of stud type in this model,
and not in other models where it is historically incorrect? In this plane model
from 2009, both are correct, so what does that say about the mixing of variants
in other models?
True collectors know that there actually is no replacement part that will ever
perfectly replace a part that is lost. The only truly correct part is the part
the set originally came with. It’s nice to get as close as possible to a correct
replacement part, but it’s a futile attempt.
So I will admit that something is lost in the catalog by harmonizing all the
hollow studs types. But the second message is that whatever is lost is quite
unimportant in relation to the effort it takes for the BrickLink community to
recognize these variants.
We weighed it up, and decided that stud types are not important enough. They
have some importance, and there are some workarounds available for the people
who really want to go down that path. But overall, what we seem to be losing
is less than what we believe we are gaining.
**************************************
One more detail about the video – in navigating around the BrickLink catalog,
I noticed Slugger used the new inventory tab on the catalog page instead of the
proper inventory page accessible by the link at the top of the page.
https://www.bricklink.com/catalogItemInv.asp?S=6989-1
There are multiple problems with this version of the inventory. First, there
is no link to the change log, which for specialists is a must. Reading the change
log lets you determine the accuracy of the data you are consuming.
Second, the match IDs do not line up with the inventory notes, so any mention,
for example, of “match ID 99” (which is critical to understanding variant inventories)
doesn’t make any sense.
Indispensable
Some of my colleagues were surprised to see such a strong reaction from our users
on this topic. But the fact is, variants are an indispensable feature of the
BrickLink catalog and they are one of the main reasons for the “sealed set” standard
we maintain for new inventories. Keeping this standard comes at a cost, and it’s
important for people to know that all of this work and energy is appreciated.
https://www.bricklink.com/help.asp?helpID=1103
BrickLink is not descending into a parts oblivion where nothing is distinguished.
I made that very clear from the very first announcement. This is simply a mid-way
correction to enable us to do better at what we already do. I trust that over
the coming months and years you will come around to believing me on that point.
|
Russell, in case you missed my other replies: Could you please send me a list
of the heads - old and new numbers? Just like the one you sent for the tiles.
And if possible the (rough) start date for that phase.
(and I thought variants were going to be merged on 15 feb but looks like nothing
has been merged  )
|
|
Message is in Reply To:  Reaction to the R.R. Slugger video - Admin_Russell | Hello again everyone, This is my official response to the video from R.R. Slugger concerning the merging of part variants in the BrickLink catalog: (URL) Here is an initial [...]
(3 months ago, Feb 16, 2024, to Catalog) |
Message Has 1 Reply: 35 Messages in this Thread: Msg 1 - Admin_Russell 3 months ago Feb 16, 2024 to Catalog
 Msg 2 - Nubs_Select (3788)  3 months ago Feb 16, 2024 to Catalog
  Msg 3 - 1001bricks (52418) 3 months ago Feb 16, 2024 to Catalog
Msg 4 - PlanetEarthToys (118) 3 months ago Feb 16, 2024 to Catalog
Msg 5 - DeLuca (286) 3 months ago Feb 17, 2024 to Catalog
Msg 6 - yorbrick (1185) 3 months ago Feb 17, 2024 to Catalog
Msg 7 - brickbiters (134) 3 months ago Feb 17, 2024 to Catalog
Msg 8 - calebfishn (2143) 3 months ago Feb 18, 2024 to Catalog
Msg 9 - Tracyd (418) 3 months ago Feb 19, 2024 to Catalog
Msg 10 « - Teup (6607) 3 months ago Feb 17, 2024 to Catalog
Msg 11 - Nubs_Select (3788) 3 months ago Feb 17, 2024 to Catalog
Msg 12 - Teup (6607) 3 months ago Feb 17, 2024 to Catalog
Msg 13 - randyf (442) 3 months ago Feb 17, 2024 to Catalog
Msg 14 - macebobo (2450) 3 months ago Feb 17, 2024 to Catalog
Msg 15 - Teup (6607) 3 months ago Feb 17, 2024 to Catalog
Msg 16 - brxstore (786) 3 months ago Feb 18, 2024 to Catalog
Msg 17 - popsicle (6666) 3 months ago Feb 18, 2024 to Catalog
Msg 18 - brxstore (786) 3 months ago Feb 18, 2024 to Catalog
Msg 19 - popsicle (6666) 3 months ago Feb 18, 2024 to Catalog
Msg 20 - randyf (442) 3 months ago Feb 18, 2024 to Catalog
Msg 21 - yorbrick (1185) 3 months ago Feb 18, 2024 to Catalog
Msg 22 - brickbiters (134) 3 months ago Feb 17, 2024 to Catalog
Msg 23 - Reki_Lobsheek (2465) 3 months ago Feb 19, 2024 to Catalog
Msg 24 - Tracyd (418) 3 months ago Feb 19, 2024 to Catalog
Msg 25 - PlanetEarthToys (118) 3 months ago Feb 19, 2024 to Catalog
Msg 26 - Saitobricks.ca (37) 3 months ago Feb 19, 2024 to Catalog
Msg 27 - Saitobricks.ca (37) 3 months ago Feb 19, 2024 to Catalog
Msg 28 - wahiggin (2864) 3 months ago Feb 19, 2024 to Catalog
Msg 29 - GreatBuy (3625) 3 months ago Feb 19, 2024 to Catalog
Msg 30 - SylvainLS (46) 3 months ago Feb 20, 2024 to Catalog
Msg 31 - BrickDeals (2811) 3 months ago Feb 19, 2024 to Catalog
Msg 32 - yorbrick (1185) 3 months ago Feb 20, 2024 to Catalog
Msg 33 - Ziegelmeister (226) 3 months ago Feb 20, 2024 to Catalog
Msg 34 - Saitobricks.ca (37) 3 months ago Feb 26, 2024 to Catalog
Msg 35 - Saitobricks.ca (37) 1 month ago Apr 12, 2024 to Catalog
Entire thread on one page
This message and all its replies on one page
|
Netherlands, Utrecht
