Re: [topicmaps-comment] Challenge Part 2 : Metadata

["Thomas B. Passin" <tpassin@home.com>]

Ah, Bernard, this is very stimulating!

[Bernard Vatant]
>
> A challenge in two parts, part 2 ...
>
> What shall we do with metadata on assertions, and singularly
> metadata indicating quality and source of information?
>
> Back to the example of Part1, the full information to be processed
> is in fact:
>
> "*According to Survey AAA*, it's *possible* that, by the end of
> 2001, France Telecom will control more than 30% of the Swedish
> phone market"
>
> The *source* (Survey AAA) and *quality* (possible) of information
> are in fact encoded as Metadata in the original document.
>

The approach is going to have to depend on what you intend to convey, so
there will not be any single "right" answer.  To start with, what is the
purpose of capturing the statement and making it available?  Going along
with this, what is the purpose of the metadata?  Indeed, if part of the
statement is actually commentary on the statement (e.g., "According to
Survey AAA"), what in fact is "the" statement?

Also, how do you think your users will try to use the information?

> How do you deal with those metadata in XTM, so that, when
> rendering the information by processing the TM, they appear to the
> end-user for what they are : metadata on an assertion, and not
> members in the association representing the assertion?
>

In this case, it seems that there is a "situation" at the core:

(1) situation: France Telecom controls more than 30% of the Swedish phone
market
(2) latestTime(situation):end of 2001
(3) authority(situation):Survey AAA
(4) likelihood(situation):possible

It is possible that we want to be able to parse the situation as well.  I'm
going to assume that this situation is to be represented by an association,
thus making it most amenable to parsing into component pieces.  However, it
could alternatively be represented as a topic, with the text of the
situation being an occurrence.  If later we want to be able to parse the
situation, we could turn it into an association and reify it.

A) If we see items (2), (3), and (4) as simple, independent comments on the
core situation (1), then we should reify (1) and make (2)-(4) occurrences of
the reified topic.

B) If we see that we will often make coordinated sets of assertions like
this about a "situation", we could broaden the definition of the "situation"
relationship so that it includes members for (2)-(4).

C) If we want to be purist and model it as would be done with Conceptual
Graphs, we would reify the situation and hang each of (2)-(4) off of it with
separate associations.  This approach is the most general, requires the most
resources, and is the hardest to pull together into a response and display
for the user.

Approach C is also what you would probably do with RDF.

If I wanted to show a summary of news reports along with whatever comments
or metadata belong to them, I'd probably choose A).

If I wanted to catalog many summaries in a uniform way, with a fixed set of
metadata, I'd probably choose B).

If I thought that I might want to enhance the "metadata" in the future and
give it some structure, I'd probably choose C).

If I wanted to comment or make assertions about the metadata items, I'd
choose B) or C).

If I wanted to display this information using a general-purpose display
program, I'd choose A), since it has the best chance of displaying the
cogent information in a compact way without special programming.

If I wanted to translate it into Prolog, I'd probably go with either A) or
C), most likely C).

As I write this, I notice what a good example it is for showing some key
differences between Topic Maps and RDF.  Starting from (1)-(4), which look a
lot like RDF, the apparently more rigid framework of Topic Maps actually
gives us the chance to have a lot of flexibiility in how we regard and
present the information, much more than RDF (at least, in the ways it is
usually used).

I haven't even touched on scopes.  Here again, it depends on what you want
to accomplish.  I look at scopes as being more or less orthogonal to the
considerations I wrote down above.  For example, suppose you want to
summarize a set of news items in a uniform way, but also to let the user
choose to see only the most likely.  Then you might want to apply a scope
"likelihood", whose values might be "possible", "probable",...  This need
not ***replace*** the expression of the metadata (be an accurrence or
whatever) - in fact, I tend to think that it ***should not***, but
convenience may prevail in a real situation

I better stop here!

Cheers,

Tom P
> Bottom line
>
> Would it make sense to put metadata on a Topic Map document,
> e.g. Dublin Core metadata?
>

Well, I could see doing it, but you could also apply such metadata using the
topic map itself (or another one), if you reify the whole topic map.

Cheers,

Tom P