[sc34wg3] Some general comments on the RM (branching from the thread Re: [sc34wg3] The Norwegian National Body position on ISO 13250)

Mason, James David (MXM) sc34wg3@isotopicmaps.org
Tue, 15 Apr 2003 17:20:52 -0400


Likewise a quick reply:

I'm a linguist by training. Syntax to me is not just the sorts of things
that you have at the very concrete level of validating a document against a
DTD. Syntax (as in Chomsky's "Syntactic Structures") is the fundamental set
of requirements on expression. The lists of constraints on values in Clause
4 of the RM are just as much syntax as that implied by the content models in
a DTD. The attaching of properties to objects is syntax, though less
concrete than specifying in what order the attachment must take place. If
you look at Chomsky's view of language, you find that he's interested in
such things as a requirement for something like a verb in a sentence, not
whether the verb comes early (English) or late (German).

The RM had better be about semantics of TMs, or it doesn't have any reason
to exist. It had better explain what it means to be a subject or for a
subject to be a role player in an assertion. Just as the SAM makes a
transition from the abstract syntax of the RM to the concrete serilization
syntax of XTM, so also it provides an interpretation of the high-level
semantics of generalized roles into concrete things such as roles in
occurrences. But the fundamental semantics have to be there in the RM or the
SAM will have to go off on its own, which is what we're trying to avoid.

While it's true that syntax, at whatever level, affects semantics
(constrains semantics), it's better to do some expanining along with
presenting syntax. "A poem should not mean but be" (Ars poetica, Archibald
Macleish) is fine as an arguing point in literary criticism, but it won't
satisfy the average reader.

Jim

-----Original Message-----
From: Jan Algermissen [mailto:algermissen@acm.org]
Sent: Tuesday, April 15, 2003 5:01 PM
To: sc34wg3@isotopicmaps.org
Subject: Re: [sc34wg3] Some general comments on the RM (branching from
the thread Re: [sc34wg3] The Norwegian National Body position on ISO
13250)


Jim,

thanks for the comments.

One short reply:

"Mason, James David (MXM)" wrote:

> I observed that I felt that the RM was the place for fundemental semantic
> grounding for TMs. 

The RM provides the ground for defining TMAs (e.g. the SAM). *ALL* semantics
are defined in TMAs.

> At this point, the RM is still heavily syntactic. It
> places a lot of emphasis on properties (Clause 3) and constraints (Clause
> 4). This material, particularly in Clause 4, is syntactic, though at a
very
> abstract level. Perhaps I should say it's structural, but for me the
listing
> of properties comes closer to syntax than just structure. 

I don't understand what 'objects' (aka topics/nodes/proxies etc) that have
properties 'attached' to them have to do with syntax. 

Despite any impression that the prose possibly creates, let me say that:
The RM has nothing to do with syntax. 

In addition, no TMA has anything to do with syntax.

Syntax is handled by syntax deserialization specifications (that process
syntax using the semantics of one or several TMAs).


JAn
 

> That syntactic
> material is necessary to provide a basis for mapping to the SAM. But it's
> severly lacking when it comes to defining the semantics of TMs.
> 
> In short: You need to be standardizing both syntax and semantics; at this
> point you're neglecting semantics. Syntax/structure should be defined as
> concisely as possible, preferably through notation or tables rather than
> prose. Prose should be reserved for things that can't be done in notation,
> which means semantics.
> 
> 1. Clause 2, the glossary, should be as brief as possible. Don't try to do
> normative stuff here; make it just a collecting point for things that need
> to be defined for clarity or because they come up again and again in the
> standard. 2.15, "r-topic" is a good candidate to stay in. 2.37 "TMM" has
no
> business in the standard. Definitions like 2.10, that simply expand an
> initialism or acronym, belong somewhere else, either in a list of
> initialisms or simply folded back into the primary topics.
> 
> 2. Clauses 3 and 4 are generally OK, so long as they are dealing with
things
> that can be dealt with in narrative prose. Reducing the definition of
> properties to a table, as in 4.2.1 is good. No sense in wasting words on
> that sort of thing.
> 
> Section 4.2.2 should be done likewise: almost all the constraints could be
> handled in a table, perhaps by expanding column 6 of Table 4.2.1. All that
> should be left of 4.2.2 is the explanatory matter that conveys semantics,
as
> opposed to structure constraints. For example, the first sentence of
> 4.2.2.1.1 is OK; the rest of 4.2.2.1 should go into the table. There is
> currently no real text in 4.2.2.2, except in the notes, so this whole
> section could be reduced to a row in a table. If the stuff in notes 10 and
> 11 is normative explanation, it shouldn't be in notes.
> 
> Figure 1 (note 13) shouldn't be in a note. It should be pulled up into the
> main text. If the figure is normative, then it can replace a whopping lot
of
> inefficient prose.
> 
> 3. Try to avoid having more than 4 levels of headings.
> 
> 4. It's fine if we put up an HTML version of this thing with plenty of
> hyperlinks. Eliot's HtTime is a good model for that. But that stuff can't
be
> normative, and it shouldn't be in the printed version. It shouldn't be in
> the PDF either, unless you can make the hyperlinks work (which they don't
in
> the file I pulled down from Sara's site).
> 
> Jim Mason
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org
_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3