Modeling Names

TMRA 2009: Modeling Names
2009-11-13

Modeling Names

Xuân Baldauf <xuan--names--2009--tmra.de@academia.baldauf.org> 1 of 28

2009-11-13

Variants
TopicName:
type: Topic
value: String
scope: Set<Topic>
variants: Set<Variant>
Variant:
value: String
datatype: IRI
scope: Set<Topic>

2009-11-13

kill Variants?
TopicName:
type: Topic
value: String
scope: Set<Topic>

☠
Variant:
value: String
datatype: IRI
scope: Set<Topic>

2009-11-13

What are variants?
„A variant name
is an alternative form of a topic name that
may be more suitable in a certain context than the
corresponding base name.”
Well, then we can actually drop variants and replace
them with topic names.


2009-11-13

What are variants?
„A variant name
is an alternative form of a topic name that
may be more suitable in a certain context than the
corresponding base name.” [TMDM]
When dropping variants, we loose the
correspondence. Oh, there is correspondence.
If there is correspondence, then:
Each variant's value overrides its topic name's value
(in a certain context).

2009-11-13

Default values of topic names
Consider: topic name which contains some variants.
As an author:
How to determine the default value? Choose any of
the variants' values? Which?
Throw the dice?
Ask a sun^W^Wan oracle?
Take the variant who you are most familiar with?
Your default value is most likely culture-dependent.


2009-11-13

No default values of topic names!
Cultural bias in default values of topic names?
Cultural bias in Topic Maps.
Should be avoided.
Proposed solution:
Drop default values of topic names.


2009-11-13

What makes names different?
Consider the city at 41°N 29°E


2009-11-13

Different or not different?
„Constantinople“ (English)
„Konstantinopolis“ (Turkish)
Are these names different?
Maybe...

o n s ta n ti
C
K
le
olis

2009-11-13

„Konstantiniyye“
„‫“قسطنطينيه‬
Looks like they are different.


2009-11-13

„Konstantiniyye“ (Ottoman Turkish)
„‫“قسطنطينيه‬ (Ottoman Turkish)
Well...


2009-11-13

„Konstantiniyye“ (Ottoman Turkish)
„‫“قسطنطينيه‬ (Ottoman Turkish)
Both names encode the same sound.
Uh!


2009-11-13

More candidates
„Istanbul“ (English)
„İstanbul“ (Turkish)


2009-11-13

More candidates
„Konstantiniyye“ (Ottoman Turkish, Latin script)
„‫“قسطنطينيه‬ (Ottoman Turkish, Arabic script)


2009-11-13

Groups of names
„Konstantiniyye“ (Ottoman Turkish, Latin script)
„‫“قسطنطينيه‬ (Ottoman Turkish, Arabic script)
Apparently, there is some „natural grouping“.


2009-11-13

Grouping properties
Names within each group are „somehow“ similar.
For each scope, there is only one name per group.


2009-11-13

Group<->members
Name<->variants
It looks like there is a structural match
between observed patterns
and TMDM


2009-11-13

Let's check the match

group member scope of member

(Name #1) “Istanbul” English

“İstanbul” Turkish

(Name #2) “Constantinople” English

“Konstantinopolis” Turkish

“Konstantiniyye” Ottoman Turkish (Latin-based script)

“‫”قسطنطينيه‬ Ottoman Turkish (Arabic-based script)

2009-11-13

Blueprint for topic names and variants
Except:
There is no value for the topic name.
There are only values for the variants.
Thus:
Abandon default values for topic names!


2009-11-13

How to fix (the TMDM)?
Well, we know:
TMDM is not going to change any time soon.
But maybe later.
3 possible solutions:
Making the topic name's value property optional.
Removing the topic name's value property.
Removing the topic name.


2009-11-13

Making the topic name item's value property
optional
Plain implementation of the requirement.
Softly requires apps to employ value selection
algorithms.
Allows for bad Topic Maps design (e.g. choosing
default value anyway).
Perfectly compatible with existing Topic Maps.
May be to weak to actually drive change.


2009-11-13

Removing the topic name item's value
property
TopicName:
type: Topic
value: String
scope: Set<Topic>
Variant:
value: String
datatype: IRI
scope: Set<Topic>

2009-11-13

Removing the topic name item's value
property
For each old topic name, create an additional new
variant.
Need to remove scope-restriction on variants as
well.
Now apps are forced to employ value selection
algorithms.


2009-11-13

Removing the topic name item
What?!?


2009-11-13

Removing the topic name item
TopicName:
type: Topic
value: String
scope: Set<Topic>
Variant:
value: String
datatype: IRI
scope: Set<Topic>

2009-11-13

Replacing the topic name item
TopicName: NameRendering:
type: Topic type: Topic
value: String
scope: Set<Topic>
Variant:
value: String value: String
datatype: IRI datatype: IRI
scope: Set<Topic> scope: Set<Topic>

2009-11-13

Replacing the topic name item
NameRendering is binary compatible to Occurrence
Looks like Characteristic
More opportunity to simplify the TMDM
Still compatible to current TMDM
Model grouping of names using TMDM, not within
TMDM
using „name rendering group“
Disadvantage: complex query if only one rendering
per group should be retrieved.

2009-11-13

Outlook
How, actually, should a value selection algorithm
work?
User-culture-dependent, not author-culture-dependent
How to model names for analysis?
Patterns for speech recognition
What about sortnames?


2009-11-13

Finish
спасибо (Russian)
დიდი მადლობა (Georgian)
‫شكرا‬ (Arabic)
謝謝 (Mandarin)
ありがとう (Japanese)
‫רב תודות‬ (Hebrew)
ᖁᔭᓇᐃᓐᓂ (Inuktitut)
ki'esai (Lojban)

Modeling Names

Recommended

Recommended

More Related Content

More from tmra

More from tmra (20)

Recently uploaded

Recently uploaded (20)

Modeling Names