[topicmapmail] Inheriting Scope

[Murray Altheim]

Steven Hammond wrote:
> Murray,
> 
>     Thanks for that answer, I was worried I wouldn't get enough of an 
> answer...  I think I followed most of what you said, but I'm still 
> thinking about "generalizes" vs. "is a" relationships.

If this is any help, you can check out the Cyc documentation on these
two relation types, plus there's a number of Cyc tutorial documents,
respectively:

   http://www.cyc.com/cycdoc/vocab/fundamental-vocab.html#genls
   http://www.cyc.com/cycdoc/vocab/fundamental-vocab.html#isa

   http://www.opencyc.org/doc/tut/

In short, the Cyc's "generalizes" (#$genls) relation type and XTM 1.0's
superclass-subclass PSI both in usage form what in the colloquial might
be called a taxonomy, in that there's the sense of having defined classes
or collections, and then by adding further constraints one comes up with
subclasses or subcollections, creating a tree structure. In this case,
"specializes" is the opposite of "generalizes" -- it's just a question
of which way up or down the tree one is traversing.

For example, in the zoological taxonomic systems, a species is a
"subclass" of genus. I quoted that because the precise definition
of both species and genus are in reality rather fuzzy, especially
with how DNA evidence has completely altered biologists' conceptions
of the taxonomic record. This is a somewhat typical example of how
real-world systems turn out to not really work so well as their
abstractions in mathematics and graph theory. There's almost always
borderline cases that point out the flaws in the stated structures.
Library science has its own, such as the problems using Dewey
Decimal Classification to classify the unclassifiable, such as
Bateson's "Steps to an Ecology of Mind." But we do what we can, eh?

The essential difference between "generalizes" and "is a" (class-
instance) is that the former creates a taxonomy, whereas the latter
forms the relationship between the classes within the taxonomy and
real-life instances of those classes, e.g., I am a member of the
zoological classification "Homo sapiens" (well, at least after 11am).

Now, not to complicate matters too much, within the zoological taxonomic
structure, when zoologists talk about a species, they actually use a
combination of two of its taxons, genus and species -- it's just a
convention within zoology to combine the two when discussing a species
-- zoologists would never say I am a "sapiens" without also including
the "Homo" (which can get you a punch in the face in Texas), whereas
in other systems it's seemingly more common to simply include just an
instance's class name when describing it). Again, social conventions.

>>And just to clarify, when you state that one Association is an
>>instance of another, do you mean to say:
>>
>>  * the typing Topic used to type Association B is either a
>>    subclass of the typing Topic of Association A
>>
>>or
>>
>>  * the typing Topic of association A is being used as the
>>    typing topic of association B.
>>
>>I ask because Associations themselves don't have instances. An
>>Association type (i.e., a Topic used as a type for an Association)
>>can be an instance of a given class, but the Association itself
>>can't be considered a class (which would be required in order to
>>have instances in the traditional concept of a class-instance
>>relation).
> 
> In response to your question, let me be more specific about what I'm 
> trying to do. The application is a tool for mapping characters, 
> locations and events in a novel or series of novels. 

How curious. That's also in large part what my own research is about,
and I've developed what looks a bit like a "common sense ontology"
(like a very small subset of Cyc) to do this, all in Topic Maps.
Perhaps we should chat offline about this. For more info, see:

   http://purl.org/ceryle/

> At the moment there 
> are two broad categories of associations, social and geographic and 
> there are a number of specific types of associations such as "lives-in", 
> "is-in", and "is-friend-of". I want to scope those broad categories to 
> define different perspectives on the map. Here is the XTM for the two 
> associations.
> 
>         <association id="#lives-in">
>             <scope>
>                 <topicRef xlink:href="#geographic-association"/>
>             </scope>
>             <member>
>                 <roleSpec><topicRef xlink:href="#character"/></roleSpec>
>                 <topicRef xlink:href="#character"/>
>             </member>
>             <member>
>                 <roleSpec><topicRef xlink:href="#location"/></roleSpec>
>                 <topicRef xlink:href="#location"/>               
>             </member>           
>         </association>
> 
>         <association>
>             <instanceOf><topicRef xlink:href="#lives-in"/></instanceOf>
>             <member>
>                 <roleSpec><topicRef xlink:href="#character"/></roleSpec>
>                 <topicRef xlink:href="#andrea_mellea"/>
>             </member> 
>             <member>
>                 <roleSpec><topicRef xlink:href="#location"/></roleSpec>
>                 <topicRef xlink:href="#boston"/>
>             </member>
>         </association>
> 
> This seems to validate with the xtm1.dtd, but your question leads me to 
> believe that it is incorrect. Why?

As I think Lars Marius Garschol pointed out recently, there's a number
of kinds of validation. XML validation of XTM content merely makes sure
that the XML markup conforms to the XTM 1.0 DTD. That level of markup
structure validation only tells us that the document is actually XTM
and can be processed by XTM tools. It says nothing about whether the
content makes sense.

At a level above that, what we might call the schema level, one would
create conceptual structures such as "is friend of" etc. such that
validation of an XTM document using to that schema would reveal errors
as according to the constraints of the schema, e.g., the schema might
state that a human couldn't be a friend of a rock, but could be of any
living being.

What you're probably running into is that in order to be able to validate
XTM "ontologies" expressing the kinds of content one finds in novels,
the requisite schema must state the concepts and relations (Topics and
Associations) for the gamut of things one finds in novels. This could
conceivably include the entirety of the Cyc ontology (if one wanted the
system to understand basic concepts of what we call common sense), or
in more restricted form, be able to constrain/validate that say, a
character must be a living being, not a rock. So in defining a character,
one would create an instance of the Topic "character", which might also
be an instance of the Topic "person" (or perhaps "dog"). Some kind of
constraint checker would flag an error if someone tried to create a
character that was a rock or a paperclip (one of the more heinous ideas
of late).

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.

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

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

> while the dtd at http://www.topicmaps.org/xtm/1.0/xtm1.dtd defines 
> member as
> 
> <!ELEMENT member
>    ( roleSpec?, ( topicRef | resourceRef | subjectIndicatorRef )* )
> 

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

> Which is correct? If the second is correct, then I can define the 
> general association without the topicRef's, which seems cleaner (i.e. 
> more like a type definition).

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

>         <association id="#lives-in">
>             <scope>
>                 <topicRef xlink:href="#geographic-association"/>
>             </scope>
>             <member>
>                 <roleSpec><topicRef xlink:href="#character"/></roleSpec>
>             </member>
>             <member>
>                 <roleSpec><topicRef 
> xlink:href="#location"/></roleSpec>       
>             </member>           
>         </association>
> 
> 
> Hopefully this make some sense.

Yes, I think you're making sense, I'm just not sure if I am anymore.
Perhaps it's time for me to go bungee-jumping off a low bridge, or
just have another cup of coffee.

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