RE: A "one size fits all" personalized web page?

Scott,

the following is long, and addresses only the argument that there are not
semantics in HTML.

consider the following table:

<table>
<caption>Inventory of boy's possessions</caption>
<tr>
   <th>Number of books</th>
   <td>5</td>
</tr>
</table>

Which, as I understand it is a semantic presentation of the information you
were trying to give (see below on "visual formatting and semantics"). If you
consult the HTML specification it will tell you that a table has a summary
attribute whose content summarises the table, and a caption which "describes
the function" of the table.

Any row may have header cells, and data cells. It is possible to explicitly
associate the headers with each cell, to ensure complete unambiguity of the
semantics, but there is a specified algorithm for inferring semantics, in
particular how headers relate to data.

In simple summary we have a property of the boy, which is the number of books
he owns, and that prperty as a value, which is 5. That information is encoded
(in my example) using the avilable semantics of HTML. There is a default
presentation defined, although there is no reason why I coudn't write the
following CSS

tr {display: block}
th {display: block; float: right; font-weight: bolder}
td {display: inline; }
caption , .adverts {display:none }

To display the table as

         5    (bold:Number of Books:bold)

We could take a more complex table:

<table>
<caption>Inventory of boy's possessions</caption>
<thead>
<tr>
   <th>Types of book</th>
   <th>fantasy</th>
   <th>technical</th>
   <th>blue</th>
</tr>
</thead>
<tbody>
<tr>
   <th>Number of books</th>
   <td>5</td>
   <td>6</td>
   <td>7</td>
</tr>
</tbody>
</table>

Which, with our stylesheet might be rendered as

       (b:blue  technical  fantasy  Types of book:b)

5 6 7                          (b:Number of books:b)

where (b: ... :b) denotes bold text

(for those who can't see it, the spacing is also messed up)

(shows the limitations of the stylesheet. Let's tidy it up a little, changing
it to:

tr {display: block}
th {display: inline ; text-decoration: underline}
th:first-element {display: block; float: right; font-weight: bolder}
td {display: inline; }
caption , .adverts {display:none }


giving us

   fantasy   technical   blue   (b:types of book:b)
   ~~~~~~~   ~~~~~~~~~   ~~~~      ~~~~~~~~~~~~~

5 6 7                         (b:Number of books:b)
                                 ~~~~~~~~~~~~~~~


(longdesc: all headers are underlined, the spacing is wrong but the ordering
is correct.)

Now we're getting somewhere near what a table does in formatting.

However, for each of these examples, a conforming parser using the HTML
specification's specified algorithm would make the correct semantic
associations, and they can easily be extracted from the source. (the tablin
tool does that, for example).

I think your argument about lacking semantics in HTML is misapplied here - it
is true that there are semantics which are not reliably native to HTML in a
machine-readable way, but there also are a great deal of semantics encoded in
HTML in a machine-readable way. Just becuase I can't infer that a paragraph
is talking about the weather in Melbourne ion tuesday from reading the markup
doesn't mean I can't infer anything at all. In fact if the information is
classed sufficiently than all I need is access to the scheme used for the
classing (This can be expressed using RDF) and I can extract those
semantics. The limitation is whether the author understands the semantics of
what they are writing sufficiently to make them explicit, and that is a whole
different ball of wax.

But where we come to here is "the semantics of visual formatting".

Visual Formatting and Semantics.

Something most o us who are sighted take or granted is the semantics inherent
in visual formats. When we see a page of text, with a few lines on the top
right hand side, followed by a short line o fixed form, followed by some
paragraphs, followed by a line which is left-aligned to the center of the
page, we may make a numbr of assumptions. At my school (white,
english-language, Australian, ...) I was taught to recognise that the things
at the top right constitute an address, that the short line at the beginning
constitutes a greeting, that the paragraphs constitute the main body of the
letter, and that the last, off-centre line is a signature, and that the
document as a whole is a personal letter. (in all probability)

Similarly, if i see the following

      Inventory of boy's possessions
  
      ---------------------------
      |  Number of books  |  5  |
      ---------------------------

(the second line of text has a border, and the "5" is seperated from the rest
of the line by a vertical internal border)

I assume that this is in fact tabulated information, with a heading or
caption.

It is clearly wrong to assert that there are no such semantics implied. There
is a whole school of typographical study and communication that does very
extensive work on what the implied semantics are, and how best to understan
them and to apply them to a given situation. However, it is just as clear
that those semantics are not well extracted by, for example, a speech
synthesiser. In particular, they are not as well extracted as the semantics
of the table we have discussed above. (emacspeak is perhaps the best example
of this that is easily available - understanding tables is something that
developers have found notoriously difficult to implement well in non-visual
platforms).

As you have pointed out, this is not something that people always find
intuitive. Indeed, many authors do not understand it enough to make use of it
without assistance. And the way that it is presented does make a difference
to its comprehensibility.

There are, we agree, limits to the things that can be reliably expressed by
HTML semantics in such a way that a user can easily and reliably transform
them. Those semantics exist, and can be ecxtracted, but for an individual to
figure it out involves communicating the method the author used - in effect,
involves the user having access to the particular ways in which the basic
HTML semantics were extended. In fact the role of class attributes is to
extend those semantics, and the role of the tite attribute is to provide a
human-readable version, but that relies on high-quality user agents,
essentially ones which allow editing of content, for the user to get real
value. These things are abundant (more so than "standalone browsers", by
number of products) but are not widely used in that way. But the real
question is how to deal with extending the semantics of HTML in a way which
is useful to the people in the real world, and I will address that in a
seperate message.

cheers

Charles
      
On Tue, 11 Jan 2000, Scott Luebking wrote:

  Hi, Charles
  
  Please forgive my not responding sooner.  I've been down with the flu
  for a couple of weeks and am just now fighting through a bad email
  backlog.
  
  I believe that a key problem is that I'm using the terms "semantic
  information" and "semantic content" in ways different than I think you
  and Gregory might be using it.  My use of "semantic information" and
  "semantic content" is more similar to how a human-computer specialist, a
  linguist, a cognitivie scientist might use the the term.
  
  For example,
  
        "Le garcon a cinq livres."
  
        "Il ragazzo ha cinque libri."
  
        "El muchacho tiene cinco libros."
  
  are statements in different languages.  The "text context" is different
  in each line.  However, the semantic content or semantic information
  is the same for all the lines.  The semantic information could be
  represented as ~the boy has five books~ .  (Notice that I'm using the ~
  to indicate semantic content or information rather than quote which
  would indicate textual content.)
  
  On web pages, there can be great variety for conveying semantic information.
  For example, if there is a table:
  
  
      Inventory of boy's possessions
  
      ---------------------------
      |  Number of books  |  5  |
      ---------------------------
  
  the semantic information ~the boy has five books~ is still the same
  even though the presentation is different.
  
  
  I believe a critical aspect of accessibility is getting to the "semantic
  information" on the page.  Naive users often confuse "semantic
  information" with "presentation".  They tend to focus on presentation
  when frequently what is more important to them is the semantic information.
  However, "semantic information" is often an abstract concept
  they are either unable to work with or are uncomfortable with while
  "presentation" is more "real" to them since they can read it.
  
  The choice of presentation can make it is easier or harder to understand
  the semantic information on the web page.  For some users, one type of
  presentation will be easier.  For other users, another type of
  presentation will be easier.  Sighted users will often do better with a
  lot of visual cuing.  However, use of visual cuing will add to the
  "underbrush" that blind users will have to fight through with their
  screen readers.  Information presented more textually and more in order
  of semantic content importance will often be preferable to blind users
  as they are extracting the semantic information from web pages.
  
  A conceptual limit in computer science is that once HTML is generated,
  in general, software cannot extract the "semantic content" represented in the
  HTML.  A corollary of this fact is that HTML cannot be transformed
  according to the semantic content of the page.  (It is very important that
  you understand this computer science limitation otherwise you won't understand
  my arguement since it is a key factor in my analysis.)
  
  Augmenting HTML via "title", "rel" or "class" is not a solution either.
  Do you see why?  (Hint:  do a "step by step" analysis of the process
  from the user's point of view.)
  
  
  Also, look at what you are assuming about about a user's "ability to
  understand what what is being given to them".  I think that a detailed
  analysis will show the leaps you are making.
  
  
  I believe in the diversity of human beings, including how they move
  from presentation to "semantic information".  A web site which recognizes
  this diversity and provides varieties of presentation with the
  same semantic information makes it easier for the various users.
  I believe my approach will result in web pages which are easier to use
  by a wider range of users with less technical demand on them.  The software
  will generally do a better job because the programmer will have a better
  understanding of the "semantic information" involved than will a user.
  (I believe that what I am proposing is compatible with what Chuck brought
  up.)  Your approach does not recognize the issue of "semantic
  content" as I've defined it, it cannot offer as many posibilities which would
  be more appropriate.
  
  I'm also getting the feeling that you might value one type of presentation
  over another.  Why are you assigning values like that?  If some user finds
  some presentation easier to use when moving from presentation to
  understanding "semantic content", why would you assign a "lesser" value
  to it?
  
  
  Again, the core issue is semantic information or semantic content.  For
  the discussion to make sense, we need to have the same understanding
  of these terms.
  
  Scott
  
  PS  The example shows about web pages organized according to semantic
  content or information.

Received on Wednesday, 12 January 2000 02:27:03 UTC