[topicmapmail] Controlled Linking and Modular Topic Maps
Murray Altheim
m.altheim@open.ac.uk
Wed, 01 Sep 2004 18:49:45 +0100
Thought I'd ask here a question that's been on my mind for awhile.
This is in essence a proposal for a PSI set. Rather than everyone
going off and developing a proprietary solution, I'm wondering if
we couldn't somehow coordinate an approach. Perhaps someone has
already come up with similar or better ways.
## Description
This is a proposal to adopt some XLink-based PSIs to indicate
link traversal behaviour, especially since we already have
XLink-based semantics on XTM links.
When building either a Topic Map or a Topic Map-based ontology,
there are times when one doesn't want to actually merge in an
entire external Topic Map at graph creation time, but rather
leave some sort of link to be later expanded, either by some
kind of application heuristic, or manually by a user.
In XTM 1.0 we have <mergeMap>, but this can't be used for this
because we designed this to auto-merge all such directives at
graph creation time (see [1]).
This leaves few options in XTM other than to create some kind
of PSI meaning "deferred link" and implementing support for it
in an application. Unfortunately, this would not be interoperable
amongst XTM applications, except for those applications that are
aware of the PSI's processing semantics/requirements. So it's
important to (a) maintain compatibility with XTM syntax, and
(b) not create any problems for applications that don't support
the particular solution, other than falling back on normal,
default link behaviour.
## MergeMap non-proposal
If we were working on an XTM 1.1 syntax (which I hope we're not),
I'd simply recommend adding XLink's 'actuate' attribute to the
<mergeMap> element and altering the definition to account for
'actuate' values, e.g.,
<!-- mergeMap: Merge with another Topic Map ...................... -->
<!ELEMENT mergeMap ( topicRef | resourceRef | subjectIndicatorRef )* >
<!ATTLIST mergeMap
id ID #IMPLIED
xlink:type NMTOKEN #FIXED 'simple'
xlink:href CDATA #REQUIRED
xlink:actuate ( onLoad
| onRequest
| other
| none ) #IMPLIED
>
It's kinda a shame we didn't think of this one back in 2000. In lieu
of this, there's always: PSIs!
## XLink's 'actuate' Attribute (see [XLink, section 5.6.2])
I'm suggesting a set of "actuate" PSIs whose subject identifier URI
(for the attribute/type) is:
http://www.w3.org/TR/xlink/#actuate-att
and whose acceptable values are the 'actuate' values: "onLoad",
"onRequest", "other", or "none", with the same implied link
traversal/actuation semantics:
The actuate attribute is used to communicate the desired
timing of traversal from the starting resource to the ending
resource. Unfortunately, the XLink Recommendation does not
provide link targets for these attributes per se, so I'm
suggesting using only the section 5.6.2 URI as a typing URI,
with values matching the 'actuate' attribute values appended
to the base URI, i.e.:
"onLoad"
An application should traverse to the ending resource immediately
on loading the starting resource. [This would be the default
behaviour for e.g., <mergeMap> an all other XLink-based links
in XTM 1.0.]
PSI: http://www.w3.org/TR/xlink/#actuate-att-onLoad
"onRequest"
An application should traverse from the starting resource to
the ending resource only on a post-loading event triggered for
the purpose of traversal. An example of such an event might be
when a user clicks on the presentation of the starting resource,
or a software module finishes a countdown that precedes a redirect.
PSI: http://www.w3.org/TR/xlink/#actuate-att-onRequest
"other"
The behavior of an application traversing to the ending resource is
unconstrained by this specification. The application should look for
other markup present in the link to determine the appropriate behavior.
[Since "other markup" is not possible in XTM, this would indicate that
other XTM-based content is being used to indicate the link actuation
behaviour.]
PSI: http://www.w3.org/TR/xlink/#actuate-att-other
"none"
The behavior of an application traversing to the ending resource is
unconstrained by this specification. No other markup is present to
help the application determine the appropriate behavior.
[Again, "other markup" does not apply, but this would mean that an
application should not expect to find any further clues as to traversal
behaviour. This is still good information.]
PSI: http://www.w3.org/TR/xlink/#actuate-att-none
## Implementation in XTM 1.0 syntax
Normally, a mergemap directive is fairly simple in XTM or LTM syntax:
<mergeMap xlink:href="http://www.shakespeare.org/plays.xtm"/>
or
#mergeMap "http://www.shakespeare.org/plays.xtm" "xtm"
Such directives are automatic, and while what we're trying to
do is add an attribute to the <mergeMap>, we can't use <mergeMap>.
If we were to simply add a PSI link as a child element of a
<mergeMap> element, this would (according to current design)
merely add the topic to the scope of all characteristics in
the incoming Topic Map. This isn't a bad approach, but considering
that applications that weren't aware of the 'actuate' PSI would
load the map immediately (current behaviour) but would add the
PSI to all incoming Topic Map characteristics (bad, as that
alters the resulting Topic Map, an unintended side effect).
Alternately, to avoid such side effects, we have to use a normal
XTM link to a topic/topic map, and characterize the link with
our PSI. Applications that weren't aware of the 'actuate' PSI
would still traverse the link as normal.
At first I thought my proposal would be only for <resourceRef>
elements to be so recognized, since this is essentially a
reference to a resource, not a Topic (semantics-wise). But when
I thought about actual usage, I want to be able to reference
either an entire external Topic Map document, or one or more
Topics within it. And I want to do it as a conditional
*association*. So really, this is an "attribute" on an association.
There are two ways to express associations in XTM, either
1. using explicit <association> elements. Since the 'actuate'
behaviour is meant to apply to the entire link/association,
the presence of one of the four actuate PSIs in the <scope>
of an <association> element is meant to indicate linking
behaviour. E.g.:
<association>
<scope>
<subjectIndicatorRef
xlink:href="http://www.w3.org/TR/xlink/#actuate-att-onRequest"/>
<topicRef xlink:href="languages.xtm#en"/>
</scope>
<member> ... </member>
<member> ... </member>
</association>
This would indicate that the link to "languages.xtm#en"
should only be traversed "on a post-loading event triggered
for the purpose of traversal", i.e., when the application
warrants it, either with or without direct user intervention.
or
2. using <instanceOf> as the shorthand for a class-instance
association. Since multiple references within <instanceOf>
are not allowed, and we'd not want to indicate that a given
object is an instance of one of these actuate PSIs, any
class-instance associations that are to indicate the actuate
semantics would need to be written using an explicit class-
instance <association>.
## Conclusion
Like I said, I kinda kick myself for not having thought of this back
in 1999/2000. I think it'd be chaos to allow this for all XTM links,
but for associations it makes pretty good sense. I'm not suggesting
we alter XTM syntax for <mergeMap>, except to keep this proposal in
mind should that ever happen.
This actuate PSI set would suffice so long as applications are aware
of it, which means buy-in from those building XML Topic Map software,
which is why I'm sending this message, as I'm curious as to others'
ideas on the subject. If there's any interest, I'm happy to formalize
this document into a web page-type proposal.
Comments, suggestions, criticisms, etc. welcome...
Murray
[1] http://www.topicmaps.org/xtm/1.0/#elt-mergeMap
[2] XLink 1.0, http://www.w3.org/TR/xlink/
......................................................................
Murray Altheim http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK .
In 1998, U.S. industries reported manufacturing 6.5 trillion pounds
of 9,000 different chemicals, and in 2000, major American companies
-- not even counting the smaller ones -- dumped 7.1 billion pounds
of 650 different industrial chemicals into our air and water.
"Toxic America: Tracking the hazardous chemicals that seep stealthily
into our bodies" -- Alexandra Rome, San Francisco Chronicle
http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2004/03/28/ING2J5QG7R1.DTL
http://www.ewg.org/reports/bodyburden/