Re: What is Data Model FOR?

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Wed Apr 28 2004 - 14:44:10 CDT

At 2:50 PM -0400 4/28/04, David Mertz wrote:
>On Apr 28, 2004, at 8:17 AM, dr-jekyll@att.net wrote:
>>I'd like to help develop a Process Model to complement the Data
>>Model I submitted a few weeks ago. I've received very little
>>comment about it -- and that scares me.
>
>I think the reason you haven't gotten much feedback, Kurt, is that
>no one (including me) really knows what purpose the Data Model is
>supposed to serve. I do recognize the terms in there as describing
>interesting data and facts about elections, so I can see a glimmer
>of a connection, but that's about all.
>
>I have a hunch that your way of thinking about it comes out of some
>kind of RDBMS analysis. I'm not sure if you think you're trying to
>do database design, maybe. But EVM2003 DOES NOT use RDBMS's for
>data storage, and I will STRONGLY advocate that OVC specifications
>avoid use of RDBMS in the production systems. Such relational
>models are poor choices for data transparency and portability. The
>right way to do it is the way the demo does (in a prototype way),
>with XML formats. I'm actually not a huge fan of XML--probably
>because I write about it for a living--but this is an area where it
>is clearly the right technology.
>
>If you'd like to make your Data Model of some use to someone, I
>would again recommend what I suggested before. Take the
>ballot-election.xml file that we use in the demo, and expand the
>format to include your extra data fields. The intention of our
>development to-date is that some superset of this file contain the
>complete specification of one election (i.e. the content data, other
>files will serve as meta-data for the GUI layout and other ancillary
>details).
>
>We could use both a commented DTD that specifies the placement of
>all your new fields (and the old one already used), and an expanded
>example of a hypothetical election with the rest of the data filled
>with realistic sample values. If you like, you could also create a
>RelaxNG (ideally compact form) schema to clarify data ranges and
>cardinalities with more precision than DTDs allow. Or if you
>insist, I guess you could use W3C XML Schemas (but I dislike them
>personally, for ever so many reasons).
>
>While production will be "Green field" as Arthur urges, I am
>confident that our XML data designs are something we really got
>right in the demo (once they are expanded in some compatible and
>predicted ways). This technical approach doesn't close off any of
>the variants that may come up with usability and security studies,
>but is simply a neutral and clear format for relevant data sets.

While the polling place computers will likely use XML, it is likely
that relational databases will have a role in a county-based
tabulation system. It's also possible that a native-XML-handling
production database system will prove robust enough to handle it
instead. The volume of data at a county level precludes the use of
flat files alone. Transparency encourages the use of mostly
human-readable (when printed) flat files at polling places.

Best regards,
Arthur

-- 
-------------------------------------------------------------------------------
Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Fri Apr 30 23:17:21 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT