Subject:
|
Re: Proposal: New Part *NAMING* System.
|
Newsgroups:
|
lugnet.db.brictionary
|
Date:
|
Mon, 13 Oct 2003 21:10:00 GMT
|
Viewed:
|
6775 times
|
| |
|
|
Just to through my 2 cents in (even though I'm two weeks behind the rest
of this thread ;-) )...I'm definitely interested in being a part of this
project. (Being a data-organization junkie may have something to do with
it.) Let me know what I need to do to get in on the ground floor of this.
In article <HLyHLE.21IJ@lugnet.com>, "Tim Courtney" <tim@zacktron.com>
wrote:
> > 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.
>
> 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 interface with each other) have totally unrelated
> numbers?
>
> One thing I like about the LDraw library is many (not all...) parts
> of similar nature are grouped. At least paired - male/female hinges,
> etc.
>
> > 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).
>
> Again, why not a modifier of the part the decoration is printed on?
In both cases, my understanding is that the part number assigned in the
database is not for the human user's use, but for the database's
internal use. Each unique part gets a unique number with which it is
tracked for all other methods of specifying that part. (I'm even
inclined to extend this unique numbering to each color each part is
found in.)
The reason for not trying to set off blocks of numbers for related parts
or modifiers for decorated parts is two-fold. One, you're trying to
predict how large a block of numbers you'll need for a given group of
parts, and it's almost guaranteed that eventually you'll run out numbers
in a block, since new parts are continually turning up. Two, more
importantly, trying to make the unique part numbers relate to how the
parts are classified completely defeats the purpose of having the
database be "skinnable"--ideally, different nomenclature "skins" would
be developed for different purposes, and how parts are grouped and
related within a particular skin would not have to follow any other
skin's groupings. If you try to group parts for numbering, you have to
make arbitrary decisions about how to group them--is a 1x2 brick a
2-stud long 1x, or a 1-stud long 2x? And that's exactly what this
database is trying to get away from: by making it skinnable, you can
group the parts by the method that makes sense to *you*, without having
to worry about how anyone else would group them. Having the internal
numbering reflect a particular grouping is just extra work for the folks
creating and maintaining the core database.
The simplest way to do it is to simply have the database serially assign
a unique part number as parts are added to the database. All
classification methods would be based on data in other fields--but the
database would link everything back to that unique serial number. Then
each part would have fields for its various characteristics, as detailed
as we determine it needs to be for unique descriptions. Then a skin can
group those parts based on whatever characteristics the skin's designer
wants.
--
Mark D. McKean - The Quantum Panda - qpanda@quantumpanda.com
|
|
Message is in Reply To:
 | | 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)
|
11 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
