On Mar 19, 2014, at 4:55 PM, Charlie Stirk wrote:
> There is a standard schema for material properties, STEP AP235 "Materials
> information for the design and verification of products", but it is not
> widely implemented. The current version of the AP235 Express schema is
> based on PLIB, and harmonized with AP 209ed2 for engineering analysis.
Thanks Charlie! I couldn't remember which AP covered materials... It's
interesting to read that AP242 looks to integrate all aspects of 209 as well.
I'm hoping we can jump straight to 242 once we can round trip some subset of
our geometry via 203 or 214.
> STEPcode can parse the schema and generate class libraries, an API, and file
> read/write executable. STEPcode provides a partial implementation of
> 10303-22, the Standard Data Access Interface, and does not yet include the
> database aspects of 10303-22.
That would have made for a good GSoC project idea. Hook up STEPcode's SDAI
generator to SQLite for the missing session/repository components...
> The BRL-CAD translator for STEP, based on STEPcode, could be expanded to
> support the CAX-IF material identification capability, which can be a key to
> material properties. Or one can use the generic STEP User Defined Attribute
> functionality. Recommended practices and sample files can be found at
> www.cax-if.org.
Albert, this is definitely something worth looking into if only so the web
interface you're proposing is flexible enough to accommodate STEP import/export
later on. My gut says the emphasis should remain on the web interface
usability, so it'll be important to make sure you capture common data needs.
> I intended to ask you about
> the desired number of traits of materials(20 40 or even more) because
> that would help in deciding about the initial layout of database
> schema like whether it would be beneficial to continue with the
> existing schema or should we better start afresh?
You must demonstrate strong rationale for starting fresh. That amounts to
designing a new schema and being able to explain in detail how and why it's
better. If you want to propose going that route, that's fine but know that
you'll need to have that sorted out long before coding begins. So for your
proposal, you are proposing work that amounts to simply using whatever schema
that is decided.
> Because the existing
> schema comprises of distinct tables for each trait of the material
> which would result in too many number of tables and that is a kind of
> laborious and cumbersome activity.
This is database normalization. There are upsides and downsides. See
http://en.wikipedia.org/wiki/Database_normalization
> So keeping extensibility in mind
> (gradually adding more and more traits) we would have to pre-plan it
> so that it does not impede the performance later.
Normalization isn't done for performance (on the contrary, you often
denormalize for performance). It's to minimize redundancy and dependencies.
For a database this small, however, the arguments for both are mostly moot if
there's a good usability design on top.
Cheers!
Sean
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
