Re: Def: Data Model

At 04:55 PM 2000-12-21 -0500, Katie Haritos-Shea wrote:
>As per today's discussion, we need to define Data Model.  

AG::

I wasn't in on the discussion, so I can demonstrate ignorance without shame.

Assumption:  There is somewhere in the drafts of the principles a statement
that the content should provide necessary information either "in markup or in
an associated data model."

If that is what needs explanation, then a general discourse on data models is
not necessarily necessary.  What we really need to make clear is the
difference
that forced us to say either/or in the above.

In this case, the "associated model" is knowledge that is not spelled out in
the markup itself but can be reliably associated with items in the content by
pattern matching against the markup.

Short definition: A data model is something which publishes patterns or rules
which aid in the interpretation of data.

Where we are headed is a pattern of practice which says: a) use these marks
(markup definition) and b) interpret those marks in the following way (model
definition).  The markup and model work hand in hand to convey what the User
Agent needs to know to have flexible presentation and interaction-control
capability reconstructed in the User Agent and delivered to the user.

Example of application of data models to accessibility: tables.  A proper
model
for tables in XHTML would define columns, and not just rows.  What column or
columns a TD cell is in can be reliably reconstructed from textual order of
the
cells in a TR row and the 'colspan' attributes of the cells you have passed
over already in the row.  A model would spell this out, so that a "myColumn"
query against a cell would be well defined and implemented alike in all XHTML
table implementations.  Because this can be reconstructed given the present
markup, we don't want to add markup.  But we want the standard interpretation
spelled out so the content can reliably be referenced in this way by User
Agents.

Homework exercise.  To understand the possible role of models in defining
formats, consider doing an HTML table as an application of the XForms work. 
That is to say, a table is a degenerate form where all the fields are defined
constants, and don't accept user input.  This would give you a data structure
in the document with a model behind it.

Second Example: assistive tracks in multimedia.  We have a variety of flavors
of these.  Descriptions of the video presented in audio.  Descriptions of the
video presented in timed text.  Replication of the dialog in timed text
(subtitles).  Replication and orientation to the dialog in timed text
(captions).  Text representing the multitrack multimedia ensemble in a form
capable of un-timed reading (script or collated transcript).  These are but a
few examples   We are very concerned as to how do we capture what media
objects
are there, and how do they relate to one another, with enough information so
that a User Agent can understand how they can be used to satisfy the needs and
desires of a user.  This is important so we can be sure that SMIL 2.0 has
enough expressive capability to say what needs to be said.  This is urgent
because the CANARIE project is building prototypes of multimedia archives that
will be played with the aid of (under the rules of) some such model.  And
it is
needed by the User Agent Working Group so they are confident that they have
asked the right kind of things of players in interpreting and offering user
control over the content.

Note: for those of you into computer math, the breakpoint is this:  The
relationships that we need to understand among the various media objects in an
accessible multimedia resource form a graph.  A collated transcript contains
equivalents for more than one of the other media objects, but not necessarily
for all of them.  The model that one can build with an XML DTD is a tree
structure.  There are references to other elements by ID that make the
model of
the XML document a graph and not just a tree, but the DTD capabilities give us
no way to say what those arcs mean, or how they are to be interpreted.  For
this we must rely on an additional model that defines the structure of the
semantic graph.  Our alternatives are to define the XML application straight
off in XML Schema or to use mixed model-building media by having a core tree
constructed with an XML DTD and annotated by RDF which completes the model as
an overlay on the structural armature that the XML DTD lays out.  The latter
construction method is what we have at present in SVG and SMIL.

We need an application or requirements model which captures the information
requirements or preconditions for graceful transformation, and an
implementation or format model which allocates this information into encodings
in the element attributes and metadata structures of the mixed-mode
dialects of
SMIL and SVG.  Sometimes it helps to look at the information in these two {as
required, as coded} views.  Sometimes one can do it in one pass, but the
results are not always satisfactory.

Warning:  we probably need to capture and understand more than one
'definition'
for data model to have this topic under control.  In the world around us,
people use the phrase in a variety of senses, some broader, some narrower; and
we _probably will need to touch all those meanings at some point_ so we
need to
be able to lump or distinguish them at different times, and might as well have
our map of the meanings in hand to guide us as we go.

In fact, in our application -- capturing information in web content that
enables and facilitates the graceful transformation of the essential
information into diverse and thereby adaptive presentations -- we will be
dealing with multiple types of data models (in the broadest sense) and data
models that are of different classes or fill different roles.

References:  groups that use the term 'data model' or simply 'model' that we
will want to care about include: RDF model and syntax, XML Schema Working
Group, and the XForms Working Group.  In addition we will want to understand
the connection between object oriented modeling and data modeling.  Because
information content is about what people perceive and understand, and people
perceive and understand things in terms of how the act, not just what
properties they exhibit or what constituents they contain.

For a mind-bending exercise, study the following two papers on model
mediation,
where there are actually multiple models spelled out in computer-interpretable
formality, interacting to create a composite capability, a composite
resource. 
[PDF warning for both references.]

 Working Paper SIDL-WP-1999-0126
 <http://www-diglib.stanford.edu/cgi-bin/get/SIDL-WP-1999-0126>http://www-d
iglib.stanford.edu/cgi-bin/get/SIDL-WP-1999-0126

 Model-Based Mediation with Domain Maps
 <http://www.sdsc.edu/~ludaesch/Paper/icde01.html>http://www.sdsc.edu/~luda
esch/Paper/icde01.html

We will be looking at RDF and XForms and XML Schema as resources in
implementing techniques to capture the necessary information.  But object
oriented analysis, or scenario analysis in any of various forms, will be
helpful in understanding our requirements.

Al

>Below is a start,
>please review and rip it apart for better
>comprehension.........................
>
>Data Model WC The product of the database design process which aims to to
>identify and organize the required data logically and physically. A data
>model says what information is to be contained in a database, how the
>information will be used, and how the items in the database will be related
>to each other. For example, a data model might specify that a customer is
>represented by a customer name and credit card number and a product as a
>product code and price, and that there is a one-to-many relation between a
>customer and a product. It can be difficult to change a database layout once
>code has been written and data inserted. A well thought-out data model
>reduces the need for such changes. Data modelling enhances application
>maintainability and future systems may re-use parts of existing models,
>which should lower development costs. A data modelling language is a
>mathematical formalism with a notation for describing data structures and a
>set of operations used to manipulate and validate that data. One of the most
>widely used methods for developing data models is the entity-relationship
>model. The relational model is the most widely used type of data model.
>Another example is NIAM. 
>
>
>Katie Haritos-Shea
>508 Coordinator / Webmaster, CIW
>NTIS/Fedworld 
>Department of Commerce
>5285 Port Royal Road
>NTIS WebLab for Accessible Design
>Room  # 2025
>Springfield, Virginia, 22161
>ph 703-605-6426  fax 703-605-6826
><mailto:kshea@fedworld.gov>mailto:kshea@fedworld.gov
><mailto:kshea@ntis.fedworld.gov>mailto:kshea@ntis.fedworld.gov
>
>
>
>

Received on Friday, 22 December 2000 12:54:54 UTC