SAM: Proposed issue resolutions

Authors: Graham D. Moore, empolis UK
Lars Marius Garshol, Ontopia
Published: 2003-02-14
Revision: $Revision: 1.3 $

This document sets forth the authors' proposed resolutions to all currently open issues in the Standard Application Model, together with the rationale for those resolutions. Interested parties are requested to offer their comments on these.

prop-subj-address-values

We propose that the constraint that a topic may only have a single [subject address] be lifted, so that the property [subject address] is replaced by [subject addresses], which is a set property.

The rationale is as follows:

See also the IRC discussion.

constr-single-subject-address

Since it was decided above to allow the [subject addresses] property to hold more than one value this constraint is now gone, and so this whole issue no longer applies.

locator-notation-support

We propose that SAM implementations should not be required to support any particular locator notation, since what interchange syntaxes an implementation supports will in any case determine what locator notations it must support.

As for what locator notations should be defined in the SAM we suggest that only those needed by an official interchange syntax should be added. More can be added as need arises.

See also the IRC discussion.

names-as-subjects

We are of the opinion that this issue is not important, and that it can be closed without further discussion.

See also the IRC discussion.

prop-subj-address-class

A general decision was made to not follow the implicit constraints in the XTM DTD (see xtm-implicit-constraints), and so we propose to allow this. The same applies to prop-subj-address-scope.

See also the IRC discussion.

prop-value

We propose the name [value] be retained, on the grounds that the string is the value of the base name, but the label of the topic. As this is a property of the base name rather than the topic, [value] seems more logical than [label].

See also the IRC discussion.

prop-variant-scope-superset

Our position is that the model used by XTM improves on that of HyTM, and that the HyTM->SAM deserialization specification should be constructed in such a way as to handle this.

See also the IRC discussion.

psi-set-psi

The URI of the page that holds the SAM PSIs will also serve as the published subject identifier for all the PSIs defined by the SAM. There will also be URIs for identifying each version.

See also the IRC discussion.

psi-subclassing-loops

We propose that superclass/subclass association loops should be allowed, with the following rationale:

See also the IRC discussion.

psi-type-instance-scope

In our opinion the clarification of the scope rules make the semantics of applying scope to this relationshop clear, but even so we think the following example should be added to the specification in a note to make it clear to readers how to interpret this.

type-instace(a : instance, b : type) / Y X
super-sub(b : sub, c : super) / Y Z

See also the IRC discussion, which did not finish the first time, and so was continued later.

reification-effects

We propose that even if a topic reifies a topic map construct there should be no restrictions on what classes it may be an instance of, since:

However, we do propose that a set of published subjects for the topic map constructs that can be reified should be defined, so that those who wish to do so may use them.

See also the IRC discussion.

scope-extension

The editors think the original SAM conformance section is sufficient.

See also the IRC discussion.

term-scope-def

We propose that the SAM should take the "scope is comprised of all subjects" view and state this clearly. The rationale is as follows:

We note that to make it easier to repeat topic characteristics in different scopes we may want to make the scope element repeatable in XTM.

scope-unconstrained-rep

Since we have proposed to make scope 'all subjects' the unconstrained scope must necessarily be represented as the empty set. (See SC34 N0327 for the rationale.)

strings-as-subjects

We consider that the model already contains the mechanisms necessary to achieve this, as using a data URL in the [subject addresses] property will effectively create a topic that represents the string the URL resolves to.

See also the IRC discussion.

psi-identification

We consider that this issue is out of scope for the SAM, but properly belongs in the Recommendations for Published Subjects to be published by the OASIS PubSubj TC.

subject-identity-establish

We have added the following text to the last paragraph of section 3.4, which we believe makes the SAM equivalent with ISO 13250:2000 in this respect.

Applications and users are therefore free to merge topics as they see fit. Most commonly this will be done by inferring the subject of the topics from their characteristics.

term-subject-indicator-def

We consider that to put a locator which refers to a subject that is not an information resource in the [subject addresses] property of a topic item is problematic. If we want to be able to infer that the subject of a topic is an information resource whenever the [subject addresses] property is non-empty this must be avoided. Clearly, it cannot be disallowed, however.

Therefore we propose to add a note stating that locators referring directly to subjects which are not information resources should be placed in the [subject identifiers] property. We can then also add text stating that a topic item whose [subject addresses] property is non-empty can be assumed to represent an information resource.

merge-srcloc-vs-subjid

This issue was formally resolved at the Baltimore meeting, but has since been reopened in the light of later experience. We propose to resolve this issue by removing the restriction that the same locator may not appear in both the [source locators] and [subject identifiers] properties of a topic item.

The rationale is that this preserves the information originally in the source document, that it avoids confusing applications by removing locators they may depend on, and also that it does not cause any difficulties or ambiguities for implementation to have the same locator appear in both properties.

See also the IRC discussion.

occurrence-variants

We feel that while we have sympathy for this proposal it is too much of a change for this version of the standard and the XTM syntax. We also feel that this change on its own would in any case be insufficient if it were to be motivated on the grounds of symmetry between the three kinds of topic characteristics.