Subject:
|
Re: Proposal: New Part *NAMING* System.
|
Newsgroups:
|
lugnet.db.brictionary
|
Date:
|
Sun, 28 Sep 2003 17:53:56 GMT
|
Viewed:
|
6676 times
|
| |
|
|
In lugnet.db.brictionary, Dan Boger wrote:
> On Tue, Sep 23, 2003 at 12:12:09AM +0000, Ray Sanders wrote:
> > I like the ideas proposed here. They are almost identical to something
> > I've been tossing around for a while with some other folks. Anyone out
> > there interested in being involved in creating a public catalog ?
>
> We're very interested in having a public system set up, and would love
> working with one. It's something that we've been planning to do (with
> LDraw) for quite some time now - we even posted back in the day, to try
> and get some momentum going, but it never took off.
>
> What do you have in mind? How can we help?
>
> Dan
This is a working draft of what I have in mind - Ray
==============================================
Conceptural Outline for a Public Parts Catalog
A) The results of the effort will be held under a public content license (such
as Open Content or Creative Commons). The results will be freely available for
anyone to use for any purpose (within the bounds of the license).
B) The catalog is an effort to provide an inventory of all known LEGO, and
LEGO-compatible, toy parts. The effort is not meant to duplicate efforts within
LDRAW, but is meant to be complimentary.
C) The catalog is intended to be attribute driven.
D) The catalog should be language neutral and support multiple language
representations for any item (where practical).
E) The catalog is not intended to handle part-set inventories, but will handle
sub-assemblies where they make sense (i.e. minifigs).
F) The catalog is intended to handle textual information, but may also keep
images and/or links to LDRAW images.
G) Arranging catalog entries into categories will be done at an abstract level.
No item in the catalog will permanantly belong to a fixed category (i.e. the
catalog will be flat).
H) Every item in the catalog will be assigned an abstract number at the time it
is added. These number will not have any relationship to mold numbers that may
or may not be stamped on the part. If a part is added multiple time, then
successive abstract numbers will be aliased back to the original, they should
not be deleted or reused.
I) Entire catalog should be downloadable as a GZ/ZIP/whatever file (possibly in
XML format)
J) The catalog should have a sub-part to track potential known colors. Known
colors may/may-not be associated with parts.
K) Decorated parts should have their own abstract number, but should also be
related to the undecorated base part (which means adding the decorated part
implies adding the undecorated base part if it does not already exist).
L) "common used part number" whether molded in the part, or abstractly generated
by another catalog list, shall be stored with relation to the site where they
are used. IOW, we do not want to pick a previously-known/widely-used part number
and annoint it. It is better to inventory the known parts and then show the
previously-known/widely-used part number as they are used by each external site.
M) The catalog shall have the ability to keep notes (or comment) entries about
parts. These will be free form and may be in any valid language.
N) The catalog should (if possible) contain basic information about the
interconnection abilities of the part (e.g. pin-male, stud-male, etc).
O) The catalog will include set names (in multiple language representations) and
notes/comments (possibly used to indicate version changes).
P) The catalog will contain physical information about parts and sets (if
possible). Physical information being weight (each or by 100s), dimensions
(which is going to be difficult for irregular parts), clumping/nesting (a metric
indicating the ability of the part to nest with like parts for
storage/shipping).
Q) The catalog will include information about instructions (multiple versions),
catalogs and other Lego items which are not strictly speaking parts or sets.
Examples of these would be promo toothbrushes, backpacks, watches, etc.
R) Text entries shall be stored internally in UNICODE (most likely UNICODE 3.0)
|
|
Message has 1 Reply:
 | | Re: Proposal: New Part *NAMING* System.
|
| (...) Ray - this sounds like a very ambitious (and cool!) project :-) See some questions inline. (...) Why not block some numbers off for natural groupings of parts? Would say, a 1x2 brick with click hinge (2 prongs) and the same with 1 prong (that (...) (21 years ago, 29-Sep-03, to lugnet.db.brictionary)
|
Message is in Reply To:
| | Re: Proposal: New Part *NAMING* System.
|
| (...) We're very interested in having a public system set up, and would love working with one. It's something that we've been planning to do (with LDraw) for quite some time now - we even posted back in the day, to try and get some momentum going, (...) (21 years ago, 23-Sep-03, to lugnet.db.brictionary)
|
11 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
