Catalog/API: Color of part 97122

Stragus

Let's have a look at this part:
http://www.brickowl.com/catalog/lego-curtain-vw-97122

BrickOwl claims it comes in Bright Light Orange (even though the "Comes in" column is zero? Is that normal?), but another marketplace (and BrickStore/BrickStock) claim it only comes in BL color Not Applicable.

Using the API, when trying to create an item with color zero (that's BrickOwl's Not Applicable accordingly to the API retrieved color list), I get either:
"Cannot list a part without a colour" if the item is created with boid=MyBOID&color_id=MyColor
or
"Invalid BOID, item not found" if the item is created with a composite boid=MyBOID-MyColor

BrickOwl apparently doesn't read the color_id when it's zero, and/or the BOID-Color combination is just rejected. Note that the set 10220's inventory claim the part 97122's color is still at Select a color, though apparently that's not the same as Not Applicable (which is also in the list). I have no idea what colorID Select a color would be, but Bright Light Orange is apparently the only color known by BrickOwl for that part.

So... Do we edit the set inventory to color Not Applicable? Does the API even accept color zero? It seemed to ignore a color_id parameter of zero (from the error message "Cannot list a part without a colour").

Help anyone? Thanks!

Stragus

And to clarify that point, if we don't make BrickOwl accept the color Not Applicable for that part, then it implies any inventory/synchronization software needs to keep a list of exceptions for color translations for certain parts...

The part 97122 would be the first in such a list, but having to track color exceptions would become rather cumbersome and error-prone in the future.

Hoddie

Lego's inventory lists this part as DK GREEN - I suppose that's what the BO catalogue needs to reflect. I'd argue that cloth should never have a colour because they're almost always printed and/or uniquely available in one colour only. N/A would seem most appropriate, but if a colour is necessary than DK GREEN would seem most appropriate.

robernat

If you guys check the link above again, now there are 2 colors: Bright Light Orange and Dark Green.
You will say: How is that posssible ? Simple, I noticed quite a while ago that unusual colors appear not only for 'fabric' parts but for many other items. When discussed with Admin, it seems that anyone who 'lists' a part in a certain color or puts it on his wanted list in a certain color (that's what I just did for dark green on this part), it's added as a 'color' in the database. So the 'color' section here on BO is very different then the 'known color' column on BL (it's more a mix of known colors / wanted list colors / listed colors).
I do believe this data should be splitted up in the long run, as it might lead to errors when people list the part or when one starts adding parts in the wrong color to inventories just because the database holds the part in a certain color that does not exsits.
If you look at the inventory of the set, there is no color indicated, it means it has no defined color (so Not Applicable).

Eric

Stragus

@RobErNat Interesting, thanks for the explanations.

Now... If only I could create lots of such items with color zero (Not Applicable) from the API. And in the set's inventory, the dropdown menu for the color of that part is still at "Select a color" rather than at "Not Applicable", if that means anything.

robernat

Not applicable is not considered a color, a while ago they wouldn't even show up in the 'for sale' items, but apparently Admin made a tiny change after my query about it (show up now).

http://www.brickowl.com/catalog/lego-foil-with-waterfall-pattern-97000
If you look at these, mine is in the list (I choosed 'NA' to list it), but the count of available ones still just says 'buy (8)' (while with mine 9 are listed). Also in the color tab, there is either 'ALL' and 'Trans Light Blue', there is no 'colortab' for 'Not Applicable'.

Wheter 'Not Applicable' should be used in set inventories in stead of 'select a color' is up to Admin, as he needs to make sure it works for all parts of this kind. So we'll need to wait for his answer on that.

Lawrence

Select a color is the same as not applicable which is the same as an uncoloured part. The api issue is a bug which I will try to fix when I'm able to.

robernat

I know nothing of coding, but wouldn't it be simpeler to consider 'not applicable' as an actual color while select a color is the same as uncolored (select a color=undefined yet)? Uncolored is used as 'master' for each part in catalog, 'not applicable' could be one of the subcolors of any part. Happens on BL like that as well, as people can list items with color 'non applicable', even the price guide reflects it and I often notice it in items listed for sale because people forgot to select a color.

Lawrence

That was actually an integral decision of Brick Owl, I probably spent 2 weeks in that particular issue, I'm happy with the way it is. "Select a color" is just a display issue

robernat

Ah, Ok, if it's that hard of an issue, then yes it's probably better to leave as is

@Hoddie: listings now as 'dark green' was the worst you could do, they are printed (partially) dark green, but they are not dark green, the base color is yellow with red and dark green lines, don't go by TLG's way of thinking as they don't build catalogs, and databases like on Brickowl need consistancy, particular with parts like this.
Besides, you'll never have a picture showing up unless you upload one (but I really hope Admin won't approve it), and if you check the 'known color' (in the set inventory) it is without color (best way for these kind of items)

DagsBricks

As with other printed parts, why wouldn't you specify a base color? In this case I would have said Yellow with Red Vertical and Green Horizontal Stripes.

Brian

robernat

For me Yellow is an option (like the poncho's), but Admin needs to tell how he sees it to keep consistancy in catalog in the long run.
On top of that, if he wants to allow the users who want to use Bricksync to have a match between their stock here and elsewhere then the same 'color' must be applied, otherwise we are back to reading message number one in this thread ;-)

Hoddie

Dark Green would be appropriate if Lego records the colour of cloth by reference to the colour of the primary print, rather than the base colour of the material. I agree that a consistent approach is needed but until we have one, I'd rather follow Lego's lead.

Lawrence

With things like cloth I prefer a colour of not applicable as the colours are usually mixed and they don't match exactly to the colours of normal parts.

robernat

I kinda expected that answer, but then you have problem with the poncho's:
http://www.brickowl.com/search/catalog?query=poncho+with
They do have a color (one even has 3 colors and 1 image is attached to the wrong color) on BO and they match BL (usefull for those who want to sync).
Reason a clear stand must be taken in regards to 'printed' cloths. I'm personally in favor of NA as well, with a description of the visible colors, but if BO does do it differently then BL (and there is no reason why it shouldn't) then those who use 'sync' will have a problem. Being Admin you need to decide wether BO follows BL on these or wether BO follows the preference you expressed (but then expect a contributor like me to apply it to all similar cases).
Maybe it's time to make a 'guideline' in regards to such things (foils as well), to avoid the confusion in the long run.

@Hoddie: being a very active contributor to BL in the past and a quite active contributor on Brickowl now, I can tell you one thing: never use blindly what TLG thinks of a certain color in regards to special items (not talking regular ABS parts), as it will mess up the database sooner or later

Stragus

I have no strong opinion regarding the color of cloth parts listed in set inventories, though N/A would seem the most appropriate.

But please, also allow one to create lots with colors (including N/A) that match the ones being used in other databases.

Lawrence

Could you clarify the issue with the ponchos? I prefer not applicable for cloth, but there will be cases where a specific colour makes more sense, there isn't a rule on it. We don't follow BL, with things like that I just decide what I think is best.

robernat

Well, the poncho's have a base color (tan for 2 of them, yellow for the other).
Example:
http://www.brickowl.com/catalog/lego-fabric-poncho-with-green-and-red-design-16479
The main image is also attached to the 'green' version of the part (import TLG I assume), while the color of the cloth is yellow all sellers have it listed as 'yellow'.
So why do these have a color and are you opposed to the OP's part having a color.
http://www.brickowl.com/catalog/lego-curtain-vw-97122
Hoddie suggested Dark Green (TLG), but the cloth is 'yellow', yet you prefer N/A (I do to)

"Admin (Lawrence)":With things like cloth I prefer a colour of not applicable as the colours are usually mixed and they don't match exactly to the colours of normal parts.

While with the Poncho's the basecolors also don't really match normal parts, and have a mixture of printed colors, yet they have a color.

"Admin (Lawrence)"I prefer not applicable for cloth, but there will be cases where a specific colour makes more sense, there isn't a rule on it.

And that's exactly the problem if I may say so: inconsistancy in the long run.

"Admin (Lawrence)" We don't follow BL, with things like that I just decide what I think is best.

Sorry, but the original data did came from BL, with all errors and with all inconsistancies. I know there is still a lot to do, and maybe these kind of things are not very important right now (maybe particulary not important for you), but if you want to give BO a consistant look in the long run (also inventories wise), it is better to work on it from the start (or to set guidelines) when things like this get discussed. New things will enter the database, the way you will treat those will depend on how you treat 'past' things, any random 'action' depending on your case to case bases will confuse people in the long run I'm afraid (look at Hoddie who decides to list the cloths as 'dark green' just because TLG calls them so).

Stragus

@RobErNat Since you are certainly an expert in matters of LEGO cataloging, what do you think would be the best way to proceed to define such general, consistent guidelines and rules?

I'm sure Lawrence (and everyone else) would consider your opinions on the topic. (and I'll be repeating myself, but we also need to allow listings in colors that match other databases.)

Hoddie

The best way IMO would be to remove colours from all fabric items, with each one having a unique BOID regardless whether two or more are identical but for the colour(s), and describe the colour of the fabric/print in the item name. This would likely mean such items are not directly comparable with their BL counterpart.

robernat

I do not need to help make guidelines and rules for the catalog, I think Lawrence is more then capable to do such, the only thing I would prefer to see is overal consistacy, something that has bothered many catalog contributors on BL as well: naming conventions, numbering conventions (not a problem here as TLG numbers are used, particulary for heads and torsos) and yes, consistancy in fabric and foil items and other special items.
This together with more realistic inventories (sorry but seeing recent molds getting attached to 20 year old inventories because it's 'automated' just bugs me as a purist collector) would be a great step forward (particulary in the long run).
If people can't rely on the catalog, they will never use it as primary 'source' to collect, and it is exactly that what a site like this must be: the best and most reliable source, as it will bring the collectors here, and they are the ones who spend big money... Currently those people (including me) are buying mainly on BL, new ones will come along and existing ones will come here to have a peak when in need for some HTF, but they will only remain here if they can trust the database. At least that's my point of view. Maybe Lawrence is trying to target other type of buyers, dunno, but I fear they are not going to be the regular big spenders (not that I need to complain, otherwise I wouldn't be exclusively here at the moment offcourse).