[topicmapmail] occurrence abuse ? Was: [geolang-comment] Firstproposals for ISO 639 and 3166 available

Kal Ahmed kal@techquila.com
Thu, 22 Aug 2002 17:55:08 +0000


On Thursday 22 August 2002 16:09, Anthony B. Coates wrote:
> ** Reply to message from Kal Ahmed <kal@techquila.com> on Thu, 22 Aug 2=
002
> 14:42:01 +0000
>
> > Adopting all of it and nesting it *inside* XTM structures makes a cle=
an
> > division between "knowledge" representation (in XTM) and "information=
"
> > representation (in strings/XML). The model you propose puts some
> > information representation into XTM, and then doesn't even go the who=
le
> > way but stops when something complex (like structured records) comes
> > up...this seems perverse to me.
>
> However perverse it seems, do remember that there are only so many new
> concepts that you can get people to accept in one leap.  Getting
> information people (most of whom probably to have relational database
> backgrounds) to accept the topic map paradigm is one hurdle, and a big
> enough one at that.  Getting them to accept that the data in a topic ma=
p is
> stored as untyped strings is another hurdle, and two hurdles may be at
> least one too many.
>

I accept that this is true. However, I am not suggesting that people shou=
ld be=20
prevented from inserting typed data into topic occurrences. I am merely=20
suggesting that the expression of data-types should be in XML Schema, not=
 in=20
some "XTM DataTyping Schema". Why should application developers be forced=
 to=20
learn Yet Another Set Of Data Types and how YASODT maps to XML Schema/the=
ir=20
flavour of SQL/whatever other system is using/providing typed data struct=
ures=20
?

> Typed data might make creation of
> simple topic map engines more difficult, but untyped data will make
> corporate acceptance of topic map engines more difficult,

I can see how that could be the case. Separating the representation of ty=
ped=20
data from the essential topic map paradigm would allow:

a) Database-oriented applications to use existing XML markup for expressi=
ng=20
their datatypes

b) All other applications to ignore datatyping and carry on treating=20
occurrence data as untyped strings.

I have yet to see a single convincing argument *against* layering the=20
datatyping. The argument that those wanting datatyping would be upset by=20
having to add an extra element into their XTM interchange document just=20
doesn't cut it because XTM is already verbose and because they would have=
 to=20
do it to represent structured data anyway. So, can you explain to me why =
a=20
layered approach is bad ?

Cheers,

Kal
--=20
Kal Ahmed, techquila.com
XML and Topic Map Consultancy

e: kal@techquila.com
p: +44 7968 529531
w: www.techquila.com