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

[Jan Algermissen]

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