OASIS Topic Maps Published Subjects Technical Committee
Pubsubj > Documents > Deliverables > Documentation of Published Subjects

 

OASIS Topic Maps Published Subjects TC Deliverables
1. Documentation of Published Subjects - Requirements and Recommendations

Version 0.5 - Last updated 2002, April 25
First release : March 18, 2002
March 29 : added suggestions in Section 2
April 20 : added links to the ISSUES document
April 25 : added Steve Pepper proposal for Part 5.1: Topic Maps PSI sets

Latest version : http://www.oasis-open.org/committees/tm-pubsubj/docs/recommendations/psdoc.htm
Editor: Bernard Vatant


Status of this document : Draft version, modified after Seattle F2F meeting - March 14
This meeting has raised a certain number of issues, gathered in the issues document.

This recommendation addresses the "shall, should, may" of :
Documentation of Published Subjects - TC Process Requirements


1 - Statement of Purpose

The OASIS Topic Maps Published Subjects Technical Committee has been set forth to help application of Topic Maps specification ISO 13250, by providing recommendations for documentation, management and use of published subjects. The initial motivation is that topic maps interoperability needs non-ambiguous definition of subjects (represented by topics), that should be provided by stable resources, made available on-line through trustable publication process.

 Those resources, organised in published subject documentation "packages", will provide both published subject indicators (human-understandable non-ambiguous definition of subjects) and published subject identifiers (stable URIs fit for computer processing, topic maps interoperability and merging, and many other foreseeable semantic applications).

The purpose of this document is to provide recommendations for the content and structure of published subject documentation. Those recommendations are aimed at publishers of ontologies, classifications, taxonomies, thesaurus, registries, catalogues, data bases ... to provide those publishers with efficient ways to make their legacy available as published subject documentation, and therefore usable by topic maps and other semantic applications.

2 - A gentle introduction to Published Subjects

A main and original feature of topic maps is that they they deal with subjects. A subject can be an unique individual object, like "Isaac Newton", "IBM, Inc.", or "Paris (France)" ... or a class of such individuals, like "famous scientists" "software companies" or "towns" ... or a more abstract concept like "gravitation" "economic growth" or "baroque style" ...
In a nutshell, a subject can be anything deserving to be identified, named, represented and generally talked about - in short, whatever can be a subject of conversation.

  • A subject is anything whatsoever, regardless of whether it exists or has any other specific characteristics, about which anything whatsoever may be asserted by any means whatsoever.

ISSUE 0 - Extension of Recommendation Scope

Suggested complementary definition:
A subject-oriented application is any document, language, software, technology, system ... using abstract representations of subjects as fundamental objects. Topic maps are subject-oriented, but other applications in the Semantic Web universe are or will certainly be subject-oriented.

How do topic maps deal with a subject? First they represent a subject formally as an abstract "topic". In XTM documents, a topic is represented by a <topic> XML element. A topic should represent an unique, well-defined, non-ambiguous subject. So far, so good, at least in the mind of a single topic map author. But topic maps applications dream of inter-operability. That means that topic maps authors, users, and computer applications dealing with them, must have ways to know if two or more topics in the same or different topic maps represent the same subject.

 How can that be achieved? A topic map author can indicate what is the subject of a topic by referring to a document, or any other kind of resource, where the subject appears to be defined in a proper and non-ambiguous way. Such a resource will therefore be considered by the topic map author as a subject indicator. Provided with this resource, an human being will be able, hopefully, to know what subject this topic represents.

In the above, "topic maps" can be replaced by "subject-oriented applications", if "topic" is read in the very general sense of "subject-representation".

  • A subject indicator is a resource that is referred to by a topic map author to provide an unambiguous indication of the identity of a subject to a human being.

Suggested generalization:
A subject indicator is a resource that is referred to, in a subject-oriented application, in order to provide an unambiguous indication of the identity of a subject to a human being.

  • Any resource can become a subject indicator by being referred to as such from within some topic map, whether or not it was intended by its publisher to be a subject indicator.

Suggested generalization:
Any resource can become a subject indicator by being referred to as such by a subject-oriented application, whether or not it was intended by its publisher to be used as a subject indicator.

Since topic maps live in the Web universe, the subject indicator has to be an addressable (network-retrievable) resource. The reference to the subject indicator will therefore use some URI, which will both address the subject indicator and identify the subject. Computers applications will of course be happy to handle this subject identifier, since two topics with the same subject identifier clearly refer to the same subject indicator, and therefore represent the same subject.

  • A subject identifier is an URI that refers to a subject indicator and provides an unambiguous indication of the identity of a subject to a machine (computer process)

Unfortunately, the whole above scenario is too simple to be sustainable. The subject indicators and subject identifiers defined only from the topic map author's end, are likely to be untrustable and unstable. URIs and the resources they address are moving targets in the Web universe. The publishers of resources used as subject indicators might not even be aware of it, and are likely to leave topic maps authors with meaningless identifiers and indicators, if any indicator at all, without previous notice.

Here the publishers enter in the loop. If some publishers are aware of the whole problem, and want to provide topic maps applications with stable, trustable, authoritative subject indicators and identifiers, the situation is far better. The publishers can provide sets of subject indicators and subject identifiers in a stable way, and declare their intention to maintain them stable and trustable for topic maps and other applications. At that point, the topic maps authors are provided with published subjects, defined in published subject documentation, coming along with published subject indicators and published subject identifiers. They will use them as before, but the whole scenario will become really sustainable.

  • A published subject is a subject for which there exists at least one published subject indicator.
  • A published subject indicator is a subject indicator that is published and maintained at an advertised address for the purpose of facilitating topic map interchange and mergeability.

Suggested generalization:
A published subject indicator is a subject indicator that is published and maintained at an advertised address
in order to facilitate interoperability of subject-oriented applications.

  • A published subject identifier is the URI of a published subject indicator, chosen and declared by its publisher as the URI to be used to identify the published subject.
  • A published subject documentation - PS Doc - is a resource containing a structured set of published subject indicators

The topic maps literature has coined the acronym "PSI", also used in XTM 1.0 specification. Note that it can expand both as "published subject indicator" and "published subject identifier". Those are two faces of the concept, one looking at humans (the indicator), and one looking at computers (the identifier).
Like Janus Bifrons over Roman doors, PSIs are warrants of a good communication between two universes ...

3 - Glossary

The following terms and concepts will be used in this document and further TC recommendations. Some of them are already defined and used by ISO 13250. Nevertheless, the TC proposes some modifications to clarify some of them and their relationships with new ones, and will send those proposals to ISO JTC1/SW34 for relevant revision and extension of ISO 13250 terminology. Both current ISO 13250 definition and PubSubj TC proposal are given when necessary.

"Publisher" is used throughout in the sense defined in Dublin Core metadata (dc:publisher)
"Resource" is used throughout in the sense of "network-retrievable resource" (IETF) or "addressable resource" (ISO 13250)

  • subject

    as defined by ISO 13250 XTM
    A subject is anything whatsoever, regardless of whether it exists or has any other specific characteristics, about which anything whatsoever may be asserted by any means whatsoever.
  • subject indicator

    as defined by ISO 13250 XTM
    A resource that is intended by the topic map author to provide a positive, unambiguous indication of the identity of a subject.

    definition proposal
    A resource that is referred to by the topic map author to provide an unambiguous indication of the identity of a subject to a human being. Any resource can become a subject indicator by being referred to as such from within some topic map, whether or not it was intended by its publisher to be a subject indicator.
    See Published Subject Indicator"
  • subject identifier

    definition proposal
    A URI that refers to a subject indicator and provides     an unambiguous indication of the identity of a subject to a machine. When a subject identifier refers to a published subject indicator, it is called a Published Subject Identifier.
  • published subject

    definition proposal
    A subject for which there exists at least one published subject indicator.
  • published subject indicator - PS Indicator

    as defined by ISO 13250 XTM
    A subject indicator that is published and maintained at an advertised address for the purpose of facilitating topic map interchange and mergeability.
  • published subject identifier - PS Identifier
    definition proposal
    The URI of a published subject indicator, chosen and declared by its publisher as the URI to be used to identify the published subject.
  • published subject documentation - PS Doc

    definition proposal
    A resource containing a structured set of published subject indicators

4 - Requirements for PS Doc content

PS Doc contains the following elements

  • PS Doc identification
  • Statement of Publisher's intent
  • Statement of boundaries and structure
  • PS Doc metadata
  • PSIs set

4.1 - PS Doc Identification

The PS Doc shall be identified by an unique and stable URI, through which all the PSIs in the PS Doc, as well as metadata and other kind of relevant information concerning the PS Doc, will be retrievable. This identifier URI will be referred to herafter as the PS Doc Identifier.

ISSUE 1 : PS Doc Identification and auto-referencing

4.2 - Statement of Publisher's intent

A PS Doc shall display in a resource document, retrievable from the PS Doc Identifier, the following formal statement from its publisher, expliciting its intention of conformance to the present recommendation.

This URI "http://psi.organization-foo/bar/" is dedicated by its publisher, "organization-foo"
to be a permanent identifier for a Published Subject Documentation,
in conformance with Requirements and Recommendations of OASIS Topic Maps Subjects Technical Committee:
http://www.oasis-open.org/committees/tm-pubsubj/docs/recommendations/psdoc.htm

4.3 - Statement of boundaries and structure

4.3.1 - Boundaries of the PS Doc
A PS Doc shall provide information defining clearly what PSIs belong to it.

ISSUE 2 : Statement of PS Doc boundaries and structure

4.3.2 - Structure of the PS Doc
A PS Doc shall provide explicit and human-readable declaration of its structure, format and syntax.

  • Syntax used for all PS Identifiers should follow as possible a consistent format throughout the PS Doc.
    Having all PS Identifiers belonging to the PS Doc Identifier is a best practice in the case of creation of an homogeneous PSIs set.

ISSUE 3 : Heterogeneous PS Docs

  • Syntax and structure used for all PS Indicators should be as possible uniform through out the PS Doc and declared explicitly, by reference to some XML DTD, Schema or any other equivalent structure definition.

ISSUE 4 : Relationships between subjects belonging to the same PS Doc

4.4 - PS Doc metadata

A PS Doc shall include the following metadata

ISSUE 5 : PS Doc relevant metadata

ISSUE 6 : PS Doc Metadata location

ISSUE 7 : PS Doc Metadata format

ISSUE 8 : Metadata non available in Dublin Core

  • Name
    The name of the PS Doc
  • Type
    The declaration of the resource as a PS Doc
  • Identifier
    The PS Identifier for the PS Doc
  • Domain
    An indication of the subject area, domain or scope of the PS Doc

ISSUE 9 : Recommended PS Doc scope (domain) of use

  • Publisher
    The entity appearing in the Statement of Intent
  • Language
    The language(s) of the PS Doc
  • Format
    The format(s) or syntax(es) used in the PS Doc
  • Date of original publication
  • Date of latest revision/version
  • Version

It may also include the other - optional - metadata

  • Description
  • Creator
  • Contributor
  • Conditions of use
  • Source
  • Coverage

In complement to those metadata, the PS Doc may include various recommendations for use, list of registered users, or any other relevant information item.

4.5 - PSIs Set

4.5.1 - Every PS Indicator in a PS Doc shall be identified by, and retrievable through an unique URI.
This URI is used to identify the subject indicated by the PS Indicator.

4.5.2 - A PS Indicator shall include the following metadata:

  • Identifier
    The URI that shall be used as the PS Identifier.
  • Language
    Language in which subject, type, and description are expressed - if different of the default PS Doc language.
  • Name
    A name given to the subject that is identified by the PS Identifier.
  • Subject
    The subject identified by the subject identifier

ISSUE 10 : PSIs "name", "subject" and "description"

ISSUE 11 : Topic Naming Constraint

  • Type
    A class of which the subject is an instance. This class should be defined itself by a PSI.
  • Description
    Text, image or any kind of relevant resource, describing the subject in a non-ambiguous, human-understandable way.

4.6 Use of Dublin Core metadata

It is recommended that the metadata used both for PS Doc and PSIs should be expressed as far as possible using the Dublin Core elements.

The following table proposes equivalence between some above recommended metadata and Dublin Core elements, both for PS Doc and PS Indicator metadata.

Dublin Core element
PS Doc metadata
PS Indicator metadata
dc:identifier
PS Doc Identifier - URI
PS Identifier - URI
dc:title
Name
Name
dc:subject
Subject
(auto-reference?)
Subject
dc:type
Type
(required value = "PS Doc")
Type
(subject type)
dc:description
Description
Description
dc:publisher
Publisher
-
dc:language
Language
Language
dc:format
Format
-
-
Date of publication
Date of publication
dc:date
Date of revision
Date of revision
-
Domain
Domain (?)
dc:source
Source
-

5 - Recommended Syntaxes, and examples of PS Doc

Considering the considerable legacy of taxonomies, classifications, ontologies, data bases and catalogues likely to be made available as PS Docs, their publishers should not be constrained to use any specific structure or syntax.

Therefore, the present recommendation will not enforce upon publishers either an unique standard structure for PS Docs, or a specific syntax for PSIs. Nevertheless, it will recommend best practices for a certain number of existing relevant syntaxes, listed below. This list does not pretend to be exhaustive, and does not preclude any other present or future format and structure that would fit the requirements expressed in section 4.

5.1 Recommendations for publishing PSI sets as topic maps

[This section is a Steve Pepper proposal]

This section describes recommendations for publishers who wish to use topic maps for the purpose of publishing PSI sets. The principle advantage of expressing PSI sets as topic maps is that the PSI sets thereby become available in a machine processable form with clearly defined semantics and can be used directly by topic map-aware applications, including taking advantage of the topic map merging facility and being accessed via a standard topic map query language. Publishers are free to express subject indicators in any form that can be rendered for interpretation by humans, including topic maps that do not follow these recommendations. However, by following these recommendations, publishers that wish to use topic maps will achieve greater interoperability with other topic map-based PSI sets and applications that are designed to derive the maximum potential from them.

5.1.1 The PSI set topic map

Each PSI set should be represented by a single topic map, called the PSI set topic map, and each PSI set topic map should contain a single PSI set. The PSI set topic map should have a canonical identifier in the form of a URL that resolves to the resource containing the topic map.

NOTE: The examples in this section assume that the PSI set topic map has the following canonical location: http://psi.mydomain.com/my-psi-set.xtm [ISSUE: Could xml:base be used to establish this the canonical identifier, or should we use an occurrence on the TM topic?]

The PSI set topic map should consist primarily of topics that are intended to be used as published subject indicators and associations that express metadata properties of those PSIs. It may also contain additional topics that are not intended by the publisher to be used as published subject indicators.

5.1.2 The topic map topic

The topic map should also contain a topic that reifies the topic map itself.
This topic, called the "topic map topic" (TM topic), is the nexus for metadata about the PSI set and should be an instance of the class http://psi.topicmaps.org/pubsubj/pubsubj.psi#psiset

EXAMPLE:

<?xml version="1.0" encoding="iso-8859-1"?>
<topicMap
xmlns="http://www.topicmaps.org/xtm/1.0/"
xmlns:xlink="http://www.w3.org/1999/xlink"
id="my-psi-set" >
<topic id="my-psi-set-topic">
<instanceOf>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#psiset"/>
</instanceOf>
<subjectIdentity>
<subjectIndicatorRef xlink:href="#my-psi-set"/>
</subjectIdentity>
<!-- names and occurrences -->
</topic>
...
</topicMap>

The TM topic should have at least one name and one description, and may also have other metadata as deemed appropriate by the publisher.

5.1.3 Published subject indicator topics

Each published subject indicator in the PSI set should be a topic whose subject is the subject that it serves to indicate. For example, the topic whose subject is "publisher" would serve as the subject indicator for that subject. A topic that serves as a published subject indicator is called a PSI topic. PSI topics should have at least one name and one description.

5.1.4 Metadata

Metadata about the PSI set and individual subject indicators should be expressed as topic characteristics of the TM topic and the PSI topics respectively. These recommendations define certain published subjects for this purpose, but publishers are free to create and use additional PSIs as required for expressing other metadata properties. Metadata properties should be expressed using subject identity, names, occurrences, or associations as described below. No topic should have more than one name in a given scope or more than one occurrence of a given type in a given scope.

5.1.4.1 Subject identity

Subject identity should be used to indicate the published subject indicator of a PSI topic via a subject indicator reference that references the topic itself.

EXAMPLE:

<topic id="my-psi">
 <subjectIdentity>
<subjectIndicatorRef xlink:href="http://psi.mydomain.com/my-psi-set.xtm#my-psi"/>
</subjectIdentity>
...
</topic>

Topics that are intended by the publisher to be used as subject indicators may be distinguished from other topics in the topic map by the fact that they have self-referential subject identity. [This property corresponds to dc:identifier] [ISSUE: What about the TM topic? Does it need an identifier? Is this the way we establish the canonical URI of the PSI set?]

5.1.4.2 Base names

Base names should be used to indicate the title(s) of the PSI set represented by the TM topic and the name(s) of the subjects indicated by the PSI topics. If no language property is specified for the PSI set, the TM topic and PSI topics should have exactly one base name in the unconstrained scope and may have additional base names in other scopes. If the language property of the PSI set specifies a single language, the TM topic and PSI topics should have either exactly one base name in the unconstrained scope or exactly one base name in the scope of the PSI set language, and may have additional base names in other scopes. If the language property of the PSI set specifies multiple languages, the PSI topics should have exactly one base name for each language, in the scope of that language, and may have additional base names in other scopes.

EXAMPLE 1
No language property specified for PSI set, or name of subject is not language dependent.
One base name in the unconstrained scope.

<topic id="my-subject">
<baseName>
<baseNameString>My subject</baseNameString>
</baseName>
...
</topic>

EXAMPLE 2:
Subject has different names in different languages (here: English and Norwegian)
One base name per language in the scope of that language.

<topic id="my-subject">
<baseName>
<scope>
<subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>
</scope>
<baseNameString>My subject</baseNameString>
</baseName>
<baseName>
<scope>
<subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#no"/>
</scope>
<baseNameString>Mitt tema</baseNameString>
</baseName>
...
</topic>

[This property corresponds to dc:title]

5.1.4.3 Occurrences

Occurrences should be used to express description properties of the PSI set and the subject indicators, and may also be used to express date properties of the PSI set, as follows:

5.1.4.3.1 Description occurrences

Occurrences of type
 http://psi.topicmaps.org/pubsubj/pubsubj.psi#description
on the PSI topics should be used to provide descriptions of the subjects indicated by the PSI topics, and may also be used on the TM topic to provide descriptions of the PSI set. Such occurrences may be internal or external.

If no language property is specified for the PSI set, the PSI topics should have exactly one description occurrence in the unconstrained scope and may have additional such occurrences in other scopes.

If the language property of the PSI set specifies a single language, the PSI topics should have either exactly one description occurrence in the unconstrained scope or exactly one description occurrence in the scope of the PSI set language, and may have additional description occurrences in other scopes.

If the language property of the PSI set specifies multiple languages, the PSI topics should have exactly one description occurrence for each language, in the scope of that language, and may have additional description occurrences in other scopes.

EXAMPLE 1
Language property of PSI set unspecified or specified as being a single language.
One description occurrence in the unconstrained scope.

<topic id="my-subject">
...
<occurrence>
<resourceData>Description of my subject.</resourceData>
</occurrence>
</topic>

EXAMPLE 2
Language property of PSI set specified as being multiple languages (here: English and Norwegian)
One description occurrence per language in the scope of that language.

<topic id="my-subject">
...
<occurrence>
<instanceOf>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#description"/>
</instanceOf>
<scope>
<subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>
</scope>
<resourceData>Description of my subject.</resourceData>
</occurrence>
<occurrence>
<instanceOf>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#description"/>
</instanceOf>
<scope>
<subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#no"/>
</scope>
<resourceData>Beskrivelse av mitt tema.</resourceData>
</occurrence>
</topic>

[This property corresponds to dc:description]

5.1.4.3.2 Date occurrences

Occurrences of type http://psi.topicmaps.org/pubsubj/pubsubj.psi#date on the TM topic may be used to indicate the date of the current version of the PSI set. Scope may be used to indicate the notation used to express the date.

EXAMPLE:

<topic id="my-psi-set-topic">
...
<occurrence>
<instanceOf>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#date"/>
</instanceOf>
<resourceData>2003-03-18</resourceData>
</occurrence>
</topic>

[This property corresponds to dc:date]

5.1.4.4 Associations

Associations should be used to specify the language property of the PSI set, and may be used to specify the publisher and creator properties of the PSI set, as follows:

5.1.4.4.1 Language

Associations of type
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#languageOfPublication
between the TM topic and one or more language topics may be used to indicate the language of the PSI set.

The TM topic should play the role
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publication

and the language topic(s) should play the role
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#language

The implication of declaring a PSI set to be in one or more language(s) is that the TM topic and the PSI topics either have a base name in the unconstrained scope, or a base name in each of the languages specified, or both; and that the TM topic and the PSI topics, to the extent that they have description occurrences, have one description occurrence in each of the languages specified.

EXAMPLE:
This association declares the PSI set to be in both English and Norwegian. (Note that two associations, one for each language, could have been used equivalently to the single association used here.)

<association>
<instanceOf>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#languageOfPublication"/>
</instanceOf>
<member>
<roleSpec>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#publication"/>
</roleSpec>
<topicRef xlink:href="#my-psi-set-topic"/>
</member>
<member>
<roleSpec>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#language"/>
</roleSpec>
<subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>
<subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#no"/>
</member>
</association>

[This property corresponds to dc:language]

5.1.4.4.2 Publisher

Associations of type
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publishedBy
between the TM topic and some other topic may be used to indicate the publisher of the PSI set.

The TM topic should play the role
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publication

and the other topic should play the role
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publisher

EXAMPLE:

<association>
<instanceOf>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#publishedBy"/>
</instanceOf>
<member>
<roleSpec>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#publisher"/>
</roleSpec>
<subjectIndicatorRef xlink:href="http://psi.mydomain.com/my-psi-set.xtm#myEmployer"/>
</member>
<member>
<roleSpec>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#publication"/>
</roleSpec>
<topicRef xlink:href="#my-psi-set-topic"/>
</member>
</association>

[This property corresponds to dc:publisher]

5.1.4.4.3 Creator

Associations of type
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#createdBy
between the TM topic and some other topic may be used to indicate the creator of the PSI set.

The TM topic should play the role
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publication

and the other topic should play the role
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#creator

EXAMPLE:

<association>
<instanceOf>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#createdBy"/>
</instanceOf>
<member>
<roleSpec>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#creator"/>
</roleSpec>
<subjectIndicatorRef xlink:href="http://psi.mydomain.com/my-psi-set.xtm#me"/>
</member>
<member>
<roleSpec>
<subjectIndicatorRef xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.psi#publication"/>
</roleSpec>
<topicRef xlink:href="#my-psi-set-topic"/>
</member>
</association>

[This property corresponds to dc:creator]

5.1.5 Human interpretable renditions

Publishers who use topic maps to declare published subject indicators may additionally make renditions of those topic maps available in some other format (e.g., XHTML or plain text) in order to guarantee increased interpretability for humans using applications that are not topic map enabled. ...

5.1.6 Other issues

[TBD]

  • type
  • other assertions
  • magic string
  • URL syntax (psi as a component?)
  • is the subject of a PSI topic the PS or the PSI itself?
  • relationship to Dublin Core (should we use URIs like http://purl.org/dc/elements/1.1/publisher
    instead of http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publisher where appropriate?)

[ISSUE: Is this whole self-reference thing too convoluted? An alternative might be to use an occurrence of type "identifier" to specify the published subject identifier. But should we then duplicate this to establish the subject identity of the topic? If we want these topic maps to be usefully mergeable, we have to. But again, it's messy. Perhaps Bernard is right that we shouldn't express psi sets as topic maps at all... If we leave the format completely open, we can always create topic maps that have a topic for each subject in any psi set and thereby achieve the same goal. This also removes the problem that we feel obliged to suggest a more easily human interpretable rendition in addition to the topic map...]

Other Draft Proposals submitted to TC

5.2 - Recommendations for PS Doc using RDF

To be delivered

5.3 - Recommendations for PS Doc using XHTML

To be delivered