[sc34wg3] Subjects, role players, and user-defined association types

[Martin Bryan]

Lars Marius

You seem to have misunderstood my:

| 1) Words are not bounded by languages: languages share words and
| therefore the mechanism that maps topics to languages must not be
| identified using scoping unless it is agreed that scope is "any"
| rather than "all".

>If I understand you correctly this is actually a different issue than
the "any"/"all". I assume what you mean is that if we say

  [fish = "Fish" / en
        = "Fisk" / no]

that implies (under the "all" interpretation) that the term for fish
in Swedish is neither "Fish" nor "Fisk". That's actually an
unwarranted inference. The standard does not say anything about how to
interpret the omission of information, so unless the application
explicitly makes the assumption that the topic maps is complete (a
closed world) it can't be inferred that just because there is no
death-of-character association for character X in opera Y that
character did not die in the opera.

>So if I understood you correctly this is not an issue. If I
misunderstood, please try again.

The problem I was addressing is that because I say that Fisk has the scope
of "no se dk" then I should be able to apply Fisk if I say that the scope I
want is "no" and not have to specify that the scope I want is "no se dk" or
whatever other set of scopes has been used to identify shared names. It is
unreasonable to expect users to know the identifiers of all scopes in which
a particular name is relevant to be able to select a particular name. They
should only need to state which scope is relevant to them. The same goes
with merging. If I have a topic Fisk with scopes "no se" and you have one
whose scopes are "se dk" then it should be possible to merge the two based
on a single agreed scope, even if the the full set are not exact matches.

| 2) In most topic maps I've thought through there is a need to make
| some distinguishing feature that is less important than a topic, but
| which allows subsetting or ordering of relevant values. This applies
| to continuous quanta (such as date of publication of an occurrence)
| and discrete quanta (such as security levels of occurrences or
| associations).

>So far I agree completely. Topic maps do need to support such things,
and it is clear that these "things" have lower prominence than typical
topics like "Norway", "weißbier", and "Paris (Greek hero)".

| Forcing these things to be presentable scoping topics, as is the
| current policy of XTM users, is bad practice for the long-term
| management and integration of topic maps. It may provide a
| "short-term solution" to the problem, but in 5 years time it will
| haunt us.

>This is where I don't follow you. Why do you think this is so bad? By
now Ontopia and others have made real solutions using topic maps that
contain lots of non-prominent topics (like those for "sort name",
"display name", and many others) without anyone flagging this as a
problem.

>It would be good if you could say *why* you think this is a problem,
because I can't say I see any difficulties with it at all.

You have only added a few topics that have been understood by your
community, who to date have been topic map experts. When you start using
things such as dates or secuity levels as topics you end up with displayable
topics whose meaning is not clear. What does a topic of 8th March 1948 or
Normal mean to you? To me it is my birth date and a statement of how easy my
birth was! In both cases the name of the topic only has meaning when you
know the role in which the date or term was being applied. Things like date
of publication of an occurrence and the meaning of security levels (is it a
black, yellow or orange security day in the US today?) are very much context
dependent and should not be treated as topics/concepts.

| 3) We should not force people to break rules in other standards. XML
| has a very clearly defined and widely accepted generalized mechanism
| for language identification which many applications handle using
| standardized modules.  These modules will work just as well if the
| xml:lang attribute is considered a facet of a topic map component.

>Now you've really baffled me. This is about how you map from arbitrary
XML to a topic map, at which point the information is no longer XML.
How is to break the rules of XML to create a topic for the subject
"Norwegian"? I already have that topic in the i18n.ltm topic map:

  [norwegian : language = "Norwegian"]
  spoken-in(norway, norwegian)
  written-in(norwegian, latin-s : script)

>Isn't this straightforward usage of topic map constructs? Do you think
I should use facets for this? If so, how?

>I can't see any problem with this, nor do I see that it breaks
anything with regard to XML. XML has no notion of topics; topic maps
have no notion of attribute values. Where is the issue?

The XML language you have chose as a base for XTM has a clearly defined
mechanism for identifying the language of text, the xml:lang attribute.
Trying to force languages into being topics when the underlying language
already has a mechanism for expressing language is totally unnecessary.

>In my opinion, this is an issue that has to be addressed as part of
creating the HyTM deserialization specification. There we have to make
it clear what to do with this situation and how the result is to be
interpreted. The question is whether anyone is going to do that.

>Who thinks keeping HyTM around is important?

Its important to those of us who believe in the whole of 13250 until such
time as SAM recognizes the relevance of facets. At present it is the only
mechanism that can do everything that 13250 permits you to do, including
simplified structures with role names as GIs.

| Facets provide a generalized mechanism for associating a specific
| name/value pair with a set of information resource components that
| has much wider applicability than just topic maps, which is why it
| is perfectly permissible in ISO 13250 to have a topic map that only
| contains facet definitions. You can think of facets as the RDF of
| topic maps, with the facet value type being the predicate.

>I guess that's true, in that you could you the mnemonics (linktype and
facetval) rather than the topic references (type and type) and so
avoid using any topic map constructs at all. I'm not sure that's
relevant to the SAM, however.

Why not?

>There are two situations:

  a) user is using facets together with topic maps, and

  b) user is not using facets together with topic maps.

>In the first case requiring topics to be created for the facet type
and value may be a problem if we accept your issue 2) above, but it
can hardly be said to be problematic because the user is being forced
to use topic maps; we've already assumed they want to use them.

But not that the user wants to see them! There is a world of difference
between what a topic map manager needs to see and what he wants users of his
topic map to see. Facets are a way of hiding things from users but still
allowing programs to use the information to select relevant material for
presentation to specific user communities.

>In the second case we don't require topics to be created because the
user is not using topic maps, and so they are not using the SAM
either, nor the deserialization specification to the SAM. It may be
that we should add some extra text to allow this usage scenario, but I
don't think it impacts the SAM in any way.

So you are saying that anyone who wanted to use facets this way would not be
allowed to interchange them with other people because they would be lost
during the deserialization process. Nice way to disenfrachise potential
users of 13250

Martin Bryan
Champion of the whole of 13250!