of Published Subjects - ISSUES
: The present document is listing issues concerning two reference
Editor: Bernard Vatant
release : May 15, 2002 : Issues have been rewritten using terminology
used in latest version of "PSdoc"
Issues raised after Seattle meeting
0 - Generalisation of Published Subjects scope to "subject-oriented
issue has been settled by April 30 meeting decisions.
-- Keep the scope of reflection strictly to topic map applications in
-- Use the generic word "applications" in the recommendation
wording to let it open to non-topic map applications
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?
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?
Statement of PSD boundaries and structure
issue seems settled by the definition of PSD constituents
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.
Heterogeneous PSD should not be recommended as best practices in the long
In heterogeneous PSD, there does not seem to have any kind of sustainable
answer to ISSUE 2.
Relationships between subjects belonging to the same PSD
is a particular case of Subject Formal Assertions
-- Is the distinction between "core" and "optional"
-- How should those formal assertions be expressed and packaged?
5 - Documentation Metadata
-- What is the list of relevant Documentation Metadata?
-- Which ones should be mandatory? Which ones should be optional?
Should be mandatory the metadata needed for identification of:
-- PSD itself (including all relevant versioning information)
-- Recommended scope/domain of use (see ISSUE 9)
Everything else optional
6 - Documentation Metadata location
-- Where should metadata be stored?
Metadata should be part of Documentation Description
7 - Documentation
-- In what format/syntax should metadata be expressed?
RDF Dublin Core ??
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?
Define specific RDF attributes ??
Need contact with Dublin Core folks to figure this issue correctly
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?
It seems consistent to attach it to the entire PSD, and not to each individual
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.
10 - PSIs "name" "subject" and
-- How is "name" different from "subject" here?
-- What should "subject" provide? a definition? or what?
-- Is not it redundant with below "description"?
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
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?
See above: if the domain of a PSD is consistent, the TNC should apply
to the Subject Indicators Set itself.
Issues raised during and after April 30 conference call
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
13 - Fragment identifiers
Are fragment identifiers recommendable PSIs, given that many current applications
can't retrieve them?
14 - Core vs additional assertions
What assertions belong to the subject definition and what are additional
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
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.
This issue is not addressed in this recommendation, but in Deliverable
2 "Management of Published Subjects".
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?
24: Internal vs External Subject Indicators
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)
25: Infinite Subject Sets
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?
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