[xtm-wg] XTM-ISS Re: Important XLink difference in DTDs

[Philip Rutherford <philipr@weborganic.com>]

-------------------------- eGroups Sponsor -------------------------~-~>
No blistered feet. No crowd. No travel. Intraware invites you to attend
a virtual tradeshow: Ensuring Scalable and Secure E-Business Systems.
http://click.egroups.com/1/9219/4/_/337252/_/969195281/
---------------------------------------------------------------------_->

Kal,
Thanks for the feedback. You make some good points.

> But there are facets to do the same job - in fact the facet can be used to
> associate any arbitary meta-data with each resource.

Facets seem to be designed to associate predefined values to information
resources independent of the topic. In my example I am defining meta data for a
resource in relation to a particular topic (i.e. the description could change
for different topics). Also in my example the meta data is free-form text
rather than a predefined value, so I'm not sure how facets would cope with
this. To use facets to capture the same information I think I'd have to do
something like the following:

<facet xlink:type="extended">
   <fvalue xlink:type="locator" facetval="description"
               xlink:href="http://mycompany.com/welcome.html />
   <my:locator xlink:type="locator" xlink:role="topic"
               xlink:href="http://mycompany.com />
   <my:resouce xlink:type="resource" xlink:role="description">
           This is a welcome message from the director.
   </my:resource>
</facet>

I'd need to specify a link to the document in the topic as well and this seems
to create a lot of extra complexity. Also when you take out the XLink specific
information as might happen in an interchange situation this facet becomes
completely redundant to the topic map. Is there an easier way to use facets to
do this?

> My only problem with this approach is that the topic is demoted from its
> status as being a link element. The reason that I find this a problem is
> that if I were to process an instance of tm.dtd with an XLink processor, it
> would equate each topic to an extended link and would group the occurrences
> as locators of the link. In other words, the XLink processor - without any
> knowledge of topic maps - correctly interprets the <topic> element as some
> sort of aggregate link. If the XLink processor were to process an instance
> of mb.dtd, it is only the containement provided by the <topic> element that
> gives any hint as to the relationship between the individual extended links
> (<occurs>). I like the idea that a less well-informed processor could still
> look at an XTM instance and make some 'true' statements about it.
>
> Of course, it could be argued that by forcing you to use facets to specify
> meta-data about the resource, the tm.dtd has 'hidden' some information from
> a standard XLink processor. But my feeling is that keeping the structural
> nature of the topic link is of a higher priority. Of course, if there is
> some way to do both that would be really cool... ;-)

I agree with your point that an XLink processor should be able to make sense of
the topic map - this is very important. I'd also like an XLink processor to be
able to see the meta-data as part of the topic. If you use XLink's
bidirectional linking in the occurs element and have a locator pointing back to
the topic itself (as shown below) this will allow an XLink processor to make
sense of the occurs element as part of the topic. This allows you to both add
the meta-data and link to the topic in the one occurs element.

<occurs xlink:type="extended">
   <locator xlink:type="locator" xlink:role="topic"
                 xlink:href="http://mycompany.com />
   <locator xlink:type="locator"
            xlink:href="http://mycompany.com/welcome.html />
   <my:resouce xlink:type="resource"
                       xlink:role="description">
           This is a welcome message from the director.
   </my:resource>
</occurs>

Also, in terms of implementation it allows the same linking mechanism to be
used for occurrences and associations. Below is an example of an association,
which as you can see has the same XLink format as the occurs element.

<assoc xlink:type="extended">
    <assocrl xlink:type="locator" xlink:role="topic"
                  xlink:href="http://mycompany.com" />
    <assocrl xlink:type="locator" xlink:role="topic"
                  xlink:href="http://mycompany.com/products" />
    <my:resouce xlink:type="resource"
                  xlink:role="description">
           A full list of company products.
    </my:resource>
</assoc>

cheers
--Philip

--------------------------------------------------------------
Philip Rutherford               E-mail: philipr@weborganic.com
Weborganic Systems Pty. Ltd.         http://www.weborganic.com
"working together on the web"
Level 10, 91 York St, Sydney 2000, Australia.
Tel: +61 2 9262 4777
Fax: +61 2 9262 4774



To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com