Background and Questions
Updated : November 4, 2001

Status of this document : The content of this page is only informative and should not be used or referred to otherwise.
Please send any comments to Bernard Vatant

1. Background

From libraries indexes to ISBN, and from local files identities to URLs and URIs ... many specifications and standards have tackled the question of resources identification, resources description and metadata.

• Identifiers and Their Role In Networked Information Applications - An introduction to the question (1997)
• URIs, URLs, and URNs: Clarifications and Recommendations 1.0 - W3C Note (September 2001)
• Dublin Core Metadata Initiative (DCMI)
• Resource Description Framework (RDF)
• Publishing Requirements for Industry Standard Metadata (PRISM)
• Digital Object Identifier (DOI)
• Universal Description, Discovery, and Integration (UDDI)
  
  ... non-exhaustive list!

But, essential as they are for interoperability of systems and applications, all those standards for resource identification and description are not sufficient to ensure full semantic interoperability in networked environments where both humans and systems are interacting and exchanging information, because they don't deal with identification of subjects independently of resources that document them.
Above quoted W3C note includes among additional URI issues " ...the use of URIs as identifiers that don't actually identify network resources ...". The independence of subjects and resources is explicitly tackled by Topic Maps specification, but efficient full development of the technology needs somehow standard subject identifiers.

Unfortunately, different terms have been used to refer to it. ISO 13250 speaks about "Public Subjects" whereas XTM 1.0 is using "Published Subject Indicators". Moreover, the resulting acronym PSI has been used in various misleading ways, as e.g. "Public Subject Identifiers" or any other mix-up of the two vocabularies. This subtle shift from "indicator" to "identifier" may have more consequences that it seems ... It raises the tricky question to know if a PSI should be only a formal address used as an abstract identifier for topic maps engines or intelligent agents (the same way a namespace may be), or needs some explicit readable content available at this address to disambiguate the subject for human users. And in fact this question is still pending, and did not help much to understand and use efficiently this already arcane concept. No wonder that no public (or published) full-scale use of PSI has been developed so far ...

One mission - the central one indeed - of OASIS Topic Maps Published Subjects Technical Committee seems to move forward beyond this essential question, not through conceptual debate but through technical solutions allowing effective development and use of PSIs through recommended methodology and practices. In a nutshell, move from the ontological approach (what they should be) down to a more pragmatic one (how to use them)

2. How to ... ?

... from Topic Maps TC viewpoint ...

Q1 ... Publish and advertize an efficient set of recommendations for publishers and users

• Define relevant publishing authority and namespace for recommendations and registry.
  e.g. oasis-open.org/pubsubj/ or topicmaps.org/pubsubj/ or specific domain like pubsubj.org/
• Define standard syntax for PSI, consistent with other existing or proposed syntax for public identifiers
  see among others a recent proposition: URN Namespace for Public Identifiers
• Define standard content and structure for PSIs and PSIs sets.
  Do we need a DTD? see propositions at:
  http://www.oasis-open.org/committees/tm-pubsubj/docs/bvt/pubsubj-dtd.txt
  http://www.oasis-open.org/committees/tm-pubsubj/docs/bvt/dc/
• Push the recommendations towards organizations maintaining vocabularies, libraries, directories, taxonomies
  Establish a list of relevant organizations and repositories for that matter

Q2 ... "Eat our dog food" by publishing and maintaining a set of core generic PSIs

• Define core generic PSI set - generic topic, association and role types, countries, languages
• Make it consistent with standard or widely-used general vocabularies, classifications and ontologies

Q3 ... Make the recommendations consistent with, and helpful to, other "semantic standards"

• Set PSIs for XML and other standards terminology (specific TC)
• Help standard organizations to publish their PSI sets in a conformant way (inside or outside OASIS)

Q4 ... Help the PSI publishers to gain visibility in relevant Knowledge Communities

• Validate, approve, recommend conformant PSI sets
• Registry of use-cases and PSI sets (or PSI namespaces)

Q5 ... Declare equivalence rules for PSIs or PSI sets

• Allow one PSI set to refer to whole or part of other existing sets

... from Publisher viewpoint ...

Q6 ... Declare that a resource (or set of resources) is published to be used as a PSI (or PSI set)

• Conform and formally refer to pubsubj recommendations
• Register PSI sets in pubsubj central registry

Q7 ... Use a legacy (ontology, vocabulary, database) to define a PSI set

• Apply transformation rules (from classes to topics, relationships to associations ...)
  

Q8 ... Publish a PSI set in a standard interoperable form

• Apply standard syntax for PSI URIs
• Conform content to recommended standard

Q9 ... Recommend a scope of usage - relevant Knowledge Communities - for a PSI set

Q10 ... Give visibility, and validate the use of a PSI set by relevant Knowledge Communities

Q11 ... Manage and update a PSI set

... from User viewpoint ...

Q12 ... Find relevant existing PSI sets

Q13 ... Use a PSI set as an efficient tool for a Knowledge Community

Q14 ... Make its use case back-referenced by PSIs publisher organization(s)