[sc34wg3] Supporting variants in TMCL

[Xuân Baldauf]

Are Gulbrandsen wrote:
> Hi
>
> Steve Pepper 30. okt. 2009:
>> Are Naito-san and I really the only two users of non-SAE languages
>> [2] that care
>> about variant names? Are they not widely used in Korea and China, for
>> example,
>> as well as Japan? What about topic maps in Cyrillic, Arabic,
>> Devanagari, etc.
>> etc.?
>
> For some more input into this discussion, I can recommend reading Xuân
> Baldaufs paper for TMRA 2009, "Modeling Names", which I had the chance
> of reviewing:
> http://tmra.de/2009/talks/Modeling_Names
>
> The paper is not yet published on the TMRA website, but I'm sure Xuân
> wouldn't mind that interested people got to read it before the
> conference. (Cc to Xuân)
Hi,

due to "popular demand", you can access a preprint of the paper at
http://academia.baldauf.org/resources/conferences/tmra.de/2009/Modeling%20Names/Baldauf%20-%20Modeling%20Names.pdf

ciao,
Xuân.
>
> In the acknowledgement he writes:
>
> Thanks go to the MOTOMU NAITO who raised the issue that there is a
> multitude of renderings of the very same Japanese name (14). This
> paper is based on and inspired by a mailing list thread which was
> effectively started by LARS HEUER suggesting that nobody would need
> variant items (15).
>
> 14 See http://www.infoloom.com/pipermail/topicmapmail/2009q2/007486.html
> 15 See http://www.infoloom.com/pipermail/topicmapmail/2009q2/007482.html
>
>
> Steve Pepper 2. nov. 2009:
>
>> * Lars Marius Garshol
>> |
>> | So far there doesn't seem to be much enthusiasm for supporting variant
>> | names in TMCL.
>>
>> That might be symptomatic of a more general apathy. Or of the fact
>> that most
>> users of Topic Maps do not (yet) have the same needs as Naito-san.*
>>
>> | The biggest problem with adding support is that variant
>> | names have no type, and so it is difficult to see how to express the
>> | matching part of the constraint. In all other constraints we use
>> | tmcl:constrain-statement or something similar, but that doesn't work
>> | for variants.
>>
>> I hope you excuse me if I say that I don't find this argument
>> particularly
>> compelling. Surely if a language cannot meet a legitimate
>> requirement, then
>> there is a problem with the language, not with the requirement?
>>
>> Unfortunately I don't understand the inner workings of TMCL well
>> enough to be
>> able to propose a solution. But are you sure you are not trying to
>> create
>> something more general than is really needed? Would it help if I were to
>> formulate a constraint in English that I believe would do the job:
>>
>>  NAMES of type "foo" belonging to
>>   TOPICS of type "bar" can or must have (one or more)
>>    VARIANTS in the scope "baz"
>>
>> In other words, we need to be able to constrain every variant
>> statement on the
>> basis, not of its type, but of what type of name it is a variant of
>> (and what
>> type of topic that name belongs to).
>>
>> Naito-san: Would that satisfy your requirements?
>>
>> Steve
>>
>> * In the old days this committee used to bend over backwards to
>> accommodate
>> everyone with a valid use case - even if they were in a minority.
>>
>> _______________________________________________
>> sc34wg3 mailing list
>> sc34wg3 at isotopicmaps.org
>> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>
>
> Best Regards,
> Are D. Gulbrandsen
> The XML-group,
> Center for Information Technology Services
> University of Oslo
>
>
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3 at isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>