[topicmapmail] Inheriting Scope

[Steven Hammond]

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

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

>> Also, in reading the dtd's the XTM spec at 
>> http://www.topicmaps.org/xtm/index.html#elt-member it defines member as
>>
>>   <!*ELEMENT* member
>>      ( roleSpec 
>> <http://www.topicmaps.org/xtm/index.html#elt-roleSpec>?, ( topicRef 
>> <http://www.topicmaps.org/xtm/index.html#elt-topicRef> | resourceRef 
>> <http://www.topicmaps.org/xtm/index.html#elt-resourceRef> | 
>> subjectIndicatorRef 
>> <http://www.topicmaps.org/xtm/index.html#elt-subjectIndicatorRef> )+ )
>>   >
>
>
>
> Well, your cut and paste has kinda messed up the original, which is
>
>   <!ELEMENT member
>      ( roleSpec?, ( topicRef | resourceRef | subjectIndicatorRef )+ )
>   >
>
> so the only difference between that and:


> is whether or not an association can have zero or more ("*"), or one
> or more ("+") members.
>

Yes, that the only difference.

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

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?

Thanks,
Steve