[topicmapmail] Controlled Linking and Modular Topic Maps
Jan Algermissen
algermissen@acm.org
Wed, 01 Sep 2004 20:59:51 +0200
Hi Kal,
seems you 'discovered' that 'hypermedia is the engine of application
state'[1] :o)
I am very glad to see this, as I was wrestling with the same issue a
while ago[2] (please excuse the horrible layout there, I am reworking the
thing but got carried away :o)
The general issue is, how some piece of hypermedia can communicate to
a user agent (or intermediary for that matter) what options there are
to advance its application state and what parameters maybe apply[3].
Incidently, not even an association type exists that represents the
semantics of the good ol' HTML link. I think it would be very fruitfull
to define a bunch of PSIs that allow us to express these things, especially
the stuff in [3], but also what you propose.
I have a question (or I maybe missed in when I looked through your proposal):
What <xxxRef xlink:href="theReferencedResource"/> do you suggest to use?
Good stuff, thanks for bringing this up.
Jan
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_5
[2] http://www.topicmapping.com/blog/more_on_xtm_as_engine_of_application_state.html
[3] http://www.markbaker.ca/2003/05/RDF-Forms/
Murray Altheim wrote:
>
> 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/
>
> _______________________________________________
> topicmapmail mailing list
> topicmapmail@infoloom.com
> http://www.infoloom.com/mailman/listinfo/topicmapmail
--
Jan Algermissen http://www.topicmapping.com
Consultant & Programmer http://www.gooseworks.org