[topicmapmail] Inheriting Scope

[Steven Hammond]

Let me know if I'm pestering too much. I don't have a knowledge 
representation background, but I've been reading everything I can find 
on topic maps and XTM for a few weeks now and I'm just getting to the 
point where I can start asking questions and putting the pieces 
together. This discussion is really pulling a lot of pieces together for me.

Murray Altheim wrote:

>
> 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."
>
Ok, I've been using template because the theoretical users of my 
application understand document templates, like for Word or OpenOffice 
and schema might get confused with XML schema. But it is a schema. It 
seemed natural to me to separate the schema from the specific instances. 
I do see that it is one context in the complete map.

> 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'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."
>
This is where I'm a little confused. I'm also using scope as a synonym 
for context. I'm envisioning an application where I can select a topic 
and study its relationship in a variety of contexts: social or 
geographic or other to be defined. The "lives-in" shares a context with 
all  other geographical associations. I guess the OO programmer in me 
just doesn't want to make it explicit everytime a "lives-in" association 
is specified; so my thought was to make a supertype that carried the 
scope (contextual) information.  But your saying that associations are 
always explicit, topics can be more or less explicit.

>
> 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
>
I've read it, but I'm still making sense of it. PSI's weren't referenced 
in any of the examples I've seen and I didn't really get them until just 
now. Seems as we both have applications that relating writing we could 
define a set of PSI's for writing concepts. This would  make our maps 
more interchangeable because we agree on vocabulary. Is there a resource 
that collects the PSI's that have been defined?

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

> 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.
>
Can you explain this a little deeper for me? I now understand
why its not an instance and now that I understand PSI, I can
see how the relationships are defined. I don't understand the
distinction between classes and types and what you mean
by the base structure is a collection not a class. Can you
elaborate or point me to some additional information?

> 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.
>
Agreed. I'm looking to use a property (namely scope) of a
subsumption relationship for filtering..

> 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.

I'm thinking  you're right, but now I'm wondering how to use
scope? Can you give me some examples of scope in the context
of your application?

Thanks,
Steve