External Representations of Designs

[Peter Dobcsanyi]

Hello All,

This is a post to outline the concept of the external representation and
its purpose in our project.


		 The External Representation of Designs
		 ======================================

Introduction
------------

    The External Representations of Designs can be best defined by its
    role in the operation of the Design Theory Resource Server (DTRS).
    DTRS has many faces, it is an ever growing database of designs,
    application server, web server for design related online documents,
    software repository etc.  The main purpose of the external
    representation is to provide a standard format for data on designs.
    This data-format is used in communication between various components
    of DTRS and its users.  Here the concept "users" covers both human
    and software agents. Some examples for such communicating agents:
    database back-end for storing designs, middle layers between the
    database and the web and/or application servers, a researcher
    uploading some particular collection of designs, an user searching
    for designs having given properties, a statistical application
    program directly accessing the DTRS database etc.  While these
    agents are free to use any internal representation of designs, they
    must use the standard external representation when they communicate
    to each other.

    There is an (evolving) document, instantiated at the beginning of
    the DTRS project, outlining our view of what designs are, and the
    principles we use to classify them. These classes differ enough to
    warrant more or less separate definitions for their external
    representation. So the "External Representation of Designs" is
    rather a collection of external representations of the main classes
    of designs.  For example, external representation for blockdesigns.
    We envision DTRS as being gradually developed along the lines
    determined by these main classes.

    An external representation definition comprises not only a formalism
    to encode a particular class of designs as mathematical objects but
    it should also be able to express the most important properties of
    these designs. Many of these properties are complex mathematical
    objects on their own right.

    Describing such properties leads us to another important purpose of
    an external representation, that is to provide a medium for
    formulating complex queries about designs. Typically these queries
    will be sent to various software components of DTRS.

    Finally, we wish to use the external representation as a
    specification tool to determine the content and, in some extent, the
    structure of the DTRS design database. Note however, the database
    internal representation can (and probably will) be quite different
    from this format.

    Satisfying the requirements outlined above, it should come as no
    surprise that what decided to use XML for external representation of
    designs.

    In short, an external representation of a class of designs is an XML
    document describing a list of designs.  Such a document serves one
    of the following two purposes:

	- encoding designs and their properties as mathematical objects.
	- expressing queries about designs in terms of their properties.


Specification Process
---------------------

    Specification of an external representation happens in many, in some
    extent interleaving, stages.

    - First we determine a class of designs which should have a common
      external representation. This decision is based on the above
      mentioned design taxonomy document. So far we decided to deal
      first with blockdesigns.

    - The second step is to choose a mathematical representation for the
      particular designs, since the same class of designs usually have
      many different mathematical models.  This step is far from obvious
      and can have significant impact on the external representation and
      related implementations. (See PJC notes, "Block designs: duality
      etc.", in a different thread.)

    - The third stage to define the XML encoding of designs and a
      chosen set of properties in the framework of the selected
      mathematical model.

      Formally, we are going to define an external representation by an
      XML Schema linked with an annotation describing the semantics of
      the components together with some discussion, rationale etc.  The
      XML Schema currently used is Relax NG in compact syntax, other
      schema formats are automatically generated.

    - The next stage is the "publishing" of the specification on the
      Web, inviting a public debate. This stage can (and hopefully will)
      be quite extensive. It is very important to reach as wide
      audience in this stage as possible. We should try hard to get
      active participation from experts, potential future users,
      interested parties etc.

    - The final step is the "consolidation", finalizing the definition
      of the external representation by incorporating the information
      obtained by the public discussion.

      This stage ends with the publishing of the final specification,
      paving the way for the next phase of development.

    Based on our recent developers meetings, it is worth to mention
    that this specification process seems to help us a lot to reason
    about our project.


Development
-----------

    Once an external representation's final definition is completed the
    development phase can start. Some of the important activities here:

    - specification then implementation of the related database

    - start systematic collection of designs from external contributors
      in the standard external representation format

    - "gluing" together the existing software components developed so
      far in the DTRS project.


Comments/discussion are welcome.

--
           ,
Peter Dobcsanyi