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

[Lars Marius Garshol]

* Martin Bryan
|=20
| The idea that facets should be discarded from the model of Topic
| Maps is wrong for three main reasons:
|=20
| 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 =3D "Fish" / en
        =3D "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.
=20
| 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).=20

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=DFbier", 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.=20

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.
=20
| 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 =3D "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?=20

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?
=20
| Lars Marius also wrote: "My understanding was that facets applied to
| resources, not to topics."
|=20
| Facets use locations that can identify to any addressable component
| of any resource, including any component of a topic map.

That's true. The question is how that reference is interpreted. If it
is not interpreted as a topic reference that's just a reference to an
information resource and not to a topic, and so you are not actually
annotating the topic in a way that a topic map processor understands.

Of course, so long as ISO 13250 doesn't actually define a data model,
what that construct actually means is anybody's guess and nobody can
really know what the spec is saying.

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?
=20
| 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. 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.

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.

--=20
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >