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

 


Help: OASIS Mailing Lists Help | MarkMail Help

geolang-comment message

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


Subject: Re: [geolang-comment] First proposals for ISO 639 and 3166 available


Hi Murray,

Lars Marius is going to be out of email contact for a few days, so I'd
like to clear up a couple of points in his absence.

At 14:23 30/08/02 +0100, Murray Altheim wrote:
>I'm curious as to how (apart from any perceived mistakes in naming
>the typing topics) the approach you are taking is different from the
>one taken in the language.xtm topic map in the XTM 1.0 Specification?

1) the subject indicators will be in X-HTML, not XTM
2) the subjects they cover will be languages and countries, not
    language codes and country codes
3) numeric codes will be used for country PSIs, not alpha codes
4) for languages, 3-letter codes will be included
5) for countries, numeric codes will be included
6) French names will be included for both
7) published subject identifiers will be given explicitly, not
    left to be inferred

There may be some other differences as well. Other than that, the
same basic approach *is* being followed.

>Then why the long discussion with John Cowan about the issue? I don't
>understand the rationale of discussing reinterpretation of 639 unless
>one is contemplating it.

The discussion is not about reinterpretation of 639: No-one wants to
do that. This disagreement is about how much of what is actually in
639 we want to capture. John and I say "everything - warts 'n' all";
Lars Marius says to leave out the bits we know (or believe) to be
warts.

>I guess you'd have to define "ontological" (probably as misused a
>term as "semantic"). What notation a file is in might be considered
>pretty irrelevant to its content. I don't see that the content of
>639 is any different expressed in a PDF file or a topic map, in
>terms of meaning ("ontology"). If you're talking about machine-
>processability, that's not ontology, that is machine processability.

...which in turn has to do with how explicitly the semantics are
represented...which is what I understood Lars Marius to be getting at.

>I'm not sure what is unclear. I've said it many, many times, and
>began my interjection here with it. I think the languages topic map
>should reify the codes in 639 as topics. Nothing more.

I'm not sure what "reify ... as topics" means here, but it sounds as
if you *still* think that the subjects we should be publishing are
the codes, not the languages. If so, you are flogging a dead horse:
That discussion has been resolved and the committee has moved on.
Each PSI will indicate/identify a *language* (or *language group*),
not a *language code*.

>If you need
>a typing topic to tie them all together, fine. But going beyond that
>begins to reinterpret the standard, which I *think* we agree is a
>bad idea.

The discussion to hand is indeed about the "typing topic" - actually
the typing *topics*: "language" and "language collection" (or "language
group"). We agree that we will have PSIs for these, because they are
concepts within 639. The disagreement is about whether the formal
representations in XTM and RDF (as opposed to the subject indicators
themselves in X-HTML) should include the assertions (present in 639)
about which 'languages' are in fact languages and which are actually
language collections.

I have suggested a kind of compromise, whereby there would be two
XTM files: one containing just topics, with names and (perhaps)
occurrences, but without class-instance assertions. The other
containing just class-instance assertions. That way we've mapped
everything in 639 in such a way that people who disagree with the
639 classification don't get saddled with it.

>If I have a point that hasn't been stated, it's perhaps that apart
>from changing the names of typing topics in the existing language.xtm
>and country.xtm, and updating any code changes from ISO, I don't see
>what it is you guys feel is necessary to do.

My seven points, above, should make that clear.

>This was discussed a
>long time ago as a task that could be completed in very short order.
>Steve argued rather vociferously that Ontopia's business was in
>jeopardy because changes needed to be made *quickly* to those topic
>maps, and that those changes were relatively minor (in terms of number
>of necessary edits).

None of this ever had anything to do with "Ontopia's business", Murray.
It had to do with the suitability of the existing PSI sets in real-world
applications and a belief that we made a few serious mistakes that
needed to be fixed before they propagated too far.

The main reason everything has taken longer than expected is that we've
all been involved in other things and that the PubSubj TC needed to
make some progress on the general issues before we could really come
to grips with countries and languages. I am convinced that we are now
very close to agreement and that Lars Marius' next draft will almost be
reading for approval.

>I'm not trying to raise a ruckus, I just don't see why there seems
>to be so much discussion about what I thought was a straightforward
>task, and the only way I could understand why that discussion was
>happening was if you were treading into territory that I thought
>we'd all agreed was verboten, or at very least unwise.

Rest assured: No-one wants to reinterpret, change, or modify anything
that is in 639. I hope that is absolutely clear now.

Steve

--
Steve Pepper, Chief Executive Officer <pepper@ontopia.net>
Convenor, ISO/IEC JTC1/SC34/WG3  Editor, XTM (XML Topic Maps)
Ontopia AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway.
http://www.ontopia.net/ phone: +47-23233080 GSM: +47-90827246



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


Powered by eList eXpress LLC