Re: [docbook-tc] Associations in an assembly

[Scott Hudson <scott.hudson@pelco.com>]

Hi Norm,

I didn't mean to say that we were replicating Topic Maps directly, but that
we wanted to provide similar functionality. We also wanted to provide
similar functionality to DITA reltable, but not duplicate them. We were
shooting for the best of both worlds and trying to simplify the model so
that a relationship could be easily established by an author.

I agree that the relationship type and association type should not hold
human readable content, like titles. I also think you are spot on in
suggesting that info be added to relationship to provide a title for the
relationship!

So, our example should really be something like:
    <relationship linkend="xidi.help.system" type="help_intro">
      <info>
        <title>New User Introduction<title>
        <abstract><para>This is a path through the help system.  It is not
meaningful outside of the help system.  Notice that the ids referenced by
the instances are on modules in the help system, not on the
resources.</para></abstract>
      </info>
      <association>path</association>
      <instance linkend="help.xidi.overview"/>
      <instance linkend="help.svn.overview"/>
      <instance linkend="help.ex.new.help.sys"/>
    </relationship>

Truth be told, I've had a hard time understanding the difference between
relationship@type and association. I think they serve a similar purpose, and
would lean more toward the element than the attribute...

Best regards,

--Scott


On 7/2/10 5:48 AM, "Norman Walsh" <ndw@nwalsh.com> wrote:

> Scott Hudson <scott.hudson@pelco.com> writes:
>> The original intent/design of the relationships structure was modeled after
>> Topic Maps:
> 
> But...
> 
>> A relationship was intended to be the topic, the association was (obviously)
>> the association, and instance was the occurrence. It seems that we have
>> morphed this a bit to the association being more like the baseName in the
>> following example:
>> 
>> An example from the TM realm would be:
>>   <topic id="w3c">
>>     <instanceOf>
>>       <topicRef xlink:href="#standards-body"/>
>>     </instanceOf>
>>     <baseName>
>>       <baseNameString>World Wide Web Consortium</baseNameString>
>>     </baseName>
>>     <occurrence>
>>       <instanceOf>
>>         <topicRef xlink:href="#homepage"/>
>>       </instanceOf>
>>       <resourceRef xlink:href="http://www.w3.org"/>
>>     </occurrence>
>>   </topic>
> 
> This example doesn't seem to have an association. And our markup doesn't
> seem to have baseName or occurrence. So I'm confused.
> 
>> I still think we want to describe the relationship (how the
>> instance/occurences are related) via the association and use the
>> relationship type as the base name?
> 
> But the type is an NMTOKEN attribute, that couldn't be used to
> hold "World Wide Web Consortium" and besides putting human readable
> content in attributes is wrong.
> 
>> I like the way that Lars Marius Garshol put it:
>> "Topic Maps make information findable by giving every concept in the
>> information its own identity and providing multiple redundant navigation
>> paths through the information space. These paths are semantic, and all
>> points on the way are clearly identified with names and types that tell you
>> what they are. This means you always know where you are, which prompted
>> Charles Goldfarb to call topic maps "the GPS of the information universe."
> 
> Sure, that sounds nice, but if we really want topic maps, why aren't
> we using XTM markup?
> 
>> Topic maps also help by making it possible to relate together information
>> that comes from different sources through merging and published subjects."
> 
> Do you have an assembly example that uses that?
> 
>> Perhaps our structure cannot provide all of this, but we also wanted this to
>> be accessible and easy to create. Perhaps our examples should be updated to
>> clearly describe the intent?
> 
> Hmm. So we've built a bridge halfway over the chasm?
> 
>                                         Be seeing you,
>                                           norm


This transmission is intended only for use by the intended
recipient(s). If you are not an intended recipient you should not read, disclose copy, circulate or in any other way use the information contained in this transmission. The information contained in this transmission may be confidential and/or privileged. If you have received this transmission in error, please notify the sender immediately and delete this transmission including any attachments.