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

[Kal Ahmed]

On Friday 23 August 2002 09:36, Lars Marius Garshol wrote:
> * Lars Marius Garshol
>
> | This can be solved by only adopting a subset of the XML Schema
> | datatypes, however.
>
> * Kal Ahmed
>
> | Which will make all those people who *do* use the other XML Schema
> | datatypes complain!
>
> Possibly. It's a choice between two evils, I would say, and the
> question is which is the lesser evil.
>

That is usually the case ;-)

> | Why is there a need to reinvent all this stuff - I would have
> | thought that it would make much more sense for TMQL to restrict
> | itself to string pattern matching, and then provide a hook for
> | extending with other query syntaxes.
>
> I think Tony Coates put it pretty well. A query language that can't
> work with numbers and dates is a pretty limited query language. These
> features are needed, and escaping into an XML query language for
> simple features like this is just too ugly for words.
>

TMQL should be a "limited" query language. It should be limited to queryi=
ng=20
topic map structures, with a suitable hook for querying the occurrence=20
information using a query language native to the occurrence information t=
ype.

> | Adopting all of it and nesting it *inside* XTM structures makes a
> | clean division between "knowledge" representation (in XTM) and
> | "information" representation (in strings/XML).
>
> Huh? How does something become more "knowledge" by ignoring the fact
> that "1234" is a number?
>

I deliberately used quotes around "knowledge" and "information". I should=
=20
probably have said "topic map information" and "non-topic map information=
". I=20
consider data-typing to be non-topic map information - it is a facet of a=
n=20
information item, nothing to do with the topic map itself.

> | The model you propose puts some information representation into XTM,
> | and then doesn't even go the whole way but stops when something
> | complex (like structured records) comes up...this seems perverse to
> | me.
>
> Well, you always knew I was perverse, so this shouldn't surprise
> you. :)
>

Sometimes I think I ought to expect it of you! ;-)

> What I am proposing is to have several different data types, some of
> which are primitive (strings, numbers, dates, ...) and at least one of
> which is not (XML). I don't see what is so peculiar about that. I find
> your suggestion that we only have one data type (XML) much stranger.
>

I would not want to characterise my position as being that anything non-X=
ML=20
cannot be an occurrence in a topic map. However, my position is that ther=
e is=20
a data-model for primitive and complex datatypes with its own query langu=
age=20
and that TMQL/TMCL should use that rather than create yet another "standa=
rd".

> Anyway, this is not an issue we need to settle just yet. What we
> should do is make sure the SAM does not commit us to anything we don't
> want to be committed to, then revisit the TMQL requirements, and
> finally look at this when we get to TMCL/TMQL.

Agreed. Though I am intrigued to know how you propose that the SAM avoids=
=20
making such a commitment if primitive data-types are to be added to the t=
opic=20
map model.

Cheers,

Kal

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

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