[sc34wg3] Representing ordered sets in Topic Maps

[Geir Ove Grønmo]

* dmitryv@cogeco.ca
| I would like to suggest topic for discussion: representing ordered sets
| using Topic Maps.
|
| For example, it is easy to represent information that a person is an
| author
| of some book. It is easy to represent information that some people are
| coauthors of some book.
|
| But I am not aware of standard easy way to represent information that
| coauthors should follow specific order.
|
| I saw several approaches to this problem:
| - rely on order of members in XTM document (well, simple but
| ... invalid)

Unfortunately that information would get lost once a conforming topic
map processor read the XTM document.

| - introduce set of roles such as 'author_1', 'author_2' etc.

This is similar to how RDF attempts to solve the challenge.

| - introduce additional role 'position' in 'coauthor' association with
| values such as http://<some location>/numbers#1, http://<some
| location>/numbers#2

Are the roles in this example referencing subjects that are numbers?

| - introduce explicit topics for groups, create types of ordered groups
| and association "ordered member"

How could one specify the order in this example?

| - implement 'list' data structure using set of topics and associations
| (head,tail roles)

Ooo. Lisp-style. :)

| I think it is important to define "standard" way to represent ordered
| sets in XTM/TMDM and probably TMQL/TMCL require some specific operations to
| work with ordered sets.

Yes, it would be nice one would agree upon a common pattern for
specifying order.

An observation that I've done is that the ordering of topics are
_always_ context dependent. There are lots of ways to order the
authors of a book:

  - the prominence of an author

  - by their birthdates

  - by their full names

  - by their telephone numbers

etc.

Here's another proposal: Use sort keys.

An example:

1. Create an association:

<association id="the-book-authorship">
  <instanceOf><topicRef xlink:href="#author-of"/></instanceOf>
  <member>
    <roleSpec><topicRef xlink:href="#book"/></roleSpec>
    <topicRef xlink:href="#the-book"/>
  </member>
  <member>
    <roleSpec><topicRef xlink:href="#author"/></roleSpec>
    <topicRef xlink:href="#author-b"/>
  </member>
  <member>
    <roleSpec><topicRef xlink:href="#author"/></roleSpec>
    <topicRef xlink:href="#author-a"/>
  </member>
  <member>
    <roleSpec><topicRef xlink:href="#author"/></roleSpec>
    <topicRef xlink:href="#author-c"/>
  </member>
</association>

2. Reify the association

<topic id="reified-the-book-authorship">
  <subjectIdentity>
    <subjectIndicatorRef xlink:href="#the-book-authorship"/>
  </subjectIdentity>
</topic>

3. Assign sort keys to the authors

<topic id="author-a">
  <occurrence>
    <instanceOf>
      <subjectIndicatorRef
  xlink:href="http://psi.example.com/#sortkey"/>
    </instanceOf>
    <scope><topicRef xlink:href="#reified-the-book-authorship"/></scope>
    <resourceData>1</resourceData>
  </occurrence>
</topic>


<topic id="author-b">
  <occurrence>
    <instanceOf>
      <subjectIndicatorRef
  xlink:href="http://psi.example.com/#sortkey"/>
    </instanceOf>
    <scope><topicRef xlink:href="#reified-the-book-authorship"/></scope>
    <resourceData>2</resourceData>
  </occurrence>
</topic>

<topic id="author-c">
  <occurrence>
    <instanceOf>
      <subjectIndicatorRef
  xlink:href="http://psi.example.com/#sortkey"/>
    </instanceOf>
    <scope><topicRef xlink:href="#reified-the-book-authorship"/></scope>
    <resourceData>3</resourceData>
  </occurrence>
</topic>

4. Done. We've now specified the order of the authors in one
particular context.

The only machinery that is needed is the "sortkey" PSI. The sort keys
used need not be strings, but could be of arbitrary types are long as
the topic map application were able to order them, i.e. as long as the
application recognizes the ordering semantics. 

New sort key types could be introduced by subclassing the
PSI. Ordering semantics would then be defined by the derived subjects.

Ideally we should have subclassed the "sortkey" PSI above as
"sortkey-coauthorship" or something like that, so that we could
describe the ordering semantics explicitly.

If a topic played more that a single role in an association then the
role type should be added to the scope in order to disambiguate the
applicability of the sort key.

Cheers,
Geir O.