OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook-tc] Associations in an assembly

The original intent/design of the relationships structure was modeled after
Topic Maps:

A topic map represents information using
* topics, representing any concept, from people, countries, and
organizations to software modules, individual files, and events,
* associations, representing hypergraph
<http://en.wikipedia.org/wiki/Hypergraph>  relationships between topics, and
* occurrences representing information resources relevant to a particular

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">
      <topicRef xlink:href="#standards-body"/>
      <baseNameString>World Wide Web Consortium</baseNameString>
        <topicRef xlink:href="#homepage"/>
      <resourceRef xlink:href="http://www.w3.org"/>

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?

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

Topic maps also help by making it possible to relate together information
that comes from different sources through merging and published subjects."

That's really the intent behind the design of relationships, is to provide a
semantic path through the content of the map. It's about providing more
functionality than the TOC can provide. It's a way of creating an ontology
about the content. I think this doc provides a good description of the
design intent: 
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?



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

>     <relationship linkend="xidi.help.system" type="path">
>       <!-- 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. -->
>       <association>New User Introduction</association>
>       <instance linkend="help.xidi.overview"/>
>       <instance linkend="help.svn.overview"/>
>       <instance linkend="help.ex.new.help.sys"/>
>     </relationship>
> To my eyes, the association looks like a title. Would it not be reasonable
> to give relationship an info with a required title instead?
>                                         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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]