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

[Jan Algermissen]

Jan Algermissen wrote:
> 
> 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).


Sorry, it appears the above sounds like "I tell you how it is!". I should
have added that what I wrote is of course only my opinion and that I 
try to find out if you agree to that.

Jan


> 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

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org