[topicmapmail] Inheriting Scope

[Murray Altheim]

Steven Hammond wrote:
> Let me take a look at this first part in more detail, and take a look at 
> the sites you listed, before I can respond to it. However, looking at my 
> specific example...
> 
> Murray Altheim wrote:
> 
>>If I'm reading your example correctly, you've got one association that
>>seems to create what might be called a "template," and another that
>>is similar to that template except that it includes references to
>>actual people (or characters), and actual places. There's no inherent
>>(from the XTM perspective) relationship between these two Associations,
>>except that they both use the same typing Topic (ID = "lives_in"). What
>>you seem to be after is a way of expressing the first Association as
>>a template, with the second as an instance of that template. As I
>>mentioned in my previous message, we never got to creating the ability
>>within XTM 1.0 of expressing Association templates. It was too 
>>contentious
>>an issue, really, as it heads into the zone of constraint languages or
>>schemas, and will be expressible (or so I'm led to understand) via one
>>or more Topic Map schema languages. There are a few in existence already,
>>but none are standardized, so you'd be tying your XTM documents to what
>>was either experimental or proprietary.
>
> This is more or less what I'm trying to do. The template serves three 
> purposes.
>
>    1. I hope to be able to view the templates and associated "generic" 
> topics as a map on their own. Ths is a generic map of the possible 
> interactions between characters, locations and events in a novel. In 
> essence this is a "template map" for a specific novel. I've read Hans 
> Holger Rath's "Making Topic Maps More Colourful", but he didn't propose 
> any specifc syntax and I didn't follow all of the abstraction.

Understood. In some circles within the knowledge representation community
there are those who make a tight distinction between a "schema" and a
"knowledge base." Those people would consider what you're calling a
"generic map" as a schema, as it would have no Topics referring to specific
instances of its Topics. For example, one would define "Character" but not
contain any actual character Topics -- these would all be stored within
the "knowledge base."

I myself don't find this distinction particularly useful, as the distinction
is itself simply one form of context within a potentially recursive graph
of contexts. I don't personally use OCML, the language primarily used in
the Knowledge Media Institute, but part of what was controversial about
it (back in the late 80s and early 90s) was that it freely mixed instance
terms within the ontology. Enrico Motta told me he saw no reason to exclude
the things he was modelling from the ontology -- they were literally the
things he was modelling -- so they were simply included in the ontology.
There is apparently little or no distinction made between a schema and a
knowledge base in OCML.

I can't speak for Holger's rationale, but my guess is that he didn't
simply because there currently is no standard way, syntax or otherwise,
for creating this schema-knowledge base distinction. In effect, every
Topic Map document, like OCML, serves as both its schema and its knowledge
base. One creates a set of structures (or "imports" them from an existing
Topic Map document) and builds up a set of expressions (Topics and Associ-
ations between Topics) modelling the ideas one wants to model. This then
relies entirely on the textual definitions/descriptions of those Topics
and any hard-wired application behaviours based on the use of those Topics.

>    2. These templates can be picked up by the user interface to define 
> possible interaction between specific topics. I can make the application 
> richer by adding association templates to the topic map instead of 
> modifying the code.

Yes, certainly. What you're calling templates may be prototypes for
associations (i.e., an association type, its roles, directionality,
cardinality, etc.) as well as specific application-specific Topics.
For example, Ceryle uses a Topic that acts as a typing Topic for
occurrences expressing the colour of a visualized Topic/graph node.
In the description for that Topic this is made clear, and any other
application that has a similar feature can map their Topic to mine
to provide their Topics with the same colorization. [Ceryle actually
uses color names rather than color specifications, with the color
names specified in an XTM document whose sole purpose is to provide
a set of colours.]

>    3. The templates carry properties (like scope) that apply to all 
> instances of them. This should reduce the verbosity of the maybe 
> (maybe?) and allow change to all instances by changing the template.

I'm not suggesting you're wrong in using scope this way, but it is
a novel approach. I feel like I've implemented a template-usage
scenario that provides the basic functionality you're talking about,
and I haven't had to resort to scope to do that. I tend to think of
scope as a synonym for "context."

>>For example, in Ceryle I've created a PSI for "Template" such that
>>Associations that have that as one of their types are considered an
>>Association template, are treated differently within my application,
>>and used to provide directionality and enable automatic role assignment
>>within my editor. But nobody else is using my approach. I'm sure the
>>same can be said of any of the Topic Map commercial products, and of
>>Robert Barta's schema language (though I've not looked at their ways
>>of handling this).
>
> I'm just getting started here, what's a PSI? This aligns with the second 
> goal of my templates. Does your approach touch the other two ideas.

Ah, sorry. You might want to glance through the XTM 1.0 Specification
before we go on too much further. PSIs, or Published Subject Indicators,
are simply Topics that we have decided are to be used as stable
indicators for Topics we wish to exchange with others. For example,
Kal Ahmed has published a set of PSIs for taxonomies. If you and I
were to both use those PSIs (by referencing their URLs as subject
indicators) when building our taxonomies, we could then interchange
them. Here's a ref to the place in the XTM spec:

   http://www.topicmaps.org/xtm/1.0/#desc-psis

>>Semantically (i.e., in terms of meaning) an empty association is
>>actually incorrect. When we developed XTM 1.0, there were those
>>within the group (I was one) who felt that the DTD should enable
>>creation of partially-completed structures so that the DTD could
>>be used in editing software in full validation mode. This allowed
>>a number of optional omissions that in practice don't really make
>>any sense, as in this case. An empty Association is not really
>>a type definition, it's just an empty Association, which has no
>>real meaning. In any event, it has no defined meaning as a type
>>definition or template. The type definition is all happening
>>within the Topic used to type the Association, that is, if a
>>Topic is created whose purpose it is to type Associations, there
>>is no more and no less meaning if it is stuck into an empty
>>Association -- the definition of what an Association means happens
>>within its typing Topic, not the <association> element. This is
>>basically mixing up XML syntax with what the markup means [I'm
>>not sure if this explanation is any clearer...]
> 
> I understand this. That was an interesting design decision for the DTD.

People who've not been involved in professional SGML publishing often
don't understand that a one-size-fits-all DTD is not that common in
industrial DTDs as used in production environments. There'll be a
loose DTD for authoring, a tight DTD for editing, various changes
made for different parts of the process, etc.  For those interested
in this rather arcane art, I recommend Eve Maler's book on SGML DTDs,
which applies equally well to XML DTDs and to some degree any kind of
schema design, and describes in great detail how DTDs are designed
and used.

One could imagine several XTM DTDs, used for different purposes. We
tried to create one that would suit most people most of the time.

> I realize that I could implement this as a series of topics. A 
> "social-association" topic of which "lives-in" is an instance. From your 
> explanation this would be the correct way within the bound of intention 
> and common usage. However, scope seemed to me naturally made for this 
> sort of filtering (social associations vs. geographic association) and a 
> generic topic map tool would be able to understand the intent. If I use 
> a hierarchy of  topics then the intended meaning really becomes 
> application specific. Yes? No?

It seems that "lives-in" is really a subclass, subtype or
subcollection (depending on your modelling structure) of
"social-association," not an instance. An instance would
be an *actual* instance of an association (as in that
concept of a knowledge base I described earlier). As I
mentioned previously, I'd built up an entire upper and
middle ontology using XTM's superclass-subclass association
type, where "lives-in" would have been a subclass of
"social-association", but now I have come to realize that
the base structure is not class but collection. The
distinction to some is subtle, though is actually quite
important.

But the basic premise holds: I don't think of this as a
form of filtering, it's thought of in knowledge represen-
tation circles as a subsumption relationship, such that all
characteristics of the superclass are always true of its
subclasses -- a transitive relation.

I'm not clear on how using scope could accomplish this,
because you're no longer dealing with the inheritance of
the subsumption relation, it seems as though you're now
relying on a bit of magic, that somehow by applying a
domain based scope, as in social associations vs. geo-
graphic association, you've got a system that correctly
filters out those things that should be inherited from
the ones that shouldn't. This is simply conflating the
idea of "lives-in" in the social domain with "lives-in"
in the geographic domain, and while you may have named
them the same, they are simply different relations. In
XTM you could use a scope to keep those two different
topics from accidentally being merged (by scoping each
base name "lives in" with its respective domain), but
I *think* what you're after is a subsumption hierarchy,
not scoping.

Murray

......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

   Bob did give me the secret to world domination, which was pretty
   startling. He looked at me and he said, "Don" (he called me Don),
   "think how dumb the average guy is." And I thought about that for
   a moment, and he said, "Half of them are dumber than that."

   http://www.austinchronicle.com/issues/vol17/issue47/screens.webb.html