[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [tm-pubsubj] Re: Country.xtm PSI; also proposed region.xtm PSI
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@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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC