|
 |
| | | Author: | Admin_Russell  | | Posted: | Feb 16, 2024 22:06 | | Subject: | Reaction to the R.R. Slugger video | | Viewed: | 430 times | | Topic: | Catalog | | Status: | Open | |
|
|
BrickLink
ID CardAdmin_Russell
|
Location:  USA, California |
| Member Since |
Contact |
Type |
Status |
| May 9, 2017 |
 |
Admin |
|
|
| BrickLink Administrator |
|
| 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.
|
|
|
| | | | | |
| | | | | Author: | Nubs_Select | | Posted: | Feb 16, 2024 22:19 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 69 times | | Topic: | Catalog | |
|
| | Thankyou for taking the time to go over this! |
|
| | | | | | | | | |
| | | | | | | Author: | 1001bricks | | Posted: | Feb 16, 2024 22:32 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 66 times | | Topic: | Catalog | |
|
| In Catalog, Nubs_Select writes:
| | Thankyou for taking the time to go over this!
|
And especially at this time: Feb 16, 2024 22:06!
Please Admin, have a good weekend.
|
|
| | | | | |
| | | | | Author: | PlanetEarthToys | | Posted: | Feb 16, 2024 23:52 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 75 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.
|
.... things with the merge seem to be going Lovely...
|
|
|
| | | | | |
| | | | | Author: | DeLuca | | Posted: | Feb 17, 2024 01:28 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 76 times | | Topic: | Catalog | |
|
| In Catalog, Admin_Russell writes:
| | 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.
|
We only know this because of complete databases like the BrickLink Catalog.
| | 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?
|
As you say, it is because other cases are historically inaccurate. To use a Star
Wars example, this is like asking why Imperial officers cannot wear single-line
rank insignias post-Yavin when they had a mix of single-line and double-line
ranks (an increasing number of the latter, over time) before Yavin.
| | 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.
|
This is pure cope, and also bull****.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | yorbrick | | Posted: | Feb 17, 2024 03:35 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 68 times | | Topic: | Catalog | |
|
| | |
We only know this because of complete databases like the BrickLink Catalog.
|
It isn't complete and never will be. With the rate new sets are produced
and the lack of information about old sets and items, there will always be uninventoried
sets, errors and guesses in old inventories, variants that are not recorded or,
if they are recorded, not catalogued as a variant, and so on.
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | brickbiters | | Posted: | Feb 17, 2024 13:25 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 74 times | | Topic: | Catalog | |
|
| In Catalog, yorbrick writes:
| | | |
We only know this because of complete databases like the BrickLink Catalog.
|
It isn't complete and never will be. With the rate new sets are produced
and the lack of information about old sets and items, there will always be uninventoried
sets, errors and guesses in old inventories, variants that are not recorded or,
if they are recorded, not catalogued as a variant, and so on.
|
which is why it's important to keep historical research data so that when
something is found you're not starting from scratch every time. this is garbage
and if russell really believed what he was saying he would open up the discussion
and voting on each part to the community since this database was built by the
community, not some group of people who think they know what's good for us
and forcing it down our throat and trying to gaslight us into believing 'we'll
come around.....'. RIP bricklink.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | calebfishn | | Posted: | Feb 18, 2024 21:38 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 86 times | | Topic: | Catalog | |
|
| I wish I had a dollar for every time someone on the discussion forum said "RIP
Bricklink".
I'd take all the money and buy a big expensive Lego set.
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | Tracyd | | Posted: | Feb 19, 2024 10:21 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 75 times | | Topic: | Catalog | |
|
| In Catalog, brickbiters writes:
| | In Catalog, yorbrick writes:
| | | |
We only know this because of complete databases like the BrickLink Catalog.
|
It isn't complete and never will be. With the rate new sets are produced
and the lack of information about old sets and items, there will always be uninventoried
sets, errors and guesses in old inventories, variants that are not recorded or,
if they are recorded, not catalogued as a variant, and so on.
|
which is why it's important to keep historical research data so that when
something is found you're not starting from scratch every time. this is garbage
and if russell really believed what he was saying he would open up the discussion
and voting on each part to the community since this database was built by the
community, not some group of people who think they know what's good for us
and forcing it down our throat and trying to gaslight us into believing 'we'll
come around.....'. RIP bricklink.
|
I picture you sitting in a concrete bunker surrounded by cases and cases of MRE's.
Bricklink is not a democracy, it never has been. Not everyone would vote even
if it was put out there, so it wouldn't be a true representation anyway.
It would just be the vocal minority that makes the biggest fuss.
|
|
|
| | | | | |
| | | | | Author: | Teup | | Posted: | Feb 17, 2024 03:08 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 77 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  )
|
|
|
| | | | | | | | | | | | | | |
| | | | | | | | | Author: | Teup | | Posted: | Feb 17, 2024 03:59 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 110 times | | Topic: | Catalog | |
|
| In Catalog, Nubs_Select writes:
Ah thanks, will bookmark that link. I know renumbering the decorated pieces takes
long (initially posed as "this way it will be easier for people and services
to adapt", later admitted it's just because they don't have any upload
capabilities so they have to do it all manually).
But I really thought at least the merging of the variants (just a handful of
entries, like a bunch of 7-teeth and 9-teeth hinges) would actually happen on
the indicated date. Even if you do it all manually it shouldn't take too
long. Well, at least they did... 3 entries it seems 
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | randyf | | Posted: | Feb 17, 2024 16:28 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 86 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | In Catalog, Nubs_Select writes:
Ah thanks, will bookmark that link. I know renumbering the decorated pieces takes
long (initially posed as "this way it will be easier for people and services
to adapt", later admitted it's just because they don't have any upload
capabilities so they have to do it all manually).
But I really thought at least the merging of the variants (just a handful of
entries, like a bunch of 7-teeth and 9-teeth hinges) would actually happen on
the indicated date. Even if you do it all manually it shouldn't take too
long. Well, at least they did... 3 entries it seems
|
Every part that gets merged is attached to inventories, so all of the inventories
that contain it have to also be manually updated one by one (remove duplicate
entry, update Match IDs, possibly update inventory notes, etc.). It is a painstaking
process, so it can take a bit to just get through one part merger. I am glad
that I don't have to do it.
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | macebobo | | Posted: | Feb 17, 2024 16:49 | | Subject: | (Cancelled) | | Viewed: | 45 times | | Topic: | Catalog | |
|
| | (Cancelled) |
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | Teup | | Posted: | Feb 17, 2024 20:12 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 66 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | In Catalog, Teup writes:
| | In Catalog, Nubs_Select writes:
Ah thanks, will bookmark that link. I know renumbering the decorated pieces takes
long (initially posed as "this way it will be easier for people and services
to adapt", later admitted it's just because they don't have any upload
capabilities so they have to do it all manually).
But I really thought at least the merging of the variants (just a handful of
entries, like a bunch of 7-teeth and 9-teeth hinges) would actually happen on
the indicated date. Even if you do it all manually it shouldn't take too
long. Well, at least they did... 3 entries it seems
|
Every part that gets merged is attached to inventories, so all of the inventories
that contain it have to also be manually updated one by one (remove duplicate
entry, update Match IDs, possibly update inventory notes, etc.). It is a painstaking
process, so it can take a bit to just get through one part merger. I am glad
that I don't have to do it.
|
Oh.. wow  I had no idea. Well, that does explain (not excuse) the delay.
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | brxstore | | Posted: | Feb 18, 2024 09:48 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 66 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | In Catalog, Teup writes:
| | In Catalog, Nubs_Select writes:
Ah thanks, will bookmark that link. I know renumbering the decorated pieces takes
long (initially posed as "this way it will be easier for people and services
to adapt", later admitted it's just because they don't have any upload
capabilities so they have to do it all manually).
But I really thought at least the merging of the variants (just a handful of
entries, like a bunch of 7-teeth and 9-teeth hinges) would actually happen on
the indicated date. Even if you do it all manually it shouldn't take too
long. Well, at least they did... 3 entries it seems
|
Every part that gets merged is attached to inventories, so all of the inventories
that contain it have to also be manually updated one by one (remove duplicate
entry, update Match IDs, possibly update inventory notes, etc.). It is a painstaking
process, so it can take a bit to just get through one part merger. I am glad
that I don't have to do it.
|
Well, have you thought about not doing it then? 
If it ain't broken, don't fix it.
Problem solved, everybody is happy, you can spend your time on more
useful stuff that has actual benefits, instead of inflicting pain on so many
users of the platform.
It is still not too late to cancel this madness. Please come to your senses.
BTW: There are much better solutions to the problems you are trying to solve.
You could for example improve the search engine and the matching engine
behind the 'Buy All' feature to allow matching all variants of a particular
item, if someone is not interested in specific variants.
Instead of getting rid of catalog items with Undetermined Type, you could
keep them for sellers who don't want to invest the time to differentiate
variants in their inventory.
I am surprised nobody at BrickLink thought about alternative solutions that
don't involve reducing the granularity of the catalog.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | popsicle | | Posted: | Feb 18, 2024 10:07 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 68 times | | Topic: | Catalog | |
|
| In Catalog, brxstore writes:
| | In Catalog, randyf writes:
| | In Catalog, Teup writes:
| | In Catalog, Nubs_Select writes:
Ah thanks, will bookmark that link. I know renumbering the decorated pieces takes
long (initially posed as "this way it will be easier for people and services
to adapt", later admitted it's just because they don't have any upload
capabilities so they have to do it all manually).
But I really thought at least the merging of the variants (just a handful of
entries, like a bunch of 7-teeth and 9-teeth hinges) would actually happen on
the indicated date. Even if you do it all manually it shouldn't take too
long. Well, at least they did... 3 entries it seems
|
Every part that gets merged is attached to inventories, so all of the inventories
that contain it have to also be manually updated one by one (remove duplicate
entry, update Match IDs, possibly update inventory notes, etc.). It is a painstaking
process, so it can take a bit to just get through one part merger. I am glad
that I don't have to do it.
|
Well, have you thought about not doing it then?
If it ain't broken, don't fix it.
Problem solved, everybody is happy, you can spend your time on more
useful stuff that has actual benefits, instead of inflicting pain on so many
users of the platform.
It is still not too late to cancel this madness. Please come to your senses.
|
Don't believe Randy was ever in favor of this move, could be wrong. Nonetheless,
this type of retort is better directed at the higher-ups here anyways, and not
the dedicated hardworking catalog folks.
| |
BTW: There are much better solutions to the problems you are trying to solve.
You could for example improve the search engine and the matching engine
behind the 'Buy All' feature to allow matching all variants of a particular
item, if someone is not interested in specific variants.
Instead of getting rid of catalog items with Undetermined Type, you could
keep them for sellers who don't want to invest the time to differentiate
variants in their inventory.
I am surprised nobody at BrickLink thought about alternative solutions that
don't involve reducing the granularity of the catalog.
|
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | Author: | brxstore | | Posted: | Feb 18, 2024 10:55 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 59 times | | Topic: | Catalog | |
|
| In Catalog, popsicle writes:
| | In Catalog, brxstore writes:
| | In Catalog, randyf writes:
| | In Catalog, Teup writes:
| | In Catalog, Nubs_Select writes:
Ah thanks, will bookmark that link. I know renumbering the decorated pieces takes
long (initially posed as "this way it will be easier for people and services
to adapt", later admitted it's just because they don't have any upload
capabilities so they have to do it all manually).
But I really thought at least the merging of the variants (just a handful of
entries, like a bunch of 7-teeth and 9-teeth hinges) would actually happen on
the indicated date. Even if you do it all manually it shouldn't take too
long. Well, at least they did... 3 entries it seems
|
Every part that gets merged is attached to inventories, so all of the inventories
that contain it have to also be manually updated one by one (remove duplicate
entry, update Match IDs, possibly update inventory notes, etc.). It is a painstaking
process, so it can take a bit to just get through one part merger. I am glad
that I don't have to do it.
|
Well, have you thought about not doing it then?
If it ain't broken, don't fix it.
Problem solved, everybody is happy, you can spend your time on more
useful stuff that has actual benefits, instead of inflicting pain on so many
users of the platform.
It is still not too late to cancel this madness. Please come to your senses.
|
Don't believe Randy was ever in favor of this move, could be wrong. Nonetheless,
this type of retort is better directed at the higher-ups here anyways, and not
the dedicated hardworking catalog folks.
|
Well, I hope the higher-ups are also reading this thread. The thread was
started by Admin_Russell, wasn't it? My comments were not directed
specifically to Randy, rather to everyone at BrickLink. I hope I haven't
offended anyone, I was trying to be constructive. I also hope I will get
some meaningful responses too
| |
| |
BTW: There are much better solutions to the problems you are trying to solve.
You could for example improve the search engine and the matching engine
behind the 'Buy All' feature to allow matching all variants of a particular
item, if someone is not interested in specific variants.
Instead of getting rid of catalog items with Undetermined Type, you could
keep them for sellers who don't want to invest the time to differentiate
variants in their inventory.
I am surprised nobody at BrickLink thought about alternative solutions that
don't involve reducing the granularity of the catalog.
|
|
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | Author: | popsicle | | Posted: | Feb 18, 2024 11:31 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 80 times | | Topic: | Catalog | |
|
| In Catalog, brxstore writes:
| | In Catalog, popsicle writes:
| | In Catalog, brxstore writes:
| | In Catalog, randyf writes:
| | In Catalog, Teup writes:
| | In Catalog, Nubs_Select writes:
Ah thanks, will bookmark that link. I know renumbering the decorated pieces takes
long (initially posed as "this way it will be easier for people and services
to adapt", later admitted it's just because they don't have any upload
capabilities so they have to do it all manually).
But I really thought at least the merging of the variants (just a handful of
entries, like a bunch of 7-teeth and 9-teeth hinges) would actually happen on
the indicated date. Even if you do it all manually it shouldn't take too
long. Well, at least they did... 3 entries it seems
|
Every part that gets merged is attached to inventories, so all of the inventories
that contain it have to also be manually updated one by one (remove duplicate
entry, update Match IDs, possibly update inventory notes, etc.). It is a painstaking
process, so it can take a bit to just get through one part merger. I am glad
that I don't have to do it.
|
Well, have you thought about not doing it then?
If it ain't broken, don't fix it.
Problem solved, everybody is happy, you can spend your time on more
useful stuff that has actual benefits, instead of inflicting pain on so many
users of the platform.
It is still not too late to cancel this madness. Please come to your senses.
|
Don't believe Randy was ever in favor of this move, could be wrong. Nonetheless,
this type of retort is better directed at the higher-ups here anyways, and not
the dedicated hardworking catalog folks.
|
Well, I hope the higher-ups are also reading this thread. The thread was started by Admin_Russell, wasn't it?
|
It was indeed. But Russell is the expression of BL, it's so-to-speak face
to it's users. You expressed yourself well I thought, but to the wrong individual
and post.
| | My comments were not directed specifically to Randy, rather to everyone at BrickLink. I hope I haven't offended anyone, I was trying to be constructive.
|
In my opinion, you've not "offended anyone" just target your well-put
thoughts better, is my point.
| | I also hope I will get some meaningful responses too
|
Sure you will
| |
| |
| |
BTW: There are much better solutions to the problems you are trying to solve.
You could for example improve the search engine and the matching engine
behind the 'Buy All' feature to allow matching all variants of a particular
item, if someone is not interested in specific variants.
Instead of getting rid of catalog items with Undetermined Type, you could
keep them for sellers who don't want to invest the time to differentiate
variants in their inventory.
I am surprised nobody at BrickLink thought about alternative solutions that
don't involve reducing the granularity of the catalog.
|
|
|
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | randyf | | Posted: | Feb 18, 2024 12:57 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 71 times | | Topic: | Catalog | |
|
| In Catalog, brxstore writes:
| | In Catalog, randyf writes:
| | In Catalog, Teup writes:
| | In Catalog, Nubs_Select writes:
Ah thanks, will bookmark that link. I know renumbering the decorated pieces takes
long (initially posed as "this way it will be easier for people and services
to adapt", later admitted it's just because they don't have any upload
capabilities so they have to do it all manually).
But I really thought at least the merging of the variants (just a handful of
entries, like a bunch of 7-teeth and 9-teeth hinges) would actually happen on
the indicated date. Even if you do it all manually it shouldn't take too
long. Well, at least they did... 3 entries it seems
|
Every part that gets merged is attached to inventories, so all of the inventories
that contain it have to also be manually updated one by one (remove duplicate
entry, update Match IDs, possibly update inventory notes, etc.). It is a painstaking
process, so it can take a bit to just get through one part merger. I am glad
that I don't have to do it.
|
Well, have you thought about not doing it then?
|
I had nothing to do with it. All I did along with the rest of the Catalog Admin
team was help to save some of the entries that were going to get merged (32064c,
10247, slopes with connections between studs, etc.). This came from the BrickLink
corporate level, not the Catalog Admin team level. Thus, those at BrickLink corporate
are doing all of the additional work for this instead of the Catalog Admin team.
Simply put, "I am glad that I don't have to do it."
| | If it ain't broken, don't fix it.
Problem solved, everybody is happy, you can spend your time on more
useful stuff that has actual benefits, instead of inflicting pain on so many
users of the platform.
It is still not too late to cancel this madness. Please come to your senses.
BTW: There are much better solutions to the problems you are trying to solve.
You could for example improve the search engine and the matching engine
behind the 'Buy All' feature to allow matching all variants of a particular
item, if someone is not interested in specific variants.
Instead of getting rid of catalog items with Undetermined Type, you could
keep them for sellers who don't want to invest the time to differentiate
variants in their inventory.
I am surprised nobody at BrickLink thought about alternative solutions that
don't involve reducing the granularity of the catalog.
|
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | yorbrick | | Posted: | Feb 18, 2024 13:17 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 65 times | | Topic: | Catalog | |
|
| | | I am surprised nobody at BrickLink thought about alternative solutions that
don't involve reducing the granularity of the catalog.
|
They almost certainly have thought about alternative solutions. They are really
quite conservative about changes and I cannot see them making changes just for
the hell of it to see if they work out better.
|
|
| | | | | |
| | | | | Author: | brickbiters | | Posted: | Feb 17, 2024 13:36 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 99 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.
|
you just keep telling yourself that. whatever copium helps you to sleep better
at night. i've read all your 'response' posts and they're all
just corporate shill garbage. the only reason you trust that we'll come around
is because you know we have no other choice because you are too afraid to open
it up to the community because you know you're wrong. lost historical research
data is not a win for anybody and in the future will only result in more work
trying to verify things because of having to start all over again, with less
and less historical research to go on. you're taking something that was built
by the community and closing it off to a select few. and i'm not even talking
about merges that are obvious, but things that are totally wrong from a functionality
point. nobody has asked for this and nobody wants this and there are much bigger
fish to fry than this. get your priorities straight.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | Reki_Lobsheek | | Posted: | Feb 19, 2024 15:51 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 86 times | | Topic: | Catalog | |
|
| In Catalog, brickbiters writes:
get your priorities straight
Perhaps people like you should follow their own advice?
Talking about 1st World problems ... sheesh
With all due respect to the (to me) borderline autistic fetish for part variants
some people seem to have, I cannot comprehend that of all the technical issues
and necessary adaptations due to changed international commerce laws to this
platform, this issue gets so much attention. It simply baffles me.
I can go as far as understanding why it could be important to a small group of
avid collectors but to expect a platform with over 1.6 million users to compromise
its functionality to adhere to the rants of a niche minority within the very
small minority that is the group of BL members that actually use the forum is
going too far IMO.
I think it's safe to say that these changes will be a headache less for the
bigger fish among the sellers here.
Erikk
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | Tracyd | | Posted: | Feb 19, 2024 16:08 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 62 times | | Topic: | Catalog | |
|
| In Catalog, Reki_Lobsheek writes:
| | In Catalog, brickbiters writes:
get your priorities straight
Perhaps people like you should follow their own advice?
Talking about 1st World problems ... sheesh
With all due respect to the (to me) borderline autistic fetish for part variants
some people seem to have, I cannot comprehend that of all the technical issues
and necessary adaptations due to changed international commerce laws to this
platform, this issue gets so much attention. It simply baffles me.
I can go as far as understanding why it could be important to a small group of
avid collectors but to expect a platform with over 1.6 million users to compromise
its functionality to adhere to the rants of a niche minority within the very
small minority that is the group of BL members that actually use the forum is
going too far IMO.
I think it's safe to say that these changes will be a headache less for the
bigger fish among the sellers here.
Erikk
|
We need a like button.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | PlanetEarthToys | | Posted: | Feb 19, 2024 17:35 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 60 times | | Topic: | Catalog | |
|
| In Catalog, Reki_Lobsheek writes:
| | In Catalog, brickbiters writes:
get your priorities straight
Perhaps people like you should follow their own advice?
Talking about 1st World problems ... sheesh
With all due respect to the (to me) borderline autistic fetish for part variants
some people seem to have, I cannot comprehend that of all the technical issues
and necessary adaptations due to changed international commerce laws to this
platform, this issue gets so much attention. It simply baffles me.
I can go as far as understanding why it could be important to a small group of
avid collectors but to expect a platform with over 1.6 million users to compromise
its functionality to adhere to the rants of a niche minority within the very
small minority that is the group of BL members that actually use the forum is
going too far IMO.
I think it's safe to say that these changes will be a headache less for the
bigger fish among the sellers here.
Erikk
|
i had a tree house once, storm came through & ripped off the branches i used
to get to it..
never got the chance to go back up there, but it was still cool to have it......
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | Saitobricks.ca | | Posted: | Feb 19, 2024 17:54 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 61 times | | Topic: | Catalog | |
|
| In Catalog, PlanetEarthToys writes:
| | In Catalog, Reki_Lobsheek writes:
| | In Catalog, brickbiters writes:
get your priorities straight
Perhaps people like you should follow their own advice?
Talking about 1st World problems ... sheesh
With all due respect to the (to me) borderline autistic fetish for part variants
some people seem to have, I cannot comprehend that of all the technical issues
and necessary adaptations due to changed international commerce laws to this
platform, this issue gets so much attention. It simply baffles me.
I can go as far as understanding why it could be important to a small group of
avid collectors but to expect a platform with over 1.6 million users to compromise
its functionality to adhere to the rants of a niche minority within the very
small minority that is the group of BL members that actually use the forum is
going too far IMO.
I think it's safe to say that these changes will be a headache less for the
bigger fish among the sellers here.
Erikk
|
i had a tree house once, storm came through & ripped off the branches i used
to get to it..
never got the chance to go back up there, but it was still cool to have it......
|
Sadness. 
|
|
|
| | | | | | | | | |
| | | | | | | Author: | Saitobricks.ca | | Posted: | Feb 19, 2024 17:51 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 48 times | | Topic: | Catalog | |
|
| In Catalog, brickbiters writes:
| | 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.
|
you just keep telling yourself that. whatever copium helps you to sleep better
at night. i've read all your 'response' posts and they're all
just corporate shill garbage. the only reason you trust that we'll come around
is because you know we have no other choice because you are too afraid to open
it up to the community because you know you're wrong. lost historical research
data is not a win for anybody and in the future will only result in more work
trying to verify things because of having to start all over again, with less
and less historical research to go on. you're taking something that was built
by the community and closing it off to a select few. and i'm not even talking
about merges that are obvious, but things that are totally wrong from a functionality
point. nobody has asked for this and nobody wants this and there are much bigger
fish to fry than this. get your priorities straight.
|
Sadly nothing we say can change anything, I’ve given up arguing, (and reasoning)
but if it helps you sleep, nubs has cataloged most of the variants in internet
archives for us to use as a reference.
|
|
|
| | | | | |
| | | | | Author: | wahiggin | | Posted: | Feb 19, 2024 12:02 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 66 times | | Topic: | Catalog | |
|
| In Catalog, Admin_Russell writes:
| | 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?
|
That is the exact reason BrickLink should maintain the information, so
we will know if it is or is not historically accurate. Because the BrickLink
database goes back decades, it is more likely that the information is correct
than not correct. I truly appreciate all the inventory and catalog admins have
done through the years to maintain the database accuracy.
|
|
|
| | | | | |
| | | | | Author: | GreatBuy | | Posted: | Feb 19, 2024 18:38 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 111 times | | Topic: | Catalog | |
|
| | | 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.
|
I understand all the reasons for why this change is happening and I know I do
not speak for everyone, but this is the weakest point that you made. It feels
as a brush off. "Well its not the part that originally came with the set
so it really doesn't matter what part you use." You must be careful with
your words, this can be used to argue for literally any change to the catalog.
"It’s nice to get as close as possible to a correct replacement part, but
it’s a futile attempt."
How is this futile? The wording here is a little disingenuous, purchasing the
correct variant will be the correct replacement part. I guess I might as well
buy a completely different part?
But I suppose then you get into the "If you replace every part on a boat
is it the same boat argument." Say I have two sets that were purchased at
the same time in the 60s. If I swap a piece between the two, the set isn't
technically original, but no one will ever be able to know that process occurred,
even myself once I forget about it. As opposed to if I swapped a 60s brick out
for a modern replacement, it will be glaring. I know the changes don't really
affect this far back, but I use it as a personal example.
It's also kinda silly that you use true collectors to advocate for this change,
when it really serves to benefit a wider audience that is not so concerned with
variations. I guess I'm not a true collector if I take my sets out of the
box? Do true collectors care about these mold variations.
But overall, yes, the change is ultimately pragmatic and I'm happy to see
a response to this. The only reason I give this response is purely because of
the few lines I am replying to. This in no way discredits the entirety of your
response.
Also, for those who disagree with the changes, please respond with a level head.
Coming off as scorned and fuming at the keyboard does not communicate your point
and only leads someone to discredit you entirely.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | SylvainLS | | Posted: | Feb 20, 2024 03:25 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 53 times | | Topic: | Catalog | |
|
| In Catalog, GreatBuy writes:
| | […]
But I suppose then you get into the "If you replace every part on a boat
is it the same boat argument." Say I have two sets that were purchased at
the same time in the 60s. If I swap a piece between the two, the set isn't
technically original, but no one will ever be able to know that process occurred,
even myself once I forget about it.
|
Ah, but that’s the “if a piece is swapped in a forest and no one is here to hear
it, does it make a sound?” argument
|
|
| | | | | |
| | | | | Author: | BrickDeals | | Posted: | Feb 19, 2024 22:35 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 73 times | | Topic: | Catalog | |
|
| Why even have these forum discussions?
LEGO owns the platform they can do what they want with it.
The problem is asking for input from the community, then just doing whatever
you had originally planned anyway. Then endless debating changes that you have
no intentions of reverting, which just inflames passions in the community.
It is just poor community relations.
Here's an idea.
1.) Make a post explaining changes that are going to be made.
2.) Explain why changes will be made.
3.) Give time frame for changes.
4.) Make changes.
Not complicated.
|
|
| | | | | | | | | |
| | | | | | | Author: | yorbrick | | Posted: | Feb 20, 2024 05:42 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 59 times | | Topic: | Catalog | |
|
| | | The problem is asking for input from the community, then just doing whatever
you had originally planned anyway. Then endless debating changes that you have
no intentions of reverting, which just inflames passions in the community.
|
They have relented on or revisited some of the proposed merges though. That shows
it is useful to have such discussions. I think we have seen that not every variant
is important. So many known variants are not individually catalogued, but most
people are happy with a single entry saying there are known differences where
there is no obvious functional difference. Getting the balance right on every
part is difficult. Some of the proposed merges where wrong to me, some were fine,
and some were more I could see it going either way.
As for inflaming passions, this is where it would be good if youtube creators
would do a little more research before creating their videos. Spreading incorrect
information and getting their followers to pile into an argument without knowing
what they are talking about does not help.
|
|
|
| | | | | |
| | | | | Author: | Ziegelmeister | | Posted: | Feb 20, 2024 06:43 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 80 times | | Topic: | Catalog | |
|
| | I have no clue who slugger is. Let's just make this change and move on. |
|
| | | | | | | | | |
| | | | | | | Author: | Saitobricks.ca | | Posted: | Feb 26, 2024 17:28 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 59 times | | Topic: | Catalog | |
|
| In Catalog, Ziegelmeister writes:
| | I have no clue who slugger is. Let's just make this change and move on.
|
I’m speechless to the level of non care exhibited…
|
|
| | | | | |
| | | | | Author: | Saitobricks.ca | | Posted: | Apr 12, 2024 13:13 | | Subject: | Re: Reaction to the R.R. Slugger video | | Viewed: | 59 times | | Topic: | Catalog | |
|
| Look at what you have done!!!😭😭😭😭😭
https://youtu.be/wtICr7eVIoU?si=hPdPyVKqi3fKDzN9
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.
|
|
|
|
|
|
|
Canada, Ontario
France, Provence-Alpes-Côte d'Azur
United Kingdom, England
Netherlands, Utrecht
Slovenia
Belgium, Brussels
