🚀 go-pugleaf

Darrell Raymond's challenge on comp.text.sgml that we think critically
about the limitations of descriptive markup systems for general data
modeling reminded me of Douglas MacLeod's address (read by Yuri Rubinsky)
at SGML '89 in Atlanta.  MacLeod made an extended analogy between
gardenvariety documents DTDs and architectural blueprints.  He suggested
that it would be a good idea to use a metalanguage like SGML to unify
the representation of information in diverse fields.  The print version
captioned by editors of <TAG> as "Will We Build Buildings With SGML
Someday?" concluded as follows:

<q>Standards such as SGML imply that there is more to documents than just
raw text and graphics.  I would like to suggest that there is also much
more to this world than just documents.  Information can be expressed as
text, or graphics, or music, or manufactured parts in three dimensions,
or even as buildings.  We all need a language that will address the
common problems of information that unite all our professions and I
believe that a metalanguage such as SGML could provide the basis for
expressing even architectural information.</q>   See "Building
Buildings: An Analogy for a Language to Build Architectures," <TAG> 14
(May 1990) 710 (10).

The levity discernable in Michael SperbergMcQueen's summary of the paper
(given in a trip report) left me uncertain whether the audience took the
analogy to heart as merely provocative and suggestive, or indeed, whether
MacLeod's lecture embodied something profoundly concrete.  Michael wrote:

<q>The second day concluded with two challenging presentations.  The
first was a talk by the architect Douglas MacLeod (read in his absence by
Yuri Rubinsky) on recent developments in computer tools for architecture.
These, MacLeod maintains, parallel (insofar as they are worthwhile) the
style and structure of SGML.  MacLeod imagined intelligent architectural
tools built on an analogy with SGML, which would allow for simple,
softwareindependent specification of building information in a form to
be used by a variety of tools from graphics software for generating
blueprints and elevations to cost estimation spreadsheets for creating
the construction budget, to specialpurpose software for calculating the
necessary insulation and thermal budget of the building or checking its
compliance with local building codes.

This eloquent and imaginative talk was well received, though the central
analogy of a buildingspecification as an SGML document so confused one
hearer that he was still asking plaintively, the next day, how a
physical object like a building or a car could possibly be parsed by an
SGML processor.  Ultimately it was made clear to him that in all known
systems a machinereadable specification, and not the physical object,
would be the parseable document  if the specification drove
manufacturing equipment, a car might indeed be produced from the SGML
document, but would have to be regarded strictly as a side effect.  A
group of casuists thereupon gathered themselves over a copy of the SGML
standard itself, and found that it explicitly leaves the physical form
of its input unrestricted.  No one could figure out how to represent
delimiters in a physical automobile but it was agreed that this was
merely an implementation detail.</q>   Posting, Date: Sun, 29 Oct 89
18:55:39 cst; Text Encoding Initative public discussion list <TEI
L@UICVM>; From: Michael SperbergMcQueen 312 99624772981; Subject:
conference report: SGML '89 (Atlanta, 2527 October).

MacLeod's paper formulated for me a question that's never adequately been
answered: where are the boundaries of "good" uses of SGML?  To the dictum
commonly conceded ("SGML is good for representing hierarchically
structures, or for information that can be modeled in terms of
containment"), Darrell Raymond suggested that when SGML moves out of its
hierarchical bailiwick, its claims to (program) application(s)
independence become compromised.  Hmmm...what does "hierarchical" mean in
this context?  Maybe (1) That the information objects we wish to
represent are at surface level susceptible to description as structural
hierarchies, or (2) That any objects, however nonhierarchical at surface
level, if transformed into (concurrent) hierarchical structures
representationally without doing violence to the multidimensional
"essences" of the objects themselves, qualify for SGML representation?  I
think there may be some debate about the wisdom of transforming
quintessentially nonhierarchical objects into hierarchical fictions for
representational purposes, or about the theoretical possibility of doing
so adequately.  If SGML isn't adequate for general data
modeling/representation of the types Darrell nominates, does this verdict
bear on SGML'a adequacy as defining information interchange languages 
if all we want to do is to get information into a common format
accessible to widely divergent (database) applications programs?

The matter of representing (descriptively, not necessarily
prescriptively) concrete 3dimensional objects still intrigues me.  The
success of HyTime seems to have vindicated MacLeod's vision, at least in
principle: we have an SGML application for structuring temporal events. 
When I try to encode written texts from antiquity, I face two and three
dimensions of physical space in addition to the structural hierarchies of
the "texts."   Suppose (it's not hypothetical) we have a basalt statue of
an elegantly garbed royal figure, superinscribed with a bilingual edict
in cuneiform and alphabetic languages.  The writing superimposed upon the
flesh and garb of the royal figure proceeds spirally around the statue,
or alternately, in uniform lines, in two different directions.  Here we
have a concrete object which begs for "information representation" in
several dimensions: to what extent "is" the object a hierarchical
structure, and to what extent can/should SGML/HyTime be used to capture
knowledge about the statue in a formal way?  What important features
cannot be captured by, or validly transformed into, hierarchical
structures?  Some aspects of the arthistorical features are clearly (?)
best represented in images (color, texture), but what about the synchrony
of both text characters and inscribed nontextual art with the three
primary axes of Cartesian space?  Is it irrelevant that the words BLORT
and BLORT1 and BLORT2 appear in successive lines on the royal figure's
staff, held at oblique angle, if the sequence BLORT, BLORT1, BLORT2
suggest an acrostic?  Is it thought that we could write a useful DTD for
"inscribed statues"  useful for incoding information about statues
other than the one in question?

My rationale in introducing this case is to show motivation for unifying
many kinds of representations into one scheme: we may not be able to
perceive relationships or patterns unless we have such synchrony across
the multidimensional representations of the object.  For the statue, we
may want to query the object for quantitative and annotative details of
its arthistorical dimension in 3dimensional Cartesian space, but we may
also want to query the intersection of arthistorical, paleographical,
"text"critical, literarycritical, linguistic, (etc.) description in any
combination.  Surely we have here multiple concurrent and (only)
partially overlapping hierarchies (and would want to use something like
CONCUR); just as surely, we have here a lot of representation of object
structures/features which are not hierarchies at all.

Questions: (1) What formalisms currently known are better than
SGML/HyTime for registering and unifying the several kinds of information
representation we want to make of the inscribed statue?  (2) How hard
will it be to build "generic" applications software supporting the study
of such objects with synchronized/unified information representation
schemes?  (3) Does anyone (else) perceive that the use of grammars (DTDs)
for *descriptive* and (versus) *prescriptive* purposes involves some
distinctions which have not yet adequately been clarified in SGML
literature?

Confession: I once tried to write a DTD for my house.  The wiring,
subflooring and other framing (visavis room boundaries) gave me
fits, but that was before I knew anything about CONCUR.  :)

rcc


Robin Cover              BITNET:   zrcc1001@smuvm1  ("onezerozeroone")
6634 Sarah Drive         Internet: robin@utafll.uta.edu  ("utaefelel")
Dallas, TX  75236  USA   Internet: zrcc1001@vm.cis.smu.edu
Tel: (1 214) 2961783    Internet: robin@ling.uta.edu
FAX: (1 214) 7093387    Internet: robin@txsil.sil.org
=========================================================================