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
|