Documentation of Published Subjects - ISSUES

Status : The present document is listing issues concerning two reference documents:

"PSdoc 0.5"
http://www.oasis-open.org/committees/tm-pubsubj/docs/recommendations/psdoc_05.htm

"PSdoc"
http://www.oasis-open.org/committees/tm-pubsubj/docs/recommendations/psdoc.htm

Editor: Bernard Vatant
Last release : May 15, 2002 : Issues have been rewritten using terminology used in latest version of "PSdoc"

1. Issues raised after Seattle meeting
http://www.oasis-open.org/committees/tm-pubsubj/docs/recommendations/psdoc_05.htm

ISSUE 0 - Generalisation of Published Subjects scope to "subject-oriented applications" ?

This issue has been settled by April 30 meeting decisions.

-- Keep the scope of reflection strictly to topic map applications in first deliverable
-- Use the generic word "applications" in the recommendation wording to let it open to non-topic map applications

ISSUE 1 - PSD and PSD Constituents Identification

1.a - How is PSD identified? Do we recommend PSD to be identified by a PSI?
1.b - If so, what should be the Subject Indicator and Subject Identifier?

Proposal: Use the Documentation Description as a Subject Indicator for the PSD.

1.c - More generally, what are the PSD constituents that need to be identified by a PSI?

ISSUE 2 - Statement of PSD boundaries and structure

This issue seems settled by the definition of PSD constituents

ISSUE 3 - Heterogeneous PSD

-- In the case PSD is built through aggregation of various sources, the original source URIs may be wanted to be used as PS Identifiers. In that case, the homogeneity requirement on PSIs structure does not hold.

Proposal:
Heterogeneous PSD should not be recommended as best practices in the long run.
In heterogeneous PSD, there does not seem to have any kind of sustainable answer to ISSUE 2.

ISSUE 4 - Relationships between subjects belonging to the same PSD

This is a particular case of Subject Formal Assertions

-- Is the distinction between "core" and "optional" assertions relevant?
-- How should those formal assertions be expressed and packaged?

ISSUE 5 - Documentation Metadata

-- What is the list of relevant Documentation Metadata?
-- Which ones should be mandatory? Which ones should be optional?

Proposal:
Should be mandatory the metadata needed for identification of:
-- PSD itself (including all relevant versioning information)
-- Publisher
-- Recommended scope/domain of use (see ISSUE 9)

Everything else optional

ISSUE 6 - Documentation Metadata location

-- Where should metadata be stored?

Proposal:
Metadata should be part of Documentation Description

ISSUE 7 - Documentation Metadata format

-- In what format/syntax should metadata be expressed?

Proposal:
RDF Dublin Core ??

ISSUE 8 - Metadata non available in Dublin Core

-- Section 4.6 gives an equivalent of most needed metadata in Dublin Core.
-- But some of them seem to have no Dublin Core equivalent. How should those last ones be declared?

Proposal:
Define specific RDF attributes ??
Need contact with Dublin Core folks to figure this issue correctly

ISSUE 9 - Recommended PSD scope (domain) of use

-- Is "domain" metadata the best way to define scope of recommended use, and intended audience?
-- Is it the same for all the Subject Indicators Set, or can it be refined at each PS Indicator level?

Proposal:
It seems consistent to attach it to the entire PSD, and not to each individual PSI.
Useful PSD should have some "ontological consistency" and should not be bags of motley subjects.
The domain/scope should be defined itself by a PSI.

Remark: No available Dublin Core element for that.

ISSUE 10 - PSIs "name" "subject" and "description"

-- How is "name" different from "subject" here?
-- What should "subject" provide? a definition? or what?
-- Is not it redundant with below "description"?

Proposal:
In a strict topic map view
"name" should be used as baseName in the scope defined by "domain". And the TNC should apply there (see ISSUE 11)
"subject" ... may provide a variant name ??
"description" is a full descriptive resource (text, image) - clearly a specific occurrence type

ISSUE 11 - Topic Naming Constraint

-- The "name" metadata is likely to be used as base name by topic maps authors.
-- What are the consequences in terms of Topic Naming Constraint?

Proposal:
See above: if the domain of a PSD is consistent, the TNC should apply to the Subject Indicators Set itself.

2. Issues raised during and after April 30 conference call

ISSUE 12 - Multimedia subject indicators

-- The current reflection has focused on subject indicators being documents or text-like resources.
-- Should the recommendation address also the eventuality of multimedia subject indicators?

open issue

ISSUE 13 - Fragment identifiers

-- Are fragment identifiers recommendable PSIs, given that many current applications can't retrieve them?

open issue

ISSUE 14 - Core vs additional assertions

-- What assertions belong to the subject definition and what are additional (optional) assertions?

open issue

ISSUE 21 - Glossary

-- There was a glossary in previous versions, that seems redundant with the gentle introduction of terminology.
-- New concepts are introduced in section 3.
-- It might be useful to have a complete glossary at the end of the document

ISSUE 22 - Subject equivalence

-- Different PSD might have identical or overlapping Subjects Sets, and should be able to declare that some subjects they deal with are identical or equivalent.

Proposal :
This issue is not addressed in this recommendation, but in Deliverable 2 "Management of Published Subjects".

ISSUE 23: Self-Referencing Subject Indicators

The Subjects Set and the Subject Indicators Set are not necessarily separated, if Subject Indicators are allowed to be self-referencing. Is such a practice to be recommended (in specific cases), allowed, or advised against?

ISSUE 24: Internal vs External Subject Indicators

The Subject Indicators can be "internal" to the PSD (meaning e.g. Subject Indicators are created and maintained by the same publisher under an unique namespace) or "external" (meaning e.g. the PSD aggregates references to Subject Indicators belonging to various sources)

ISSUE 25: Infinite Subject Sets

In the case of infinite subject sets (e.g time and space), is it possible to allow both subject indicators and identifiers to be dynamically created on application's request, and not be static documents?

ISSUE 26: Consistency of Subject Indicators with Subject Formal Assertions

"The information expressed in Subject Formal Assertions belongs to the subject definition" means that this information must have a matching human-readable expression in the Subject Indicator. It is the publisher responsibility to make those formal assertions consistent with the Subject Indicator content.