What is Data Model FOR?

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Wed Apr 28 2004 - 13:50:18 CDT

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.
==================================================================
= 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:20 2004

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