Re: [tm-pubsubj] Re: Country.xtm PSI; also proposed region.xtm PSI

[Murray Altheim <murray.altheim@sun.com>]

Steve Pepper wrote:
> 
> At 11:33 10/01/02 +0100, Bernard Vatant wrote:
> >Let's sum up the positions, if I get them correctly
> >...
> >
> >Murray and Bernard think that this specific TC should be open to field experts
> >of various organizations,
> >and not restricted to internal debate in the topic map core community
> >concerning
> >controversial existing PSIs.
> 
> Whether or not this makes sense depends on what we want to achieve with
> this committee. My primary aim is to get corrected versions of country and
> language out as soon as possible, and ensure that they encourage best
> practices, as regards both topic map modeling in general and published
> subject definition in particular.

Agreed, in the sense that we need to be clear about what *this* committee
has within its charter. If its charter is to further define PSIs and 
provide and example of them in the publishing of one or more topic maps,
then I agree. 
 
> To my mind, these PSI sets should simply express what is in the
> corresponding ISO standards (3166 and 639) in a form usable by topic map
> applications and DO NO MORE THAN THAT! They should contain no extended
> material beyond what is in 3166 and 639; there should be no mappings (for
> example) from ISO codes to other controlled vocabularies or natural
> languages. All that kind of stuff is fraught with difficulties and
> contention, and we should steer clear of it. Our job is pure translation.
> If there are inconsistencies in the ISO standards, we should find a topic
> map representation that preserves those inconsistencies.

If the ISO code sets were fixed entities, this would be true. But they're
not. They are (as they must be) changing periodically to reflect the 
continuing changes in the names of languages and countries. There is 
continued maintenance of the code sets by ISO, by different groups of
people. A correct maintenance of the language and country topic maps must 
include liaison with the relevant ISO committees to understand their
issues, their delivery schedules, with planned updates based on updates
to the code sets. I (Murray) developed the country.xtm and language.xtm
topic maps in active coordination with contacts from ISO, MARC, and the
UN. It's inappropriate that I (Murray) should continue in this role,
or that any other person should do this. It should be handled by a 
formal liaison role within a TC. This is not pure translation, even if
the topic maps do not go beyond the ISO codes. 

And BTW, the reason they do is that the communities that actually use
the ISO codes do not include everyone. The MARC codes are used by the
US government, and the UN codes are popular within many foreign 
governments. ISO's codes widely disseminated but by no means universal.

> Given that, I don't see the need for domain expertise. If anyone knows of
> specific issues in the ISO standards that cannot be handled without
> recourse to domain experts, I would like to hear about them. Otherwise I
> think this particular task should be done quickly and efficiently by us.
> (In fact, I believe Lars Marius has already done it.)

Uh, I (Murray) have already done it. I'm not sure where the desire to
rewrite these from scratch comes from, but it's unnecessary. They were
published with the XTM 1.0 Specification, and I believe all we're talking
about is bug fixes, not a complete rewrite. If you believe otherwise, please
explain the rationale.

> >Steve P. prefers to see the question tackled inside PubSubj TC.
> 
> No. I'm easy. Whatever gets the job done as quickly and efficiently as
> possible.

I'n not in favour of expediency for expediency' sake. The current set
of PSIs currently exist and are functional, as has been stated numerous
times. If there are semantic errors *within* the topic maps or if there
are missing or changed codes, this is easily fixed. But 

   http://www.topicmaps.org/xtm/1.0/language.xtm#en

will not be changing, and that is what's important. I do agree within
what I've said above that we should perform this task as soon as is
reasonably possible.
 
> > > It could make sense to extend the charter of PubSubj to encompass these
> > > two, on the grounds that they already have some kind of semi-official
> > > existence and are themselves establishing a precedent for other sets of
> > > published subjects.
> >
> >This "semi-official existence" is by itself an issue, as you are well
> >aware of.
> 
> I don't think it's an issue. It's a *problem* in a sense that those two PSI
> sets are out there and are referenced by the specification in a way that
> encourages people to regard them as having some form of seal of approval.
> Whether they do or not is irrelevant, as long as people believe that. They
> need to be made to be exemplary in every way possible.

I still do not see the *problem* you keep referring to. If by the last
sentence you are making your primary point, then I would suggest we not
concentrate on language and country, but instead on core.xtm, since it
is absolutely necessary to the functioning of XTM, whereas language and
country are not.
 
> > > This really is the job of PubSubj, so by taking in
> > > country and language, the existing TC would be neutralising a possible
> > > competitor!
> >
> >What do you have in mind? What kind of competitor or competition?
> 
> Simply that country and language as they are now are setting a precedent
> that will be in conflict with the guidelines PubSubj intends to create. The
> longer they are around (in their present form), the harder it will be to
> clear up the resulting mess.

I consider the current situation pretty stable, as it has been for over
a year. Internal changes to language.xtm and country.xtm will have little
or no effect on existing software or implementations, at least insofar as
the proposed changes I believe you and Lars Marius have explained over the
last year. When an update to the three topic maps is published by OASIS I 
would hope that there might be some consideration of wrapping them in the
ISO flag, since the XTM 1.0 DTD is somewhat useless without at least the
core.xtm topic map.

> I still think a discussion of the statement of purpose is more important
> than deciding whether or not to start a new TC. It could take place in this
> forum, if the rest of the TC agree. Otherwise we should take it elsewhere.

I would suggest that if we are truly looking for an exemplar of the 
PSI concept, we fix errors or "new thinking on publishing PSIs" in core.xtm 
itself. That can be our exemplar. I'd prefer to see language and country
(and whatever problems they have, including issues of code sources, 
updates, and the semantics of the codes) discussed in a different light
since these issues *do not* affect core.xtm. And because of the necessity
of establishing a more formal relationship (both politically and 
operationally) with ISO in order to maintain the codes (and with the 
MARC records office and the UN if we want to be able to state "North
America" or "Europe" (something the ISO codes do not have), then this
should be handled under a new TC whose charge is this activity.

And there are likely as many issues with core.xtm as with the country.xtm
and language.xtm topic maps. For example, mapping XTM into any other
markup or representation system requires the ability to express the 
PSIs of *all* XTM language components. We'd in Dallas (I believe) agreed
to include PSIs for everything in XTM, then backed down. We need to 
revisit this. Also, with topic map association templates and the issues 
surrounding use of XTM as its own schema, there may be minor changes to
the existing set (in terms of language) or major changes (if templates
are to become part of core). I don't really expect the latter to occur,
but my point is that in my research it has occurred to me that such a
template.xtm topic map will likely need to "include" core.xtm as a 
module (of course using <mergeMap> syntactically), and that we may need
to establish *how* best to do this, which might include changes to core.xtm
as well as recommendations on how template.xtm might best perform this feat.

Anyway, ignore the last paragraph as simply an example. These issues are
best brought to the surface when we concentrate on core.xtm, which I 
think (rather than country and language) would certainly be within the
purr-view of this TC.

Murray

...........................................................................
Murray Altheim                         <mailto:murray.altheim&#x40;sun.com>
XML Technology Center, Java and XML Software
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025

            Corporations do not have human rights, despite the 
          altogether too-human opinions of the US Supreme Court.