OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Mary Nishikawa wrote:
> 
> Dear TC Members and Prospective Members,
> 
> Happy New Year.
> 
> Murray, I began to take a look at the PSIs you wrote for XTM because I want
> to follow your examples and build on then to make other much-needed
> PSIs.  I tried to validate  the contents of language.xtm and country.xtm in
> one xtm file and discovered that alpha2 and alpha3 topics are used in both.
> We need to define unique IDs for all of the topics in PSIs, no matter which
> file they are in, right? If so, I changed the alpha2 alpha3 to beta2, beta3
> in country.xtm. I also fixed the "Afghanistan" instance in country.xtm (I
> hope you don't mind. You had written "to fix" so I made it the same as the
> other instances, otherwise, the file would not have validated).

The changes you've described invalidate the semantics of the originating
content. The terms "alpha2" and "alpha3" have nothing to do with alpha
and beta, it's simply "alphabetic 2 character" and "alphabetic 3 character."
There's no reason at all to worry that language.xtm and country.xtm have
IDs in common, as IDs are only required to be unique within a specific 
document. The resultant PSIs are "unique-wi-fied" by the base URLs of their
parent documents.

I also don't understand why you needed to modify the files for validate at 
all. They are both completely valid XML as they stand. I've validated them
literally thousands of times in opening them up within applications, processing
them, and of course validating them during their initial development and 
testing. The "to fix" note in the file had to do with code changes from ISO,
not syntactical changes necessary to the country.xtm file.

> Also, I think that you mentioned that you worked on a PSI for DC Elements.
> I think that we really do need it. Can you submit it, if you have it? Thanks.

Certainly, though I think we should first discuss what we're doing with 
these files, who is taking responsibility for their maintenance, where
they're being published, etc.

> I created a new PSI region.xtm which is the
> "Composition of macro geographical (continental) regions and component
> geographical regions"
> 
> http://www.un.org/depts/unsd/methods/m49regin.htm
> 
> of the United Nations Statistical Division.
> 
> http://www.un.org/depts/unsd/methods/

You perhaps could have contacted me prior to taking on this effort. I already
have a region.xtm topic map that uses the UNSD Geographical Region codes. I've
already commingled these codes in creating region.xtm. I've also got a geo.xtm
topic map based on the MARC codes. See below.

> There are also countries and codes associated with this listing. I wonder
> how we could incorporate this information into country.xtm, or should we
> keep this as a separate PSI? Only trying to cover geography can get quite
> complex. I am wondering how we should handle class instances. Can we safely
> define a Continental region  as a super-class and component geographical
> regions as a subclass? Should we also define associations in a PSI?

This is what I've done in region.xtm. I have a "Boundary", "Bounded 
Geographical Region" and "Bounding Geographical region" topics to type 
associations establishing bounds between countries.
 [...]
> 
> Bernard, I was not sure about the copy write notice. I used both
> topucMaps.org and Oasis-Open.org. I also wondered if we need to formally
> get permission from the UNSD if we do want to use this.

You do.

> I really want to get started working on this and I have others that I want
> to work on. I am looking forward to everyone's feedback.

I've already received permission from the UN on use of these codes. I
contacted the MARC standards office and to my recollection you don't
need permission to use their codes as they're in the public domain.

I'd be interested in discussing this further, and especially in better
coordinating these types of efforts so that people don't duplicate
efforts as seems to be the case here. Before we begin throwing files
around and developing topic maps it might be a good idea to discuss
how we're going to divide the work and responsibility.

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

               Rally against the evils of iceburg lettuce! 
            Grab a kitchen knife and join the Balsamic Jihad!


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC