| |
Currently, there are three active major part databases out there:
Partsref, Peeron Inventories, and the BrickLink Catalog. All have their
advantages:
Partsref has keywords, cross-referencing to other databases, and usually
excellent pictures[1].
Peeron has Partsref parts and good pictures for non-Partsref parts, and
good navigability (and is tied in with inventories[2]).
BrickLink is the most complete and has really good navigation.
There are, however, problems. The one that has become increasingly a
source of frustration for me is over-specificity. The current part
taxonomy either does not recognize distinctions[3] or enforces them almost
absolutely. But there needs to be room for indeterminacy. As a recent
example, see
http://www.bricklink.com/messageThread.asp?ID=3096
I believe that this problem springs from the LDraw-basis for parts
taxonomy. Someone building a part in LDraw needs to know the exact
geometry of a given part. This is fine (vital) for a part author, but
fuzziness is vital for parts buyers and sellers, those making inventories,
and even CAD *users*. Another contributor to this problem is the use of
TLC's numbers, even when, e.g., TLC uses two numbers for the same part.
I think that the Lego community needs a new, universal, and more flexible
parts identification scheme[4,5]. Here are some test examples that
capture what I think is needed:
6192 and 30337 (bricks 2x4 with rounded top) should be the same unless
someone is specifically looking for one or the other.
Someone looking for Captain Redbeard's head should have no trouble finding
both stud solid and stud hollow versions at the same time.
People should be able to decline to choose whether, say, a particular
grille tile is with or without groove (for example, while doing an
inventory from instructions, where it may not be clear).
People *should* be able to specify whether a Slope 45 2x1 has or does not
have a center post, but not be pushed either way.
People should be able to identify a part as patterned even when
the particular pattern is not in a relevant database (when, e.g.,
inventorying a brand new set).
At the present time, things are rough. People can, quite innocently,
enter bad data while selling parts or inventorying sets:
http://peeron.com/inv/parts/3626b?ignorepat=y
says that stud-hollow minifig heads have been available every year since
1978. . .
My proposal would be to adopt a universal number of the form
xxxx.yyyy.zzzz
(where xxxx, yyyy, and zzzz are numbers[6] of no universal length) such
that xxxx describes the part as an abstraction (e.g., minifig head) (and
this number may well be the LDraw/TLC base number, but needn't be), yyyy
describes the particular geometry (e.g., stud hollow), and zzzz describes
the pattern (e.g., smiley). The trick would be to make 0 undefined
(indeterminate). Then <minifig head id>.0.0 would match both stud solid
and stud hollow in all patterns (and, for that matter, would match
friendly skulls, which is not current behavior). Such a scheme would give
non-experts an out from committing to something about which they are not
sure while at the same time allowing a part to be specified as finely as
possible by people who know, care, and are confident (4x8 waffle plate?
No problem!).
The tricky part is that quite probably no one (at least, no one in
charge of a popular parts database) has time to do this. . .
Thoughts?
--
TWS Garrison
http://www.math.purdue.edu/~tgarriso/
Remove capital letters in address for direct reply.
[1] Printed parts (especially minifig heads) tend to be too small to
distinguish, but parts with edges are often easier to understand from CAD
renderings than from photos. The major failing of Partsref is how
searches dead-end the user. . .
[2] So one option for finding a part is to look in the inventory of a set
you know contains that part.
[3] For example, I don't believe anyone currently distinguishes between
the internal designs of minifig torsos, although the fact that these have
changed was raised in connection with set 10000.
[4] I know this has been brought up before in this newsgroup, although I'm
too lazy to look up references.
[5] Actually naming and categorizing parts is a whole 'nuther debate,
which isn't really relevant to this; as long as everyone can agree on a
common id for a part, translation between naming or taxonomical schemes is
simply a matter of implementation (see, for example, Partsref).
[6] Of course, any ASCII string is fine, but preferably lowercase alpha
characters and digits, and digits are easiest to deal with.
|
|
Message has 2 Replies:
 | | Re: Thoughts on Parts Taxonomy
|
| I like the idea of better indexing, and would be happy to incorporate any new method into peeron - now someone just has to write it :) I know that indexing by a non-unique field (which is the part number) is a bad thing - it's just the easiest and (...) (22 years ago, 11-May-02, to lugnet.db.brictionary)
| | | Re: Thoughts on Parts Taxonomy
|
| I'm not going to quote it because I agree with it in total. I'd like to add some related thoughts that have been nagging at me ever since I first encountered Brick{Bay,Link} and LDraw... The thing that bugs me most is the names given to the parts. (...) (22 years ago, 11-May-02, to lugnet.db.brictionary)
|
9 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
