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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj-comment message

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


Subject: [tm-pubsubj-comment] TM Fragments (was: tuesday conference)


Title: [tm-pubsubj-comment] TM Fragments (was: tuesday conference)

> * Lars Marius Garshol
> |
> | ... I don't this is a very good idea, actually. Extracting topic map
> | fragments is not easy,

> * Thomas Bandholtz
> |
> | Why?
>
> OK. Let's say that you want the topic "Puccini" from the Italian Opera
> topic map. What should we send you? "Puccini" is an instance of
> "composer", it has names in the scopes "normal form" and "short name";
> which of those topics should we send you, and how much of them? And
> how many of the topics needed to understand *their* characteristics
> should we send you?

What would the user want to learn about "Puccini" first (semantically)?

I think something like: Puccini (birth & death dates, a picture of his face) was a composer of the Italian Opera. May be a list of his most important works, may be some links to sound files.

In this moment I would not be interested to learn how "composer" is defined (This might be a link, though). Also links should be: "Puccini" (to learn more about him), and "Italian Opera".

> The same of course applies to occurrence types, occurrence scopes,
> association types, association role types, and association scopes, but
> without complicating this picture to any great extent.

This is one aspect I do not like about XTM. Types are Topics. Scopes are Topics .... Everything is a Topic. I see some trends even to make associations a Topic. This is an intersting philosophical discussion, but not a working formal syntax.

Something like this has never been defined in the ISO standard itself - only in XTM, an interchange format. But this is another story. See my thread about "formal syntax".

> Associations, however, are a different story. Do we send you the
> topics playing the other roles in the association? If so, how much of
> them?

Think about what a user might want to learn first. The user I have in mind is not interested about the topic map's typology, but in Puccini, and may be in the Italian Opera.

More about this below.

> Reification also enters the picture, but I think you see where I am
> going.
>
> Of course, it is fully possible to define lots of policies for what
> information to include and what to leave out, but I am not at all
> certain that it is possible to come up with a single policy that will
> work in *all* situations.
>
> And, most of all, I am not at all sure that this is in any way
> relevant to published subjects.

I think this is the most relevant aspect. If we are publishing information that not really has been requested by the user, he will not consult us the next time.


> | Associations are part of "topic charasteristics". (Now and then all
> | of us should re-read good old ISO13250). If I include associations,
> | I need to include the associated topics as well. No need to include
> | the whole TM.
>
> If you apply that algorithm recursively most likely you *will* end up
> with the whole topic map, or at least 90% or more of it.

If you use XTM you may have this problem, as anything is a topic.

I recommend only to include topics that are associated directly (ISO-"distance" = one association) to the identified topic.

Distance? Look at ISO 13250:
"A topic map defines a multidimensional topic space - a space in which the locations are topics, and in which the distances between topics are measurable in terms of the number of intervening topics which must be visited in order to get from one topic to another, and the kinds of relationships that define the path from one topic to another, if any, through the intervening topics, if any."

If the user wants to know more, he can access any of the associated topics themselves.

Thomas Bandholtz
CM / KM Division Manager; XML Network Moderator
Competence Center Content Management
SchlumbergerSema
http://www.schlumbergersema.com

Kaltenbornweg 3
D50679 Köln / Cologne
Germany
+49 221 8299 264



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


Powered by eList eXpress LLC